[Openid-specs-heart] Draft HEART Meeting Notes 2016-03-28

[Sarah Squire]

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

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


Sarah Squire
Engage Identity
http://engageidentity.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160328/bbd959fe/attachment.html>