[Openid-specs-heart] Draft HEART Meeting Notes 2015-10-19 (format feedback requested)

[Sarah Squire]

A quick note on the meeting notes: I got some feedback that it would be
helpful to attach names to statements in the notes both to make it clear
that the statements are not necessarily the opinion of the entire working
group and to make it clear whom to follow up with in case of questions or
further discussion. I did that this week, and it has made the notes rather
long. Would it be helpful to have a quick summary at the top in the future?
Any other general meeting note feedback?



*Next Week*


No call next week due to the OpenID Foundation Meeting.


Participants

Debbie Bucci

Justin Richer

Sarah Squire

Glen Marshall

Adrian Gropper

Jin Wen

Thompson Boyd

John Moehrke

William Kinsley

Gunther Meyer

Dale Moberg

Eve Maler

Abbie Barbir

Steve Greenberg

Danny van Leeuwen

Edmund Jay

Jim Kragh

Tom Sullivan

Sequence Diagram of Registration Use Case

Diagram can be found here:
http://openid.net/wordpress-content/uploads/2015/10/PHR-to-EHR-simplified.pdf

Justin:

There are several places in this diagram where Alice has to authenticate
across different domains, which OIDC would help with, but we might not want
to include them because we are trying to look at the needs for OAuth
specifically with this use case.

Debbie:

It would be great to put the binding ceremony into the diagram more
explicitly.

Adrian:

When we talk about binding, we should consider the second use case when a
custodian is included in the binding process.

Justin:

That is certainly in scope for the working group, but it is not in scope
for this use case. However, it may be useful to revisit the concept of
identity binding with all use cases in mind.

Debbie:

Should we map where UMA, OIDC, and OAuth connect together?

Justin:

We could map out a full cold boot where none of the systems have been
introduced to each other before.

Danny:

What does the “out of scope” note mean?

Debbie:

The “out of scope” note only applies to the information directly below it.
It’s from an early draft of the use case.

Gunther:

The dotted lines and solid lines are good, but should the flow start with
Alice selecting a PHR?

Debbie:

Alice was shopping around for a PHR. We can make that clearer.

Gunther:

What happens when Alice delegates access to someone else?

Sarah:

We do have another use case that focuses on delegated access.

Debbie:

The other two use cases build on this registration one. Right?

Justin:

All of the use cases are interdependent and can be used together.

UMA Sharing Design Patterns

http://lists.openid.net/pipermail/openid-specs-heart/Week-of-Mon-20151019/000547.html

Eve:

UMA authorization servers will have to do protocol as well as policy. In
order to facilitate interoperability, some policy patterns have to be
established.

There are four major identified patterns:

   1.

   Individual to agent-of-NPE
   2.

   Individual to NPE
   3.

   Individual to role
   4.

   Individual to individual

There is some concern about 3, because RBAC is so hard to do to begin with.
We can have a chained-delegation feature, but that seems to only work well
when everyone is using the same AS, which is what we are trying to get away
from. How do we accomplish 2 and make sure the information gets shared with
people who actually get things done. It leaves some things undefined.

Bill:

The way healthcare systems typically work is that Alice grants someone
access, and they will take the data and import it into their EHR as part of
her chart. They won’t constantly go back to the other one. A more common
pattern is that once Alice grants access, they will move the data into
their system which will have their own access control systems.

Justin:

It will be common for people to have export access to one system and import
access to another system, so ultimately that is a cache consistency
problem. Ultimately, these patterns boil down to Alice sharing to someone
with an aspect. Numbers 1 and 4 are identical except Bob gives her a
different email address.

Eve:

They are different in a legal context. There may be additional claims where
Alice asks the recipient to adhere to certain restrictions, perhaps
restrictions that Bob as a private individual couldn’t meet. It may be that
even though the protocol looks identical, Dr. Bob may be held to a higher
legal standard than regular old Bob.

Adrian:

I did a small talk about the BLT sandwich and UMA at the Global Identity
Summit. I could present it. I see what you’re doing in terms of
interoperability. However, there’s another dimension of the client that
each party is using. Wouldn’t it be easier to combine the client and the
requesting party in the pattern?

Eve:

Maybe we should consider the client along with the requesting party in our
thinking?

Justin:

Consider them separately, but realize that claims may represent the
requesting party or the client.

Eve:

Clients can’t get trust elevated with claims.

Justin:

If the client can provide a signed assertion about itself to the requesting
party endpoint, then it can represent itself.

Eve:

That’s not the way it was intended to work, and it might not be
interoperable.

Sarah:

Are you imagining these as policy restrictions? Or are we just coming up
with a common language for common patterns?

Eve:

It could be that there’s one pattern that’s so obvious we standardize on
it, or we could leave patterns open.

Gunther:

Sharing with individuals is useful, but it’s troublesome because
individuals might change roles, so sharing with an NPE or a department of
an NPE might be more valuable.

Justin:

That would require a common taxonomy for hospital hierarchies and having
users actually look at them and have to decode them.

Eve:

I see both sides. Pattern 2 is very elegant. You can’t keep people from
sharing with individuals, so we should keep that available, but maybe
sharing with entire organizations is what we should standardize on, but
that violates the security principle of least access. The right way to do
access control is to do a default-deny approach. Pattern 2 is a default
permit approach, and that’s worrying.

Bill:

My concern is that Dr. Bob will load the information into his EHR, and he
needs to share it for treatment, payment, and operations.

Justin:

We do need to acknowledge the caching issue, and just assume that it’s
going to happen. We can actually embrace that. When the data gets pulled
in, it keeps records of when it was pulled, so it’s not treated the same as
local data. Also, what if when Alice shares it, she shares it with Dr. Bob,
but Dr. Bob’s system identifies the correct ABAC policy for that
information.

Adrian:

The first thing doctors do is ask for a gmail address to communicate with
the patient. The doctor can put that in the chart. The fact is that the
ability to keep the NPE out of communications is hugely valuable.

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