SIP-018 Signed Structured Data

[MarvinJanssen]

The Signed Structured Data specification proposed in this SIP describes a standard way to deterministically encode and sign Structured Data. Structured Data is data that can be represented in human-readable format and used in applications and smart contracts. The aim of the standard is to produce signatures that are straightforward and inexpensive to verify by smart contracts.

Reference implementation:

• https://github.com/MarvinJanssen/stx-signed-structured-data

Requires:

• to-consensus-buff / CV serialisation in Clarity as described in Feature request: allow hashing functions to hash other Clarity types stacks-network/stacks-core#2693. I am currently using a custom REPL / Clarinet that includes this function. I will make an effort to publish the branch as soon as possible.

See also:

• Expose method to sign arbitrary messages leather-io/extension#1051
• Feature request: allow hashing functions to hash other Clarity types stacks-network/stacks-core#2693
• Expose chain ID in Clarity stacks-network/stacks-core#2982

[jcnelson]

Thank you for submitting this SIP! Based on my initial read, my recommendation is to split this SIP into two or more SIPs with the following proposals:

• A SIP that proposes to-consensus-buff, which is a breaking change and thus needs a consensus consideration. It could activate with, but no sooner than Stacks 2.1.

• A SIP that proposes a data signing and verifying scheme built around to-consensus-buff that recommends signed data begin with a canonical preamble that encodes a message prefix constant, a domain, a chain ID, etc. This could activate anytime after to-consensus-buff goes live, and it does not need consensus consideration.

[jcnelson]

I took another pass at this, in light of the recent OpenSea phishing attack. While I stand by my belief that discussion of to-consensus-buff should be part of the Stacks 2.1 SIP, I think the rest of this is good. Most of my comments are just asking for minor clarifications.

[friedger]

Just as additional context, Verifiable Credentials are a second type of structured data that wallets should support

[radicleart]

Marvin - a question on making the domain info stronger by eg including domain names and user agent info?

cf. EIP 712 says this..

The way to solve this is by introducing a domain separator, a 256-bit number. This is a value unique to each domain that is ‘mixed in’ the signature. It makes signatures from different domains incompatible. The domain separator is designed to include bits of DApp unique information such as the name of the DApp, the intended validator contract address, the expected DApp domain name, etc. The user and user-agent can use this information to mitigate phishing attacks, where a malicious DApp tries to trick the user into signing a message for another DApp.

[aulneau]

Hi all -- just wanted to let folks know that I've implemented support for interacting with wallets that support this standard within micro-stacks:

Relevant versions:
micro-stacks: >= 0.5.0
@micro-stacks/react: >= 0.2.1

Some docs:
https://docs.micro-stacks.dev/modules/core/connect/message-signing
https://docs.micro-stacks.dev/modules/integrations/react/message-signing

Note: I have also implemented support for recoverable signatures in both RSV mode (like this sip expects) and VRS mode (like legacy stacks functions used)

[jcnelson]

Did another pass. Let's go ahead and advance this to Accepted 🎉

Before we can advance to Recommended, I have two outstanding comments that need to be addressed. Also, @kantai (who is now on the technical CAB) needs to make a pass as well.

[MarvinJanssen]

SIP document updated with the new "SIP018" prefix in 318bad3!

To everyone that was/is implementing SIP018: this is a BREAKING CHANGE.

The prefix has been changed from a single-byte 0xC0 to six bytes: [0x53, 0x49, 0x50, 0x30, 0x31, 0x38]. (Which spells "SIP018" in ASCII.)

If you are curious why, see this discussion: #57 (comment)

The reference implementation has also been updated to reflect the change:

• https://github.com/MarvinJanssen/stx-signed-structured-data

[aulneau]

[email protected] has been updated to support the latest implementation of this SIP, matching the test vectors supplied in 318bad3

[kantai]

This looks great to me, just had some superficial comments, and then we can move this to recommended!

[MarvinJanssen]

Implemented suggestions and moved to Recommended.

[jcnelson]

Cool! Do the authors feel that this is ready for activation?

[MarvinJanssen]

Yep. But will give @janniks time to respond to the last open conversation.

[jcnelson]

Wanna ping me when it's ready? @janniks @MarvinJanssen

[MarvinJanssen]

Ready to go @jcnelson

[jcnelson]

Cool, it's now listed as "activating" in the README. Can you set the status to Activation-in-Progress? Thanks!

[MarvinJanssen]

Done!

[MarvinJanssen]

Looking at the activation criteria:

1. to-consensus-buff or equivalent functionality is added to Stacks 2.1.
2. At least one popular wallet application implements the standard before or within one year of the launch of Stacks 2.1.

Do you think both have been met @jcnelson? Hiro Wallet as well as the Stacks Ledger applet added support for SIP018 messages and to-consensus-buff has been added to Stacks 2.1. Can we thus consider this SIP activated or do we wait until the launch of Stacks 2.1?

[jcnelson]

Just an update on this -- we will merge this when 2.1 activates on mainnet.