ITI XUA Extension

History

Trial Implementation

Final draft July 16 -- approved for Trial Implementation

• IHE_ITI_TF_Supplement_Cross-Enterprise_User_Assertion_TI_2010-07-16.doc

First draft July 15 -- for review and potential approval

• XUA-Extension July 15
• Comment disposition July 15

Public Comment

• July 12, 2010 - Committee disposition of All Public Comments
  • Need to better understand choices of role vocabularies between ISO, ASTM, and SNOMED-CT. Likely will not mandate any one, but will rather describe the three as preferred before a security domain extends.
    • I have these documents if someone wants them for review on this work item I can provide a copy specifically for that purpose, but due to copyright I can not broadcast them
    • In looking at the three, I don't see a compelling reason for us to select either. I am not even sure that a developer would gain by having one selected
    • Committee Decided July 14:
      • We will not choose any of these
      • We will leave this as a named option
      • We will indicate that values will come from an operational chosen value-set (See SVS, ESVS)
      • We will indicate that the mapping of local roles to the operationally chosen value-set is left to the implementer (See SVS,ESVS)
      • We will indicate that the value-set used must be configurable, and Service-Providers may need to deal with multiple value-sets for example in a case where it serves more than one security domain
      • We will indicate how to record the role in the ATNA audit events that are relevent
  • Other attributes
    • Committee Decided July 14:
      • Will add a set of new attributes as 'well-known' attributes to be used when POLICY requires that they be included
      • These attributes are not manditory to support, but when the concept is supported this mechanism should be used
      • These attributes are not inside a named IHE Option, as there is no conformance clauses besides being well-known attributes
      • The attributes come from XSPA as emphasized by NHIN
        • Subject ID - Descriptive Name of the user
        • Subject Organization - Descriptive Name of the Organization the user is coming from
        • Subject Organization ID - URN identifier of the Organization the user is coming from
        • Home Community ID -- when in the context of XCA defined Communities the home community ID the user is coming from
        • National Provider ID - When the user is a provider and has a National Provider ID
  • PurposeOfUse
    • Committee Decided July 14:
      • Will add a new Named Option for PurposeOfUse
      • Likely call this "Accounting of Disclosure Support" Option
      • Will defined well-known way to convey PurposOfUse using XSPA attribute
      • Will thus leaving the vocabulary to a security-domain choice (same model as role above).
      • Will point at a reasonable set of vocabulary sources for this value.
      • We could include a fragment of the NHIN, ISO, XSPA, epSoS, French list
      • Will indicate the impact to ATNA audit messages, which means we ADD a new attribute to ATNA message schema following the HL7 PASS Audit work
  • Will continue to look toward epSOS to see if the consent mechanism we added satisfies their relation-to-patient need
    • July 14 - no update
• July 11, 2010 - Initial disposition of All Public comments July 11, 2010
  • Comments received from 9 individuals

Profile Supplement Drafts

• XUA++ Profile Supplement April 26, 2010
• XUA++ Profile Supplement February 24, 2010

Detailed proposal

XUA Extension detailed proposal November 20, 2009

Use Cases

1. Role-Based-Access Control: Need to specify a fuller vocabulary of attributes needed for access control decisions.
2. Consent/Authorization: Need to carry an indicator of BPPC document that is relevant to the transaction
3. Level Of Assurance for (a) the authentication event, and/or (b) the provisioning of the account
4. Extended Audit Logging: Support link building services descriptive identifiers to support environments where post-processing doesn’t have access to directory for id translation into description.
5. Purpose-of-Use: Carry in the assertion purpose-of-use, including support for Break-Glass / Emergency-Mode-Access
6. Relationship-to-Patient: Carry the indicator of the patient, relationship to patient, location of patient

Detailed Development

Role

XSPA

Structural Role

This is the value of the principal’s structural role Structural roles are described in ASTM E2595-07, Standard Guide for Privilege Management Infrastructure.

Structural roles provide authorizations on objects at a global level without regard to internal details. Examples include authorization to participate in a session, connect authorization to a database, authorization to participate in an order workflow, or connection to a protected uniform resource locator (URL). The structural role is the role name referenced by the patient’s consent directive.

This profile specifies ASTM 1986-98 (2005) Standard Guide for Information Access Privileges to Health Information persons for whom role based access control is warranted as the defined default structural roles to be used in this profile. ASTM E1986 NOTE: At the time of this writing, ASTM E31 is still in the process of completing the formal enumeration ASTM 1986 roles.

Structural roles are specified by reference to an OID. Roles will be typed as strings and an OID will be assigned to each unique structural role authority. The enumerated ASTM E1986 role will be passed with the assertion. Enumerated roles under the OID will be identified through the use of the element

<urn:oasis:names:tc:SAML:2.0:profiles:attribute:XPSA: structural_role> within the assertion.

NHIN

Uses XACML role

3.3.2.5 Role Attribute

This <Attribute> element shall have the Name attribute set to “urn:oasis:names:tc:xacml:1.0:subject:role”. The value of the <AttributeValue> element is a child element, “Role”, in the namespace “urn:hl7-org:v3”, whose content is defined by the “CE” (coded element) data type from the HL7 version 3 specification.

The codeSystem is defined to be “2.16.840.1.113883.6.96" and the codeSystemName is defined to be "SNOMED_CT". The Role Element shall contain the SNOMED CT value representing the role that the NHIN Authorization Framework Specification v 2.0 user is playing when making the request. The value set to be used is “User Role” and the OID 2.16.840.1.113883.3.18.6.1.15

An example of the syntax of this element is as follows: as defined in HITSP C80.

<saml:Attribute Name="urn:oasis:names:tc:xacml:2.0:subject:role">
 <saml:AttributeValue>
  <Role xmlns="urn:hl7-org:v3" xsi:type="CE" code="46255001"
   codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED_CT"
   displayName="Pharmacist"/>
 </saml:AttributeValue>
</saml:Attribute>

The NHIN Trial Implementation “UserRole” attribute has been replaced by the Subject Role attribute defined in this section.

Not sure if this is the same as the XACML and/or SAML RBAC profiles

epSOS

uses XSPA method

Urn:oasis:names:tc:xspa:1.0:subject:role

Also seems to endorse the XSPA permissions mechanism. Should we endorse permissions based methods?

LOA

• NHIN uses the native SAML AuthnContext
• epSOS - I couldn't find any mention of LoA
• XSPA - I couldn't find any mention of LoA
• OASIS - sstc-saml-assurance-profile-draft-01.pdf

Plan

• Evaluate the content of the Resources for how well they address the above Use-Cases
• Discover new vocabulary that may be used for the above Use-Cases
• Further develop the Use-Cases that can be resolved in the next few months, drop the use-cases that do not have mature standards available.
• Write up likely use-cases for review at First T-Con (Feb 26, 2010)
• Evaluate the use-cases and create logical groupings into Options
• Write up logical grouping Options with pointers to likely standards solutions
• Review at Second T-Con (March 19, 2010)
• Take action items from Second T-Con for Third T-Con (April 9, 2010)

Resources

XUA Predicate Profile that this Extension modifies

OASIS XSPA - SAML

OASIS SAML Assurance Profile Draft

epSOS Experience with XSPA

epSOS input on grouping XUA++ with XCA: audit trail format and Hl7 permissions

NHIN Messaging Framework, Authorization Framework

ENISA EU suggestion on AAL Mapping the IDABC Authentication Assurance Levels to SAML 2.0

Notes

FTP site for this project

Current NHIN specifications Return to ITI Technical Committee