Replay prevention

[paulbastian]

To prevent replay attacks the following mechanisms could be used:

• AS/Issuer providing a nonce
• reuse of existing of existing parameters as nonce
• limiting the lifetime of PoP (through JTI)

AS/Issuer providing a nonce

This requires an additional endpoint/ an additional roundtrip

reuse of existing of existing parameters as nonce

For some flows it might be doable to reuse the auth code/pre-auth code as a nonce, this saves another roundtrip but might not work for all flows, like PAR endpoint

limiting the lifetime of PoP (through JTI)

This is the existing mechanism described in the spec, the JWT PoP includes a jti and the AS needs to keep track of used jti values until they are expired

[paulbastian]

Option 2 is grant specific and not desired. Option 3 is in the text as a MAY Option 1 should be considered in DPoP-style and be added to the text

[PieterKas]

Support for a server generated nonce over which the attestation can be generated is something that is highly desirable to protect against pre-computation attacks. We have seen attacks where attackers deploy malware an pre-compute signatures (including manipulation of the system clock) and then exfiltrating these signatures for future use. This was one of the reasons why we strongly advocated for the inclusion of server supplied nonces in the DPoP standard.

Perhaps we can use a similar mechanism as in DPoP to include an optional server supplied nonce when generating the attestation (see Section 8 and 9 in DPoP for inspiration on supplying nonces as part of the interaction with the authorization and resource servers). The inclusion of the nonce as part of a 200 response helps save on roundtrips (bar the first need for a nonce).

[paulbastian]

todo: describe how a nonce request error look like