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

[Eve Maler]

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


*Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging Technology
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
Join our ForgeRock.org OpenUMA <http://forgerock.org/openuma/> community!

On Mon, Oct 19, 2015 at 2:26 PM, Sarah Squire <sarah at engageidentity.com>
wrote:

> 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
>
> _______________________________________________
> 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/20151019/4474307c/attachment.html>