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