Forward actions from the minute or so after Sarah had to leave the call:

Now that we've combed through one use case end to end, let's start putting together the semantic OAuth document based on this use case. We need to go through everything in there and make sure we've got the right scopes and scope structures to solve at least this one limited use case. That will give us a starting point for the rest of the work.

While we're at it, we need to make sure that we could build this using what's defined in the applicable security specs, too. If not, we need to revise those.

Let's go build stuff! -- Justin

Attendees:

Debbie Bucci

Glen Marshall

Sarah Squire

Justin Richer

Eve Maler

Jeff Shultz

Anwar Reddick

Tom Sullivan

Josh Mandel

Edmund Jay

William Kinsley

John Moehrke

Chris Shawn

John Bradley

Abbie

Adrian Gropper

Jim Kragh

Salvatore D’Agostino

We edited the “Alice Enrolls with PCP” use case in Google Docs: https://docs.google.com/document/d/1IvbdWerdvMuA1dQ-KQvVKqIBrAas7FoenNVUtgpqYrw/edit?usp=sharing

to indicate which parts of the use case are core and peripheral

Privacy policies are called “notices of privacy practices,” and they are acknowledged, not consented to. Some practices have people sign that acknowledgement and some don’t. While this process is essential to every healthcare transaction, it is not something we are going to profile as part of HEART, so it is considered peripheral to our project.

Are Alice’s authorizations actually bidirectional or synchronous? They are from her perspective, but from the perspective of the technology, they are neither. They are two one-way RESTful interactions.

Nothing in this use-case is outside the scope of vanilla OAuth, including the dynamic client registration that may have happened before the use case starts. Where we need UMA is if Alice were to bring her own authorization server that neither the PHR or EHR have seen before.

Dynamic client registration in the UMA heart profile will be mandatory to implement.

If you implement UMA, does everyone need to know that you’re speaking UMA? Yes. However, the introductions don’t have to be dynamic. For HEART, we want to enable that dynamism.

Are there any assumptions about the end-user availability? Yes, OAuth assumes that the user is present. UMA does not make that assumption. That is irrelevant to this use-case, since this is Alice-to-Alice sharing.

This use case doesn’t require UMA, but we could create a new branch of the use case that translated the same transactions into UMA.

We don’t know how deployments will roll out, so in order to make this work for Alice, we have to work on scenarios to be friendly to all parties and stakeholders.

The “lab” portion of the use case was included so that in a different version of the use case a lab could also have a FHIR API and act as a third-party.