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

Thanks for the explanation, William.

Is there or should there be guidance in the spec for providing an
optional user handle for when the token issuer trusts the client with
this information?

Regards, Jim

On Fri, Sep 10, 2010 at 6:25 PM, William Mills <wmills@yahoo-inc.com> wrote:
> 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
>