comments on XSPA SAML profile Public Review Draft 02

[Richard Franck <Richard_Franck@us.ibm.com>]

Hello,

I am pleased to submit the following comments on the Cross-Enterprise Security and Privacy Authorization (XSPA) Profile of Security Assertion Markup Language (SAML) for Healthcare Version 1.0, pursuant to the 15-day public review announced on June 15.

1. (Section 2.12.4) The attribute “locality” is ambiguously defined, and there is no information on the format this information should follow (including, significantly, no indication of the expected data type). Further, the use of the word “locality” conflicts with how that term is used in the SAML 2.0 specification, where it refers specifically to the IP Address or DNS name for the system from which the subject was authenticated. This conflicting use of the term could cause confusion.
   
   Rather than having an attribute that essentially duplicates the information in the “organization” attribute, it would be much more useful to have an attribute that represents a unique ID of the organization, represented as a URN or OID.
   
   There is no indication in the text of this section as to which of the attribute identifiers listed in Section 3.2 corresponds to the “locality” attribute. (This omission occurs in the description of several other identifiers as well.)
   
2. (Section 2.12.5) The description of this attribute (Structural Role) states that values should be drawn from ASTM 1986-98 (2005), from a list of “Healthcare Personnel that Warrant Differing Levels of Access Control”. However, ASTM 1986-98 provides only a free-text description of various roles for healthcare personnel; it does not provide an unambiguous (i.e. coded) representation of those roles, and thus is unsuitable as a value set for an OASIS standard, which demands precise and unambiguous values. The ASTM web site does not indicate any current effort to revise ASTM 1986-98 to create a coded representation.
   
3. (Section 2.12.7) It is not clear why the Permission attribute needs to be carried on the SAML assertion of the request when the definition describes it as an attribute of the protected resource, and thus could never be known by the requester.
   
4. (Section 2.12.10) I think there is a typo? should be “support of security and privacy ...”
   
5. (Section 3.2) The attribute identifier “urn:oasis:names:tc:xacml:2.0:subject:locality” is referenced in the table, but this attribute is not defined in the XACML 2.0 specification. The purpose of the attribute “urn:oasis:names:tc:xspa:1.0:environment:locality” in this table is not clear – it does not seem to map to any of the attributes described in section 2.12. But the absence of a clear mapping from Section 2.12 to the table makes the entire list of attributes subject to misinterpretation.

Best Regards,

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