V2 - DID

[the-frey]

To-do list:

• [ ] DID pattern, current working thought did:dens:<dens-id> (as it is available https://www.w3.org/TR/did-spec-registries/#did-methods)
• [ ] Define exactly how DID data is stored:
  • sub-key in meta?
  • Replace meta with DID entirely? (...probably this)
• [x] Replace :: with . as :: is not in spec - https://www.w3.org/TR/did-core/#did-syntax (then again†)
  • question: remove our parent (/) syntax? It clashes with DID path syntax (gut feel: yes)
• [ ] Implement DID dereferencing, which returns only the DID document. (NB this suggests that replacing the meta with DID style meta entirely is a better shout)

† this is also mentioned:

NOTE: Colons in method-specific-id
The meaning of colons in the method-specific-id is entirely method-specific. Colons might be used by [DID methods](https://www.w3.org/TR/did-core/#dfn-did-methods) for establishing hierarchically partitioned namespaces, for identifying specific instances or parts of the [verifiable data registry](https://www.w3.org/TR/did-core/#dfn-verifiable-data-registry), or for other purposes. Implementers are advised to avoid assuming any meanings or behaviors associated with a colon that are generically applicable to all [DID methods](https://www.w3.org/TR/did-core/#dfn-did-methods).

The method-specific-id format MAY include colons. The use of colons MUST comply syntactically with the method-specific-id ABNF rule.

However my concern here is that users may not understand the relation being presented. My other concern is that using dots will not be understood, so open to ideas there.

[the-frey]

Current thoughts on import:

1. Dump Juno DENS state at a date
2. Import name -> wallet mappings into new app state and get users to update state

[the-frey]

Thoughts on stale ids: introduce method where they are auto-freed after 10y if some renew button hasn't been hit.

Renew is free (except for cost of gas)

[the-frey]

Wever suggests replace :: with .

[spoo-bar]

One more possible todo (at least to think, unless @the-frey already has a soln)

DIDs by definition are immutable and cannot be deleted. But dens can be burned. So how to handle burning a dens? Replace with empty null value?

[the-frey]

Target architecture from discussion:

DENS stays as its own contract DID is a new contract

if a DENS is interacted with* and a DID does not exist for that minerva address, then a new DID record should be created on the DID contract.

From the P.O.V. of the DID contract, DENS is only one service provider.

Service providers should be updateable via an endpoint (sudo or admin multisig) on the DID contract.

• i.e. mint, metadata update

@spoo-bar do you want to stick the example document you had on here so we can use that as a target shape?

[spoo-bar]

DID format

did:minerva:{minerva_addr}

Sample DID docuemnt

{ 
    "id": "did:minerva:minervaa1d18a9a76a0a86b62fcdcb2e547173f3c9",
    "publicKey": [ 
        { 
            "id": "did:minerva:minervaa1d18a9a76a0a86b62fcdcb2e547173f3c9#keyID-1", 
            "type": "Secp256k1VerificationKey2019", 
            "publicKeyBase58": "tfJRkK8kEu8YFML8bwpkZwzo8YXDFhfFuryfGQAtw4jg" 
        } 
    ],
    ...
    "service": [ 
        { 
            "id": "did:minerva:minervaa1d18a9a76a0a86b62fcdcb2e547173f3c9#spoo_bar", 
            "type": "dens", 
            "endpoint": "spoo_bar" 
        },
        { 
            "id": "did:minerva:minervaa1d18a9a76a0a86b62fcdcb2e547173f3c9#spoorthi", 
            "type": "dens", 
            "endpoint": "spoorthi" 
        }, 
    ]
}