[OGSA-AUTHZ] Use of IDList in Use of WS-TRUST and SAML to access a Credential Validation Service

[Tom Scavo]

Hi David,

There are two issues with the <SubjectAttributeReferenceAdvice>
element (apart from the fact that it requires a proprietary schema):

1) it contains SAML V1.1 <AttributeDesignator> elements, which are
gone in SAML V2.0; and

2) it contains URIs (as opposed to entityIDs) and therefore precludes
the use of SAML metadata.

I don't really understand your use case, so I can't suggest an
alternative, but these two issues strongly argue against the
<SubjectAttributeReferenceAdvice> element, I think.

Tom

On Fri, Oct 3, 2008 at 8:34 AM, David Chadwick <d.w.chadwick at kent.ac.uk> wrote:
> Dear WG
>
> at our last meeting in Singapore, on a suggestion from Tom Scavo, we
> discussed changing from the GFD.66 SubjectAttributeReferenceAdvice
> element to the SAML IDList element and I made the edits to our profile.
>
> We have now been implementing this to see how it works in practice, and
> we have encountered the following problem, namely that IDList only lists
> attribute authorities and does not associate the attribute types that
> they issue with these attribute authorities. GFD.66
> SubjectAttributeReferenceAdvice on the other hand does associate AAs
> with the attributes they issue.
>
> The meeting suggested that the implementation can pick up the attribute
> list from meta information of the AA, which indeed it can. However, this
> does not allow a user to specify which attributes he wants to use ie.
> provide the user with least privileges.
>
> Consider a VOMS server in which a user has multiple attributes. The meta
> information for the VOMS server will tell the CVS which attribute types
> are supported by the VOMS AA. But it will not help the CVS to decide
> which ones to ask for this user session, since the user is no able to
> tell the CVS which ones he wants. With SubjectAttributeReferenceAdvice
> the user was able to tell the CVS (indirectly via the PEP) which
> attributes he wished to be picked up from where for this session. With
> IDList the user is unable to tell the CVS.
>
> I am therefore proposing that we revert back to the
> SubjectAttributeReferenceAdvice element since it provides the user with
> the least privileges control that he needs. On the user's grid job
> request he adds the parameter "please pick up my attribute X from AA Y",
> which the PEP can then transfer to the CVS in the
> SubjectAttributeReferenceAdvice element. The CVS can perform the third
> party query mode request to the AA for the specified attribute (using
> the Use of SAML to retrieve Authorization Credentials profile), and if
> the user does have attribute X, this can be validated by the CVS and fed
> into the PDP.
>
> regards
>
> David
>
>
> *****************************************************************
> David W. Chadwick, BSc PhD
> Professor of Information Systems Security
> The Computing Laboratory, University of Kent, Canterbury, CT2 7NF
> Skype Name: davidwchadwick
> Tel: +44 1227 82 3221
> Fax +44 1227 762 811
> Mobile: +44 77 96 44 7184
> Email: D.W.Chadwick at kent.ac.uk
> Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
> Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html
> Entrust key validation string: MLJ9-DU5T-HV8J
> PGP Key ID is 0xBC238DE5
>
> *****************************************************************
> --
>  ogsa-authz-wg mailing list
>  ogsa-authz-wg at ogf.org
>  http://www.ogf.org/mailman/listinfo/ogsa-authz-wg
>