HIMSIG20080530
Liberty Alliance Project
SIG Health Identity Management
May 30, 2008
12:00pm-1:15pm EST
Conference Call
Meeting Notes
Author: Kurt Kolok
Attendance:
Asa Hardcastle, OpenLiberty Expert
John Fraser, Mednet USA (Co-Chair)
Bob Pinheiro, Independent Contributor
Lena Kannappan, Fugen Solutions
Helen Hill, Henry Ford Health System
Dave Weitzel, Mitre
Sampo Kellomaki, Symlabs
Mick Talle, University Bank
Brett McDowell, Liberty Staff
Kurt Kolok, Liberty Staff
Agenda:
1. Welcome and introductions
2. Bob Pinheiro – Identity Theft SIG status overview, discussion of high assurance electronic trust services and identity theft prevention
ID Theft SIG has produced a few documents on the wiki (technical aspects related to ID THEFT, Definition document). The SIG is looking at purpose, etc… with the idea that they would make recommendations to LAP re: taking a proactive role in developing a specification, best practices, strategies, provisions, etc…
There are different definitions of ID Theft, the most common of which is making fraudulent purchases online. For the purposes of the SIG we mean someone impersonating someone else by opening an account in their name. Keeping information private is good, but the information is out there and it is hard to prevent it from falling into the wrong hands. We are thinking about stronger identity authentication; this approach fits well with the Identity Assurance Framework(IAF) (a basis for stronger authentication of identity claims).
• Electronic trust services
• Stronger authentication
• Anything LAP could do with IAF to support stronger authentication for consumers.
• OpenID provides a credential but no identity proofing.
• Low assurance is not of interest, it is the high assurance we are more interested in.
• Proofing, business issues, credential management are all addressed to a certain extent in IAF.
IAF determines what you have to do to get a credential, etc… A token or credential is issued when identity is proven. Relying Party would have to trust the identity accredited by Liberty. IdP sends the assertion back to the Relying Party to confirm whether or not the person was able to prove their identity.
• Need to get these high assurance identity services into the hands of ordinary consumers.
• Need to address how the RP can tell if the identity being claimed has been registered
Instead of the IdP selling direct to consumers maybe they would sell to Relying Parties. Anyone who issues a new account is supposed to have an identity assurance policy (outlining a way of verification of identity). It may not be Liberty’s job to identify those business models.
One thing LAP could do is have a Discovery Service (DS) that could match an identity with a specific IdP (identity proofing for consumers).
Banks to Consumers: haven’t these issues already been addressed on the consumer level? Consumers may need to show two forms of ID, but today’s requirements may not align with Liberty’s requirements (they should conform to IAF).
• Organizations are more worried about following FFIAC vs. Liberty.
• Financial services are good candidates for taking on the credentialing burden.
• May or may not be direct mapping.
A Relying Party can allow consumers to access different assurance level information. Nothing restricts banks to only using IdPs.
How is the IdP going to make money at this (they need a business reason)?
Banks do issue some kind of credentials, but do banks want to be IdPs to the consumers?
Are we questioning whether or not consumers are going to request distribution of some of their credentials? Are we questioning whether or not consumers will want such a service? Helen Hill and Mick Talle(?) worked on a GSA program along these lines—consumers wanting credential providers to give them credentials. Someone would need to go out and market it to consumers and convince them they need the service. In order for the patient to run any form of application they would need some sort of credential. There would have to be a certain strength level for the consumer to be able to run the application. It was noted that this seems to be a recurring theme.
Patients need credentials but can we move them into the broader world of IdPs?
3. Asa Hardcastle – OpenLiberty status overview, discussion of ID-WSF’s applicability to medical records
Brett and Eric have shared how Liberty can play a role. RPs have to have something to work with in order to give the patient the credentials. There are large privacy and security concerns. The business drivers you would use in OpenLiberty include a very well vetted framework.
• Need IOP and conformance support from LAP.
• Need someone to prove you can do what you have adopted.
These systems are based on work from the enterprise community. It is also based on relationships which have already been established. Business relationships need to be set up beforehand. The following comes into play once the identity has been established.
Open Liberty is:
--focused on continuing dialogue and drafting white papers and specifications re: open identity concepts.
--an open source implementation.
--focused on web services, strong XML SOAP layer.
RPs need to have libraries that allow them to communicate with large vendor applications. This allows software developers to build components that work with the providers. Discovery Service would match profile with identity. Anyone who develops an application can use Open Liberty.
We have recently added 2 developers, 2 implementations of SPs (1 in a consumer environment), and SAML 2 SPs as well.
We have a number of services which might be of interest to the HIM SIG.
ID-WSF: once you have done single sign on you have the issue of exchange of information (which is necessary for applications to work together to provide the best experience to the end user) but need to engage the user selectively.
-- You log in
-- prove who you are
--application would want to get information about you.
-- service you just decided to use wants access to your information.
-- it will ask you if it is ok to access that information
-- there will be an interaction at this time (Liberty is a major component of this process).
-- Permission is given to the source rather than to the application which happens through a process of interaction.
ID-WSF provides a rich environment. Discovery Service is able to issue tokens that give your profile to your WSP. RP would ask for access through the DS. DS would give RP ability to pull information and possibly write information.
Sounds similar to CardSpace Info Cards: RP can discover who the IdP is to access the information (seems to support a canonical use case for members of the healthcare SIG. MedNet is working on a use case in the emergency medical information area.
Use Case example:
ER Doctor has to be credentialed so he/she logs into a system, discovers where the patient information is and through some kind of role/authentication/authorization service accesses the information.
Assumptions: the patient exists outside that particular hospital’s health records and can actually exist outside of RHIO.
Background:
Personal health record: a record that lives in the doctor’s office (or data service).
Components out of the ID-WSF environment would include Discovery Service and People Service (understanding the relationship between emergency personnel and the person who manages the information). A person may have stated that they do not want anyone to access this information. In the event that the patient is unconscious the user would have to permission the regulation to access the information. Service manager for the record is going to allow what is enforced by law. Instead of the individual needing to do something specific they would need to agree to the requirements.
Use Case: doctor or ER staff needs to access a patient’s information.
The patient is unconscious and would need to have something on them which would give someone enough information to bootstrap (driver’s license for example). This generates an authentication token which allows an entire flow of information to take place. The patient would also need to have something on him/her that points to where his/her medical records are. A healthcare provider could run a healthcare record service. There would be an endpoint reference which could be retrieved.
There is the matter of economics/deployment policy when the ER doctor logs in to the hospital system to access the information you would need a trusted environment (it could be in more than one place).
SSL or PSS layer—strongest way is to have signed messages that are encrypted at both ends with a prearranged authentication certificate. You would have to create a relationship between the entities to begin with. From the ID-WSF layer, there is a service called personal health records service which is tightly controlled/tested for conformance. There needs to be a standard that makes this work (services template and services specification applied to medical information). The DS is the first thing that gets hit; it locates where you can get the person’s information and identifies who is requesting it.
Does the DS enforce authentication and authorization for access to the healthcare information?
It could be anyone. It could be that one entity has both records and authorization. ID-WSF could be used for both DS and to access the information. PHR can have an interaction requirement in addition to the above (interaction service could be used as well). You would specify the type of service you’re looking for (tell DS ‘here is the token that identifies who I am and here is what I’m looking for”. The token would have to have certain information. It would depend on who issued the token (there would need to be a standardized set of requirements for finding someone’s health records—a record locator system). It could simply be a number on a card which the individual possesses.
NOTE: OpenLiberty is moving quickly and growing rapidly. Those involved believe it is an exciting time to get involved and is an ideal place to act as a driver to develop specifications.
We will continue the OpenLiberty conversation on the next call in two weeks.
ACTION: Asa will return in two weeks to continue discussions (Friday June 13).
ACTION: John will start an email thread to tighten up the use case.
4. Comments and questions
Call ran out of time.
Meeting Adjourned
