Adding to the --seed option to create DIDs on start up for other DID Methods

[swcurran]

As noted by @PatStLouis in the 20240917 ACA-Pug meeting, when the --seed option is used as a startup parameter, a key is created along with a did:sov DID that uses that key by ACA-Py. This issue is to discuss how to extend the startup parameter (and define an OpenAPI endpoint -- but without a seed) to create keys and bind them to DIDs. For example (and this is totally wrong -- just used as an example), extend --seed values to be "<seed>,<did method>,<did parameter>" -- e.g. "123456,tdw,example.org"`. The intention of the issue is to cover:

• What DID methods should we support immediately through this interface?
  • Which ones can be created with startup options (or should we drop that?) and which ones can only be created by an OpenAPI call because the key id (kid) must be returned.
  • What does it mean to have multiple keys with the same flag (e.g. "public")
• For each DID method, what does ACA-Py do?
• As @dbluhm has mentioned what are the "key purpose" flags that should be supported (initially -- with more added as appropriate) that tell ACA-Py, and the per DID Method code what to do when a new DID is to be created.

For the OpenAPI endpoint, for security reasons, we won't pass in the seed (assuming that ACA-Py generates a seed on the fly).

Editorial: I'm using this issue to generate discussion and probably have some fundamentals wrong in the issue. Feel free to edit this issue description to improve the quality of the resulting conversation.

[zoblazo]

DID

• decentralized identifier, made to be resolvable into a DID Document (DIDDoc)

DIDDoc

• must contains (among other things) cryptographic public keys owned by the controller of the DID that allow them to prove control over the DID
• will also contain a physical endpoint (such as a URL) to which messages can be sent to the Aries agent

NYM

• part of some DIDs, specialized terminology and not applicable to most DID methods (other than few did methods dealing with ledgers like did:sov and did:indy)

• the did:sov method spec requires the NYM part of the did (refered as idstring) to be a 16-byte uuid base58 encoded using the Bitcoin/IPFS alphabet (source : https://sovrin-foundation.github.io/sovrin/spec/did-method-spec-template.html)

• the did:indy method spec has precise requirements concernying the NYM:

  1. the NYM ledger transaction to be executed on an indy network by an authorized entity
  2. this NYM transaction must be signed with the DID Controler's VERKEY
  3. a custom validation must be made on the NYM transaction depending on the NYM transaction version (source : https://hyperledger.github.io/indy-did-method/)

--seed

• Unless paired with ''--wallet-local-did', currently represents the seed used to generate the default (public) DID and thus the default key pair (with hardcoded method=SOV, key_type=ED25519). The did must already be present on the ledger
• Broadly speaking, the seed is necessary to generate a key pair. That key pair could (in theory) be of a different type than ED25519 and it could be associated with a DID of method other than SOV (regardless if a NYM transaction is concerned or not)

With all that said, it seems acapy should NOT mix the notions of seed, NYM and DID (or DID method) :

• the --seed parameter should only concern the generation of the ED25519 key-pair (as long as we're OK with the hard-coded ED25519 key type) and thus, the VERKEY.

• For the DID itself, there are two visions, one where the agent is responsible of generating the DID and another where the agent is simply fed with the DID.

• In the case where we want aca-py to handle the generation of the did :

  • a new --did-method parameter could be added to specify the intended dd-method (ex: 'sov', 'indy', 'web')
  • if --did-method is not specified, acapy could fallback to its current behavior of generating a default DID SOV.

• In the case where we don't want aca-py to handle the generationg of the did:

  • a new --did parameter could be added to specify the intended 'default did' (ex: 'did:sov:2wJPyULfLLnYTEFYzByfUR' or 'did:indy:sovrin:CYQLsccvwhMTowprMjGjQ6
  • --seed and --did could be used together to associate the (default) keypair to the default (public) DID.
  • we would have to decide what happens when --did is not provided
  • this approach seems preferable since a public did must be pre-created on the ledger anyway and it would avoid having to support the generation of DIDs following multiple specifications for multiple did methods

• In both cases, aca-py would (and should) work with DIDs, and forget all about NYMs

Then comes the concern of public did vs default did :

• both terms are mixed and perhaps should not be.
• There is only one default did
• It seems acapy should be able to have more than one public did (with perhaps different did methods). Then this idea of a single 'public DID' should most probably rather be seen (and named as) as a 'Default DID'. That default DID could be public or not (--wallet-local-did already exists for that).