[Openid-specs-ab] Discussion on the UserInfo endpoint and Claims

[Nat Sakimura]

Up to now, we have discussed three possibilities.

(authz_discovery is the process of obtaining endpoint url that matches the
requested resource type
 and associated access token.)

1) token_endpoint+authz_discovery, userinfo_endpoint
2) token_endpoint, userinfo_endpoint+authz_discovery

And today, the third came up:

3) token_endpoint, userinfo_endpoing, authz_discovery

Prior to February F2F, the draft was written in the form of 1).
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.

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".

Todays discussion, 3) tries to strip them out. Each endpoint will be simpler
and completely modular, but will require additional round trip.

FYI, my preference is 1) > 3) > 2). Factoring the current deployment impact,
it probably is 3) = 2) > 1).



On Tue, Mar 15, 2011 at 10:11 AM, Breno de Medeiros <
breno.demedeiros at gmail.com> wrote:

> Openid-specs-ab on BCC: as it's a closed discussion group.
>
> Background: There's a discussion on being able to assert claims about
> the user. For instance, a claim by the US Postmaster General about the
> user's address. Or a claim by the Japanese Government about the user's
> country of citizenship. Some of these claims cannot be generated by
> the server itself (which might be authoritative for, say, a claim
> about the user's email address if the server is also the user's email
> service provider). The current proposal by Nat/JBradley was that
> UserInfo endpoint would have a fairly extensible schema able to
> describe generic claims and additionally provide locations where
> claims could be retrieved from (if the server is unable to generate
> them), together with OAuth2 tokens that would be redeemable at those
> locations.
>
> I provided the feedback that the UserInfo endpoint would probably be
> more valuable by focusing on supporting the basic use case of
> authentication with (unverifiable) claims about user attributes
> asserted by the server, and move the handling of claims to a Claims
> Provider Discovery endpoint.  This endpoint could perform the
> translation, i.e., in exchange from an access token return a list of
> claim providers by claim type and the tokens that could be used for
> each of them. In this case, claims provided by the server (i.e.,
> claims for which the server is itself authoritative) would be handled
> exactly as any other 3rd party claims.
>
> We agreed to continue discussion here.
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>



-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110315/23505dcd/attachment.html>