Closed swcurran closed 2 years ago
Instead of: "The SHA-256 hash of the first 16 bits of the public key" we should "The base58 encoding of the first 16 bytes of the SHA256 of the public key", as in id =Base58(Truncate_msb(16(SHA256(verkey))))
. This still requires the definition of encoding of verkey, e.g. binary, full hex or ~hex
I just realized that the short version~verkey relies on this mechanism, as the full_verkey = id || ~short_verkey
?
Updated the PR to include an update to the algorithm per the discussion at the 20220118 Indy Contributors call.
Please review the update.
Looks good imho and I like the idea of moving away from the abbreviation.
Sidenode unrelated to the spec: Should the client side handling (creating the full verkey if an abbreviation is found) be integrated into indy-vdr so this doesn't need to be implemented in every aries implementation? Right now this does not seem to be the case if I didn't miss anything quickly glancing over the code. I guess this is more of a question regarding the scope of indy-vdr: Is it supposed to be purely ledger interaction or some sort of convenience layer as well?
Per #26 , use a better way to connect a DID with its initial verkey (self-certifying DID).
I'm more of a messenger on this one. The argument is #26 make sense about not making the approach signature scheme specific. I'm less sure about the properties of the proposed approach, so would welcome feedback from others on that. It seems to make sense :-).