ICRC-25: Version negotiation

[frederikrothenberger]

Currently ICRC-25 specifies version fields in both requests and responses. If the signer does not have the exact matching version, it is supposed to send an error back to the relying party.

As it currently stands, this makes it hard for relying party to find out which version is actually supported by the signer.

Let's use this issue to discuss how we want to proceed with the version field.

Options (as I currently see them):

Option	Description	Versioning Mechanism
1	Drop the version field	New versions will have a new ICRC number with a new method, discoverable using icrc25_supported_standards
2	Allow the relying party to send an array of versions	The relying party sends the list of all versions it supports, the signer picks the highest from the list it supports (or sends version_not_supported if there is none)
3	Allow the relying party to send the highest supported version	The relying party sends only the highest supported version. It is expected to support all lower versions. The signer picks the highest version it supports that is equal or lower to the relying party highest version (or sends version_not_supported if there is none)

Personally, I'm in favor of option 1 because it simplifies our standards. Using the icrc25_supported_standards method we can easily provide improved versions of existing methods. This also aligns better with the standardization process that does not really allow to publish new versions of existing standards. On top of that, given every method has its own standard, this allows signers to drop support for the old version by simply not including it in the list of supported standards.

@plitzenberger, @sea-snake: What is your opinion on that?

[plitzenberger]

@frederikrothenberger I'm voting for option 1 with introducing versioned methods.

[frederikrothenberger]

introducing versioned methods

Could you elaborate on that? I.e. you would do icrc31_get_principals_v2? Although icrc31_get_principals_v2 would be specified in some other ICRC?

We could also simply offer icrcXX_get_principals, where XX is > 31 indicating that it is a later standard.

[sea-snake]

My vote would be for option 1, it simplifies the method signature by keeping it constant (no versions = no changes) while allowing for new methods (for e.g. new versions) with new icrc standards analogues to how icrc canister standards are currently evolving (new or extending standards over versioning within a standard).

By keeping it constant, relying parties could reliably support older signers with older methods without ever having to update the implementations for calling and handling these methods. Relying parties could opt for newer methods when available (returned in supported methods call).

Also by keeping it constant, signers could consistently support older relying parties by implementing older methods without ever having to update the implementation for incoming calls and returning responses.

From UX perspective, if a signer decides to drop support for an older method, the relying party will know a method is not supported after querying the supported methods during the initial connection. This makes is simple for the relying party to indicate to the user that the signer is not supported on their platform.

All of this would be a lot more complicated on both ends if methods themselves were versioned.

[frederikrothenberger]

As discussed in the working group meeting on February 06, 2024 the version field will be dropped. If there is a need for an improved version of an existing method, a new ICRC standard should be made to describe the method.

Given ICRC numbers are part of the method name, we can then name the method the same, except for that number.

Example: icrc31_get_principals could eventually be superseded by icrcXX_get_principals.

I will close this issue, once all the existing drafts have been updated.

[frederikrothenberger]

All drafts have been updated.