Cross-Enterprise User Assertion - Discussion

Introduction

IHE has defined a profile for Enterprise User Authentication (EUA) and Personnel White Pages (PWP) for use within an enterprise. The IHE is now defining transactions that cross enterprise boundaries, specifically the XDS profile and others that create an Affinity Domain. When transactions cross enterprise boundaries the mechanisms found in the EUA and PWP profile are insufficient and often nonfunctional. To provide accountability in these cross enterprise transactions there is a need to identify the requesting user in a way that the receiver can make access decisions and proper audit entries.

Cross-Enterprise User Assertion(XUA) profile will provide the user identity in transactions that cross enterprise boundaries. Enterprises may choose to have their own user directory and their own unique method of authenticating. To provide accountability in these cross enterprise transactions there is a need to identify the requesting user in a way that the receiver can make access decisions and proper audit entries.

Detailed Profile Proposal for XUA January, 2007 : John Moehrke

The profile document is being developed at Cross-Enterprise User Assertion Profile

Discussion

The profile document is being developed at Cross-Enterprise User Assertion Profile

May 18 - face-to-face

• healthcare PKI : not there because no application required
• claims about the identity vs the identity : don't use the word 'establish the identity'. use the word 'claim'.
• vol 2 : add more specific atna for XDS
• vol 1 : need a hint in vol 1 that you are required to use the saml assertion in the audit record
• service provider processing not clear on failures : if validation fails this shall be treated as an un authorized user on the grouped transaction (for example Stored Query and Retrieve)
• X.6.2 : re-state the current scoping
• all : spell out WS and WSS
• line 420 : fix up language to be more readable (Chad will fix)
• all : replace IDP with X-Assertion Provider
• carefully managed -- not clear : clarify
• security considerations section : is stored and available from IHE.

Voted to approve pending edits -- unanimous approval

Edits are complete

Evening Discussion May 14

1. We will ONLY support Identity Assertions. No attributes will be mandatory. Attributes are allowed by negotiation within an Affinity Domain.

We know that ATNA is in place, so we have a secure mutual-authenticated SP knows that it is talking to a trustable system with appropriate policy SU knows that it is talking to a trustable system with appropriate policy

communication with the IDP - Need signature on the assertion from the IDP

Risk -- exposure of the identity value (username which may be an email) -- Addressed between SP and SU -- Not addressed prior or post transaction

The XUA will only identify the user. We do not give information necessary to define what their role is. We do not give any information on how to tell if the user is the patient.

Issues May 14, 2007

1. What is the relationship to WS-SecurityPolicy Version 1.2. (Maryann will drive discussion)
   • Seems that the XUA profile could be expressed by a single WS-SecurityPolicy (or fragment of one).
   • The XUA profile could be described as a the above policy in the absence of a service published policy. Thus a service is allowed to publish a policy and that IHE doesn't constrain that policy. The minimal requirements found in the XUA profile would be considered the minimal interoperability that everyone should plan on supporting.
2. We still have no one suggesting any attributes that we want to make XUA recommended or mandatory. One suggestion was that the XDS authorSpeciality could be used.
3. Volume 1 indicates principal, there is push to require the XUA represent the human user
4. Are we comfortable with continuing to require minimal support to TLS, while allowing other (async) mechanisms to be negotiated.
5. Need to define the ATNA encoding rules.
6. Is this really a profile? Need transaction numbers
7. Should XDS actors have an XUA option declared so that it is clear which transactions XUA is applied to? There have been concern about some of our transactions that are used in some minor way on specific transactions but not wholly available across the full application. (E.g. PIX support for the purpose of XDS, but not for anything else.)
8. Are we comfortable not specifying how to get assertion or how to validate...
   • We had talked about showing the relationship of EUA and XUA. Meaning that a system that uses EUA to authenticate user should be given at least one (non-normative?) way to convert the TGT into a XUA?
9. Do we publish the WS-Policy that represents the minimal interoperability specified in XUA?

Discussion Notes

1. We may choose to publish a WS-Policy, but this is clearly a stretch goal.
2. We may choose to define that the Affinity Domain define a role vocabulary that could be included in the XUA Assertion as an Attribute.
   • Where the EMR knows enough about the user to know that they are (Treating-Specialist, Treating-GP, Treating-Nurse, Emergency, Researcher, Finance, Clerk, etc). The EMR indicates which of these the user is currentnly acting as when requesting the SAML Identity Assertion from the IDP. The IDP would verify that the user does have that role and would either include the Attribute in the assertion or none.
3. No discussion
4. Yes
5. No discussion on how ATNA references a SAML Assertion
6. Still not clear. Feels like a transaction profile, Feels like a content profile, feels like just appendix... Not clear
7. Possibly a good idea to put Options inside XDS for XUA as we do have XDS specific behaviors
8. Yes (see test plan)
9. Yes, if we have time.
10. Need to have Connectathon straw man
    • Applications can bring their own implementations that might include self-IDPs (ala 2005 like solution)
      • XUA Implementation Demo 2005 Guide August 2005, John Moehrke
    • Connectathon will provide one example setup for those applications that have used EUA to authenticate users and who use WS-Trust to get their SAML Identity Assertions.
    • If we decide to have something like a role in XUA, then Connectathon will define that role vocabulary.

Preparation materials for Face-to-face

WS-Policy Guidelines document is targeted for new assertion authors (its a work in progress)

 http://www.w3.org/TR/2007/WD-ws-policy-guidelines-20070330/ 

WS-Policy Primer is targeted for policy deployers

 http://www.w3.org/TR/2007/WD-ws-policy-primer-20070330/

Information from Maryann Hondo

Following up on questions regarding WS-Policy & WS-Security Policy here are some links and presentations:

I think this is available publicly, I googled developerworks and it seems to show up....people might have to register to get access to the tutorial though http://www-128.ibm.com/developerworks/edu/ws-dw-ws-understand-web-services5.html

here's a general pointer to the materials that were used in the W3C workshop: http://www.w3.org/2004/09/ws-cc-program.html

in particular there was a tutorial presentation..... http://www.w3.org/2004/10/presentations/david.ppt and http://www.w3.org/2004/10/presentations/claus.ppt

and I have two presentations: one that IBM & MS have used at conferences (Digital ID world) to present WS-Federation and how its built on the other specifications. It's a little old but,I think it covers a lot of the concepts at a very high level

second, an IBM presentation that our standards folks have used for training more recently at SHARE http://www.share.org/

April 20 Meeting

Updated parts of the profile

• Cross-Enterprise_User_Assertion_(XUA)_Profile#XUA_Requirements
• Cross-Enterprise_User_Assertion_(XUA)_Profile#Volume_II

OPEN ISSUES

• What is the relationship to WS-SecurityPolicy Version 1.2.
  • Seems that the XUA profile could be expressed by a single WS-SecurityPolicy (or fragment of one).
  • The XUA profile could be described as a the above policy in the absence of a service published policy. Thus a service is allowed to publish a policy and that IHE doesn't constrain that policy. The minimal requirements found in the XUA profile would be considered the minimal interoperability that everyone should plan on supporting.
  • This is a newly approved standard, but already many companies have claimed conformance (Microsoft, IBM, Sun, and BEA)
• I am still not sure exactly how to specify the details.

Meeting notes

Post meeting discussion

--David Channin writes -----

I won’t be on the call, unfortunately, but wanted to add two cents about the content of the 
assertion. I think we SHOULD require specification of ROLE according to the ISO standard for 
Healthcare Roles also I think we should require specification of “purpose” which would be the 
list of “emergency, treatment (clinical), payment, operations (the HIPAA 3), research and 
education”. This, combined with user identity, would allow decisions for the majority of 
healthcare scenarios. I.e., Identity, Role, Purpose

--David Webber writes-----

Identity, Role, Context (Purpose) I find purpose rather subjective - whereas context provides
specific parameters relating to the operations and the situation of the participant. For me 
purpose is one of the possible context parameters.

--Mike Davis writes -----

Regarding the discussion in on roles, I'll throw in my two cents as well...not so much on 
the XUA discussion but more generally on what is going on in the RBAC area in ISO, ASTM 
and HL7.  Hopefully, this will be helpful.

1.  Purpose of use is subjective and users lie.  Purpose of use was part of the draft HHS 
Security NPRM and was removed in the final.   The assertion of role is usually sufficient 
and in any case context specific parameters would probably be more useful.  Context seems 
to offer more possibilities.

2.  ISO discusses two types of roles, structural and functional.  I don't believe ISO 
defines functional roles except as to general type.  ISO does define structural roles 
however.  ASTM E1986 defines another possible set of structural roles as well, so 
probably these should eventually be asserted by reference to an OID.  Neither ISO nor 
ASTM defined roles are adequate in general for detailed HC authorizations.  HL7 is 
currently balloting OASIS XACML and ANSI INCITS compliant permissions as an international 
standard that will allow for the interchange of fine-grained interoperable authorization 
assertions for clinicians, administrative, IT and other HC support users.  The results 
of the ballot should be known in a few days.

3.  It may be that the authorzation assertion would not necessarily even assert the 
roles (actually permissions)  that someone had.  More likely, the resource (target) 
might advertise what permissions were needed for access to some workflow, or task 
therefore implicitly suggesting the purpose of use.  The asserting organization PDP 
representing the claimant would only need the assertion to carry the value "yes" 
(the claimant has the required authorizations in my domain), "no" (he/she does not), 
indeterminate, etc.  While it is possible to assert mutally agreed upon proprietary 
roles between organizations, this still  rprobably equires some additional out-of-band 
coordination as to meaning.  This approach has not been very successful to date.
 
4.  ISO 10181-3 provides for access control information (ACI) that could be asserted 
to a verifier in order to make an access control decision (including roles).  Perhaps 
providing a way to assert ACI rather than just roles would be a more general approach 
and would define some of the context values you are looking for?

IHE Phone call March 30, 2007

Agenda

• Review Use-cases
• Review minimal profiling effort needed

Open Issues

• Not clear if this is a full profile or just appendix material
• Not clear if we need to specify the IDP/STS or if we can simply point at the standards.
  • Need to allow for applications to be their own IDP/STS, specifically small clinic EMR.

NOTES: ITI_Tech_2007_Meetings#Minutes_March_30

Notes for IHE Tech Face-to-Face -- March 14, 2007

Conclusions

• Will rename XUA to Cross-Enterprise User Assertion
• We will NOT be using WS-I profiles. We will be specifying that WSS be be added to the SOAP message, and that the XML token type be used, and that the XML token type be filled with a SAML v2.0 Assertion. Thus only calling out WSS and SAML 2.0 as standards.
• Use SAML 2.0 because SAML committee wants that used when legacy install is not present
• SAML Assertion content: Focus on Authentication and Attribute statements. NOT Authorizations
• Place the mechanism of obtaining the SAML Assertion out of scope. This is not necessary to profile in order to get interoperability on the specific transaction
  • This means we are not directly profiling identity federation but are enabling identity federation.
• Will recommend the use of SAML Metadata standard to streamline the configuration. The SAML Metadata standard allows for the communication of things like: Identity Provider Certificate, Service Provider's requirements around assertion attributes, etc
  • IHE may be able to publish a fragment of a WS-Policy with the constraints of the XUA profile. This will further be specialized by each service provider.

XUA Use-Cases

• User using Registry or Repository where the service provider wants a user identity for additional detail in their audit log
  • User Identity is all that is required
  • The User Identity must come from any trustable identity provider.
    • This may be a single identity provider in an Affinity Domain. (Germany using SmartCard issued chaining back to a single CA)
    • This may be (most likely is) a set of identity providers where these identity providers are likely in the control of each enterprise in the XDS Affinity Domain. (MAYO clinic identity proider, St Mary's identity provider, Kaiser identity provider, etc)
• User using Registry or Repository where the service provider wants to impose be assured that the user has been authenticated to a specific assurance level. This is not a case of not trusting the system, but recognition that the system supports different levels of authentication. For example the system supports a proximity card as a form of authentication, as well as Smart-Card with PIN. This is not a replacement for ATNA access controls which give distributed access controls.
  • User Identity with level of assurance of that identity is needed..
• User using Registry or Repository where the service provider wants to impose additional access controls. This is not a replacement for ATNA access controls which give distributed access controls.
  • This use-case may introduce break-glass concerns that will not be addressed.
  • In the simplest form the binding of the user identity to the service providers access controls is out of scope. There is some proprietary mapping of the user identity to local roles to local permissions
  • In more complex forms may want attributes that indicate the user's role
    • May at best leverage the CEN role codes.???????
• Specialized XDS for Emergency Dataset. In this case the transfer of information to the XDS Consumer is not critical to fully control, and thus the administration is willing to accept requests from any system as long as they can provide a user-assertion from a trusted source. This trusted-source may be a specialized IDP for First Responders. (See RSA Pilot)
  • In this case only a user identity with proper linkage to a trusted IDP is needed. No specific attributes are needed.
• User using Registry or Repository is the patient. They are using an authorized PHR service which is handling the XDS Consumer responsibilities (including ATNA). The service provider wants to restrict the information returned to those that have been released for patient consumption (for example a lab result that regulations require the provider to discuss in person before releasing the information)
  • In this case the user identity is needed for audit logging
  • In this case the user identity needs to be linked to their role as the patient
• User using a Cross-Community-Bridge needs to provide a user assertion that can be utilized by the Cross-Community-Bridge.
  • This requires that the Assertions can be re-purposed for the next Bridge or Reg

SAML Assertion Parts

• Authentication type and strength --> YES
  • Subject:
    • should there be one? --> Likely this is needed as the singular value to go into ATNA log
    • What is the NameID format? --> Transient may be out of scope
    • What type of subject confirmation should be used to assume that an agent does not missue the assertion? Holder-of-key? --> Good topic to discuss for public comment.
  • Conditions: What should be used for audience information? Affinity domain? We can constrain assertions to a specific use. In a bridging case should there be proxy restrictions? --> This is not clear why we would constrain this further. We might give guidance.
  • AuthnStatement: What types of AuthnContext do you accept, just references? If not what does the craziness of comparing contexts to determine ordering per the SAML spec mean?
• Attributes --> Depending on use-cases
  • AttributeStatement: What's the name format? What are the names? OIDs? (i sure hope not) What specs (ASTM, ISO, etc.) should be profiled as attribute profiles?
• Authorizations --> Deprecated by SAML committee, that wants us to use XACML
• The SAML Assertions MUST be signed by the IDP.

EXAMPLE SAML ASSERTION

1: <saml:Assertion xmlns:saml=”urn:oasis:names:tc:SAML:2.0:assertion”
2: Version="2.0"
3: IssueInstant="2005-01-31T12:00:00Z">
4: <saml:Issuer Format=urn:oasis:names:SAML:2.0:nameid-format:entity>
5: http://www.example.com
6: </saml:Issuer>
7: <saml:Subject>
8: <saml:NameID
9: Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
10: j.doe@example.com
11: </saml:NameID>
12: </saml:Subject>
13: <saml:Conditions
14: NotBefore="2005-01-31T12:00:00Z"
15: NotOnOrAfter="2005-01-31T12:10:00Z">
16: </saml:Conditions>
17: <saml:AuthnStatement
18: AuthnInstant="2005-01-31T12:00:00Z" SessionIndex="67775277772">
19: <saml:AuthnContext>
20: <saml:AuthnContextClassRef>
21: urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
22: </saml:AuthnContextClassRef>
23: </saml:AuthnContext>
24: </saml:AuthnStatement>
25: </saml:Assertion>
Figure 6: Assertion with Subject, Conditions, and Authentication Statement

Notes from IHE Tech Face-to-Face -- March 13, 2007

The key items to accomplish this week are:

1. Develop a profile (not clear if this is transaction or content profile or just more parts of the Web-Services Appendix or XDS Actor options or something else)
2. Focus on XDS Stored Query and XDS WS-Retrieve (while being open to others if time/resources)
   1. remind audience that the use-case involves at least two different administrative domains that are operating under different technology, procedures, role-models, etc. They are cooperating in the XDS Affinity domain under an overarching policy that indicates that these differences can be rationalized. The XDS transactions are transferring control from one entity to another. This fact is important to the discussion about what is reasonable uses of the Assertion.
   2. we will be using XDS to exchange data between a simple doctor, the VA, and MASS General. It is not likely that they will all agree to the same RBAC security model. This is not necessary to have this agreed to, but it is reasonable that at the policy level they can.
   3. This results in an important fact that the XUA is usable for audit logging, but is of a lesser extent useful for access controls.
3. Leverage WS-I Basic Security Profile (version 1.1)
   1. Need Version 1.1 as it profiles SAML 2.0. http://www.ws-i.org/deliverables/workinggroup.aspx?wg=basicsecurity
      1. Not clear to me how WS-I Basic Security Profiles will handle MTOM, they both reference SOAP with attachments.
      2. Not clear to me the relationship of WS-I profiles to SOAP 1.2. WS-I seem to me to refer to SOAP 1.1 or 1.0. --> This will be profiling work that we need to do. WS-I is developing 2.0 versions of their profiles with SOAP 2.0 support. (Roberto)
   2. WS-Security header
   3. WS-Security XML Security token using SAML 2.0 Assertions
   4. Focus on Authentication and Attribute statements. NOT Authorizations
   5. Don't restrict Service Providers or Service Users from using other methods, the constraints are a minimal floor for interoperability sake.
   6. Does this impact ATNA (Node Authentication)? Do we further profile WS-I to only TLS, thus not using (allowing) XML Signatures/Encryption? Is there a reason to restrict in this way, Especially for Web-Services?
4. Leverage SAML-Protocol for the requirements of the IDP (STS), thus no new profiling from IHE
   1. Thus leveraging Liberty Alliance Certification to the SAML 2.0 standards
5. Examine the potential User Attributes for the use-cases
   1. User is Patient, Provider, Guardian, Application, Clerk, Security Admin, etc
   2. We may find useful attributes to profile:
      1. X.509 certificate compliant from ISO/TS 17090 – Health Informatics PKI, for identify management
      2. Assertion LDAP Metadata compliant from ISO/TS 21091 – Healthcare Informatics – Directory services for security, communications, and identification of professionals and patients (submitted for publication)
      3. Functional and Structural Roles from ISO/DTS 21298 (work item in committee) --- CEN 13606-4 is the same vocabulary and is normative.
      4. List of Professions from ASTM E1633 – Standard Specification for Coded Values Used in Electronic Health Record.
      5. Information access privileges from ASTM E1986 – Standard Guide for Information Access Privileges to Health Information
      6. Role vocabulary from ASTM – Privilege Management Infrastructure (work item document number not assigned)
   3. Need to make the assertion from a patient clearly indicating that the assertion is for a patient
      1. Should include the patient ID
      2. Need to be clear in the profile that there are many issues with patient access that are not handled (e.g. patient accessing lab results that have not yet been released for patient consumption, Consent, Specific provider restrictions, Specific data restrictions, Workflow of a physician that needs to discuss the data before the patient sees it, Delegates (parent, child, guardian, elder)) --> This should go into our Appendix L (policies necessary for Affinity Domain)
      3. Patient accesses XDS through some 'service' like a PHR. The PHR needs to be a member of the Affinity Domain.
      4. Need to be clear on the case where a physician is a patient... which role?
   4. When the User Assertion is about an enterprise personnel (provider, clerk, etc), then we should allow for retrieving of these attributes from PWP. Update PWP profile as necessary with attributes not found there.
6. Show at least one way that a system using EUA can get XUA Assertions
7. Show at least one way that a browser [interacting with Middleware] can obtain an XUA Assertions for the Middleware to use in XDS Stored Query requests or XDS WS Retrieve(a common XUA-Consumer arrangement)
8. Show how the XUA Assertions are encoded in ATNA Audit messages. Some have indicated that the whole SAML Assertion needs to be saved in the audit message. The hope is that we can pull the user identity out of the SAML Assertion.
9. Show roadmap for other transactions (HL7 V3, HL7 V2, DICOM, Browsers) --> This is likely just a note of the resources to go look at to work with.

The following are open issues that the IHE IT Infrastructure Technical Committee has on the XUA profile. We invite comment on these issues as they will assist with the ultimate profiling into the XUA profile.

1. Not clear if we need to define any configuration requirements. (aka SAML Metadata standard)
2. Should we rename this to “Cross-Enterprise User Assertion (XUA)” to show that we are addressing the user assertion and not the act of authenticating the user?
3. Not clear how much we need to reference WS-SX
4. There are questions around how the application calling on a service that needs XUA knows that XUA is needed?
5. There are questions around how the application calling on a service that needs XUA knows what the XUA Assertion needs to contain?
6. There are questions around error modes around the assertion, transaction, access rights (e.g. do we tell the user why it fails)?
7. Should we informatively cover an EMR/EHR doing self-assertions are a simplified model that doesn't scale well, but gets around client side lack of standards
8. How is Emergency Mode handled?
   1. One view is that this is just an infrastructure robustness issue.
   2. This must work for medical devices where the medical device includes all the standards when it is shipped from the manufacture. No ‘agent’ can be required to make this work.
   3. Do we have a well defined way for one actor to declare that it is in emergency mode? Clearly this mode doesn’t have to be accepted. Clearly the use of this mode must be carefully managed with policy.
   4. Possibly a ‘claimed’ functional role.
   5. May need to look at yet a more simple (radical) approach to user identity. This might use something simpler than SAML assertions, or might be SAML assertions in self-assertion mode.
9. Do we need to further restrict SAML transactions. (ex. Single Logout)?
10. How will this change if we institute a federated XDS Registry where the initial XDS Query transaction may be reflected and spread to multiple other Registries and possibly further?

I expect that there will be some proposals of how we can accomplish the above that we can discuss Tuesday morning.

HIMSS, IHE, Internet2, and Liberty Breakfast Panel and 2007 plan

February 28, 2007: There was a meeting sponsored by IHE, HIMSS, Internet 2, and Liberty Alliance to discuss the issues facing the healthcare industry around identity. This was organized by Michael J. McGill, PhD from Internet2.

Presentations by:

• Holt Anderson: Executive Director of NCHICA
• William Weems: The Texas Medical Center approach
• John Moehrke: On the IHE process and vision for XUA

This discussion very much made it clear that Policies must worked on. Technical solutions, no matter how elegant or complete, will fail without clear and agreed policies. There is a workgroup between Liberty Alliance and HIMSS that may be a very good place to help gather policy lessons learned and to help create boiler plate policies. It is this combined Policy work with the IHE Technical work that will make this successful.

January 29, 2007 -- Meeting Notes

Detailed Profile Proposal for XUA January, 2007 : John Moehrke

Notes:

• Will focus on XDS Stored Query and the new XDS Web-Services Retrieve
  • Need to show how future work will fill in other transactions
• Relies on the updated Web-Services clarifications also taking place this year
• Need only profile WS-I Basic Security Profile 1.1
  • Use SAML Assertions -- don't need to specify SAML Protocols
• Need to show how EUA and XUA are related
• Need to show how the SAML Assertion will be represented in the ATNA Log message
• Access Controls will NOT be required or specified. XUA should support some reasonable Access Controls.

Open Issues/Questions:

• How will XUA be published? Important to make it easy for customers to properly ask for the support and for vendors to be clear on what is truly supported.
  • Is it a full profile?
  • Do we change XDS Actors?
  • Do we add XDS Options?
    • Is this a "Global Modular Option"?
      • Might this show up as a profile with no transactions?
  • Do we use IHE Actor Grouping?
  • Is our work this year really "XUA for XDS Consumer"?
• Will we be forcing WS-Security in all transactions even when no individual user is controlling?
  • For example a system doing a pre-fetch because a patient is scheduled that day

Dec 12, 2006 Face-to-face meeting: IHE XUA, caBIG, Northwestern, and Project Sentinel (Georgetown University)

Dave Channin has observed that these groups are all doing something similar and that IHE may be a good forum to bring them together into a common and interoperable solution. The first use-case that was discussed would be a workstation that needs to interact directly with XDS/XUA while also interacting with caBIG services.

Discussed the IHE solution and XUA path.

Then discussed the caBIG security architecture. In this model there is a service (Dorian) that can interact with SAML assertions (1.1 today but moving to 2.0), and returns Proxy-Certs for the same user to be used with interactions with caBIG. These Proxy-Certs are used in the TLS communications so that the caBIG can attribute the session with a user. caBIG also uses WSRF to provide session based web-services.

It was determined that Dorian could convert an XUA assertion properly. There was some non-optimal solutions for how a caBIG service could convert from the Proxy-Certs back to a SAML assertion for interactions with XUA based services (e.g. XDS). Further investigation is needed but there was some level of confidence that this could be done.

The second, and much harder, use-case is when this workstation interacts with a potential caBIG service that would need to further interact with XDS/XUA. The second use-case is much harder as the caBIG service must be able to be an intermediary for the user credentials. This is complicated because of the caBIG architecture that requires the use of proxy-certs that can not carry with them anything more than the minimal attributes defined by caBIG. Thus converting back to a SAML assertion that can be accepted by the XUA/XDS is very difficult.

Dave Channin will produce more text and diagrams. This project was named "XUA Testbed" (aka the Project Sentinel / Northwestern XUA Pilot.

Dec 5, 2006 -- face-to-face ITI Tech

XUA - Look at XDS Query first year, XDS Retrieve second year. Does query need to be field-able after 1 year? For ATNA purposes, document patient ID can be retrieved by looking up URI in registry. With ATNA there may be an issue with automated pre-fetch. Handle ED differently - different cert per service with different policies. Would MTOM force f-bit encoding (data expansion)?

May want to look at 3 different environments: high, medium, low policy scopes. Should include Roles and Affinity Domain type information. Do not include authentication. What are the interoperability issues? Assertions?

IBM implementation for NHIN - Since Repository doesn't know patient ID, Registry issues timed token for retrieval (illegal in XDS). Thus the Registry acts like an intermediary for repositories. Registry controls access. -- This is not a recommended solution for IHE as the URIs returned by the registry can not be used in documents or in the future. The IHE design is such that the URIs returned can be embedded in documents or used as references in the future (likely by other people).

Discussion on the priority of our transactions to use XUA to help scope the amount of work to do this year (both profile development and product engineering). This discussion focused around using the AHIC Emergency usecase, and recognizing that data use is more important than data export. Thus the query and retrieve are the focus. The query is already a web-service, and thus should be the top priority. But it is recognized that the Retrieve is the more interesting one for two reasons. First it is the one that exposes the high-fidelity data (document vs metadata), second it is the one where the original-enterprise would still be in control as they could be using a local repository. Thus they want to know to whom they are sending the document.

The query is more likely to be automated (pre-fetch) based on an ADT, Order, or Schedule and thus less likely to be able to provide a human user identity. The Retrieve however is more likley to be a human selecting from previously pre-fetched query.

If we update the XDS-Retrieve transaction to a Web-Service, then the XUA work should include both the query and the retrieve.

Plan as of December 2006

1. The use-cases need to be updated to be more clinical and less technical
   1. To better communicate what we are providing
   2. To better uncover the requirements for the transactions
2. Maturity concerns
   1. There still is very limited support for SAML 2.0. The vendors are all working on it. The SAML community is all unified that 2.0 is the right one for future work. The problem appears to be vendors trying to get some revenue on existing development.
   2. WS-I and WS-SX appear to be maturing on target.
3. decide scope
   1. are we only going to focus on web-services transactions? (no support for HL7 v2 MMLP or dicom or wado or RID)
   2. we should focus year one on XDS-Query with an assumed Affinity domain Policy.
   3. Strong (Charles) request to include XDS-Retrieve as well.
      1. Would likely need to have a WS version of Retrieve. Where the old HTTP-GET retrieve never supports user (XUA) identities, where the new one has support.
      2. HITSP Emergency Responder usecase – repository wants to know the user identity that it is handing over information to.
   4. There is evidence that the XDS-Query is more likely to be done by an automated process, where as the XDS-Retrieve is more likely to be attributable to a specific user.
4. Produce a roadmap that shows how to get this done in multi-year.

Test Plan

There are two different ways identified to test this profile in the first year.

1. Applications that choose to incorporate the IDP functionality. Thus they don't rely on any external IDP.
2. Applications that have implemented EUA, and thus need an IDP that will convert EUA tokens into XUA tokens.

For (1) there is no additional infrastructure that the Gazelle tools need to offer. The XDS Registry and XDS Repository simply need to be configurable to accept the Applications internal IDP as a trustable IDP. This functionality is required regardless. The interesting discussion is does the application need to support all the

For (2) Gazelle needs to offer both a Kerberos KDC as well as an IDP that can convert the kerberos tokens into appropriate SAML tokens that are compliant with XUA.

1. The Application will use EUA to get the user authenticated.
2. The Application will use WS-Trust to with the kerberos identity to get the SAML Assertion

Question:

1. Should we not allow (1)? At least if we allow (1), then their application must fully conform to the SAML IDP specification, otherwise the Service Provider will not be able to do attribute queries.
2. Should we provide an IDP that is configured to support WS-Trust queries given a username/password pair.

References

Normative

See Cross-Enterprise_User_Assertion_Profile#Data_Standards

Informative

• Detailed Profile Proposal for XUA January, 2007 : John Moehrke
• Cross-Enterprise User Authentication Draft September 12, 2006 : Tech Editor: John Moehrke
• XUA Implementation Demo 2005 Guide August 2005, John Moehrke
• WS-I Publishes New Profiles and Usage Scenarios for Public Review Working Group Drafts of Basic Profile 1.2, Basic Security Profile 1.1 and Reliable Secure Profile 1.0 Usage Scenarios, December, 2006
• Security Concepts, Challenges, and Design Considerations for Web Services Integration US Department of Homeland Security, US-CERT, Dec 14 2006
• Presentation of XUA Scope and Plan I put together for use at HIMSS to explain XUA and our current direction.

[1]

FYI

FYI: Ping Identity white paper

Again, some interesting input to our work.

White Paper From Ping Identity Corp: February 2007, Internet-Scale Identity Systems, An Overview and Comparison

http://www.pingidentity.com/InternetIdentity010707b.pdf

ZXID Version 0.8: A C library Implementing the Full SAML 2.0 Stack

John: This is not an endorsement, but simply pointing at what might be a useful toolkit.

Sampo Kellomaki, Software Announcement

ZXID is a C library that implements the full SAML 2.0 stack and aims to implement all popular federated ID management protocols such as Liberty ID-FF 1.2, WS-Federation, WS- Trust, and ID Web Services such as Liberty ID- WSF 1.1 and 2.0.

http://freshmeat.net/projects/zxid/?branch_id=65768&release_id=245917

SAML Single Sign-On (SSO) Service for Google Apps

Google Apps offers a SAML-based Single Sign-On (SSO) service that provides partner companies with full control over the authorization and authentication of hosted user accounts that can access web-based applications like Gmail or Google Calendar.

More at http://code.google.com/apis/apps/sso/saml_reference_implementation.html

See also the demo: http://code.google.com/apis/apps/sso/saml_static_demo/saml_demo.html

January 22, 2007 -- OpenID vs SAML OpenID had been the topic of a few conversations, and then I find two nice articles on the topic. I think the choice is still clear that IHE must use SAML.

Comparison: OpenID and SAML Jeff Hodges, Draft Technical Report Version -00

http://www.xmlgrrl.com/blog/archives/2007/01/21/openid-and-saml-a-swirling-nexus/ OpenID and SAML: A Swirling Nexus] Eve Maler, XML Grrl Blog

January 10, 2007 -- Good news in the industry

Liberty Alliance, Microsoft Discuss Identity Protocols Jeremy Kirk, InfoWorld

Pilot Projects

There are a few pilot projects that we are working with to gather lessons-learned so that the XUA profile can be better.

Middle East Technical University, Turkey

See Implementation Experiences On IHE XUA and BPPC December 5, 2006; Tuncay Namlı and Asuman Dogac, Software Research and Development Center, Middle East Technical University, Ankara, Turkey

Also at http://www.srdc.metu.edu.tr/publications

Project Sentinel / Northwestern XUA Testbed

Georgetown University in collaboration with Northwestern Univeristy. We plan to modify the OHF IHE Document Consumer and the NIST Registry to support SAML assertions. The plan is to demonstrate this at RSNA 2007 Annual Meeting. A proposal for such a demonstration has been submitted to the RSNA Radiology Informatics Committee for their consideration at their Feb 2007 planning retreat.

Meeting Notes:

December 12th, 2006

Eclipse Open Healthcare Framework

Don ??

HIMSS - GSA Pilot

PKI in Health Care: HIMSS/GSA E-Authentication Pilot Project

Participating RHIOS

1. e-Health Connecticut
2. Michigan Data Sharing & Transaction Infrastructure
3. CHRISTUS Health of Texas
4. Community Health Information Collaborative (Minnesota)
5. Nevada Single Portal Medical Record
6. Ohio Supercomputer Center Bioinformatics
7. Virtual Medical Network (Cincinnati, Ohio)

See Presentation given to University of Minnesota's Health Informatics graduate program Dec, 2006, Pete Palmer and John Fraser

European Pilot

Contribution by Emmanuel CORDONNIER (April 3, 2007)

France : One project is the Dossier Medical Personnel (National PHR www.d-m-p.org) which aims to control any access from Health Care Professionals (www.gip-cps.fr) and Patient through a "Federated Identity Portal" which checks the validity of the HealthCare Professional certificates (Smart Card based PKI), the existence of the National Patient Identifier (which is eventually different than the Citizen National ID) and the authorization given by the patient for this HCP to access her/his PHR. The portal is delivering a "token" containing a SAML assertion which are both required to "open" the access to the National PHR Registry/repository (both are merged but it is a Virtual but they will be implemented by a set of providers, chosen by the patient. So the portal will have also to send back the address of the Registry/repository for this particular patient - which can change in one day!). This DMP is still at the project level and the first official tender (after one year of experimentation) was emitted end of March, 2007, for an official start date presently (it may change...) fixed to 1Q2008.

I will have a look on your work and transmit it to the DMP people (which have eventually definitely - I hope so - choosen IHE XDS as a basis for the service).

I know that XDS based projects exist in Italy at least and Germany, Nederlands at least are looking to it, but I do not know if they use SAML, yet.