RE: Comments for XSPA 2.0 SAML profile

[Duane Decouteau <ddecouteau@edmondsci.com>]

Duane DeCouteau
Senior Software Engineer


EDMOND SCIENTIFIC COMPANY (ESC)
"A Veteran Owned Small Business"
4000 Legato Road, Suite 1100
Fairfax, Virginia  22033
Fax: 703.896.7601
Cell: 406.410.0894

www.edmondsci.com
At Edmond Scientific, we strive to develop and implement complete technical solutions that complement existing managerial and operational structures, optimizing our customers' ability to effectively use technology. That is why we say at Edmond Scientific, "We Engineer Solutions."
Confidentiality Statement: All information in and attached to this e-mail may be proprietary, confidential, privileged and otherwise protected from improper or erroneous disclosure. Such information is solely for the use and benefit of the intended recipient(s). Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.  If you are not the sender’s intended recipient, you are not authorized to intercept, read, print, retain, copy, forward, or disseminate this email or any information contained in or attached hereto.  If you have erroneously received this communication, please notify Edmond Scientific Company immediately by e-mail and destroy all copies of this message (electronic, paper, or otherwise).

La información contenida en este correo electrónico puede ser privilegiada o confidencial, o estar protegida de ser divulgada. Si este correo no le fue dirigido a usted, cualquier diseminación, distribución o reproducción del mismo está estrictamente prohibida. Si usted cree que recibió este correo por error, favor de contactar al envíate inmediatamente.

________________________________________
From: xspa@lists.oasis-open.org [xspa@lists.oasis-open.org] On Behalf Of Michael Dufel [michael.dufel@jerichosystems.com]
Sent: Friday, June 15, 2012 12:11 PM
To: XSPA TC
Subject: [xspa] Comments for XSPA 2.0 SAML profile

1. The NwHIN Authorization guide specifies the use of a pseudo ­ xspa
subject id attribute of "urn:oasis:names:tc:xspa:1.0:subject:subject-id"
instead of using the XACML subject-id as called out in the XSPA 1.0 and
2.0 draft. Should we care?

****Don't care

2. The NwHIN Authorization gude specifies the use of a structured HL7 type
as the attribute value for the purpose of use and role attributes. We
decided to reference other sources for the value of these attributes, but
should we copy the concept of a coded type or just leave the value lacking
the notion of a code system? The commonly accepted health care IT practice
when it comes to standards seems to prefer using coded or strongly typed
values, so I advocate a similar approach for consistency sake.

***Does the community plan to write policy based on a attributes code, codeSystem, codeSystemName, not sure this complexity would help implementors.

3. We have "urn:oasis:names:tc:xspa:2.0:resource:type" and
"urn:gov:hhs:fha:nhinc:service-type". The XACML action-id is still unused
and I suggest eliminating both of these attributes in favor of the XACML
action-id.

****Disagree, The resource (and subsequent authorization) could describe an cross-enterprise XDS.b message where the action could be Create, Read, Update, Delete.
right now we represent all NwHIN type request DocQuery, DocRetrieve with implied action of Read...
I think both are needed although "urn:gov:hhs:fha:nhinc:service-type" is US realm specific.

4. The patient id is represented by the XACML resource-id attribute, and
the provider is represented by the NPI. However, the NPI can represent
both a provider and a clinic. We should break this attribute into
provider and clinic NPI attributes to avoid any mixup and allow for the
reliable identification of a physical location in a privacy policy.

5. The subject-id is reserved for the requestors free-text name. Names are
not unique identifiers and are not suggested for access control decisions.
I suggest changing the XACML profile to make the subject-id optional and
the NPI mandatory.

6. Alternate suggestion for the handling of unique identifiers is to
replace the NPI attributes with equivalent attributes for a subject unique
identifier, provider unique identifier, and clinic unique identifiers.

***I think we should refer to current ONC rules, and implementation guides regarding use of NPI.


Regards,


Michael Dufel
Jericho Systems Corporation
Toll Free:  877.231.2200
Local:  972.231.2000
Fax:  972.234.1100
EnterSpace Technology:  Tools that Rule®
All rights reserved. Product names are trademarked by their respective
companies.  EnterSpace Technology is covered under United States Patents
7,779,247, 7,792,828, and 8,060,504.
The information contained in this e-mail and all attachments transmitted
with it is the Confidential and Proprietary information of Jericho Systems
Corporation.  If the reader of this message is not the intended recipient,
or an employee or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any dissemination,
distribution, copying, or other use of this message or its attachments is
strictly prohibited. If you have received this message in error, please
notify the sender immediately by replying to this message and please
delete it from your computer.




---------------------------------------------------------------------
To unsubscribe, e-mail: xspa-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: xspa-help@lists.oasis-open.org