Unsolicited thoughts on fingerprinting: My team is doing an implementation of an idempotency system targeting rich clients (mobile apps and web SPAs, which can maintain their own idempotency protocol client implementations) and while compliance with a particular spec isn't our primary motivator, we implemented idempotency fingerprints for our use case (and were pleased to see them referenced in this document) so that we could provide a better experience for customers with fewer successful network round trips.

Scenario:

1. User submits a mutative request, receives a network timeout. [whether the request was a success is unknown to the client at this time]
2. User changes their mind, amends the request and resubmits. The protocol client retains the idempotency key for the resubmission intentionally.
3. Depending on whether the request was a success:
   a. If the initial request reached the server and was successful, the server reports that the attempted action is in conflict because of input mismatch, enabling the protocol client to report to the user that their request cannot be processed due to a conflict.
   b. If the initial request did not reach the server, the server performs the amended operation, and the client carries on without additional user interaction, or a need for additional automated reconciliation network attempts before the customer is allowed to resubmit.

Our hypothesis is that idempotency fingerprints are most useful for human-in-the-loop interactions with moderate to high risk of network partition. Most server-to-server idempotency scenarios can rely on the client not to change its mind about the operation wanting to be performed - the request payload is probably baked into a background job already alongside the idempotency key. For server-to-server idempotency protocols, we do not implement request fingerprinting for simplicity and to avoid many of the security risks I described in issue #40 just now.

I get the impression this section is just describing a best practice and providing implementation guidance. I'm not opposed to implementation guidance in specifications, but I don't see how this is useful. At the very least I suggest the normative language ought to be removed (the "MAY" doesn't make any guarantees that any party would find useful, it just seems to be descriptive), and the section moved to an appendix.

@darrelmiller We can expand the error scenarios section to cover the two scenarios you highlighted. Lmk what you think. Thanks.

@sdatspun2 Having pondered this for a whole lot longer, I can imagine a scenario where a server wants to protect itself against badly written clients that send the same idempotency key but not the same request.

According to RFC9110

A request method is considered "idempotent" if the intended effect on the server of multiple identical requests with that method is the same as the effect for a single such request.
https://www.rfc-editor.org/rfc/rfc9110.html#section-9.2.2

So, in my opinion, the scenario @jmileham described is out of scope because if a user changes the input values, then the subsequent requests should not expect to be idempotent.

I think clarifying that a server MAY use fingerprinting to help ensure that clients are using idempotency keys appropriately is reasonable guidance.

I do have some concern about this suggestion in the text

Checksum of selected element(s) in the request payload.

This infers that a client should be allowed to change some elements of the request. I suppose as long as the second request captures the same user intent, so that regardless of whether the first or second request succeeds the outcome for the user is the same, then all is good.

So, in my opinion, the scenario @jmileham described is out of scope because if a user changes the input values, then the subsequent requests should not expect to be idempotent.

I think clarifying that a server MAY use fingerprinting to help ensure that clients are using idempotency keys appropriately is reasonable guidance.

I second this. I would not expect a client to reuse the same idempotency key if the request is significantly changed.