OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [security-services] On allowing multiple value types for an attribute

Thanks Scott.

I think based on your comments here and Hal's comments on the call today, I am convinced that the XSPA profile should probably comply with the XACML Attribute Profile of SAML and thus stick to the XACML data types 

A related question is whether there is any mapping from saml:Subject/NameID to an XACML attribute (perhaps subject-id). The XSPA specs currently use XACML's subject-id  for carrying the unique ID of the subject. If not (as it appears by the specs), then the next question is whether there should be a requirement (or at least a recommendation) in XSPA that the value of the subject-id attribute matches that of saml:Subject/NameID. 
I checked the specs and it seems that although saml:Subject is optional, it is mandatory when saml:AttributeStatement is present. So we have to have a saml:Subject in XSPA SAML assertions.
I appreciate if you people can share their thoughts on this issue.

PS: I really tried to speak up on the call this morning but I think my audio had some problems and I could not be heard.

Mohammad Jafari, Ph.D.
Chair, OASIS Cross-Enterprise Security and Privacy Authorization (XSPA) Technical Committee

> -----Original Message-----
> From: Cantor, Scott [mailto:cantor.2@osu.edu]
> Sent: Thursday, November 06, 2014 8:27 AM
> To: Mohammad Jafari; security-services@lists.oasis-open.org
> Subject: Re: [security-services] On allowing multiple value types for an
> attribute
> On 11/5/14, 11:55 PM, "Mohammad Jafari" <mjafari@edmondsci.com> wrote:
> >
> >Conceptually, I don't think it's a good idea to define different
> >attribute names (i.e. different attributes) for different encodings of
> >the same attribute. It's somehow like defining two separate Date
> >attributes for when it is expressed in MM/DD/YY and DD/MM/YY.
> Syntax is part of an attribute's definition. In LDAP terms, you can't define an
> attribute type as one syntax and then use a different syntax without changing
> the attribute type (which in SAML terms is the name).
> Problems like your date example come up all the time and I would always
> argue for using separate names, or for adding a piece that specifies the
> encoding as part of the value. But xsi:type isn't that thing. It's too tied up in
> XML validation to be safely used that way.
> >As for the SAML requirement, could the concern be addressed by
> >specifying that only one type should be used per instance of attribute,
> >regardless of how many values are provided?
> There is no SAML requirement you're violating, I'm just arguing that it's not
> the best choice, and you will have interop problems with SAML
> implementation code if you do it. Basically anything but string is hopeless,
> but expecting code to handle multiple syntaxes with one name is even more
> hopeless. You're guaranteeing implementation problems.
> -- Scott

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]