##Attending:

Debbie Bucci

Cait Ryan

Sarah Squire

Kathleen Connor

Glen Marshall

Tom Sullivan

Josh Mandel

Thompson Boyd

Adrian Gropper

Scott Shorter

Justin Richer

Jim Kragh

Dale Moberg

Hope Morgan

Jin Wen

Nancy Lush

Edmund Jay

Discussion

Debbie: Scott has been working on the terminology, and he’s been thinking about folding the use cases into that.

Scott: There are some terms on the wiki that’s hard to get to. We’ll be putting that terminology on the OpenID wiki by next week’s call. Once those terms are there, I suggest we represent the use cases on the wiki itself so we can crosslink the terminology.

Sarah: That’s a good idea. The plan has always been to put the use cases on the wiki long term.

Debbie: Eve made a suggestion about coding the use cases and adding structure.

Sarah: Putting them on the wiki will force us to add structure.

Scott: Agreed.

Debbie: Let’s take a look at Eve’s use case. Alice is married and wishes to selectively share her medical record with other people.

Tom: This use case could involve devices that are not connected to the internet. Alice could be entering it instead of having it transmitted.

Adrian: The delegation use case (elderly mom with caregiver) is designed to highlight the fact that UMA is allowing others to access the data. I think if you take out the device data, Eve’s use case and my use case are the same thing. I’m not sure what’s Eve’s intent was in putting device in there. Any personal data will look the same to our profiles.

There’s delegation of authorization of authority and there’s delegation of access.

Sarah: I don’t think I understand the distinction you’re trying to make.

Adrian: The “others” in the title have nothing to do with the resource owner.

Sarah: Yes they do. The resource owner has delegated access to them.

Justin: I think maybe Adrian is conflating resource owner with data subject. I’m having trouble following.

Adrian: In one case, you’re delegating to someone who will use the data. In the other case you’re delegating the ability to delegate access.

Sarah: There’s no technical difference between the two.

Adrian: But when you do that, the resource server may know it’s a case of delegation. It is out of band of the UMA profile. That’s delegation from the resource subject to what we’re calling the grantor. They control the authorization server. That’s what I call delegation of authorization.

Debbie: Now that Eve has joined, is there a specific kind of delegation we’re talking about?

Eve: We’ve been defining some terms in UMA legal. We now have a concept of a “resource subject” or “data subject” or “pii subject”. I think what we mean is the person controlling the authorization of data that is relating to them.

Sarah: Would you say that’s the difference between the use cases is that the grantor is the resource subject in yours and the grantor isn’t the resource subject in Adrian’s?

Eve: Yes

Eve: We can always make another use case that adds IoT. There are a lot of reasons to want unified sharing. We can stick to that and not add complications of IoT.

Debbie: Who are the actors that we’re delegating to?

Eve: Alice’s husband would probably be a good exemplar of everyone she could share to. I just happened to come from an institution where I had to fill out an advanced directive. I also have a list of medications and immunizations. We’ve talked about the virtual clipboard.

Adrian: Eve, in your use case, are there any documents or attributes that are public and not protected?

Eve: Let’s say you have an API with a hundred elements of data. Let’s say 97 are worth protecting and three tend to be things you want to be publicly available. You would still put them under protection and set policy making them public, that way you have an audit trail and if you ever want to protect it, you can do that easily.

Adrian: Is there a situation where Bob might not want to disclose who he is to get access to Alice’s resources?

Debbie: I think we’re trying to start with a simple profile.

Sarah: There is nothing in the protocol that prevents Alice from setting a policy on her authorization server allowing access to a resource with no login required and no access record possible.

Adrian: Okay, that’s what I wanted to know.

Debbie: We’re totally excluding IoT?

Eve: Let’s leave out of scope things that are directly delivered by a device, but let’s leave in self-reported data like blood pressure, pulse, etc. For example, medication list is more or less self-reported.

Debbie: Okay.

Eve: The use case isn’t fleshed out. The problem statement is the meat of it. It goes beyond the OAuth use case in talking about controlling access. I could flesh out the rest of the use case by next week.

Jin: There might also be other information that might be of interest to the patient to share besides medications. One of the goals is to allow patients to donate and access research data.

Debbie: We will update the problem statement.

Eve: I can start to add a little bit of the flow, but I mostly want to work on the problem statement so that we can work on semantic profiling.

Adrian: I don’t see why we need to break out the different situations in terms of why the data is moving across a FHIR interface.

Debbie: What comes to mind for me is consent elements and auditing elements.

Eve: You can see the early-stage "UMA legal" terms here; focus on Resource Subject and Grantor definitions for now: http://www.commonaccord.org/index.php?action=doc&file=GH/KantaraInitiative/UMA-Text/Terminology/Terms_0.md