<html><body 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 class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.292969); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); ">the protected resource being a PoCo endpoint directly or existing OAuth endpoint. </span><br><br>=nat via iPhone</div><div><br>On 2011/01/08, at 0:24, John Bradley <<a href="mailto:ve7jtb@ve7jtb.com">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 class="Apple-interchange-newline"><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"><a href="mailto:dr@fb.com">dr@fb.com</a></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"><a href="http://graph.facebook.com/username">graph.facebook.com/username</a></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 class="h5">
<div><br>
</div>
<span>
<div>
<div>On 1/6/11 11:40 PM, "Nat Sakimura" <<a href="mailto:sakimura@gmail.com" target="_blank"><a href="mailto:sakimura@gmail.com">sakimura@gmail.com</a></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/"><a href="http://www.sakimura.org/en/">http://www.sakimura.org/en/</a></a><br><a href="http://twitter.com/_nat_en"><a href="http://twitter.com/_nat_en">http://twitter.com/_nat_en</a></a><br>
_______________________________________________<br>Openid-specs-ab mailing list<br><a href="mailto:Openid-specs-ab@lists.openid.net"><a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a></a><br><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br></blockquote></div><br></div></div></blockquote></body></html>