Subject: [OAUTH-WG] draft-fett-oauth-dpop-00

From: Daniel Fett <[email-masked]>
Date: Thu, 28 Mar 2019 11:17:03 +0100

Hi all,

I published the first version of the DPoP draft at
https://tools.ietf.org/html/draft-fett-oauth-dpop-00

Abstract

   This document defines a sender-constraint mechanism for OAuth 2.0
   access tokens and refresh tokens utilizing an application-level
   proof-of-possession mechanism based on public/private key pairs.

Thanks for the feedback I received so far from John, Mike, Torsten, and
others during today's session or before!

If you find any errors I would welcome if you open an issue in the
GitHub repository at https://github.com/webhamster/draft-dpop

- Daniel

---

From: Ludwig Seitz <[email-masked]>
Date: Thu, 28 Mar 2019 12:05:20 +0100

> GitHub repository at https://github.com/webhamster/draft-dpop

A quick nit:

in figure 3 you seem to be using the "jwk" claim to include the pop-key 
in the token. Any reason for not using the "cnf" claim from RFC 7800?

/Ludwig

-- 
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51

---

From: Mike Jones <[email-masked]>
Date: Thu, 28 Mar 2019 11:28:51 +0000

Good observation, Ludwig.  We should do that.

				-- Mike

-----Original Message-----
From: OAuth <[email-masked]> On Behalf Of Ludwig Seitz
Sent: Thursday, March 28, 2019 12:05 PM
To: [email-masked]
Subject: Re: [OAUTH-WG] draft-fett-oauth-dpop-00

On 28/03/2019 11:17, Daniel Fett wrote:
> Thanks for the feedback I received so far from John, Mike, Torsten, 
> and others during today's session or before!
> 

A quick nit:

in figure 3 you seem to be using the "jwk" claim to include the pop-key in the token. Any reason for not using the "cnf" claim from RFC 7800?

/Ludwig

--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51

---

From: Filip Skokan <[email-masked]>
Date: Thu, 28 Mar 2019 19:48:45 +0100

Hello Daniel, everyone,

I've hacked together an AS implementation to enable client-side
experimentation using this draft.

You can find this hosted at
https://draft-fett-oauth-dpop-00.herokuapp.com (it's
also the issuer identifier). There's a default client registered and
dynamic registration is also open, so hack away. It's using the draft
version with dpop_binding expecting "jwk": { ...jwk } rather then "cnf": {
"dpop+jwk": { ... jwk } } as the payload claim as suggested by Ludwig.

There are more notes on the index page itself.

Aaron kindly accepted to work on the SPA client-side demonstration, I'm not
a SPA guru mastermind like Aaron and it would take me ages to deliver that
particular piece. That being said I did test this with a regular web app as
well as a CLI client using both code+pkce and dynamic port binding as well
as device authorization grant client. Works.

Feeding back to the draft

   - i think we should mention the client to provide reasonable expiration
   value of the dpop JWTs (max minutes). Altho not critical since we require a
   jti, as an AS i don't wanna cache the used jti values forever :)
   - the AS should error when the dpop JWT contains private key material
   - altho implied by the use of "public" and "private" key i think it
   wouldn't hurt explicitly forbidding "oct" JWKs
   - i don't see a point in dpop_proof containing the JWK again unless the
   AS is supposed to do something new with it
   - it wouldn't hurt mentioning that, kinda following 6750, when
   dpop_proof is sent it's in a query for GET, in the request body for a POST.
   my provider for instance will ignore query parameters during a POST. With
   that said, what about RS endpoints using other methods? Maybe placing the
   proof in a header isn't a terrible idea afterall.

Kind Regards,
*Filip Skokan*

On Thu, 28 Mar 2019 at 11:19, Daniel Fett <[email-masked]> wrote:

> If you find any errors I would welcome if you open an issue in the GitHub
> repository at https://github.com/webhamster/draft-dpop
>
> - Daniel
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Filip Skokan <[email-masked]>
Date: Fri, 29 Mar 2019 17:39:01 +0100

And here's a real simple client-side implementation using

- Webcrypto API
- IndexedDB API
- fetch

https://boiling-escarpment-16732.herokuapp.com/

It's not really a SPA but uses the same browser APIs and no backend other
than a web server hosting the html.

Best,
*Filip Skokan*

On Thu, 28 Mar 2019 at 19:48, Filip Skokan <[email-masked]> wrote:

> You can find this hosted at https://draft-fett-oauth-dpop-00.herokuapp.com (it's
> Aaron kindly accepted to work on the SPA client-side demonstration, I'm
> not a SPA guru mastermind like Aaron and it would take me ages to deliver
> that particular piece. That being said I did test this with a regular web
> app as well as a CLI client using both code+pkce and dynamic port binding
> as well as device authorization grant client. Works.
>
>    - i think we should mention the client to provide reasonable
>    expiration value of the dpop JWTs (max minutes). Altho not critical since
>    we require a jti, as an AS i don't wanna cache the used jti values forever
>    :)
>    - i don't see a point in dpop_proof containing the JWK again unless
>    the AS is supposed to do something new with it