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">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">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>
<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">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/">http://www.sakimura.org/en/</a><br><a href="http://twitter.com/_nat_en">http://twitter.com/_nat_en</a><br>