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

[Eve Maler]

Thanks for this, John. It shows how there's a straight line from CDs to
policies to policy engines that have to execute them. This is where I was
heading, perhaps not very articulately, in talking about resource sets vs.
scopes. Policy engines distinguish the objects protected from the actions
that can be performed over them -- it's something of a fundamental
principle of authorization.

If we're looking for a way to "ask for multiple resource sets" but only
have a way to "ask for multiple scopes" and therefore choose to call
resource sets scopes through concatenation tricks, I'm reminded of XML-RPC
patterns, where arbitrary instructions ("verbs") are tunneled over HTTP in
preference to resource-oriented/RESTful design, which puts the emphasis on
the "nouns".


*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 10:18 AM, Moehrke, John (GE Healthcare) <
John.Moehrke at med.ge.com> wrote:

> This amorphous scope could also be represented in FHIR as a
> ConsentDirective.
>
> http://hl7-fhir.github.io/consentdirective-consentdirective.html
>
>
>
> Sorry that ConsentDirective is such a mess right now. We are trying to
> resolve open-comments, while also doing design.
>
>
>
> The concept is that we need a resource in FHIR that can capture a complex
> policy.
>
>
>
> Such as: I give my guardian (X) read access to all my health information,
> except for the records during 1982, and except for records marked with the
> security-tag==Restricted. I further give Create/Update permission to
> schedule appointments. I further give Create but not Update permission to
> write observations.  We ‘believe’ we can write these policies using
> ConsentDirective today…
>
>
>
> Once this kind of a policy is registered. Then a reference to that
> specific instance of a ConsentDirective could be a scope requested… This is
> not necessarily the vision today, the vision is more that this is rules
> that the Access Control Decision engine (however implemented) would use to
> determine if an action is authorized. But Scopes are simply broad requests
> for a multi-point decision to be made vs point-by-point.
>
>
>
> Sorry that I don’t know enough about UMA to help there.
>
>
>
> John
>
>
>
> *From:* Openid-specs-heart [mailto:
> openid-specs-heart-bounces at lists.openid.net] *On Behalf Of *Eve Maler
> *Sent:* Tuesday, June 16, 2015 12:01 PM
> *To:* Justin Richer
> *Cc:* openid-specs-heart at lists.openid.net
> *Subject:* Re: [Openid-specs-heart] HEART Scopes & Resource Sets
>
>
>
> The ability in OAuth for a client to request multiple resources and
> permissions over them seems valuable, of course. Given that "resource set
> registration" and "permission granting" are distinct activities in UMA,
> though, I'm reluctant to conflate them for OAuth historical reasons, and
> would prefer to think about how to solve the problem "correctly" if
> possible. (Josh, btw, I did give examples of distinct scopes over different
> resources, e.g., Salesforce's "chatter" scope. This pattern seems pretty
> common.)
>
>
>
> Though it didn't make it into UMA V1.0, the group discussed a pattern
> where the RS could register multiple permissions vs. just a single one, and
> there is a communications channel between the client and AS (the request
> for authorization data at the RPT endpoint) that could be used to convey
> the client's desires as well. I want to be clear that this is in the realm
> of potential *UMA extensions* (e.g., for consideration in V.next) rather
> than just HEART profiling. But the ease of experimenting with and creating
> extensions (e.g. adding JSON properties to requests and responses) is one
> big reason why we felt comfortable wrapping up V1.0 after a fairly lengthy
> development process.
>
>
>
> In fact, FWIW, I've been having a discussion with some folks in a
> different context that looks exactly like "generous resource set/permission
> registration by the RS at the AS in response to a limited initial access
> request by a client". So this isn't a totally one-off conversation.
>
>
>
> *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
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__forgerock.org_openuma_&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=c5kzzfYQsMqNe16ufsx_ex-37vO5OdZxWdiMY3NLTUw&s=V4ANvo3RiGqeVCqKj2A2X2tAVz5LFrZlDFhG5-Zr44E&e=>
> community!
>
>
>
> On Tue, Jun 16, 2015 at 7:42 AM, Justin Richer <jricher at mit.edu> wrote:
>
> 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
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__forgerock.org_openuma_&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=c5kzzfYQsMqNe16ufsx_ex-37vO5OdZxWdiMY3NLTUw&s=V4ANvo3RiGqeVCqKj2A2X2tAVz5LFrZlDFhG5-Zr44E&e=>
> 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
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__openid.net_heart_resource-2Dtypes_StepCounts-3Ahttps-3A__openid.net_heart_scopes_view&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=c5kzzfYQsMqNe16ufsx_ex-37vO5OdZxWdiMY3NLTUw&s=0mTQz2RR8olvVSG_ACkhJzRacqxp2v3gLXA6ZhqWDfQ&e=>".
> 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.hl7.org_fhir_rsrc_med.json&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=c5kzzfYQsMqNe16ufsx_ex-37vO5OdZxWdiMY3NLTUw&s=LlLtJhH_OIlUQ8SrcVg9EKLAat9EbG1iG-ZuUXZgxD0&e=>*",
> 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.hl7.org_fhir_rsrc_step.json&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=c5kzzfYQsMqNe16ufsx_ex-37vO5OdZxWdiMY3NLTUw&s=ru9SOoymql5fFmJhLU7HIVtaL7Yle27JOrDGnsPcX4w&e=>*",
> 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...
>
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dheart&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=c5kzzfYQsMqNe16ufsx_ex-37vO5OdZxWdiMY3NLTUw&s=W7yuOEE1q5v0b9HN875EHzZ1NnyWF2UJW3HAEpXkFmU&e=>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150616/446b9882/attachment-0001.html>