Designing an open DID document demo flow with no private key incode, using signatures instead.

[mattsmithies]

Understanding of Library

Firstly, Let me know if I've missed something, I've been looking through the repo and grokking through the available demos for managing dids and credentials and from what I understand this is the overarching theme:

1. There is a single topic per did document and related messages.
2. There is an expecation of a private key to create a topic (this topic is restricted by a submit key).
3. DID messages can be read through an identifier, that has it's own topic - indicated by HcsDidEventMessageResolver

As there doesn't seem to be any filtering on an idenifier to a topic coupled with the submit key dependency I would imagine this is the best path.

An ask or an appropriate method for public key-only signing

As this lib will eventually become part of the Hedera official repo I believe there should be a demo/method for self-custodial users, under this scenerio:

A user or organisation with their private key within either:

a) A wallet such as a Hashpack, Blade, Metamask, or others. b) A wallet in a programatic/semi-custodial setting such as fireblocks, magic link or others.

In either case, there will be no direct access to a private key and there should be a signing flow instead. Within Guardian Issue #3719 this is the result that would be desirable.

So, looking through the code over the last couple of hours its not obvious to me that at a core lib level this is possible, currently.

With this in mind, there would be some potential considerations for a feature such as this.

• The creation/management of a DID identity can optionally be only pub key based, and rely on external signatures.
• The amount of signatures might end up being a friction point for truly self-custodial wallets, there should be an option to delegate the sending of messages from an automated system (creation of did docs, topic creations etc) for non-sensitive data submission.
  • Alternatively, this could be split into two separate topics, where one topic is only the signatures/signing of sensitive credentials or important documents (consider guardian/sustainibility usecases where a VVB can sign off authority)
• This latter point is less of an issue for wallets/accounts using email based authentication such as magic link, to balance convenience over deep security.

Would finally note that this list isn't exhaustive, but is simply aiming to carve a path for public-key self-custodial pub key signing. I also understand that solutions such as this require demos that cover a larger vector of the whole stack, there might need to be a FE and BE demo.

With this in place, as part of this SDK, it would be reasonably trivial to create a simple API that wraps backing with a database, as a separate but basic open source identity solution.

[mattsmithies]

Feel free @derek-meeco to provide insight and/or let me know if I've overlooked something.