Hi all, I'm new to all of this, please forgive me if I'm missing any expectations or conventions here.
I have a bit of feedback for OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer (DPoP) draft-ietf-oauth-dpop-09 ( https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop). I'm aware that you're already after the Working Group Last Call, so I'm trying to come in with mostly non-normative changes, and with draft suggestions rather than just open questions. I've opened several pull requests against the RFC repo so that needed changes can be easily incorporated, and not get blocked by changes that are more my preference. I also wanted to follow up here to provide a little bit more context on the change proposals. # PR Nonce clarifications, more complete documentation, and guidance https://github.com/danielfett/draft-dpop/pull/157 It seems like there might be a little bit of a disconnect between what has been discussed around nonces and what's actually present in the draft. I saw that there's a previous edit suggesting a "recently supplied" nonce, and that's more in line with my expectations than the previous draft, but it's immediately followed by a paragraph starting with "The intent is that both clients and servers need to keep only one nonce value for one another." I made a couple changes to revise this statement to suggest the server keeps a window of recent nonces, to add "nonce" to the syntax section of the document, and to add a few more details to the nonce section of `DPoP Proof Replay {#Token_Replay}` # PR Proposal Section 7.2 Client Considerations https://github.com/danielfett/draft-dpop/pull/158 Added a `Client Considerations` sub-section to `Protected Resource Access {#protected-resource-access}`. I think there's a lot of potential to get retry on idempotent requests wrong here going forward. This is regularly handled at an HTTP client level, and that is likely to thrash for some server implementations. I added a recommendation to generate a new DPoP proof for retry, even if it's something they've previously considered a transient error. I don't really have guidance for improving this spec in environments where there are frequent network errors, but it seems like a concern worth considering as well for implementers. # PR Fully specified examples https://github.com/danielfett/draft-dpop/pull/160 Added nonce to the DPoP proof examples. Added decoded DPoP proofs to examples. It's nice to not have to decode while looking at examples. Additionally, added references to the private keys used for signing and repeated the requirement to redact private key material from requests a few more times. I'm not sure if it's unconventional to include a private key in a RFC, but it's a throwaway key, and reiterating private key redaction in DPoP proofs a few more times seems like it couldn't hurt. # PR Checking DPoP Proofs tweaks https://github.com/danielfett/draft-dpop/pull/159 In `Checking DPoP Proofs {#checking}`: `alg` checking seems vague, especially around "is deemed secure". Adding a reference to `dpop_signing_alg_values_supported` here instead, and moving the details of algorithm selection to that metadata section instead. Clarifying that order is not implied by the numbering of this list. Fixing link to RFC3986. Please let me know if you have any suggestions for improving these change proposals. Thanks, Spencer Balogh
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
