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

[Filip Skokan <[e-mail]>]

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 <[e-mail]> wrote:

> 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 <[e-mail]> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>