Answering Rifaat’s question, per Brian’s comment
https://github.com/danielfett/draft-dpop/issues/37#issuecomment-534192398, at
IETF 105 there was consensus to at least initially do this work in a separate
draft.
-- Mike
From: Aaron Parecki <[email protected]>
Sent: Tuesday, March 10, 2020 6:47 AM
To: Justin Richer <[email protected]>
Cc: Mike Jones <[email protected]>; Rifaat Shekh-Yusef
<[email protected]>; [email protected]
Subject: [EXTERNAL] Re: [OAUTH-WG] OAuth 2.0 DPoP for the Implicit Flow
This is my sentiment as well, I would not support this text being added to the
DPoP draft.
Aaron
On Tue, Mar 10, 2020 at 6:35 AM Justin Richer
<[email protected]<mailto:[email protected]>> wrote:
I for one appreciate it being a separate draft as I don’t agree with this
solution but do think we should move forward with DPoP.
— Justin
On Mar 10, 2020, at 6:40 AM, Rifaat Shekh-Yusef
<[email protected]<mailto:[email protected]>> wrote:
Mike,
What was the reason for creating a separate draft for this?
Why cannot this be folded into the exiting DPoP draft?
Regards,
Rifaat
On Mon, Mar 9, 2020 at 8:12 PM Mike Jones
<[email protected]<mailto:[email protected]>>
wrote:
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]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
--
----
Aaron Parecki
aaronparecki.com<http://aaronparecki.com>
@aaronpk<http://twitter.com/aaronpk>
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
