We encountered an implementation problem with the credentials module.

Consider the standard flow when a partner re-rolls credentials.

1. Sender issues PUT /credentials using the existing Receiver token, containing a new Sender token.
2. Receiver generates a new Receiver token and returns it to the Sender.

This is seemingly straightforward, but there is a subtle problem because the validity of the tokens is not strictly defined during the exchange. A Sender may regard the new Sender token as invalid until exchange is complete, or it may regard it as immediately valid, having invalidated the previous Sender token for security reasons. The Receiver thus has a dilemma.

Case 1

1. Sender who DOES NOT activate new token until credentials exchange succeeds sends PUT /credentials.
2. Receiver generates a new Receiver token but encounters an issue resulting in an HTTP error response. The Receiver should NOT store the new Sender token.

Case 2

1. Sender who DOES activate new token before credentials exchange sends PUT /credentials.
2. Receiver generates a new Receiver token but encounters an issue resulting in an HTTP error response. The Receiver SHOULD store the new Sender token.

But there is no way of knowing, via the specification, whether a token is valid during the credentials exchange. (We could, obviously, test the new credential with a side-request during the exchange, but that is not part of the spec.) Thus the eMSP cannot deal with all CPOs correctly based on the spec alone.