[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. Regards, 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]