[Openid-specs-heart] Draft HEART meeting notes 2015-07-06

[Justin Richer]

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

On 7/6/2015 6:39 PM, Sarah Squire wrote:
>
> 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.
>
> Sarah Squire
> Engage Identity
> http://engageidentity.com <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/20150706/f0d28381/attachment-0001.html>