<br><br><div class="gmail_quote">On Fri, Jan 7, 2011 at 07:24, 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">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></blockquote><div><br></div><div>It becomes complicated when you consider that there will be multiple scopes encoded in the request, not only for userinfo endpoint, but possibly for other APIs.</div>
<div><br></div><div>A major advantage is that the OpenID Connect response becomes a simple OAuth2 response, and works identically for both flows.</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>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></blockquote><div>
<br></div><div>Well, yes. There have been problems with disclosing user identities through the browser in initial authentication, with identity leaking through embedded content, for instance. But if the identity is not encoded in the response, then a token is needed for even public information at the UserInfo endpoint to identify the user. Additionally, the UserInfo endpoint might be able to provide information even for users that do not have public profile data if the request always uses a token.</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>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></blockquote><div><br></div><div>Agreed. </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>
Or are you talking about the protected resource being a PoCo endpoint directly?</div></div></blockquote><div><br></div><div>That's an orthogonal discussion, in my view.</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>John B.</div><div><br></div><div><br><div><div><div></div><div class="h5"><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">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">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></div></div><blockquote type="cite"><div><div></div><div class="h5"><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">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">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>
_______________________________________________<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><br>_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net">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><br><br clear="all"><br>-- <br>--Breno<br>