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.

Eve added: The names are very helpful. I for one don't mind the length (pixels are cheap). Thanks, as always, for contributing in this fashion!