Hey Ryan, what is a relying party?

How do payers tie an identity (assuming there is trust for the identity provider) to a member? Similar question for a payer.

What does XMS stand for?

@Ryan, can you please define the HHS XMS flow?

Overview is coming shortly

It stands for External User Management System (XMS)

@ Gaurav Thank you.

@Josh the draft HL7 Interoperable Digital Identity and Patient Matching IG includes the member identifier in the OIDC user profile; see: https://build.fhir.org/ig/HL7/fhir-identity-matching-ig/digital-identity.html

@Josh Lamb: there are multiple ways that can be accomplished. Many payers outsource that activity to a third party credential service provider, but can also carry out that work themselves by offering members an opportunity undergo a step-up ID proofing process if they want be able to use their credential with parties outside of the payer

^ that of course is the abridged version, and deserves a longer discussion

How does this work integrate with the work HHS is doing with Real-ID?

Thank you Julie and Kyle. If my understanding is correct, if there was a network of payers/providers who elected to have these ids created then they could begin to share information using this identity. If this is correct, I am still a bit fuzzy on how a member/patient match will work so that the single identity can begin to represent many separate identities. Or is this meant to help support member/patient match but it does not solve that issue?

I would encourage thinking about this from the customer-first lens. Having to have someone sign up with an external site/company/app is really clunky. Would encourage thinking about how to make this happen via API calls vs. separate user experiences that are disconnected from the user experience the person is actually trying to use.

No OAuth2?

+1 Cille

great point Cille - i totally agree

Or is OAuth2.0 implied with OIDC?

The user experience @cille is the same as it is today. You would go to a site/app and register yourself and log in.

Is the idea that the Mayo Clinic (say) may join XMS so your patient portal credentials issued by Mayo, which become XMS-compatible, can then be reused to authenticate you at other health systems?

It will not be the same experience for consumer portal users, who today do not have to be formally credentialed - how portals get assigned today is not typically through an IAL2 compliant credential process. So this will be different for consumers.

so Humana.com or centene.com or ID.me can be an credential service provider? isn't there still a problem with the user having a bunch of CSPs?

As a payer and relying party in this future state, our members would still need to create an account and go through identity proofing with us before leveraging XMS, correct?

Yes Thats how I understand

@kurt yes although you as a relying party could accept a digital identity from another source

@lloyd yes, any of those could be CSPs. You have a bunch of CSPs today in your consumer world. We are looking at reducing the number of CSPs you would need to authenticate yourself across systems.

yes @julie

I was/am under the impression that HHS would participate in collaborating with the Real-ID work and extend its use for HealthCare. Is that not accurate?

@Guarav Can you address Ricky's question on how XMS uses OAuth and OIDC?

@Ricky - Yes OAuth2.0 is implied in OIDC support.

What are the privacy guarantees of XMS? Will patients be able to have confirmation that usage of their certified credential will not be tracked across various servers?

thanks - so at registration time we should say "if you have registered at any of these places you can use those credentials - followed with list of trusted CSPs". And at login we should say the same. And we could just send them to our preferred CSP even if they said they wanted to register with us, or didn't understand the question

How do the back channel connections get established? It that an out-of-band dependency that you have to assume already exists to support this flow?

Directionally @lloyd, yes. In a decentralized way using Tiered OAuth or using the XMS identity broker service.

Seems like lots of confirming steps needing to be taken by the patient. Step 1 Jane said she wanted to get the info from the health care organization. Why can’t the credential assertion contain all of those confirmations vs. having to keep going back to the patient?

@lloyd, For a CSP to be integrated on XMS, the CSP has to be certified by a third-party certifier such as Kantara Int or DirectTrust. We will only bring on CSPs that can provide the certification that they are NIST 800-63-3 Compliant.

Do you need to click to get step 7?

does the patient select the CSP or does the XMS find the "appropriate" CSP? I'm still trying to nail the user experience.

The idea is that UDAP Tiered OAuth feels like single sign on but it's enabled dynamically using trusted digital certificates.

@lloyd - It is a user driven process to select the CSP they have an IAL2 credential

Can you summarize the roles and how many players are wanted in each role

@Lisa: the back-channel is standard OIDC where the hospital can use the OIDC user info endpoint to request data from the IdP.

OneRecord like to participate since we did TDRAAP

Are there plans for an API to support IL2 Compliant accounts to be created using pre-existing information? This would allow for upgrades without user engagement (with opt-in).

@Deven, from a privacy point of view, each actor should be confirming that the user is ok with the data that actor holds being shared with others. This could be simplified by user preferences like "always share my information with trusted entities", etc.

Is there a plan to support an ecosystem of 3rd party digital health apps using this system?

@Josh - User engaged ID proofing is required for an IAL2 account (and not to be done on user's behalf) per NISt - APIs, etc. could be/are beneficial for enriching the data attributes about the user

@Sebastian 3rd party digital health apps play a critical role in UDAP flows, so yes, absolutely

👍🏻

Thank you apologies have to jump. Look forward to receiving the deck and your summary. GREAT!

Is there a timeframe when you want a response on POC participation?

Hi Ryan, are you planning to send out these slides ?

;-)