Up to now, we have discussed three possibilities. <div><br></div><div>(authz_discovery is the process of obtaining endpoint url that matches the requested resource type </div><div> and associated access token.) <br><div><br>
</div><div>1) token_endpoint+authz_discovery, userinfo_endpoint</div><div>2) token_endpoint, userinfo_endpoint+authz_discovery</div><div><br></div><div>And today, the third came up: </div><div><br></div><div>3) token_endpoint, userinfo_endpoing, authz_discovery</div>
<div><br></div><div>Prior to February F2F, the draft was written in the form of 1). </div><div>It was because userinfo endpoint is just another regular oauth resource, while token_endpoint may return any number of extension parameters, and it indeed is returning the list of endpoint urls and access tokens. </div>
<div><br></div><div>During the F2F discussion, it was switched to 2). The reason was that the result of authz_discovery is actually user metadata, which could conceptually captured into "UserInfo". </div><div><br>
</div><div>Todays discussion, 3) tries to strip them out. Each endpoint will be simpler and completely modular, but will require additional round trip. </div><div><br></div><div>FYI, my preference is 1) > 3) > 2). Factoring the current deployment impact, it probably is 3) = 2) > 1). </div>
<div><br></div><div><br><br><div class="gmail_quote">On Tue, Mar 15, 2011 at 10:11 AM, Breno de Medeiros <span dir="ltr"><<a href="mailto:breno.demedeiros@gmail.com">breno.demedeiros@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Openid-specs-ab on BCC: as it's a closed discussion group.<br>
<br>
Background: There's a discussion on being able to assert claims about<br>
the user. For instance, a claim by the US Postmaster General about the<br>
user's address. Or a claim by the Japanese Government about the user's<br>
country of citizenship. Some of these claims cannot be generated by<br>
the server itself (which might be authoritative for, say, a claim<br>
about the user's email address if the server is also the user's email<br>
service provider). The current proposal by Nat/JBradley was that<br>
UserInfo endpoint would have a fairly extensible schema able to<br>
describe generic claims and additionally provide locations where<br>
claims could be retrieved from (if the server is unable to generate<br>
them), together with OAuth2 tokens that would be redeemable at those<br>
locations.<br>
<br>
I provided the feedback that the UserInfo endpoint would probably be<br>
more valuable by focusing on supporting the basic use case of<br>
authentication with (unverifiable) claims about user attributes<br>
asserted by the server, and move the handling of claims to a Claims<br>
Provider Discovery endpoint.  This endpoint could perform the<br>
translation, i.e., in exchange from an access token return a list of<br>
claim providers by claim type and the tokens that could be used for<br>
each of them. In this case, claims provided by the server (i.e.,<br>
claims for which the server is itself authoritative) would be handled<br>
exactly as any other 3rd party claims.<br>
<br>
We agreed to continue discussion here.<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>
</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></div>