[Openid-specs-heart] HEART 2015-08-05 meeting notes

[Eve Maler]

Thanks for sending notes, Debbie! A couple of tweaks below:


*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 Wed, Aug 5, 2015 at 12:26 PM, Debbie Bucci <debbucci at gmail.com> wrote:

> Attendees:
> Eve Maler
> Justin Richer
> Josh Mandel
> Adrian Gropper
> Thomas Sullivan
> Debbie Bucci
>
> We have decided to delineate between mechanical and semantic scope docs.
>

(Just "semantic", I think. The UMA doc, at least, will have more than
scopes, and the OAuth one might possibly, too.)

We decided call the profiles that are just for security purposes
"mechanical" so that we could name them right in the use case, everywhere
the [PROFILING] tag appeared. I took a stab at defining what we mean by
"semantic": "Related to either the FHIR API, or the content of the
resources accessed through it" (or something like that).


>
> For the PCP <-> PHR use case:
>
> The pre determined choice token confidential token choice and exactly what
> information needs (example: PHR's authorization endpoint)  to be shared in
> advance between the PCP's EHR and Alice's PCP was left out of the
> discussion for now.
>

I think we were talking here about a "confidential client" and what
information it needs.


>
> There is one basic mechanical Oauth  generic flow that occurs twice in the
> use case.
>
> Given the group has generally agreed that the SMART specifications are a
> good place to *start ... *for this particular use case  the only semantic
> FHIR scope that is necessary is the patient/*.read scope that grants
> permission to read any resource for the current patient.
>

So in other words, we're suggesting that the client ask for "the whole
enchilada"...


>
> During the registration process Alice should be able to select at a fine
> grain level which resources she is willing to share with the PHR.   This
> mimic's a specific process - Adrian please provide.  This information will
> be used to generate the access token.
>

...and that Alice be able to uncheck scopes she doesn't want to grant.
Adrian talked about an "ROI" form (and I know he didn't mean return on
investment -- can't remember what it stands for).

(This isn't a tweak, just a comment:) One of the things that trust
frameworks above might want to nail down, over and above our profiling, is
requirements around the UX displayed to patients to ensure they understand
what they're authorizing. Even at our profile level, if there are large
numbers of scopes for Alice to consider (I don't know how many there are),
we may want to consider different ways of bucketing them as OIDC has done
for attributes.


>
> The one thing left at the end of the discussion is whether the patient
> record is implicit or explicitly stated.  This is a design decision that
> may make a difference as we move towards our next use case in
> which delegation is a factor.
>
> Corrections/updates appreciated.
>
>
>
> _______________________________________________
> 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/20150805/8bea7958/attachment.html>