Re: [OAUTH-WG] Reason why no user identifier?

There are use cases where the user does not wish to disclose anything extra in the 3 legged case.  For example, I am both a Yahoo and Facebook user, and I want to allow events to be published on Facebook when I comment on an article at Yahoo (there are many many of these kinds of pairings).  I don't want to tell Yahoo! my account name at Facebook, Yahoo gets a credential to use with Facebook that discloses nothing about me other than I am a Facebook user and I want Yahoo to use the updates API.

Making a user identifier a requirement prevents these use cases.  There are other use cases where a site may want to provide a user handle separate from the token that can be used as a primary key, but again is opague and discloses nothing about the user.  The token can be used to fetch user information if the PR chooses to allow that.

> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Jim Pravetz
> Sent: Friday, September 10, 2010 6:03 PM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] Reason why no user identifier?
> 
> I'm curious and would appreciate some background as to why there is no
> user identifier associated with tokens (access, refresh, or
> authorization code)? It seems so common to use identifiers, and
> convenient, that this is a surprise. In contrast, the spec does define
> a client identifier.
> 
> In my use case I have a client (native application) that stores
> records retrieved from a server, for one or more individuals (i.e. I
> maintain credentials for multiple users). Without a user identifier,
> it would seem that user identification would have to be retrieved from
> data returned from the protected resource, and it seems plausible that
> existing protocols might not have this capability.
> 
> It would also seem more efficient to be able to determine if a user
> already has a local (on client) credential without going through the
> full process of getting an access token and retrieving a protected
> resource. For instance, if a user initiates an enrollment process the
> process could be stopped early if a token for a userid is already
> possessed.
> 
> I would think the protected resource server would also benefit from a
> user identifier. At a minimum it would provide useful logging
> information for failed login attempts, and perhaps could be used in
> risk analysis.
> 
> Apologies if this is an old topic or if I missed the explanation
> somewhere.
> 
> Regards, Jim
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth