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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xspa message

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


Subject: specific points about attribute names


Hello again,

In this second thread I just want to make a couple of specific, more-or-less technical points about attribute names.

1. The XSPA XACML profile says the subject-id should be specified using the identifier "urn:oasis:names:tc:xacml:2.0:subject:subject-id". This identifier is not defined in the XACML CORE profile. In the spreadsheet that David created in response to my initial comments, he said "The XACML profile was designed to be v2 compliant." No argument. But the XACML v2 spec uses attribute names defined in the namespace "urn:oasis:names:tc:xacml:1.0" (along with some defined in the "urn:oasis:names:tc:xacml:2.0" namespace). I don't know anything about XACML 1.0, but I suspect that the authors of XACML 2.0 decided to adopt the attribute names defined by XACML 1.0, and where they determined a need to create new attributes, they used the "2.0" namespace.

2. The XSPA XACML profile says the attribute name "urn:oasis:names:tc:xacml:2.0:subject:locality" should be used to specify a unique identifier of the consuming (requesting) organization. This identifier is not defined in the XACML CORE profile. Further, when the SAML 2.0 specification uses the term "locality", it defines it very specifically (as part of the SAML <AuthnStatement>) as "Specifies the DNS domain name and IP address for the system from which the assertion subject was apparently authenticated." I think it is extremely unwise to overload the word "locality" with a different meaning. And I also think that the XSPA profile needs to invent an identifier in any case, since the one listed in the current draft does not exist in the "xacml:2.0" namespace as described. Thus, it makes a lot of sense to me to create an identifier (in the XSPA:1.0 namespace) that describes the attribute as "organization-id".

Futher, I suggest that the data type for this identifier by "anyURI". This would allow two different, non-overlapping, and very precise representations of organization that should cover any scenario where an organization ID needs to be conveyed:
1. an OID, using the form: urn:oid:2.16.840.1.113883.3.2 , for example, to represent the Mayo Clinic. OR
2. a URL, for an organization that does not have and/or does not wish to obtain an OID, for example: http://firsthealth.org.

This attribute should appear in both the SAML profile and the XACML profile. Requesters must use the attribute in their AttributeStatements, and policy authors could use the attribute as a Subject Attribute in policies that grant or deny access to resources. Obviously, both requests and policies must use the same representation, and the evaluation is done as defined by the XACML function urn:oasis:names:tc:xacml:1.0:function:anyURI-equal.



Richard Franck
Certified IT Architect, IBM Global Business Services
Healthcare and Life Sciences
office: 1-919-254-4771
mobile: 1-919-302-3880
e-mail: Richard_Franck@us.ibm.com



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