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

Sun Jul 31 20:47:59 UTC 2016

Eve

One thing that I am concerned about is that we are explicit for the consumer about what the goodness of fit between this courting ritual and their perception of what it is that is actually choreographed.

I am not sure how if ready-made resources and scope semantics mean something along the lines of Sensitivity Categorization as was used in the Consent2Share projects but if they are one of the things that we learned was that regardless of who does the coding (I,e,. the expertize of the SME’s that are involved) there will always be false positives and false negatives because – as Led Zeppelin made plain in Stairway to Heaven – “You know sometimes codes have two meanings.”

I would like to ensure that one of the baked in premises of any work we release to the world includes a consumer facing clarification that when you rely on a method of indicating privacy preferences that is reliant on treating a coded value as either sensitive or not that – at least for some codes – there is some likelihood that this categorization may be a false positive or a false negative.  

If we aren’t explicit about this risk I feel we have failed a fundamental test of trustworthiness by not being transparent about the things we know when we present on this topic.

Not directed at anyone specifically but I get anxious thinking about folks trusting that we are able to accurately do these kinds of things.  As Glen Marshall pointed out – we have to get better at what we are trying to do and until we can do it and convey the risks of false positives or false negatives we owe it to the consumers of the world that are trusting in us.

Aaron

‘ 

Aaron Seib, CEO

@CaptBlueButton 

 (o) 301-540-2311

(m) 301-326-6843

cid:image001.jpg at 01D10761.5BE2FE00

From: Openid-specs-heart [mailto:openid-specs-heart-bounces at lists.openid.net] On Behalf Of Eve Maler
Sent: Friday, July 29, 2016 4:32 PM
To: Adrian Gropper
Cc: HEART List
Subject: Re: [Openid-specs-heart] Draft HEART Meeting Notes 2016-07-25

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/> 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/20160731/923a063a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 3142 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160731/923a063a/attachment-0001.jpg>