<div dir="ltr"><div><div><div><div>My assumption is that adoption of UMA and the user experience are best served by combining an OpenID Connect Client with an UMA Authorization Server. In this way, direct "presence on the wire" by the RqP would be optional at the discretion of the Authorization Server. The AS could decide to trust no federated OP, the RS as an OP, and/or some federated OP. In the latter case, the federation would decide if "presence on the wire" is required or not (similar to how FIDO requires "presence on the wire" to activate the FIDO token as a login client).<br><br></div>The "present on the wire" distinction would be moot in the case of AS authentication or RS authentication as an OP.<br><br></div>This distinction certainly interacts with resource scopes. In the HIPAA CE case, for example, the RS needs to know whether the RqP and client is subject to an access delay (patient) or not (provider) - otherwise it might be tempted to impose the delay on everyone bearing a token from the AS and that would reduce the value of the API immensely.<br><br></div>Bottom line, the AS SHOULD be an OpenID Client and the RS SHOULD support OP Dynamic for a good user experience for both the RO and the RqP. The RS and the AS MAY participate in federations that protect the privacy of the RqP and extend SSO beyond the RS - AS relationship.<br><br></div><div>Adrian<br></div><div><br></div>Adrian<br><div><div><div><div><div><br><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF">
    </div></blockquote></span><br></div></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 8, 2015 at 3:16 PM, Justin Richer <span dir="ltr"><<a href="mailto:jricher@mit.edu" target="_blank">jricher@mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">We’ve discussed the redundancy of the AAT in the UMA working group, and we’re mandating claims gathering flows that identify and bind the RqP. Since we can’t cut out the AAT entirely and still remain compatible with UMA 1.0, this was a workaround. We also did discuss this exact workaround on the UMA list and/or tracker: using client_credentials to get the AAT. <div><br></div><div>I strongly believe that the requirement of a user-delegated AAT drastically restricts the deployability of this spec. It requires that the RqP have the ability to generate delegated OAuth access tokens from the AS, which is controlled by the RO. This simply cannot be counted on unless you’re in a very narrow ecosystem, and we cannot assume such an ecosystem as a requirement here. This recommendation keeps the syntactic compatibility with UMA 1.0 while making the actual protocol more sensible and widely deployable.</div><div><br></div><div>Ultimately this is a recommendation in an implementer’s draft. If people don’t do it, then we change the recommendation.</div><div><br></div><div>I do not agree with the call to hold off on the ballot for this issue.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div> — Justin</div></font></span><div><div class="h5"><div><br><div><blockquote type="cite"><div>On Dec 8, 2015, at 2:53 PM, Eve Maler <<a href="mailto:eve.maler@forgerock.com" target="_blank">eve.maler@forgerock.com</a>> wrote:</div><br><div><div dir="ltr">I apologize for only sending this now. The following sentence was not in the version on which I sent comments to Justin and Sarah on November 23.<div><br></div><div><i><a href="http://openid.bitbucket.org/HEART/openid-heart-uma.html#Tokens" target="_blank">HEART UMA Sec 2</a>: "It is RECOMMENDED that the PAT use a user-delegated mechanism for issuance and the AAT use a non-delegated method for issuance."</i></div><div><br></div><div>I believe this incorrectly specifies a critical profile detail, as well as using terms that are not very well-defined.</div><div><br></div><div><b>Minor issue in the HEART UMA profile and tackling the terminology issue for techies and nontechies alike</b></div><div><br></div><div>First, the minor issue: As we discussed briefly on the call yesterday, "user-delegated" and "non-delegated" appear to correspond to what have been colloquially called "three-legged" and "two-legged" in the OAuth community.</div><div><br></div><div>In plain English, the first one means that a human delegates to a client application the right to access some protected resource. The second one means that the client gains access to the protected resource autonomously, on its own recognizance. (UMA would look at the larger context of the "NPE" that the app represents -- in other words, it would note that there actually <i>is</i> a resource owner and it's not a human being.)</div><div><br></div><div>It would be much clearer to identify the acceptable OAuth "<a href="http://tools.ietf.org/html/rfc6749#section-4" target="_blank">grant</a>" flows in each case; "non-delegated" translates uniquely to the OAuth <a href="http://tools.ietf.org/html/rfc6749#section-4" target="_blank">client credentials</a> grant flow.</div><div><br></div><div><b>Major issue in the HEART UMA profile</b></div><div><br></div><div>Now the major issue: The "non-delegated" [client credentials] recommendation suggested here for the AAT would be incorrect for solving any use case where the requesting party is a human being ("natural person"). I believe you're suggesting <span style="font-size:12.8px">an experimental usage of UMA that was not intended by the original spec:</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><i><a href="https://docs.kantarainitiative.org/uma/draft-uma-core-v1_0_1.html#authorization-api" target="_blank">UMA Core Sec 1.3.2:</a> "An AAT binds a requesting party, a client being used by that party, and an authorization server that protects resources this client is seeking access to on this requesting party's behalf. .... The issuance of an AAT represents the approval of this requesting party for this client to engage with this authorization server to supply claims, ask for authorization, and perform any other tasks needed for obtaining authorization for access to resources at all resource servers that use this authorization server.</i></span><i style="font-size:12.8px">"</i></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">I'm concerned that an implementation that treats the client as autonomous/NPE for AAT purposes, and then switches to a "human requesting party" interpretation later on during trust elevation, may have anomalous behavior when it comes to overall management of the requesting party's identity compared to properly conforming authorization servers. This is essentially, then, an anti-interoperability recommendation.</span><br></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Thus, I don't believe we can leave the recommendation as is.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><b>Side issue probably not for the profile but for UMA generally</b></span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">As an aside, it should be noted that, even though the requesting party should be the "same entity" referred to in both the AAT stage and later on, the authorization server still shouldn't use the AAT to "mine" the identity of the requesting party for trust elevation at the later stage. This is a temptation we discovered some integrators may fall prey to, which leads to a potential privacy violation.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">I've been meaning to add a note about this to the <a href="http://kantarainitiative.org/confluence/display/uma/UMA+Implementer%27s+Guide?src=contextnavchildmode" target="_blank">UMA Implementer's Guide</a>; I'll leave the longer explanation about this for another time (or the UIG itself).</span><br></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><b>Acknowledgment of the larger UMA issue and suggestions for potential profile fixes/additions</b></span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">The constraint where the requesting party needs a "login account" of some sort at the authorization server used by the resource owner -- let's call it "the resource owner's authorization server" (RO's AS), vs. "the requesting party's desired authorization server" (RqP's AS), that is, the authorization server the requesting party <i>uses for preference</i> when they're in the resource owner role themselves -- is indeed a tricky one.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">(In case people are wondering where the motivation for this requirement came from, the passage quoted above describes a key one having to do with experience: </span><i style="font-size:12.8px"><a href="https://docs.kantarainitiative.org/uma/draft-uma-core-v1_0_1.html#authorization-api" target="_blank">UMA Core Sec 1.3.2:</a> "... </i><span style="font-size:12.8px"><i>The authorization server is able to use this association to manage future processes of authorization and claims-caching efficiently for this client/requesting party pair across all resource servers they try to access; however, these management processes are outside the scope of this specification." </i>We shall see whether this was the right optimization choice at this stage of UMA's life cycle... :-) )</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">One perhaps semi-satisfying workaround for the purposes of our profile might be to recommend that the authorization server offer the requesting party the opportunity to single sign-on into the RO's AS using their "RqP's AS" login (if they have one). One could imagine an identity trust framework among authorization servers so that they're relying parties/identity providers to each other in a "star of trust".</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><b>A thought about interactions between the basic profile and higher-order profiling for trust elevation</b></span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">At ForgeRock we have recently prepared some materials that describe ways to do identity-claims-based trust elevation given different widths of UMA "ecosystem", once the AAT layer has been laid down. I'd be happy to share these materials as food for thought.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Note: They may have some interactions with the basic HEART UMA profile if we get into recommending any particular federated identity patterns at this basic level, so let me know if you think I should add those materials to <i>this</i> thread.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><b>Suggestion for handling the unfortunate Implementer's Draft timing</b></span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">I realize that what I'm talking about here is not really a non-normative change to the wording. However, if I'm looking at the commits correctly, it appears that this change was made as part of a flurry of edits on December 1, which is fairly late in the game for a substantive revision (I myself was in the wilds of Norway and unfortunately not keeping up with regular work very well!). Looking at the list traffic, I'm unclear what requests actually led to this change.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">I think it would be appropriate to hold off on the ballot, if possible, until we discuss what to do with this text. If things are already in the works (Debbie?), then I think we may possibly be looking at another Implementer's Draft with some alternative (normatively changed) wording. As explained to us previously, we can theoretically have as many of these drafts as necessary, so we know it's possible, even if not ideal.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></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 class="gmail_quote">On Thu, Dec 3, 2015 at 1:38 PM, Justin Richer <span dir="ltr"><<a href="mailto:jricher@mit.edu" target="_blank">jricher@mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span><div><br></div></span><div>User delegated means an end user delegates access and is involved in the process. Non-delegated means the client is acting on its own behalf for that step. This text is saying the RO needs to set up the relationship between the RS and the AS, but the RqP doesn’t have to be present on the wire to set up the relationship between the client and AS. This is to patch around a technical limitation in UMA 1.0 that would otherwise require the RqP have an account of some type at the AS that was able to generate OAuth tokens. </div><br><span><font color="#888888"><div><br></div><div> — Justin</div></font></span></div></div><br></blockquote></div><br></div></div>
</div></blockquote></div><br></div></div></div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br><div dir="ltr">Adrian Gropper MD<span style="font-size:11pt"></span><br><br><span style="font-family:"Arial",sans-serif;color:#1f497d">PROTECT YOUR FUTURE - RESTORE Health Privacy!</span><span style="font-family:"Arial",sans-serif;color:#1f497d"><br>HELP us fight for the right to control personal health data.</span><span style="font-family:"Arial",sans-serif;color:#1f497d"></span><span style="font-family:"Arial",sans-serif;color:#1f497d"><br>DONATE:
<a href="http://patientprivacyrights.org/donate-2/" target="_blank"><span style="color:#0563c1">http://patientprivacyrights.org/donate-2/</span></a></span><span style="color:#1f497d"></span>
</div></div></div></div></div></div></div></div>
</div>