On 10/31/06, David Chadwick <d.w.chadwick@kent.ac.uk> wrote:
Tom Scavo wrote:
On 10/31/06, David Chadwick <d.w.chadwick@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