<div dir="ltr"><div><div><div>Justin,<br><br></div>How far long is the UMA addition to MITREid Connect right now? Would it make sense for us to design the absolutely simplest possible demo of UMA around the most trivial use case we can think of as a way of getting everyone on the same page?<br><br></div>I'm volunteering to help with the design, documentation, and management of such a demo. I might code C or Python but I doubt that would help. <br><br></div>Adrian<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jul 12, 2015 at 8:48 PM, Debbie Bucci <span dir="ltr"><<a href="mailto:debbucci@gmail.com" target="_blank">debbucci@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">It does make sense and I can at least *see* your perspective. Not quite covinced the gap are that wide and/or that adjust couldn't be made as we move to pilot implementations. </p>
<p dir="ltr">Side by side ... is closer.<br></p><div class="HOEnZb"><div class="h5">
<div class="gmail_quote">On Jul 12, 2015 8:05 PM, "Justin Richer" <<a href="mailto:jricher@mit.edu" target="_blank">jricher@mit.edu</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
An OIDC client and an OAuth client are after different things,
though. OIDC is an authentication and identity protocol, OAuth is
neither. An OIDC client is going to specifically be looking for the
id_token and specifically asking for the 'openid' scope in order to
get it. The mechanics on the wire, on the other hand, are nearly
identical between the two, since an OIDC transaction really is just
an OAuth transaction with a couple of special inputs (the 'openid'
scope) and outputs (the 'id_token' in the token response). You can
pretty easily build an OIDC client on top of an OAuth client.<br>
<br>
However, it's just not the same with UMA and OAuth (or OIDC). Think
of it in terms of software: if I have an UMA client and I try to
make it talk to a plain OAuth RS, it's going to have no idea what to
do. Same goes the other way around. It's not a matter of "just a
couple more redirects", since those redirects define a completely
different protocol and require different code paths. If you're very,
very careful you can have them side by side, and that's the best
that we can work for in HEART in my opinion. But that doesn't mean
we should try to figure out what both UMA and OAuth look like for
every single use case. Especially when considering you can do AS
introduction to both the client and RS outside of UMA (mostly --
we'll need to paste over some protocol gaps but it's all doable).<br>
<br>
And finally, in UMA 1.0, it's the RS that actually needs to know
which scopes to give for a transaction. The user and client have no
way of telling the RS which scopes they want, the RS just has to
guess correctly and attach those to a ticket. The client in UMA is
supposed to just take the ticket and let the AS figure out what to
do with it. <br>
<br>
Hope this makes sense,<br>
-- Justin<br>
<br>
<div>On 7/12/2015 7:57 PM, Debbie Bucci
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>
<div>
<div>
<div>>>> Unfortunately, there's no "is_alice"
flag in the protocol stack that we can count on. <br>
<br>
</div>
Maybe there should be. How does a client know its an
OIDC client .... the presence of the id_token? An OAUTH
client needs direct the resource owner (assumed Alice?)
to get a token on its behalf by somehow knowing what the
authorization endpoint is ... typically done via the RO
user agent and the redirect URI is/are given. In the
delegated flow ... Alice is not around ... could that be a
trigger? Bob (delegate) will need to have a pre arranged
relationship with the authorization server in some way or
manner. <br>
<br>
<br>
>>>An UMA client needs to be able to be pointed
to an AS, take in a ticket (as a JSON value, regardless of
what encoding the API it's speaking to uses), talk to the
"requesting party" endpoint to trade the ticket for a
token, and then it needs to be able to gather the claims
that the AS gives it hints for. As Eve keeps pointing out,
those claims could be absolutely anything, fulfilled by
the client or by someone else or just because it's
Tuesday, so the client is really going to need to be
written to a very specific profile of UMA for it to have
any chance of doing something useful. Then it needs to
come back with the ticket, again, and try to get a token,
potentially repeating the claims gathering cycle if it
guessed wrong on the last step. <br>
<br>
</div>
I believe you just [primarily] explained the *on the wire*
on the ATT flow (thank you!). <br>
</div>
</div>
<div>Following the flow ... it seems the burden is on the
Requesting party to understand what claims the AS hints for -
not the client. <br>
</div>
<div><br>
</div>
I may be naive but does a client really know how many redirects
occurs until its has an access token?<br>
<br>
<div>
<div>
<div>
<div>
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
<br>
</div>
<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" text="#000000">
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<blockquote style="border-width:medium medium medium 1pt;border-style:none none none solid;border-color:-moz-use-text-color -moz-use-text-color -moz-use-text-color rgb(204,204,204);padding:0in 0in 0in 6pt;margin:5pt 0in 5pt 4.8pt">
<div>
<div>
<div>
<div>
<div>
<div>
<table style="width:670.45pt;margin-left:5.4pt" width="1117" border="0" cellpadding="0" cellspacing="3">
<tbody>
<tr style="height:26.25pt">
<td style="padding:0.75pt;height:26.25pt">
<p class="MsoNormal" style="margin-bottom:6.7pt;text-align:right" align="right"><span style="font-family:"Arial","sans-serif""> </span></p>
</td>
<td style="padding:0.75pt;height:26.25pt"><br>
</td>
</tr>
</tbody>
</table>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
</div>
</blockquote></div>
</div></div><br>_______________________________________________<br>
Openid-specs-heart mailing list<br>
<a href="mailto:Openid-specs-heart@lists.openid.net">Openid-specs-heart@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr">Adrian Gropper MD<span style="font-size:11pt"></span><font size="1"><br><font size="2">Ensure Health Information Privacy. Support Patient Privacy Rights.<br></font></font><span style="font-size:11pt"><font size="1"></font></span><font size="2"><a href="http://patientprivacyrights.org/donate-2/" target="_blank"><font color="blue"><u>http://patientprivacyrights.org/donate-2/</u></font></a><font color="blue"><u> </u></font></font><span style="font-size:11pt"></span><span style="font-size:11pt"></span><span style="font-size:11pt"><font size="1"> <br></font><div></div></span><br></div></div>
</div>