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 <panva...@gmail.com> 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 <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
