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

[Josh Mandel]

And, er, when I said "Alice signs into her resource server", I meant "
*authorization* server".

On Mon, Jun 15, 2015 at 5: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".*
>
> 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).
>
> 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").
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150615/fbd1259e/attachment.html>