DidParser/BytesToKey API should enable use of other DID methods

[chunningham]

Excellent crate! I understand the initial implementation approach of being bound to did:key, but the API of BytesToKey and DidParser::parse assumes/requires that:

1. a public key will always be extractable from the DID string
2. DIDs will always be generative/not need to be resolved

Which actually permanently rules out any non-did:key methods (did:pkh is generative but a pub key cannot be extracted from the DID, and most other DID methods are not generative/require resolution and so would need DidParser::parse and BytesToKey to be async). Is there interest in a PR to move to a more general API to support such methods?

[cdata]

Hi @chunningham thank you for your consideration and the kind appraisal!

As you probably have noted, this crate is still "alpha." The API should be considered incomplete, in-progress and probably volatile.

The UCAN-spec requires did:key method support as a minimum for compliance, so that is where I started. It allows for other methods as an augmentation, so did:pkh and other methods may be used. I'm actually not a DID-method expert, so you may have insights here that the project could benefit from.

A PR would be welcome, although given the alpha nature of this crate I would ask for your flexibility during the review process.

One important consideration to keep in mind: I am explicitly developing a plausible web browser deployment path via the WASM target. This doesn't demand that all features be supported on the web, but it does mean that we should strive to maintain parity across targets and also keep the library size lean (as feasibility / practicality allows).

[chunningham]

Just to fill in the inference gap, the key difference (pun intended) is that in did:key, there is a 1:1 correspondence of DID to Pubkey and the public key itself is embedded in the DID string and thus can be extracted. In other methods (e.g. did:pkh, which essentially abstracts over various blockchain ecosystem accounts) there is a similar 1:1 correspondence, except that the DID string is (usually) a hash of the public key, so it cannot be processed to yield the public key itself. Indeed, even resolving the DID will give a DID Document with only the pub key hash, not the public key itself (some signature systems like Ethereum/secp256k1 allow the public key to be "recovered" from the signature, allowing verification of a signature without disclosing the key in advance) (this illustrates the distinction between something like a Linked Data Verification Method and "simple" public keys). That class of immutable, "1:1" DID methods is "generative": a DID string can be used to generate the entire DID Document.

The most general complication is that more complicated methods generally require a resource fetch over a network as they treat the DID Document as a mutable resource, allowing the set of public keys for a given DID to be updated, necessitating async and complex machinery like HTTP for full resolution. This class of resolution-based methods actually makes up the majority of methods, despite the fact that did:keys probably make up the vast majority of all used DIDs in practice. All that said, it makes absolute sense to start with did:key and the industry-at-large is facing similar questions of which DID methods are commonly supported and how to modularise the resolver interfaces for all of them. In particular when it comes to more constrained platforms like WASM, bundling multiple DID methods can blow up bundle size quite fast, as many DID methods have all kinds of fancy but specific features.

[cdata]

Thank you for that swift (and probably sparse) survey of what we are considering here @chunningham .

Here are my reactions (in no particular order):

• There is no hard requirement that all resolution mechanisms be possible in web browsers, allowing...
  • If features are not available on the web, there should be no byte size or code complexity cost for folks targeting the web
• We have already accepted async in much of the API, owing to the fact that it is not ergonomic to interact with Web Crypto synchronously from Rust/WASM at this time
• Although I am explicitly targeting WASM in web browsers, I currently do not have a plan to target WASM runtimes more generally
  • This may simplify the challenge, as you can assume DOM APIs such as fetch are available
  • It would be nice to support other WASM environments, but it is not a use case I have and can be considered out of scope for now if that helps
• If we can factor the API such that support for additional DID methods may be plugged in at the discretion of the crate consumer, that might be the happiest path forward
  • Perhaps there are small changes we could make that would enable support for other methods to be more easily layered on top?