[Openid-specs-heart] Draft HEART Meeting Notes 2016-07-25

Fri Jul 29 20:32:19 UTC 2016

This group may be interested to see the discussion that the UMA group
subsequently held on this subject. Rather than quoting the whole thing
here, I'll just draw your attention to the section of our minutes
<http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-07-28>
called
"UMA specs wrt standardized APIs with standardized resource and scope
semantics". Warning: It's in tech-speak. ("UIG" is UMA Implementer's Guide.)

Netted out, I *think* there's an interesting solution here for how a FHIR
server, as an UMA resource server, and an UMA authorization server could
sort of do a courting ritual and indicate to each other that some
ready-made resource and scope semantics are in play.

(Hmm. It's not a complete solution, I'm realizing. But it's a start...)

*Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging Technology
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
*ForgeRock Summits and UnSummits* are coming to
<http://summits.forgerock.com/> *Sydney, London, and Paris!*

On Mon, Jul 25, 2016 at 2:41 PM, Adrian Gropper <agropper at healthurl.com>
wrote:

> Great progress today but much left to do to reach consensus. Here's where
> I hope we have consensus so far:
>
> *HEART will, at the very least, enable the full range (full range meaning
> HIPAA, non-HIPAA, and 42CFR endpoints) of HIE transactions using
> patient-level FHIR resources that may or may not have HL7 Confidentiality
> Codes as metadata. HEART will do this through the issuance of an UMA
> Requesting Party Token by an UMA Authorization Server.*
>
> Beyond this point we got some pushback from Eve as relates to how scopes
> might relate to standardized subsets of patient-level FHIR resources
> (allergies and/or medications) and whether UMA wants to allow down-scoping
> access to a registered resource based on the Authorization Server request
> or by introducing sensitivity to metadata like an HL7 Confidentiality Code.
>
> This seems like a critical next step to resolve. If UMA does not choose to
> allow subsetting by the AS (or the Client or Resource Server as well, I
> suppose) using the UMA scope mechanism, then the only solution would be for
> a typical EHR resource server to register dozens or maybe hundreds of
> individual resources even though these resources are all well known as part
> of the FHIR standard. We might call these standard sub-resources. If that's
> what UMA wants, so be it.
>
> Even if UMA decides that scopes cannot be used to subset a resource, how
> would UMA deal with release of information based on a piece of metadata
> like a Confidentiality Code or a data of acquisition for a particular
> sub-resource?
>
> (Note that the HL7 spec allows Confidentiality Codes to be set on a
> resource by the resource server's policy and/or by the patient. This could
> be important to the user experience both at the RS and at the AS.)
>
> I hope the UMA folks can make clear how HEART should deal with FHIR
> sub-resources and metadata associated with a sub-resource.
>
> Adrian
>
>
>
> On Mon, Jul 25, 2016 at 5:01 PM, Sarah Squire <sarah at engageidentity.com>
> wrote:
>
>> 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
>>
>> 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.
>>
>>
>> Sarah Squire
>> Engage Identity
>> http://engageidentity.com
>>
>> _______________________________________________
>> Openid-specs-heart mailing list
>> Openid-specs-heart at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>>
>>
>
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160729/7e8015a7/attachment.html>