On Tue, Nov 26, 2019 at 6:26 PM Richard Backman, Annabelle < richa...@amazon.com> wrote:
> > That’s not directly attached to the access token. This means that every > RS has to know about DPoP. > > True, but you could avoid that by embedding the access token in the DPoP > proof (similar to draft-ietf-oauth-signed-http-request) and sending that as > the sole token. Technically, that’s no longer a bearer token so sending it > as “Authorization: bearer <token>” would be wrong, but DPoP already commits > that sin. > To clairy FWIW the current DPoP draft doesn't commit that sin. It uses “Authorization: dpop <access-token>” and "DPoP: <DPoP-proof-JWT>" headers. There were some examples attempting to illustrate how all the pieces of the proposal worked, including this particular part, in the slides I had for Singapore. But unfortunately I never made it past slide #6. On the other hand the OAuth MTLS draft does commit said sin. But it was intentional with the aim of easing adoption/migration to it. -- _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
