V51 - OAuth - DPoP proof replay attack protection

[randomstuff]

Should be a requirement about DPoP proof replay attack protection

Possible concrete mitigations:

• use a server-provided nonce
• limit the window of validity of the DPoP proof
• "jti" storage

FAPI 2.0 does not require the usage of DPoP server-side nonce:

if using DPoP, may use the server provided nonce mechanism

FAPI 2.0 has this requirement about "iat" validation (which is valid applicable to DPoP and other JWTs as well) but this actually does not help so much for our purpose:

to accommodate clock offsets, shall accept JWTs with an iat or nbf timestamp between 0 and 10 seconds in the future but shall reject JWTs with an iat or nbf timestamp greater than 60 seconds in the future.

[randomstuff]

See #2185

[randomstuff]

I don't believe, we should require the usage us DPoP nonce (FAPI 2.0 does not require it) or "jti" storage.

Possible options:

• do not mention this topic at all;
• only require that some mitigation is in place;
• require that "iat" validation uses a small window of validity.

[elarlang]

As we going to write requirements that must be followed by everyone (on a specific level), then I recommend ignoring the topic till we are not 100% sure or it is too specific an edge case with a small impact.

[TobiasAhnoff]

I think this does not need to be a requirement, FAPI also recognizes this as an "edge case", given confidential clients and alignment with other FAPI requirements (which we also have for L3), and in https://openid.bitbucket.io/fapi/fapi-2_0-security-profile.html#section-6.2 states that

These mitigations may have potential complexity, performance or scalability trade-offs. Attacker type A5 represents a powerful attacker and mitigations may not be necessary for many ecosystems.

So, I vote for "do not mention this topic at all" (even if e g nonce is a good mitigation to implement for some scenarios)