Subject: [OAUTH-WG] OAuth 2.0 DPoP for the Implicit Flow

From: Mike Jones <[email-masked]>
Date: Tue, 10 Mar 2020 00:11:43 +0000

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>.

---

From: Filip Skokan <[email-masked]>
Date: Tue, 10 Mar 2020 08:01:10 +0100

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 <Michael.Jones=[email-masked]>:
> 
> 
> As I previously described, 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.
>  
> https://tools.ietf.org/html/draft-jones-oauth-dpop-implicit-00
>  
> 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.
>  
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Tue, 10 Mar 2020 06:40:30 -0400

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 <Michael.Jones=
[email-masked]> 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.
>
>
>
>    - https://tools.ietf.org/html/draft-jones-oauth-dpop-implicit-00
>
>
>
>    - 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>.
>
>

---

From: Justin Richer <[email-masked]>
Date: Tue, 10 Mar 2020 09:33:37 -0400

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-masked]> wrote:
> 
> Mike,
> 
> On Mon, Mar 9, 2020 at 8:12 PM Mike Jones <Michael.Jones=[email-masked] <mailto:[email-masked]>> 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.
> 
>  
> 
> https://tools.ietf.org/html/draft-jones-oauth-dpop-implicit-00 <https://tools.ietf.org/html/draft-jones-oauth-dpop-implicit-00>
>  
> 
> https://self-issued.info/docs/draft-jones-oauth-dpop-implicit-00.html <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 <https://self-issued.info/?p=2063> and as @selfissued <https://twitter.com/selfissued>.
> 
>  
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

---

From: Aaron Parecki <[email-masked]>
Date: Tue, 10 Mar 2020 06:46:42 -0700

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-masked]> 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
>
>> 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.
>>
>>
>>
>>    -
>> P.S.  This notice was also posted at https://self-issued.info/?p=2063
>> and as @selfissued <https://twitter.com/selfissued>.
>>
>>
-- 
----
Aaron Parecki
aaronparecki.com
@aaronpk <http://twitter.com/aaronpk>

---

From: Mike Jones <[email-masked]>
Date: Tue, 10 Mar 2020 16:03:43 +0000

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-masked]>
Sent: Tuesday, March 10, 2020 6:47 AM
To: Justin Richer <[email-masked]>
Cc: Mike Jones <[email-masked]>; Rifaat Shekh-Yusef <[email-masked]>; [email-masked]
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-masked]<mailto:[email-masked]>> 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-masked]<mailto:[email-masked]>> wrote:

Mike,

Regards,
 Rifaat

On Mon, Mar 9, 2020 at 8:12 PM Mike Jones <Michael.Jones=[email-masked]<mailto:[email-masked]>> 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.

                                                       -- Mike

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth
--
----
Aaron Parecki
aaronparecki.com<http://aaronparecki.com>
@aaronpk<http://twitter.com/aaronpk>

---

From: Mike Jones <[email-masked]>
Date: Tue, 10 Mar 2020 16:21:37 +0000

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-masked]>
Sent: Tuesday, March 10, 2020 12:01 AM
To: Mike Jones <[email-masked]>
Cc: [email-masked]
Subject: [EXTERNAL] Re: [OAUTH-WG] OAuth 2.0 DPoP for the Implicit Flow

Hi Mike,

Best,
Filip

Odesláno z iPhonu

10. 3. 2020 v 1:12, Mike Jones <Michael.Jones=[email-masked]<mailto:Michael.Jones=[email-masked]>>:

                                                       -- Mike

---

From: Brian Campbell <[email-masked]>
Date: Wed, 11 Mar 2020 13:27:49 -0600

On Tue, Mar 10, 2020 at 10:21 AM Mike Jones <Michael.Jones=
[email-masked]> wrote:

> 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?
>

Yeah, in general, the “htu” and "htm" values should probably be related to
the actual request being made. PAR is a potentially interesting case where
it could maybe be argued that the values should reflect the eventual
request to the authorization endpoint. But I don't see any real reason to
pursue that angle. PAR could also potentially accept the DPoP header rather
than the dpop parameter because it's being called directly by the client.
But PAR being consistent in how it treats authorization request parameters
is probably preferable. And honestly PAR + DPoP bound access tokens issued
directly from the authorization endpoint seems a dubious combination so
maybe it's okay to be left un or under specified. Or maybe even prohibited.

>
>
> 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.
>

+1000

>
>                                                        Thanks,
>
>                                                        -- Mike
>
>
>
> *From:* Filip Skokan <[email-masked]>
> *Sent:* Tuesday, March 10, 2020 12:01 AM
> *To:* Mike Jones <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* [EXTERNAL] Re: [OAUTH-WG] OAuth 2.0 DPoP for the Implicit Flow
>
>
>
> Hi Mike,
>
>
>
> - 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 <
> Michael.Jones=[email-masked]>:
>
> 
>

-- 
_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._