<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Assuming the JWT is signed then a smart client validates the sig and a dumb one sends it to the Sig validation endpoint otherwise known as the user info endpont.<div><br></div><div>The endpoint then only needs to validate the sig on the JWT and hand it back in the simple case.</div><div><br></div><div>John B.<br><div><div>On 2011-01-14, at 10:14 PM, Nat Sakimura wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">I agree in sending the entire JWT to the Signature Validation Endpoint. UserInfo Endpoint looks like a kind of such. <div><br></div><div>=nat<br><br><div class="gmail_quote">On Sat, Jan 15, 2011 at 9:55 AM, John Bradley <span dir="ltr"><<a href="mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com</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">I was thinking that the access tokens for the various endpoints would be in the JWT. The JWT would only be the access token for the user info endpoint.<div>
<br></div><div>John B.<div><div></div><div class="h5"><br><div><div>On 2011-01-14, at 9:51 PM, Nat Sakimura wrote:</div><br><blockquote type="cite"><br><br><div class="gmail_quote">On Sat, Jan 15, 2011 at 9:03 AM, John Bradley <span dir="ltr"><<a href="mailto:ve7jtb@ve7jtb.com" target="_blank">ve7jtb@ve7jtb.com</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">I think exchanging code for the access token in the web server flow is equivalent proof for any assertion returned along with the access token in the web server flow.</div></blockquote><div>
<br></div><div>Thanks. </div><div> </div><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><br></div><div>On your second question, that's why I was asking if the JWT returned in the web server flow could also be the access token. Given that it is a new endpoint there are no backwards compatibility issues. </div>
<div><br></div><div>It works for the user agent flow as well, as far as I can tell. I was discussing a similar idea with the UMA people for there dumb mode flow.</div></div></blockquote><div><br></div><div>Unless, of course, we return the access tokens for multiple endpoints. We may not want to reveal more information than necessary. </div>
<div><br></div><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><br></div><div>John B.</div><div><div><div><div></div><div>
<div>On 2011-01-14, at 8:52 PM, Nat Sakimura wrote:</div><br></div></div><blockquote type="cite"><div><div></div><div>Hi. <div><br></div><div>I have a question about the validation characteristics of the UserInfo Endpoint. </div>
<div><br></div><div>According to the <a href="http://openidconnect.com/" target="_blank">openidconnect.com</a> proposal, the Client is supposed to make a query to the UserInfo Endpoint if it does not wish to validate the signature on the positive assertion that includes the access_token. It sends the user_id and access_token to the UserInfo Endpoint and it gets back asserted_user among other things. If asserted_user is true, then the validation was successful. </div>
<div><br></div><div>It makes some sense in the User-Agent Flow. In case of the User-Agent Flow, the assertion is returned through the browser/user-agent so it cannot be trusted. It may have been tampered etc. Thus, assuming it is operated by the Authorization Server, sending the query to the UserInfo Endpoint has value. Also, there is an additional value in doing so because the UserInfo Endpoint can validate that it is the same User-Agent that was found at the End User Authorization Endpoint, that the User-Agent has not been swapped. </div>
<div><br></div><div>However, it does not make much sense in case of the Web Server like flows where 'code' is exchanged to 'access_token' over the direct https Client-Server channel. All the validation characteristics for the UserInfo Endpoint already exists in the Access Token Endpoint. Thus, UserInfo query is redundant as a validation process and becomes an OPTIONAL user attribute query. </div>
<div><br></div><div>Am I missing something? If I am right, then the 'MUST check' language comes in for the validation through the UserInfo Endpoint only in the User-Agent Flow. In fact, the assertion does not even have to be signed by the Server in case of Web Server/Artifact Flow. </div>
<div><br></div><div>Also, in the current <a href="http://openidconnect.com/" target="_blank">openidconnect.com</a> proposal, only the access_token and user_id but not the entire token is sent to the UserInfo Endpoint. It was argued earlier that this was done because UserInfo Endpoint ought to be a regular protected resource. I thought that was a good reason. However, now I consider it as a validation endpoint, I find some value in sending the entire JWT as well. If the JWT was using RSA or EC-DSA as a signature algorithm, then the validation endpoint can be operated by a separate entity than the Server, without assuming any additional characteristics on the access_token. It probably is worth considering. </div>
<div><br>-- <br>Nat Sakimura (=nat)<br><a href="http://www.sakimura.org/en/" target="_blank">http://www.sakimura.org/en/</a><br><a href="http://twitter.com/_nat_en" target="_blank">http://twitter.com/_nat_en</a><br>
</div></div></div>
_______________________________________________<br>Openid-specs-ab mailing list<br><a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote></div><br></div></div></blockquote></div><br><br clear="all"><br>-- <br>Nat Sakimura (=nat)<br><a href="http://www.sakimura.org/en/" target="_blank">http://www.sakimura.org/en/</a><br><a href="http://twitter.com/_nat_en" target="_blank">http://twitter.com/_nat_en</a><br>
</blockquote></div><br></div></div></div></div></blockquote></div><br><br clear="all"><br>-- <br>Nat Sakimura (=nat)<br><a href="http://www.sakimura.org/en/">http://www.sakimura.org/en/</a><br><a href="http://twitter.com/_nat_en">http://twitter.com/_nat_en</a><br>
</div>
</blockquote></div><br></div></body></html>