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

[Sarah Squire]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150706/49891cb5/attachment-0001.html>