Add Source::KeyAndPattern and DIDMethods::generate

[clehner]

Allow passing an additional string to a DID method in the generate function.

Implementing generate on DIDMethods allows generating a DID from a set of DID methods given a DID method name and optional additional string, separated by a colon (:).

The additional string may be a prefix or pattern for the DID's method-specific ID, according to the DID method.

This is intended to enable #124.

[sbihel]

I was a bit confused at the beginning for the recursion. Maybe pattern isn't the right term, maybe something like inner_did, but that might be more specific than intended. I don't have a strong opinion.

[clehner]

@sbihel yes, it is kindof like an inner DID or sub-DID. DID Core doesn't say DIDs must use a hierarchical namespace. I was thinking maybe for some DID methods it might be a suffix or glob pattern instead of only a prefix, e.g. *-example. It also might be an arbitrary string that might not be a pattern at all. So the naming is questionable, as is the meaning - but effectively it is just a string input argument for the generate function alongside the JWK.

An alternative could be to use a Metadata structure instead of string. DID Core specifies Metadata structure (map of properties) for DID resolution, DID URL dereferencing, and "other DID-related processes". Then we could define a property, which could be registered in the DID Specification Registries, to indicate the public key hash type for did:pkh. That would just be a little more verbose, as in the CLI it might be used this:

didkit key-to-did pkh -i publicKeyHashName=tz

instead of the shorter way based on this PR:

didkit key-to-did pkh:tz

Also the DIDKit API (non-CLI) would need to be updated to take an additional metadata/options object. That would be a breaking change, unless a new set of functions is defined (e.g. keyToDIDWithMetadata and keyToVerificationMethodWithMetadata). This PR's approach doesn't require changing the type signatures of the functions keyToDID and keyToVerificationMethod - but it changes the name and meaning of the methodName argument.

For a bigger picture, we could consider how this might work with DID creation more generally. There isn't a standard interface for creating or generating a DID like there is for resolving one, but we could look at what Universal Registrar does: it has a CreateRequest type in its HTTP API, and a register() function for drivers to implement. CreateRequest takes an options property. register takes an options property and also an identifier string, which is the DID to registry (when known). For generative DID methods (e.g. did:pkh and did:key), we don't know the identifier at creation time, so could not use the identifier parameter of the register function, unless we bend the meaning of it to include partial DIDs or patterns, like what this PR uses. Otherwise, we would need to use options, and need to define an option name for this PR's pattern/name string. In that case, maybe it would be better to just use metadata/options here instead of a method-pattern string. It seems it would be simpler semantically to define an option like publicKeyHashName, although it would be more verbose on the CLI and require API changes in DIDKit.

[sbihel]

I agree that using metadata would be simpler semantically, but as an end user I find the current interface better.

Thank you for the explanation, I think this PR is good as it is 👍

[clehner]

Thanks, @sbihel

[clehner]

Rebased, and updated Changelog.
Edit: CI failed due to #150

[clehner]

Rebased