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

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 <danielf+oauth@yes.com> wrote:

> 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
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>