[OGSA-AUTHZ] Next Telecon

[Tom Scavo]

On 10/31/06, David Chadwick <d.w.chadwick at kent.ac.uk> wrote:
> Tom Scavo wrote:
> > On 10/31/06, David Chadwick <d.w.chadwick at kent.ac.uk> wrote:
> >
> > As far as I can tell, there really are only two models,
> > represented by Figures 1 and 2.  Figures 3 and 4 don't really add
> > anything new to the model.
>
> Well they show the difference between the push and pull modes of
> operation.

Without loss of generality, push and pull can be illustrated on one
set of diagrams.  Indeed, Figures 1 and 2 do just that.

> This is actually quite a big difference in terms of
> usability, client complexity, privacy, etc.

But that seems mostly irrelevant to the primary purpose of the document.

> > I think the PEP needs to (optionally) provide the following additional
> > data to the context handler (who in turn passes it on to the CVS):
> >
> > - the unique identifier (entityID) of the Identity Provider that exposes
> > the AA
>
> Now why would that be important?

The entityID is the key to the SAML metadata file.

> More important than the IDP ID is surely the AA contact details,
> especially for the pull model (unless you are equating the two as being
> the same thing?).

A complete metadata description of the AA will be found in metadata.
Admittedly, the location endpoint of the AA is important, but it is
not the only piece of metadata of interest.

> We have included the latter in the existing SAML1.1
> profile, as a URL, and can add it to the current spec as well.

What "existing SAML1.1 profile" are you referring to?

> > - the SAML Subject to use as a query subject
>
> this is conceptually the authenticated name in the diagrams.

Is the "authenticated name" referred to in the diagram the DN from the
certificate?  If so, this *could* be used as the NameIdentifier in the
query, but more generally, the issuer of the certificate may want to
provide an alternate SAML Subject.  In particular, the Format of this
Subject may be something other than X509SubjectName.

> It can be
> encoded as a SAML Subject if you wish. This is just detail.

No, not quite.  If the Grid SP needs to query, it should first look in
Subject Alt Name for a SAML Subject.  If it doesn't find one, it
should fall back on X509SubjectName.

> > These quantities might be bound to the certificate used to
> > authenticate to the PEP, in the SIA extension
>
> Conceptually SIA is probably the right field to insert details of where
> to get subject attributes from.

Exactly.  The IdP entityID should go in the SIA extension.

> >> In XACML, an attribute is currently defined as an attribute ID, a data
> >> type and a value. The contents of all 3 are transparent to the protocol
> >> and are carried as XML strings. So essentially they can contain
> >> anything. When we package a credential as an attribute, we simply define
> >> a new attribute ID and data type to represent the credential and the
> >> value is then the string encoding of the credential.
> >
> > Does the "SAML 2.0 profile of XACML v2.0" apply?
>
> Yes, this is what I already use in the draft profiles published earlier
> this year

Then why do we need a new profile?  Can't we just use the "SAML 2.0
profile of XACML v2.0"?

Tom