extends tezos/caip10 & caip122

[0xqibing]

Adds CAIPs for Tezos.

[zachferland]

for Ed25519, this caip-122 for this namespace looks good, since same message format and pretty standard Ed25519 stuff, but do you want to define it for Secp256k1 and P256 as well?

[0xqibing]

Actually, we can also define the Secp256k1 and P256, so did:tz1, did:tz2, or did:tz3 can be used. Then generated signature and its public_key should be grouped together, to ensure verification without any external APIs.

[0xqibing]

I have committed new changes to the Tezos namespace. Please check it for us

[bumblefudge]

Hey there @QibingLee -- Apologies for the delay in review. For the most part this looks good, but I had a few questions:

1. Could we update CAIP-2 (and the chainIDs in CAIP-10 while we're here) with a Limanet and a Ghostnet example? If you could add, as I did in the CAIP-2 the genesis block hash, it helps people test their own computation of the chainID string for private chains or future testnets...
2. I'm a little lost on the mention of a public key being passed-- do dapps request (or already get from the wallet connection step) a public key, for both onchain and offchain use-cases? Should this public key be part of the SIWT plaintext message, and/or appended to the canonicalized-and-stringified form that gets signed and verified against?
3. As above, could I ask you to provide a complete sample plain text message and a base64url-encoded byte representation of it, the way the original CAIP-122 spec does at the end of the ## examples section? This would serve the same "check your math" function as the CAIP-2 example in point # 1 above... which can be pretty important if someone wants to build SIWT into an app!

[bumblefudge]

Any updates, @QibingLee ? @zachferland would you feel qualified to address my requests instead, if Qibing isn't available to get this over the line?

[bumblefudge]

Suggested change

	[CAIP-10]: https://github.com/ChainAgnostic/CAIPs/blob/8fdb5bfd1bdf15c9daf8aacfbcc423533764dfe9/CAIPs/caip-10.md
	[CAIP-10]: https://ChainAgnostic.org/CAIPs/caip-10

[jdsika]

Keep this open as I will likely have a look at it soon-ish

[ukstv]

Hey all, re: CAIP-122, could you please provide an example of how a message should look like when presented to a user for signing? It would be interesting to see if there is any meaningful difference between tz1, tz2, tz3 signers.

[bumblefudge]

@QibingLee @jdsika any update here? I actually had a follow-up question that came up in another conversation about profiling CAIP-122:

1. what exactly are the valid possible values for t in the signature segment when serialized as a tripartite JWS object?

I see here in the current draft that different binary objects get prefixed by type, but what I don't understand is the signatureMeta.t value. For comparison, the EVM equivalents are named after EIPs, eip155 (for the classic personal_sign function) and eip1271 (for smart-contract-wallet interfaces defined in that EIP), and they refer to interfaces that require different variables be passed. The equivalent in the Tezos developer environment might be taquitoInMemorySigner and beaconSigner, since the digest being signed over has to be formatted/encoded differently for the different signing interfaces. Ideally a CAIP-122 profile would define an ENUM of the possible signing-styles, so that when CACAOs get replayed and verified in a new context by a new verifier, they know how to encode the CAIP-122 message to make the signature verify 😄

(I'm going from https://tezostaquito.io/docs/signing/, please point me to a better reference if there is more current or comprehensive guidance about different signing interfaces that people are actually using in the wild! )

[bumblefudge]

Note: the requirement to define an ENUM of valid signatureMeta.t values wasn't really explicit enough in the original CAIP-122; we made it more explicit in a recent PR when we realized profilers weren't defining them!

[bumblefudge]

@jdsika feel free to re-open if you are still working on Sign In With Tezos!