Re: [xspa] specific points about attribute names

My responses to Richard's questions and/or statements

1) I suspect your point may be true, the correct namespace for subject-id is urn:oasis:names:tc:xacml:1.0:subject:subject-id and can be found in both the XACML 2.0 http://docs.oasis-open.org/xacml/2.0/XACML-CORE/Example_2/ request.xml example as well as the XACML 2.0 RSA Interop Scenarios Document where IBM participated in it's development and demonstration. In reviewing our code from RSA 2008, London, and HIMSS the 2.0 namespace was used and allowed, however our requests where proxied through OpenSSO XACMLRequestProcessor which may have corrected the issue as our testing was schema constrained. I will check with Sun Microsystems developers on this point I do not believe escalation to the TC is required at this time, we will just note it correct the namespace in next version of profile. You may not be aware the NHINConnect v2.1 is also using OpenSSO XACMLRequestProcessor.

2) We can take this under advisement for future update, agree that attribute is optional, and SAML v2.0 describes it as DNS name or IP address. I do not however feel this is constraing NHIN efforts, or limiting the creation of extensions (note the additional action-id value) for specific implementations. I have attached a table from the NHIN Policy Engine Design Document for v2.1. The home-community-id, a complex element, I believe provides equivalent of subject locality in you implemenation.

Subject Discovery (In from NHIN)

Attribute URN	Data Type	Group	Description
urn:oasis:names:tc:xacml:1.0:subject:subject-id	http://www.w3.org/2001/XMLSchema#string	Subject	Sender’s User ID
urn:gov:hhs:fha:nhinc:home-community-id	http://www.w3.org/2001/XMLSchema#string	Subject	Sender’s Home Community ID
urn:gov:hhs:fha:nhinc:assigning-authority-id	http://www.w3.org/2001/XMLSchema#string	Resource	Local Patient ID Assigning Authority
urn:oasis:names:tc:xacml:1.0:resource:resource-id	http://www.w3.org/2001/XMLSchema#string	Resource	Local Patient ID
urn:oasis:names:tc:xacml:1.0:action:action-id	http://www.w3.org/2001/XMLSchema#string	Action	Action being performed. This must be set to: ‘SubjectDiscoveryIn’

Regards,

Duane

From: Richard Franck <Richard_Franck@us.ibm.com>
To: xspa@lists.oasis-open.org
Sent: Thursday, June 25, 2009 9:36:23 AM
Subject: [xspa] 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

xspa message

Subject Discovery (In from NHIN)