feat: Adds CAIP-122 standard for XRP Ledger. #84
Conversation
* feat: Adds CAIP-122 standard for XRP Ledger. * fix: Add some clarifications and follow the ripple-keypairs implementations for signing and verification * fix: Branch was renamed from master to main * fix: Remove double
antondalgren
changed the title
|
Any news on this @bumblefudge? |
|
LGTM with minor edits, which i left on your fork. Are there already public and open source implementations of this that you can link to from the # References section? If so, please add in the form: [name of implementation]: link to git repository
|
|
Thank you! Currently there are no reference implementations for this @bumblefudge |
| ``` | ||
| ### Signature Verification | ||
|
|
||
| Signature verification behaves similarly. We can use standard [secp256k1][] or[Ed25519][] signature verification. |
There was a problem hiding this comment.
Note that in the case of EVM, there are multiple signing methods (the spec mentioned eip155, aka personal_sign, classic metamask arbitrary unstructured text signing, and eip1271, aka smart contract wallet signing, for signatures produced by deployed smart contracts). is there only one signing method in Ripple, that you simply pass a secp256k1 or ed25519 key to, or are they two different signing interfaces with slightly different digest constraints/encodings, etc?
if the latter, it would be good to define the ENUM of valid signatureMeta.t values (recognizable names of signature interfaces in the XRP toolchain). and if the former, maybe just an ENUM with only one member? 😄
There was a problem hiding this comment.
https://xrpl.org/signing-methods.html
I hadn't thought about multi-signatures, but maybe we just include that in the enum and let future teams worry about that one 😅
There was a problem hiding this comment.
There is only one signing method in Ripple, that you simply pass a secp256k1 or ed25519 key.
There was a problem hiding this comment.
i mean, multi-signature might be the same algorithm/method but isn't the payload a little differently constructed? or am i missing something? you don't need to define it, I just want to make sure someone else defining it later understands how to do it (i.e., how to PR this adding a section for what's particular to it and adding a new valid value for SignatureMeta.t)
There was a problem hiding this comment.
I don't think multi-signature is relevant for this use case. But I'm happy to learn more about it otherwise.
It is used to verify the that the signature originates from the provided public key
| SigningPubKey String | ||
| } | ||
| ``` | ||
|
|
||
| ### Signature Creation | ||
|
|
||
| The abstract data model must be canonicalized to a string representation in an unambigious format, and then the string serialized to the proper binary format mentioned [above](#signing-algorithm) to be signed over with the proper algorithm. |
There was a problem hiding this comment.
Would it help to just specify JCS here, since it's the most general-purpose canonicalization for JSON?
There was a problem hiding this comment.
@antondalgren @ukstv thoughts ?
There was a problem hiding this comment.
I have no strong opinions regarding adding it or not.
| @@ -30,6 +30,16 @@ Correspondingly, a message needs to be serialized to bytes prior to signing it w | |||
|
|
|||
| We propose using the signature type `xrpl:secp256k1` and `xrpl:ed25519` to refer to the chain and algorithm used uniquely. | |||
There was a problem hiding this comment.
I would maybe add a sentence to this paragraph like,
These two signature types are the only two available and can be considered the defaults per key type. The typing of the signature MAY be made explicit by including a `SignatureMeta.t` property set to either `xrp1:secp256k1` or `xrp1:ed25519`, but if omitted the appropriate one of these two defaults should be obvious from the keytype provided in the `SignatureMeta.SigningPubKey` value.
There was a problem hiding this comment.
I think the context of your sentence is covered in the Signing Algorithm section.
Aligned with the ripple-keypairs implementations for signing and verification.