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. >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 phil.h...@oracle.com On Jun 12, 2014, at 1:04 AM, Hannes Tschofenig <hannes.tschofe...@gmx.net> 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 > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
