Attending:

Debbie Bucci

Sarah Squire

Kathleen Connor

Thompson Boyd

Nancy Lush

Eve Maler

Cait Ryan

Walter Kirk

Adrian Gropper

Ken Salyards

Scott Shorter

Oliver Lawless

Dale Moberg

Julie Maas

Glen Marshall

Jin Wen

Hope Morgan

Celestin Bitjonck

Jim Kragh

Discussion:

Debbie: I would like to focus on understanding the resource sets and how they’re used. I will assume that the resource server that has a relationship with the authorization server, it seems like each RS will have an AS. Typically, wouldn’t the client be registered with the authorization server as well?

Eve: If this were straight OAuth, it would be true anyway. OAuth works in a way so we would call it all narrow ecosystem.

Debbie: What I didn’t understand is that OIDC is an API and you have a protection API and these layer on top of the OAuth protocol, right?

Eve: Right. They’re UMA standardized bits of the protocol that didn’t exist in OAuth. Similar to the way that OIDC invented its own identity API and OAuth-protected it.

Debbie: And you have similar endpoints for UMA authorization and protection.

Eve; Right. Those are OAuth protections of the UMA API.

Debbie: When the resource server registers the resource set and scopes, does that happen twice?

Eve: The second time that wording appears - maybe a better wording would be registering permission. It’s now a particular client acting on behalf of a particular Bob. In the first one, there’s no client in the picture yet.

Debbie: Wouldn’t the client know what resources it wants when it goes to the resource server?

Eve: Yes, but it doesn’t know the resource set id, it just hits a URL. It gets back information in the header telling it where to take the permission ticket.

Debbie: So a client goes to a FHIR API, and the resource server has registered with the AS. So the client then has to go to the AS?

Eve: It’s no different from how OAuth protected resources work. The client has to be aware of what it can do with the API and aware of the protection mechanism.

Debbie: So instead of Alice needing to add Bob as another authorized user for the flows to that resource, the advantage of UMA is to give in-time, temporary access without having to have that full authorization piece in place all the time.

Eve: The resource server could have invented a proprietary mechanism for sharing. The upside of UMA is that you could go get an open-source library and do it yourself. Also, OAuth isn’t built for sharing with another party. You can also hook up a resource server to an authorization server set up by another person or organization.

Debbie: I realize it’s a burden for a patient or a consumer to have maybe hundreds of endpoints, but if you’re thinking about a provider who has a resource, that could be thousands. So the resource set is pre-registers so Alice can set her authorizations.

Eve: OAuth is a synchronous authorization grant. UMA enables asynchronous.

Debbie: I’d like to address Kathleen’s comments

Adrian: I want to talk about consent and authorization. Consent involves Alice and the resource server. It’s a contract, effectively. Authorization is something that happens when the client is available to be specified to whoever is going to do the authorization - in this case the authorization server. I think it will help everyone if we use consent and authorization in this way.

Oliver: Consent is an agreement between an individual and a server?

Adrian: To the extent that you’re saying to someone who has your data, “here’s my policy” that is a prior agreement.

Oliver: You said there was a contract between the client and the server?

Adrian: The contract is between the resource owner and the server.

Oliver: Yeah, but the contract of consent is between the provider and the patient. The method of transmission could change completely.

Glen: Consent is really a policy aspect. It doesn’t imply anything technical. Authorization has specific security meanings. Let’s not try to overload these terms or create variant definitions.

Debbie: We had hours and hours of arguments and discussion when we did privacy on FHIR. Consent to me is a contract between the resource owner and the requesting party.

Oliver: All I’m saying is the technology is not the other endpoint.

Adrian: I’ll drop it. I was trying to be helpful. I don’t want to go down a rathole. The goal of UMA and HEART is to define protocols to be used for health information exchange. Just like you might be asked by hospital to consent to your information being shared, then there would be a series of policies and other things to control what goes through the HIE. HEART fits the same slot.

Debbie: So for the last profile that we’re focused on - it’s the UMA profile for FHIR. As a start, can we agree that the resource server is a FHIR server and that the resources would be FHIR resources?

Oliver: Yes, but it’s not just FHIR.

Debbie: Agreed. We just need to layer on top of it.

Eve: We’ve said that we’re profiling for FHIR as an exemplar, so it’s clear that we’ll have some resource sets that are targeted at FHIR.

Kathleen: While the clipboard idea is cool, there are some policy issues that might hold that up. It might be better to pick a subset which could be used at some point to create a clipboard. Just assume that this data is coming from an EHR.

Debbie: I don’t think we can assume that there’s confidentiality codes.

Kathleen: If the patient adds data and marks it as confidential, when it goes back into HIPAA-land, it may not have standing.

Adrian: Let’s focus on the fact that we agreed that we’re talking about a FHIR client talking to a FHIR server. Do we have a consensus on whether we’re only dealing with patient-level resources?

Oliver: That’s fine. It could be the case that this get launched at an introductory level. You can’t enable this until you have agreements between the parties.

Adrian: Whatever we do in HEART at the patient level has to be able to be mapped to NYP patient form I mentioned earlier.

Kathleen: There’s no problem with that. The term we’ve been using is consent directive.

Debbie: I would say that the RPT that is issued by the authorization server is a release for information. Not specific to NYP, or any particular law.

Eve: They contain entitlements and permissions. We’ve had trouble mapping roi forms to UMA because there’s no equivalent.

Debbie: There are some things we could enforce.

Oliver: I think we should just keep going and see what syncs up.

Eve: I would love to do that. We’ve had trouble mapping.

Oliver: What if we just talk about a testing environment and keep going incrementally, and then once there’s more detail.

Adrian: If we agree to only use the limited set of terms - FHIR resources, patient-level - can Eve draw up a sequence diagram?

Eve: We are not doing an roi. We’re doing a consent directive. It’s more akin to terms and conditions.

Debbie: The RPT is a consent to release.

Ken: Why don’t you just say it’s a FHIR consent directive?

Adrian: We don’t share the same definition of consent. What’s the difference between an ROI form and a consent directive?

Debbie: I really want to put consent aside and talk about how you actually get an RPT that a resource server defines resource set that Alice can set her preferences to, that a client can request, and a resource server can release.

Oliver: I think the base case is the provider to the patient.

Debbie: That’s not the use case we’re trying to do. Alice wants to share with another provider.

Let’s say that we have the 15 base resources. Could the token that goes back to the resource server have a subset of what’s there? If the client asks for more than it’s allowed to have.

Eve: The client attempts access by making API calls one at a time.

Eve (in chat): My availability in August: Here Aug 1, absent Aug 8 (business trip to Australia), here Aug 15, absent Aug 22 vacation), here Aug 29.

Nancy: So you’d request each thing you want one at a time.

Debbie: I thought the advantage of a resource set was to be able to find it all with one.

Eve: There are web resources, FHIR resources, and there’s a reason UMA calls resource sets resource sets. The resource server is authoritative for its own API, resource set boundaries and content are its own business. If we made a ‘first visit resource set’ allowing for a single API call that returns that information.

Debbie: Can she set individual scopes on the resource set?

Eve: Yes. If you have a fitness watch, your scopes could be kinds of information, or kinds of access. It’s going to be odd if they’re not orthogonal to each other.

Debbie: So my question is if I request meds, allergies, and conditions. When Alice is presented with her authorization. Can she say that her dentist can’t have meds? Can she pare that down?

Eve: If someone is asking for information, and you want to send less information, that’s a very hard technical question. In access management, that’s a very hard problem to solve.

Debbie: So if we need a subset, we will need multiple data sets.