Closed AaronGoldman closed 3 months ago
We have ed25519-priv
already, 0x1300
. What do you mean by "secret" in this context, are you talking about the private key, or a seed for a private key, or something else?
I was looking at an old table.csv thanks for reading the doc for me. 🤦♂️
I propose we add codes for ed25519-secret.
0xde since it is the opposite of 0xed.
Reason Working with multi-key makes short convenient unambiguous keys trivial. eg. The key
z6Mkg7Uz4NKdLrMHKXu2t3Moeu9TE7bapb2PMdxJn1JjjuX1
can be included in identifiers like did key.did:key:z6Mkg7Uz4NKdLrMHKXu2t3Moeu9TE7bapb2PMdxJn1JjjuX1
is generated from seedz625wgYZKAw6AYFT3MiZf9UmJAA26F1sXTwXroGLuj8v4bo8
The multiformat0xde
which is followed by exactly 32 bytes of seed. would allow an equally terse unambiguous URI safe secret key representation.because of the multiformat prefix a library could read
z6Mkg7Uz4NKdLrMHKXu2t3Moeu9TE7bapb2PMdxJn1JjjuX1
orz625wgYZKAw6AYFT3MiZf9UmJAA26F1sXTwXroGLuj8v4bo8
to produce the verification key. But onlyz625wgYZKAw6AYFT3MiZf9UmJAA26F1sXTwXroGLuj8v4bo8
would produce the signing key.did:key
has been one of the most compelling uses of multiformats and I think a complimentary 48 char way of storing the secret key would be valuable.