[Task] Stardust Method

[cycraig]

Description

This is the tracking issue for tasks required for the Stardust UTXO-based DID Method.

A small proof-of-concept is on the feat/stardust-poc branch, which simply embeds an empty DID Document in the stateMetadata of an Alias Output. The identity_stardust crate on that branch is separate from the workspace, this is due to incompatible dependencies related to iota-client. I suggest continuing parallel development with the new and old DID Methods for the least friction, since the alternative would break all existing tests and examples that interact with the Tangle. Development should continue in isolation, with generic components incrementally being updated to support multiple DID Methods.

Note that the current intention is not to release did:stardust as a separate DID Method, but rather use it as a working title; the did:iota method (at least in name) will be replaced with this in the future.

Notes

There were a number of issues encountered during development of the proof-of-concept, most minor.

1. The AliasId is inferred from the Block, so need to use a placeholder DID when creating a new DID Document, or publish twice: first to get the AliasId, then publish the DID Document. Publishing twice seems ill-advised and likely to cause more problems than fix them; the proof-of-concept resolution simply replaces all occurrences of the placeholder DID when extracting the DID Document.
2. Cannot get an OutputId (needed to resolve an AliasOutput) back from an AliasId (hash of OutputId), need to use Indexer API. This is fine since iota-client provides functions to do so, just needs a few steps and some type wrangling.
3. The response from the Indexer is an Output, not a Block, so cannot infer an AliasId from it. Fine since we use the AliasId from the DID to retrieve the Output in the first place. The OutputDto conversion is a bit annoying though.
4. The pieces needed to publish an update are fragmented (OutputId for input, amount, DID Document, etc.), bit annoying to reconstruct. Maybe use a holder struct like Holder { AliasOutput, StardustDocument } with convenience functions?
5. Inferred fields such as the controller and governor need to reflect in the (JSON) Document but excluded from the StardustDocument serialization when published. Handle with a separate pack function like with current DID Messages?
6. AliasId addresses are stringified as prefixed hex strings, e.g. 0xa1b2c3.... Initially I stripped the prefix for the DID tag, so did:stardust:a1b2c3... but maybe keeping the prefix is fine? did:stardust:0xa1b2c3...? Doesn't save many bytes and some Ethereum DID Methods keep the prefix, which is simpler.

Regarding iota-client: I think we should just implement a trait for it rather than re-export all its builder methods which we currently do. Then for the Wasm bindings we can just implement the trait for the iota.js equivalent, if possible?

To-do list

Please link PRs that match the To-do list item behind the item after it has been submitted.

These are just the initial steps for the immediate term.

• [ ] Types.
  • [x] StardustDID (including placeholder + StardustNetwork for Mainnet, devnet + Shimmer equivalents?).
  • [x] StardustDocument + features. (#951)
  • [ ] ~ResolvedStardustDocument wrapper for StardustDIDDocument + AliasOutput?~
  • [ ] StardustDocument stateMetadata packing (#942).
• [ ] StardustClient interface
  • [x] Trait-based or wrapper-based (like current IotaClient)?
  • [ ] DID resolution.
  • [ ] DID creation + updates? Could be left for the Account, rely on iota-client to publish in low-level API?
• [x] Generalise Resolver interface for multiple DID Methods. Pluggable interface abstraction possible similar to Agent? #970
• [x] Generalise credential, presentation validation for multiple DID Methods (#935)
• [ ] Private Tangle in CI for testing? Need to request funds from faucet for byte deposit.