<div dir="ltr">Adrian and I were chatting off-list, and he asked me to share here more detail that I gave him about how the AS stays out of passing attributes to the RS. Here's what I said:<div><br></div><div>"The RqP might reveal an attribute to the RS, but if they do, it's entirely in the context of a local (non-UMA) authorization process, and does not go through the AS. If the AS knows the RqP has a valid medical license in the state of MA, the AS doesn't reveal it to the RS. And if the RS comes to find out that the RqP has a valid medical license in the state of MA, the RS didn't learn it from the AS.<div>
<p class="">(Note that this is all true because we're assuming that the default "bearer" UMA token profile is in use. If an alternate token profile were in use that changed the responsibilities of the AS, namely letting it just collect the RqP's attributes and stick them in the RPT, vs. evaluating out [Alice's] policies against them and putting the resulting permissions in the RPT, then the RS would indeed see the attributes. But that would change a LOT of things, and I'm not currently advising it.)"<br><span class=""></span></p><p class="">FWIW,</p><div class="gmail_extra"><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 Tue, Jan 5, 2016 at 9:47 PM, Eve Maler <span dir="ltr"><<a href="mailto:eve.maler@forgerock.com" target="_blank">eve.maler@forgerock.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Hi guys-- I'm following along as best I can on a busy day/night, so I hope my contribution for the moment will be additive and not missing the point...<div><ul><li>Adrian's points about ensuring fairness to Alice around the hospital trying to block information access are very well taken.</li></ul><ul><li>I don't quite see why an individually controlled AS is strictly required, though I see how it can help at the margin. Certainly the RS has business reasons (risk mitigation and so on) why it favors more blocking; if the AS is in business to serve Alice it will already work in her favor, but more business-model pressure in that direction is good.</li></ul><ul><li>Note that the default way that UMA works doesn't involve the AS passing any of the requesting party's attributes along to the RS; it just passes calculated "permissions" in the access token for the RS to inspect before judging whether to let the requesting party and their client app in. (An alternate UMA token profile could arrange for passing attributes instead, but on balance I'd probably not advise that we go in that direction in our profiling...)</li></ul><ul><li>However, UMA does <a href="https://docs.kantarainitiative.org/uma/draft-uma-core-v1_0_1.html#give-access" target="_blank">say</a> "The resource server MAY apply additional authorization controls when determining how to respond" when the access token contains sufficient permissions for the requesting party to get access. Obviously, this is where potentially pernicious behavior like delaying access for 72 hours could creep in.</li></ul><ul><li>The UMA group has been working on draft model clauses that could form the basis for legal agreements, consent receipts, etc. We've been discussing what to do about model clauses that ensure the RS <b>never</b> gives access when the access token contains insufficient permissions, and offering model clauses that say the RS <b>has to</b> notify the RO somehow whenever it blocks immediate access when the access token contains sufficient permissions. (Accounting of disclosures, anyone?)</li></ul><ul><li>This could be an interesting element for us to profile, <i>if</i> we consider this to be in scope -- iffy because it's in business model-land.</li></ul></div></div><div class="gmail_extra"><br clear="all"><div><div><div dir="ltr"><div><div dir="ltr">
<p><b>Eve Maler<br></b>ForgeRock Office of the CTO | VP Innovation & Emerging Technology<br>Cell <a href="tel:%2B1%20425.345.6756" value="+14253456756" target="_blank">+1 425.345.6756</a> | 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>
</blockquote></div><br></div></div></div></div>