sRFC 0024: Extending off-chain message signing standard

sRFC
1

sRFC 0024: Extending off-chain message signing standard

Summary

Off-chain message signing (OCMS) is a standard used by software wallets, hardware wallets and protocols to sign arbitrary text messages. These messages have a variety of use cases that all revolve around the same workflow - proving wallet ownership without requiring the user to sign and submit a transaction that pays gas.
Currently, OCMS lacks line break support in its most simple and widely used encoding. This sRFC proposes changes to the standard to add line breaks to allow better formatted messages from apps to improve overall UX.

Reference

Current OCMS standard version 0 is being used as a baseline for this sRFC.
The new standard version should emerge from forking the current reference and implementing the changes bellow.

Changes

  1. Change the header version from 0 to 1.

From:

Only the version 0 header format is specified in this document

To:

Only the version 1 header format is specified in this document

  1. Change the definition of “Restricted ASCII” to include the ‘\n’ (0x0a) character in version 1.

From:

** Those characters for which isprint(3) returns true. That is, 0x20..=0x7e .

To:

** Those characters for which isprint(3) returns true or the newline - \n character. That is, 0x20..=0x7e or 0x0a.

Examples:
In the examples bellow assume that all message encodings are set to 0 - Restricted ASCII, only header version changes

The following message works across both versions:

A sample message with no newline character.

The following message fails when the header version is 0 but is to be accepted with the newly specified version 1:

A sample message with line breaks.
This message allows apps to add line breaks and to better format to their messages.

Compatibility
Adding support to the new version is trivial, just checking the updated header version and the extra newline character on messages.

In order to be backwards compatible with the previous version for software that needs to parse and handle these messages, implementers just need to be slightly lax on header version checks. Instead of forcing the header_version == 0 one can check if header_version <=1.

2 Likes