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

I doubt it wants to go into the core spec beyond the ability to extend easily.  You start to get into the semantics of what an identifier is and what is useful where.  My opinion is it wants to be either a small extension or a separate webservice call that allows the fetch.

> -----Original Message-----
> From: jpravetz@cayosystems.com [mailto:jpravetz@cayosystems.com] On
> Behalf Of Jim Pravetz
> Sent: Friday, September 10, 2010 7:23 PM
> To: William Mills
> Cc: oauth@ietf.org
> Subject: 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
> >