search

hyperledger / indy-did-method

Indy DID Method Specification
https://hyperledger.github.io/indy-did-method/
Creative Commons Attribution 4.0 International
18 stars 14 forks source link

Update the method for self-certifying DIDs per suggestion in #26 #27

Closed swcurran closed 2 years ago

swcurran commented 2 years ago

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 :-).

paulbastian commented 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

paulbastian commented 2 years ago

I just realized that the short version~verkey relies on this mechanism, as the full_verkey = id || ~short_verkey?

swcurran commented 2 years ago

Updated the PR to include an update to the algorithm per the discussion at the 20220118 Indy Contributors call.

Please review the update.

c2bo commented 2 years ago

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?