[Openid-specs-heart] HEART Scopes & Resource Sets

[Eve Maler]

Hi Josh-- 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 Mon, Jun 15, 2015 at 2:24 PM, Josh Mandel <
Joshua.Mandel at childrens.harvard.edu> wrote:

> Hi all,
>
> I didn't mean to take a hard-line position on today's call about scope
> definitions! To my mind, our approach to scopes will need to work
> hand-in-hand with our approach to endpoint (or resource set) discovery --
> so I feel a bit awkward discussing scopes here in isolation. But that said,
> let me see if I can at least highlight the tension that we heard in the
> past hour's discussion (in a neutral way):
>
> ---
> *Goal: Whatever the model, we want to support a use case where Alice signs
> into her resource server and can set some policies in an intuitive way.
> |She'd see something like (very, very roughly):*
>
>  My Medications:
>  * Who can view?
>  * Who can write new prescriptions?
>
> My Step Counts
>  * Who can view?
>  * Who can remove?
> ---
>
> The question is about how this works under the hood.  I think we were
> discussing two models:
>
> *Model 1: The "UMA-First" approach*
> *We have a resource set like "Alice's Medications", with scopes like
> "view" and "prescribe". And we'd have a resource set like "Alice's Step
> Counts" with scopes like "view" and "delete".*
>
> *Model 2: The "OAuth-First" approach*
> *We have a resource set like "Alice's FHIR Endpoint", with scopes like
> "Medications.view", "Medications.prescribe", "Steps.view", and
> "Steps.delete".*
>
>
Talking about an "OAuth-first" approach for setting policies is making me
confused. I know what it looks like to enable OAuth-like flows in UMA when
Alice is both the requesting party and the owner of the resource. And I
know what it looks like to enable Alice to set policies at an UMA
authorization server (which might hold the results of a previous OAuth-like
flow done in UMA). But I don't know what "setting policies in OAuth" means
because the OAuth experience is about consenting at run time (possibly
checking and unchecking individual scopes), and revoking tokens at the
AS/RS.

So the closest UX analog would probably be the wording displayed in an
OAuth consent dialog, maybe something like:

   - View [and prescribe] your medications
   - View [and delete] your steps



> If the *types* of Resource Sets and the allowed scopes are standardized in
> advance (which UMA supports), then a mapping between Model 1 and "vanilla"
> OAuth could be as simple as: "concatenate the UMA resource set type
> followed by ':' followed by the UMA scope name" -- so for example, you
> might derive an OAuth scope like "
> https://openid.net/heart/resource-types/StepCounts:https://openid.net/heart/scopes/view".
> Or under Model 2, the scopes could be reused directly (no mapping
> required).
>

In what sense is "reuse" meant here? A coding model, or an architectural
model, or a semantic model?... There are ways in which I could imagine a
deep kind of semantic reuse being possible without concatenation tricks
being necessary. However, not being a developer, I'm not sure if they match
what you're thinking of.

For example, in my previous response to the minutes email, I outlined how
some APIs have implicit mappings between scopes and acceptable
endpoints/resources to which they apply.

Let's say (totally making this up) the FHIR has two endpoints, with one
endpoint for medication records and one for fitness steps. There's an
UMA-standardized resource type for each. There's
"*https://www.hl7.org/fhir/rsrc/med.json
<https://www.hl7.org/fhir/rsrc/med.json>*", with instances of it registered
with scopes "*view*", "*download*", "*transmit*", and "*add*" (so some
clients can insert new entries). Alice's medications might be in a resource
something like "*/alice/meds*". (What's displayed in her AS dashboard might
look a lot nicer than that.) And there's
"*https://www.hl7.org/fhir/rsrc/step.json
<https://www.hl7.org/fhir/rsrc/step.json>*", with instances of it
registered with scopes "*view*", "*download*", "*transmit*", and "*chart*".
Alice's steps might be in a resource like "/alice/steps".

(If the scopes are in the form of URIs, they could be standardized to a
further degree, in that a bunch of metadata could be pulled by the
authorization server and used to present standard labels and icons, and
other semantics could be linked to them.)

If the very same API were OAuth-protected, with the very same resource
endpoints, there might still be the same resource endpoints, with the same
scopes, where three of them work on both resource types, "*add*" only works
on "*med*", and "*chart*" only works on "*step*". These resources could
still have a standardized meaning in terms of both resource naming and
schema/format; there just would be nowhere to "hook" a standardized
resource type URI into.

Seen this way, the OAuth approach and the UMA approach are quite similar,
differing only in the implicitness vs. explicitness of the resource set
layer.


>
> Of course, some interesting things happen when we layer in details like...
>
> W*hat if Alice has access to multiple records (say, her own and her
> mother's)?* In vanilla OAuth the binding of permissions to these records
> is generally implicit. How should they play out in UMA? Under Model 1, we'd
> probably see two more Resource Sets created ("Alice's Mom's Medications"
> and "Alice's Mom's Steps"). Under Model 2, we'd probably see one more
> Resource Set created ("Alice's Mom's FHIR Endpoint").
>

I've been doing some work around chained delegation of this sort. Indeed,
these are separate records, and must remain that way. Alice may not have
all the permissions over her mother's records that she has over her own!
One way to present such "downstream" items is to present them under a
separate "Shared With" area. And there are various ways to organize owned
items, e.g. by who you tend to share them with or by function. In
discussions with consumer IoT folks, it seems that smart light bulbs want
to be gathered by "room".

FWIW...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150615/29bfe3c2/attachment-0001.html>