There are other advantages of returning the token in the UserInfo endpoint. An important one is that it alleviates concerns about token length.<br><br><div class="gmail_quote">On Fri, Jan 7, 2011 at 08:46, Nat Sakimura <span dir="ltr"><<a href="mailto:sakimura@gmail.com">sakimura@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hideki's suggestion was to return a JWT token that has user_id etc. within as access_token. It should work as long as the resource endpoint understands the access_token. <div>
<br></div><div>A issue however comes up if we have a OAuth 2.0 Resource Endpoint that we do not want to change. Then, the Authorization Server is constrained to issue the access_token the way it has been doing and cannot convert the access_token to the JWT token. </div>
<div><br></div><div>I am interested to find out if there are so many Resource Endpoints that falls under this category. If it is negligible, then we can drop this requirement. </div><div><br></div><div><font color="#888888">=nat</font><div>
<div></div><div class="h5"><br><br><div class="gmail_quote">
On Sat, Jan 8, 2011 at 1:13 AM, Breno de Medeiros <span dir="ltr"><<a href="mailto:breno@google.com" target="_blank">breno@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><br><div class="gmail_quote"><div>On Fri, Jan 7, 2011 at 08:06, Nat <span dir="ltr"><<a href="mailto:sakimura@gmail.com" target="_blank">sakimura@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF"><div>That is the whole point I and Hideki was making. </div><div><br></div><div>I assumed that what David is pointing out is that <span>the protected resource being a PoCo endpoint directly or existing OAuth endpoint. </span></div>
</div></blockquote><div><br></div></div><div>Nat, could you be more explicit. I am not sure what point you and Hideki were making.</div><div><br></div><div>As for the protected resource being an existing OAuth endpoint, I think that is an orthogonal issue to a large extent.</div>
<div><div></div><div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF"><div><br>=nat via iPhone</div><div><div></div><div><div><br>On 2011/01/08, at 0:24, John Bradley <<a href="mailto:ve7jtb@ve7jtb.com" target="_blank">ve7jtb@ve7jtb.com</a>> wrote:<br>
<br></div><div></div><blockquote type="cite"><div>One of the motivating factors of the JWT is that it can be a oAuth access token.<div><br></div><div>It seems simpler to include claims like userID in the signed access token, rather than having to include a separate access token inside.</div>
<div>The access token is for the user info endpoint in ether case.</div><div><br></div><div>Accessing public info at the user-info endpoint without a token should not be impacted by the access token format. Am I missing something?</div>
<div><br></div><div>If you get the access token through some other flow there is no particular issue with it being a JWT or some other format as long as the protected resource understands it.</div><div><br></div><div>Or are you talking about the protected resource being a PoCo endpoint directly?</div>
<div><br></div><div>John B.</div><div><br></div><div><br><div><div>On 2011-01-07, at 6:39 AM, Nat Sakimura wrote:</div><br><blockquote type="cite">Hmmm. That is interesting. So, it means that I should not optimize for the OpenID/OAuth use cases. The two cases below are different use cases than the OpenID/OAuth protected resource access. Is there any other use cases that people have in mind? <br>
<br><div class="gmail_quote">On Fri, Jan 7, 2011 at 4:43 PM, David Recordon <span dir="ltr"><<a href="mailto:dr@fb.com" target="_blank"></a><a href="mailto:dr@fb.com" target="_blank">dr@fb.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;color:rgb(0, 0, 0);font-size:14px;font-family:Calibri, sans-serif">
<div>I see two cases which may not work here:</div>
<ol>
<li>you're requesting public data in which case just a userid is required and no access token or JWT</li></ol></div></blockquote><div>For accessing public data, one can always ask without a token. </div><div>(I actually like the <a href="http://graph.facebook.com/username" target="_blank"></a><a href="http://graph.facebook.com/username" target="_blank">graph.facebook.com/username</a> style access.) </div>
<div>Using JWT received as a token to access restricted content does not prevent this behavior. </div><div>Am I missing something? (In the older version of the connect proposal, it was returning such URL instead of opaque user_id. That was good.) So this does not seem to be a blocking factor. </div>
</div></blockquote><div><br></div><br><blockquote type="cite"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;color:rgb(0, 0, 0);font-size:14px;font-family:Calibri, sans-serif"><ol><li>you got the access token via a non-OpenID OAuth 2.0 flow. I can imagine a PoCo endpoint doubling as the OpenID user info API.</li>
</ol></div></blockquote><div>This probably is more relevant. </div><div><br></div><div>Then the question would gets to the point Hideki pointed out: </div><div>why cannot we make "signed" as we call now the "access_token" with token_type=signed_openid? </div>
<div>It will save us from defining an OAuth extension variable called "signed" and more OAuth2.0 compliant. </div><div><br></div><div>(As a side issue: I started to feel that we probably do not need "code" in the OAuth2.0 spec., but just "access_token" with type="authz_code". "code" is just another type of access_token which can only be used once and at the authz endpoint.)</div>
<div><br></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;color:rgb(0, 0, 0);font-size:14px;font-family:Calibri, sans-serif">
<div><div></div><div>
<div><br>
</div>
<span>
<div>
<div>On 1/6/11 11:40 PM, "Nat Sakimura" <<a href="mailto:sakimura@gmail.com" target="_blank"></a><a href="mailto:sakimura@gmail.com" target="_blank">sakimura@gmail.com</a>> wrote:</div>
</div>
<div><br>
</div>
<blockquote style="border-left:#b5c4df 5 solid;padding:0 0 0 5;margin:0 0 0 5">
<div>Hi guys. </div>
<div><br>
</div>
<div>Do you have objection to passing the entire JWT ("signed") instead of access_token and user_id extracted to the UserInfo endpoint? </div>
<div>That seems to be a lot simpler. </div>
<div><br>
</div>
<div>=nat</div>
</blockquote>
</span>
</div></div></div>
</blockquote></div><br><br clear="all"><br>-- <br>Nat Sakimura (=nat)<br><a href="http://www.sakimura.org/en/" target="_blank"></a><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"></a><a href="http://twitter.com/_nat_en" target="_blank">http://twitter.com/_nat_en</a><br>
_______________________________________________<br>Openid-specs-ab mailing list<br><a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank"></a><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></div></div><br>_______________________________________________<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>
<br></blockquote></div></div></div><br><br clear="all"><br>-- <br><font color="#888888">--Breno<br>
</font></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>
</div></div></div>
</blockquote></div><br><br clear="all"><br>-- <br>--Breno<br>