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

[Eve Maler]

Below (deleting the content of the other sub-thread)...


*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, Jun 17, 2015 at 4:58 AM, Thomas Hardjono <hardjono at mit.edu> wrote:

>
> Hi Eve,
>
> Does it help if we view all the participants as "resources", so that even
> the API-caller (as the "client") is also seen as a resource (specially if
> the client has a call back URI). So all the policies (scopes) themselves
> are seen as resources that happen to sit at the UMA-AS.  This allows us to
> view relationship facts also as a resource - which also helps in the
> privacy design/engineering aspects of HEART. For example: If Bob is seeing
> a medical specialist (Dr Alice) and he wants this fact/relationship to be
> private, then viewing this as a resource (that sits either at the UMA-AS or
> elsewhere) allows policies and access control to be placed on this resource.
>

While a graph approach could beneficially see everything as a node, which
is what I think you're calling a resource, "resource"/"resource set" has a
technical meaning in an UMA context (and also in a web context), and
broadening its definition in this way would, I fear, just confuse things.
In the work that my team has been doing (ForgeRock CTO's office), fwiw, we
see relationship management as "upstream" from the OAuth or UMA layer, so
that if you want to use it to drive authorization policy, you can -- but
sometimes relationships are more than just about data/API access. For
example, a medical or general power of attorney comes with other
responsibilities that have nothing to do with access to data.

Eve


>
> I agree with you that the RBAC model doesn't work here (i.e. doesn't scale
> to the use-cases we are all seeing today) - specially because "role" is
> context-dependent.
>
> For delegation, what is the current "legal" (e.g. HIPAA) construct used
> for actors to delegate to other actors?  Anyone here in HEART have any
> thoughts?
>
>
> /thomas/
>
>
> ________________________________________
> From: Eve Maler [eve.maler at forgerock.com]
> Sent: Tuesday, June 16, 2015 2:06 PM
> To: Thomas Hardjono
> Cc: Justin P Richer; openid-specs-heart at lists.openid.net
> Subject: Re: [Openid-specs-heart] HEART Scopes & Resource Sets
>
> 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<mailto:
> 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150617/e65887c1/attachment.html>