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

Wed Jun 17 10:02:36 UTC 2015

 This thread is touching on everything that I thought it would  ...

 I am going to boil this down to the internal conversation we had over the
weekend -

A. FHIR scope interop between OAUTH/UMA
B. Current gap (perhaps in both specs!) that is leaning towards  or could
inform UMA extension
C.  Overarching access control/ABAC conversation   - that John seems to
have touch upon.   I have a whole bunch of questions there ... If FHIR
resources/attributes are being used for the PIP - are they being used for
enforcement (PEP) as well - is DS4P like FHIR tagging on the table?  Will
vendors implement? ... (no need to answer just throwing them out there )

If we will focus on A .. that should inform B  - but others are interested
- perhaps and entirely different thread/conversation  is needed for C

In re: to vectors -- consent related -  sensitive health topics and
delegation are two areas I believe are relevant for this WG.

On Tue, Jun 16, 2015 at 2:06 PM, Eve Maler <eve.maler at forgerock.com> wrote:

> Hi Thomas-- Delegation in this sense (actively choosing to assign
> authorization rights to someone else) is something I'm working on a lot
> lately. ("Delegation" is a word with a lot of meanings, sigh.) Obviously,
> Alice-to-Bob sharing is supposed to be a key UMA benefit.
>
> I think you're using "scope" in an odd sense by talking about "creating a
> new scope for Bob". It's more like a policy in that case, or a policy
> template or something. Or maybe you're suggesting that, through family
> relationships, there's a kind of role basis for sharing ("mother-daughter")
> that determines policy workflow, and when Bob differs enough from a
> standard role, you have to peel him away from it. (Though God help us if we
> replicate RBAC for ordinary consumers and patients. It doesn't even scale
> in the enterprise.)
>
> As for propagation, this may be a bit far afield for the main topic under
> discussion in this thread, but for those who are interested, I see some
> huge potential for how to drive layers of sharing policy off of graph
> technology. (My colleagues recently did a forward-looking demo
> <https://www.youtube.com/watch?v=-BAyu4KuSOI&index=8&list=PLK58Vrtd56-U4YkavFo0DR1yFpkw9G_lm>
> of graph-driven policy with an IoT bent (24:00).)
>
>
> *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 Tue, Jun 16, 2015 at 8:42 AM, Thomas Hardjono <hardjono at mit.edu> wrote:
>
>>
>> Folks,
>>
>> Sorry for having been absent for a while.
>>
>> >>> Eve:
>> >>> In discussions with consumer IoT folks, it
>> >>> seems that smart light bulbs want to be
>> >>> gathered by "room".
>>
>> So this is the second time in two weeks that I've heard discussions about
>> resources/scopes and OAuth2.0 (the other venue was related to IoT).
>>
>> (1) One of the problems with grouping resources (what we call "resource
>> sets" here) is that there are always cases where there is an exception to
>> the access being granted. For example, Alice has created a "resource set"
>> called "lighting in the house". She wants to grant Bob (the electrician)
>> access to this resource set with the exception of lighting in the kitchen,
>> say. So the access control logic has to be able to handle this
>> semantically. If there too many exceptions to the resource-set scope, then
>> you may as well create a new scope just for Bob.
>>
>> (2) Relationships as a "resource" or "scope":  Should relationships be
>> expressed as a resource or scope (or both/neither)? So in Josh's example,
>> Alice and her Mom have a relationship that allows Mom to say "I grant my
>> daughter permission to read my Med files". Not to get theoretical, but what
>> if Alice has a sister Cathy who also qualifies as "daughter-of".
>>
>>
>> I'm not sure if the OAuth WG ever addressed these issues, but in the UMA
>> WG we really haven't addressed them sufficiently (too busy getting UMA core
>> 1.0 finished). We also haven't addressed the issue of delegation and
>> propagation of delegated rights.
>>
>> /thomas/
>>
>>
>> ____________________________________________
>>
>>
>> From: Openid-specs-heart [mailto:
>> openid-specs-heart-bounces at lists.openid.net] On Behalf Of Justin Richer
>> Sent: Tuesday, June 16, 2015 10:42 AM
>> To: Eve Maler
>> Cc: openid-specs-heart at lists.openid.net
>> Subject: Re: [Openid-specs-heart] HEART Scopes & Resource Sets
>>
>> Eve,
>>
>> The main difference is that it’s not at all uncommon in the OAuth world
>> to ask for authorization to multiple resources protected by the same AS
>> simultaneously. In fact, this is seen as a *feature* of the OAuth approach,
>> since it’s lower decision overhead for the user (when done right). In that
>> case, if a client asks for “read write delete” scopes of an AS, the AS
>> still needs to know *what* those scopes apply to. Since OAuth doesn’t have
>> any type of resource or audience identifier (a big hole in the spec), this
>> gap has been usually filled by having a scope identify the resource. Note
>> that this is still semantically sensible and doesn’t go against what
>> “scope” is defined as.
>>
>> This is where you get the matrix definition. You’ve got some scopes that
>> mean “where can I do things” and others that mean “what can I do there”. I
>> think Josh’s approach of “what.where” is reasonable given this technical
>> constraint, and not without precedent. As far as the AS is concerned, it’s
>> dealing with just strings from the client, but it can still easily make the
>> UX of the authorization page a little smart based on the understood
>> semantics of these well-defined scopes.
>>
>>  — Justin
>>
>> On Jun 15, 2015, at 7:44 PM, Eve Maler <eve.maler at forgerock.com> wrote:
>>
>> 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 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", 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",
>> 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...
>>
>> What 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...
>> _______________________________________________
>> Openid-specs-heart mailing list
>> Openid-specs-heart at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>>
>>
>
> _______________________________________________
> 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/20150617/ae50b356/attachment-0001.html>