The response from the token endpoint has multiple parameters. There is no reason to put information the client needs in the access token.
That creates more problems than it solves. John B. Sent from my iPhone > On Jun 12, 2014, at 4:14 AM, Hannes Tschofenig <hannes.tschofe...@gmx.net> > wrote: > > Only a short note: We haven't standardized a delegation mechanism yet > and the proposals we had discussed in the past did not require the > client to understand the content of the access token even for delegation. > > Having said that I would like to note that it still required the AS to > send additional information to the client. Other protocols that support > delegation, like Kerberos, have included the information in the same > ticket (just in the unencrypted part of the payload). > > Ciao > Hannes > >> On 06/05/2014 10:19 PM, John Bradley wrote: >> Using structured access tokens to do delegation or convey other claims >> to the RS can and should be separate from the assertions delivered to >> the client. >> >> The tokens will have different audiences and if using Proof of >> Possession different presenter key material. >> >> Using one token for both things may work in the simplest use case but >> breaks a lot of things in OAuth. >> >> John B. >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
