RE: [xspa] Proposed Agenda for October 10, 2008, 1:00pm ET call

Comments on XSPA-SAML-PROFILE-01.

High level comments:

* This document need to do a better job at explaining what it is covering and what it is not. SAML can be used for things other than requesting authorization decisions, so this document needs to carefully scope.

* There seems to be specifications in here that should be left to policy. I think this is the normal maturation of this document so have only included a few instances. XSPA should provide the infrastructure and examples of how these specific use-cases might use specific vocabulary, but it is unnecessary to define the normative use-cases nor the normative vocabulary (e.g. Purpose of Use – see below)

Specifics:

* Page 11: There is a specification for “Name” and “Organization” that make statements about US (not global) policy choice derived from HIPAA. This is not a general truth. The Name and Organization must be derivable under specific circumstances but in most cases are protected information. That is to say that to know the name of the user is not required in an ‘accounting of disclosures’, and would violate the privacy of the ‘user’ if exposed. Thus policies need to protect not just the patient but also the users. This said, I don’t think XSPA should get to this level of detail. This information can be set in policy

* Page 12: The specification of ASTM E1986 is not necessary and brings in standards that are not accepted globally. The roles should be bound in policy, not standard.

* Page 12: The mapping of ASTM role codes to NUCC is not necessary in XSPA. This detail is simply not needed in this document.

* Page 12: Not all systems use OIDs for roles. This is overly restrictive and not needed in XSPA.

* Page 12: Purpose of use. This is an interesting start on a purpose of use table. The development of this vocabulary should take place in a healthcare standards organization, I recommend HL7. XSPA should simply identify where purpose of use would be used when the policy has identified a purpose of use vocabulary.

* Page 14: Actions. It is useful to explain how in XSPA the action is identified. But it is unnecessary for XSPA to define a vocabulary. This vocabulary should be defined in a healthcare specific organization such as HL7.

Page 15: Resource. We should separate the ‘subject’ from the ‘resource’. That is the ‘resource’ is a protected resource for which the ‘subject’ has a stake. For example a ‘document’ is the resource, and the document contains healthcare information about the ‘patient’ as the subject.

Page 15: Consent directive. This needs lots of work. The method described is not clear and not functional.

Page 16: Resource Masking. Is this really needed in this standard? Resource Masking can be done in many ways. I recommend we put this one out of scope for now.

John Moehrke

xspa message