<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.&nbsp;<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">&lt;<a href="mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com</a>&gt;</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. &nbsp;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">&lt;<a href="mailto:ve7jtb@ve7jtb.com" target="_blank">ve7jtb@ve7jtb.com</a>&gt;</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.&nbsp;</div><div>&nbsp;</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. &nbsp;Given that it is a new endpoint there are no backwards compatibility issues. &nbsp;</div>

<div><br></div><div>It works for the user agent flow as well, as far as I can tell. &nbsp;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.&nbsp;</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.&nbsp;<div><br></div><div>I have a question about the validation characteristics of the UserInfo Endpoint.&nbsp;</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.&nbsp;</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,&nbsp;assuming it is operated by the Authorization Server,&nbsp;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.&nbsp;</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.&nbsp;</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.&nbsp;</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.&nbsp;</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>