On 06/12/2014 12:22 PM, Phil Hunt wrote:
One of the use cases is to return only a token that is NOT an access token and
is only an authentication assertion that is not opaque to the client.
A key concern is clients do not always want to ask users for consent to access
their profiles or any other resource. They just want authentication.
How many times do we see things like login with Yahoo, Twitter, Facebook and
they apparently want access to too much information? I’ve got lots of web site
developers who don’t want that because it looses registrations as a significant
percentage of users always refuse. These developers just want an authn ctx
and the easy-sign-on benefits.
If the developers want just the authentication context and not the
entire details about the user from providers such as Facebook, can we
just not ask with an appropriate scope for the provider? Something like
scope=username or scope=useremail. When the provider gives the data,
then it is understood that there was authentication and some user consent.
From this standpoint, having separate tokens makes sense. One remains opaque
to the client targeted for the resource server. The other is for the client.
You could have a new token type that can be dual-purpose and parseable to
everyone, but I think that may end up being more confusing. It would also mean
impacts to resource servers to support a new non-opaque token type.
Phil
@independentid
www.independentid.com
[email protected]
On Jun 12, 2014, at 1:04 AM, Hannes Tschofenig <[email protected]>
wrote:
Torsten,
nobody suggested that the access token would suddenly not be opaque to
the client.
The question therefore is whether the id token is not opaque to the
client. Is that the assumption?
On 06/05/2014 09:39 PM, Torsten Lodderstedt wrote:
the access token is opaque to the client. That's great! Let's keep it
that way.
Ciao
Hannes
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
