<div dir="ltr">Below (deleting the content of the other sub-thread)...<div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr">







<p><b>Eve Maler<br></b>ForgeRock Office of the CTO | VP Innovation & Emerging Technology<br>Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl<br>Join our <a href="http://forgerock.org/openuma/" target="_blank">ForgeRock.org OpenUMA</a> community!</p></div></div></div></div></div>
<br><div class="gmail_quote">On Wed, Jun 17, 2015 at 4:58 AM, Thomas Hardjono <span dir="ltr"><<a href="mailto:hardjono@mit.edu" target="_blank">hardjono@mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Hi Eve,<br>
<br>
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.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>Eve</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.<br>
<br>
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?<br>
<br>
<br>
/thomas/<br>
<br>
<br>
________________________________________<br>
From: Eve Maler [<a href="mailto:eve.maler@forgerock.com">eve.maler@forgerock.com</a>]<br>
Sent: Tuesday, June 16, 2015 2:06 PM<br>
To: Thomas Hardjono<br>
Cc: Justin P Richer; <a href="mailto:openid-specs-heart@lists.openid.net">openid-specs-heart@lists.openid.net</a><br>
<span class="">Subject: Re: [Openid-specs-heart] HEART Scopes & Resource Sets<br>
<br>
</span><span class="">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.<br>
<br>
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.)<br>
<br>
</span>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<<a href="https://www.youtube.com/watch?v=-BAyu4KuSOI&index=8&list=PLK58Vrtd56-U4YkavFo0DR1yFpkw9G_lm" rel="noreferrer" target="_blank">https://www.youtube.com/watch?v=-BAyu4KuSOI&index=8&list=PLK58Vrtd56-U4YkavFo0DR1yFpkw9G_lm</a>> of graph-driven policy with an IoT bent (24:00).)<br>
<span class=""><br>
<br>
Eve Maler<br>
ForgeRock Office of the CTO | VP Innovation & Emerging Technology<br>
Cell <a href="tel:%2B1%20425.345.6756" value="+14253456756">+1 425.345.6756</a> | Skype: xmlgrrl | Twitter: @xmlgrrl<br>
</span>Join our ForgeRock.org OpenUMA<<a href="http://forgerock.org/openuma/" rel="noreferrer" target="_blank">http://forgerock.org/openuma/</a>> community!<br>
<span class=""><br>
On Tue, Jun 16, 2015 at 8:42 AM, Thomas Hardjono <<a href="mailto:hardjono@mit.edu">hardjono@mit.edu</a><mailto:<a href="mailto:hardjono@mit.edu">hardjono@mit.edu</a>>> wrote:<br>
<br>
Folks,<br>
<br>
Sorry for having been absent for a while.<br>
<br>
>>> Eve:<br>
>>> In discussions with consumer IoT folks, it<br>
>>> seems that smart light bulbs want to be<br>
>>> gathered by "room".<br>
<br>
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).<br>
<br>
(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.<br>
<br>
(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".<br>
<br>
<br>
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.<br>
<br>
/thomas/<br></span></blockquote></div></div></div>