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

From: Jim Pravetz <[email-masked]>
Date: Fri, 10 Sep 2010 18:03:08 -0700

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

---

From: William Mills <[email-masked]>
Date: Fri, 10 Sep 2010 18:25:46 -0700

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: [email-masked] [mailto:[email-masked]] On Behalf
> Of Jim Pravetz
> Sent: Friday, September 10, 2010 6:03 PM
> To: [email-masked]
> Subject: [OAUTH-WG] Reason why no user identifier?
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Jim Pravetz <[email-masked]>
Date: Fri, 10 Sep 2010 19:22:54 -0700

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

---

From: William Mills <[email-masked]>
Date: Fri, 10 Sep 2010 22:16:39 -0500

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.

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Jim Pravetz
> Sent: Friday, September 10, 2010 7:23 PM
> To: William Mills
> Cc: [email-masked]
> Subject: 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.
> >

---

From: David Recordon <[email-masked]>
Date: Fri, 10 Sep 2010 20:17:41 -0700

Hey Jim, you should join the OpenID Connect work. We're layering
decentralized identity on top of OAuth 2.0.
 - http://openidconnect.com/
 - http://lists.openid.net/mailman/listinfo/openid-specs-connect

On Fri, Sep 10, 2010 at 7:22 PM, Jim Pravetz <[email-masked]> wrote:

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