DID Context mgmnt?

[jandrieu]

I'm trying to understand how additional contexts are managed.

I see that DIDs are created with just the default https://www.w3.org/ns/did/v1.

How would one specify additional contexts? I see that in neither the MsgCreateDidDocument nor MsgUpdateDidDocument

Is that even possible?

[PaddyMc]

Thanks for reviewing 🙇

You can use the MsgUpdateDidDocument and a custom script to update a did doc context

https://github.com/allinbits/cosmos-cash/blob/main/proto/did/tx.proto#L68

[jandrieu]

Ok. So, the document in the MsgUpdateDidDocument has no constraints? I can change the context, add verification methods, add properties?

[PaddyMc]

Yeah, we left it this way so it will ease the burden on client developers. All data will still be validated wrt the standard.

[jandrieu]

Does that include handling custom contexts with additional properties?

JSON-LD validation would work in that case, but without JSON-LD validation, you would need to update the code any time a property is added to the DID Spec Registries.

For example, did:ethr supports arbitrary properties only partially. You can store it on chain, but the resolver won't be able to read it. You can use a different resolver, but on most timeframes, did:ethr is essentially locked to just a few top-level properties.

[PaddyMc]

Yeah it does, so long as the context is a valid URL, we can update the context with multiple contexts 😄

[jandrieu]

What if the context is more complicated?

For example, this is (structurally) a valid context

   "@context": [
    "https://www.w3.org/ns/did/v1",
    {
      "EcdsaSecp256k1VerificationKey2019": "https://w3id.org/security#EcdsaSecp256k1VerificationKey2019",
      "publicKeyJwk": {
        "@id": "https://w3id.org/security#publicKeyJwk",
        "@type": "@json"
      }
    }
  ]

Although you could almost restructure the document a bit to get the following

   "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/v1",
  ]

But it turns out that https://w3id.org/security/v1 doesn't actually contain the definitions for EcdsaSecp256k1VerificationKey2019 and publicKeyJwk, so you can't recreate the contexts in that way, even if you change the DID document to stay in sync. The initial example is a valid, inline context.

The other work around would be for someone to publish a new context with EcdsaSecp256k1VerificationKey2019 and publicKeyJwk defined, and use that URL. That would be a viable work-around, but definitely extra overhead.

In a separate note, are unknown contexts retrieved to validate the JSON-LD? Or simply recorded as is?