DID:WEB resolves to DID Resolution Result

[vitorpamplona]

Fixes #20:

1. Changes the nature of the did.json document to become a DID Resolution Result that contains a DID Document and not the DID Document itself.
2. Establishes the presence of DID Document Metadata with possibilities of adding cryptographic proofs to verify DID Documents.
3. Allows multiple representations (JSON, JSONLD, XML, CBOR, etc) of the DID Resolution Document for the same DID:WEB based on DID Resolution Options

Impact on current implementers

This is a backward incompatible change.

Current producers must wrap the root property of their did.json file into a didDocument property.

DID Resolvers should check for the presence of a didDocument property to indicate compliance of the producer with this new version. If the property is present, an optional didDocumentMetadata property can also be available and should be parsed accordingly.

The spec's did.json goes from:

{
  "@context": "https://www.w3.org/ns/did/v1",
  "id": "did:web:example.com",
  "verificationMethod": [{
     "id": "did:web:example.com#controller",
     "type": "Secp256k1VerificationKey2018",
     "controller": "did:web:example.com",
     "ethereumAddress": "0xb9c5714089478a327f09197987f16f9e5d936e8a"
  }],
  "authentication": [
     "did:web:example.com#controller"
  ]
}

To:

{
  "@context": "https://w3id.org/did-resolution/v1",
  "didDocument": {
    "@context": "https://www.w3.org/ns/did/v1",
    "id": "did:web:example:com",
    "authentication": [{
      "id": "did:web:example:com#keys-1",
      "type": "Ed25519VerificationKey2018",
      "controller": "did:web:example:com",
      "publicKeyBase58": "H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
    }],
    "service": [{
      "id": "did:web:example:com#vcs",
      "type": "VerifiableCredentialService",
      "serviceEndpoint": "https://example.com/vc/"
    }],
  },
  "didDocumentMetadata": {
    "@context": [
      "https://w3id.org/did-resolution/v1"
      "https://w3id.org/security/suites/ed25519-2020/v1"
    ],
    "created": "2019-03-23T06:35:22Z",
    "updated": "2023-08-10T13:40:06Z",
    "proof": {
      "type": "Ed25519Signature2020",
      "created": "2022-08-21T12:54:33Z",
      "verificationMethod": "did:web:example.com:trustedSigner#WEB",
      "proofPurpose": "assertionMethod",
      "proofValue": "z3e7VcjAVz7RVb7uuH7NQzDuF9AXK3vfH65xnSJSRiLK3vTPUoCDgcE4JC1UfZhbD1wgFsWxQwdWEtrRqhbnqvyYs"
    }
  }
}

[peacekeeper]

-1 to detaching the proof in this way. You can include it in didDocument

I know that in VCs and Data Integrity, the assumption has always been that the proof property is included in the same JSON-LD object that it covers, but I would contrast that with the initial design that we had when we introduced DID metadata (based on this proposal: https://github.com/w3c/did-core/issues/65#issuecomment-597030882). We said at that time that a proof is not data about the subject, but rather metadata about either the document, or the resolution process, and that therefore it belongs into one of the two metadata buckets.

Semantically, having the proof inside the DID document would be a bit like having the proof inside the credentialSubject object, no?

Structurally, having the proof outside the DID document would make it easier to cleanly distinguish between proofs that are added by the DID controller or the DID method (DID document metadata), and proofs that are added by a resolver (DID resolution metadata).

From a pure RDF/JSON-LD perspective, I think there shouldn't be a strict necessity to have the proof object directly under the object it applies to, or?

[vitorpamplona]

@peacekeeper Thanks Markus! I fixed them all.

I think the text could use a lot of improvements outside the context of this PR to be better aligned with the DID Resolution specification. I am just trying to not change everything. :)

For instance, I think we need to force DNSSec just like we force HTTPS. But that is for another day.

[vitorpamplona]

Not really interested in breaking changes right now

Hi Mike, any suggestion on how to add the DID Document Metadata with backwards compatibility?

[letmaik]

Doesn't this prevent the actual resolver from adding its own metadata?

[peacekeeper]

Doesn't this prevent the actual resolver from adding its own metadata?

There are two "buckets" of metadata. DID document metadata and DID resolution metadata. Metadata about the resolution process itself should only go into the second bucket.

[OR13]

I suggest we close this PR, and perhaps tackle some of the concepts addressed here using additional headers.

[OR13]

Closing this PR (it does not seem like it can reach consensus).

I am open to discussing on issues, feel free to file, and link here.