Hi all, I recently built a prototype of DPoP using Go, and wanted to provide some feedback as I went about the implementation.
The implementation is open source: https://github.com/pquerna/dpop Overall the spec felt functional, though I think the biggest gaps for a deployment are with the Access Token interactions, but this makes sense since that seems to be addressed in the future by <https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-00> Jumping into specific items: cnf in DPoP-Proof > o "cnf": Confirmation claim as per [RFC7800] containing a member > "dpop+jwk", representing the public key chosen by the client in > JWK format (REQUIRED for DPoP Binding JWTs, OPTIONAL for DPoP > Proof JWTs). Is there a use case for this being present in the DPoP-Proof JWT? As I've implemented DPoP, I didn't see how it was helpful to be sent as a `cnf` claim of the Proof? Request Headers vs Parameters > 5. Token Request (Binding Tokens to a Public Key) Placing the DPoP Binding JWT in the HTTP Header `DPoP-Binding` is different than most other OAuth extensions that I am familiar with. It is easy in the Go OAuth2 library to add URL / /body params to the `/token` endpoint, but it is impossible to add an HTTP Header. Is there a reason that the binding can't be sent as an OAuth Parameter in the token request body? HTTP Request Signing > o "http_method": The HTTP method for the request to which the JWT is > attached, in upper case ASCII characters, as defined in [RFC7231] > (REQUIRED). > > o "http_uri": The HTTP URI used for the request, without query and > fragment parts (REQUIRED). HTTP Request signing may be a quagmire that this spec wishes to avoid, but it seems very hard to avoid "fixing" it for at-scale adoption. With the Okta-hat on, I think this is one area we would like to see some iteration on. I think it would be ideal to not require multiple client sign() and server validate() PKI operations per request, so this is where combining DPoP-Proof and a Request Signature start making sense to me. Keeping it simple, there are two approaches for DPoP for adding attesting about the HTTP Request: a) Adding parts of the HTTP Request as claims b) Adding a hash of an HTTP Request as a claim For option (b), it seems like part of this could live in a separate spec: 1) request canonicalization 2) request hashing <https://tools.ietf.org/html/draft-cavage-http-signatures-11> does cover request canonicalization, but the hashing is part of the specific signature scheme. From an implementors POV, layering draft-cavage-http-signatures-11 in addition to DPoP is annoying since it would take two sign or verify key operations per request. I'm not sure where the spec-author team wants to take this area, but am interested in providing feedback. JWT as AT > 7. IANA Considerations > > [[TODO: MIME type registration for at+jwt ]] Assume this will eventually be done via <https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-00> Thank you for the work so far, and I'm happy to provide further feedback as the spec evolves. Paul _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
