I haven’t thought about PAR but would welcome thoughts. In general, I assume
that the “htu” value should be the actual endpoint used. What do others think?
Yes, I agree that the DPoP parameters on the front channel should only apply to
the front-channel access token, whereas if you’re using a response_type like
“code token”, then you’d want to send a separate DPoP proof JWT to the token
endpoint. I’ll plan to add that to the next draft.
Thanks,
-- Mike
From: Filip Skokan <[email protected]>
Sent: Tuesday, March 10, 2020 12:01 AM
To: Mike Jones <[email protected]>
Cc: [email protected]
Subject: [EXTERNAL] Re: [OAUTH-WG] OAuth 2.0 DPoP for the Implicit Flow
Hi Mike,
Thank you for the implicit dpop draft, quick questions
- what htu and htm should be used when used with PAR?
- is it fair to say that authorization request provided dpop parameters only
apply to authorization endpoint issued access tokens and in case of hybrid flow
- the client sends a new proof with the access token request to the token
endpoint?
Best,
Filip
Odesláno z iPhonu
10. 3. 2020 v 1:12, Mike Jones
<[email protected]<mailto:[email protected]>>:
As I previously described<https://self-issued.info/?p=1967>, members of the
OAuth working group have developed a simplified approach to providing
application-level proof-of-possession protections for OAuth 2.0 access tokens
and refresh tokens. This approach is called OAuth 2.0 Demonstration of
Proof-of-Possession at the Application Layer (DPoP). Among other benefits, it
does not require a complicated and error-prone procedure for signing HTTP
requests, as some past approaches have.
However, the DPoP specification to date has assumed that the client is using
the OAuth authorization code flow. As promised at the last IETF meeting, we’ve
now published a simple companion specification that describes how DPoP can be
used with the OAuth implicit flow – in which access tokens are returned
directly from the authorization endpoint. The specification is mercifully
brief because very little had to be added to supplement the existing DPoP spec
to enable use of DPoP with the implicit flow. Thanks to Brian Campbell and
John Bradley for whiteboarding this solution with me.
Finally, in a related development, it was decided during the OAuth virtual
interim meeting today to call for working group adoption of the core DPoP
draft. That’s an important step on the journey towards making it a standard.
The specification is available at:
* https://tools.ietf.org/html/draft-jones-oauth-dpop-implicit-00
An HTML-formatted version is also available at:
* https://self-issued.info/docs/draft-jones-oauth-dpop-implicit-00.html
-- Mike
P.S. This notice was also posted at https://self-issued.info/?p=2063 and as
@selfissued<https://twitter.com/selfissued>.
_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
