DID:WEB resolves to DID Resolution Result #63

vitorpamplona · 2022-08-22T13:38:08Z

Fixes #20:

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.
Establishes the presence of DID Document Metadata with possibilities of adding cryptographic proofs to verify DID Documents.
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"
    }
  }
}

…ution Document that contains a DID Document and not the DID Document itself. 2. Establishing the presence of DID Document Metadata with possibilities of adding cryptographic proofs to verify DID Documents. 3. Allowing multiple representations (JSON, JSONLD, XML, CBOR, etc) of the DID Resolution Document for the same DID:WEB.

index.html

Co-authored-by: Orie Steele <[email protected]>

msporny · 2022-08-29T19:12:38Z

index.html

            by prepending <code>https://</code>.
          </li>
          <li>
            If no path has been specified in the URL, append
            <code>/.well-known</code>.
          </li>
          <li>
-            Append <code>/did.json</code> to complete the URL.
+            Map the DID Document Option's accept property to a file extension:


If we are going to do content negotiation, we should follow the HTTP standard: https://www.rfc-editor.org/rfc/rfc7231#section-5.3 or at least ask the HTTP WG what the suggested path is for Conneg these days.

If we are going to do content negotiation, we should follow the HTTP standard

Strong +1 on following HTTP. DID core is very consistent with HTTP content negotiation.

https://www.w3.org/TR/did-core/#did-resolution-options

https://www.w3.org/TR/did-core/#did-resolution-metadata

msporny

In general, +1 to this PR -- the response being a DID Resolution result makes a lot of sense.

The only concerning bits are: 1) the way the proof is detached from the DID Document (don't do that), and 2) the content negotiation bit.

Regarding concern 1, if you leave the proof as a part of the DID Document (and add an appropriate context), that would address that issue. Unless you were really trying to digitally sign the DID Document metadata, in which case, the proof is probably fine where it is?

Regarding concern 2, move the content negotiation changes into a separate PR, as that is a permathread that has been burning for a while: #52 ...we might just want to ask the HTTP WG what the suggested path is for Conneg these days.

peacekeeper · 2022-08-29T19:59:40Z

-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: w3c/did-core#65 (comment)). 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?

# Conflicts: # index.html

peacekeeper

I don't really have a strong opinion whether or not did:web should be changed, but if the decision is to support metadata, then this needs to be better aligned with the DID Resolution specification, e.g.:

Use of different names for the same thing "DID Resolution Document" vs. "DID Resolution Result".
The DID Resolution specification already defines an HTTP(S) mapping of the DID Resolution process (e.g. the use of the Accept: header), so there should be no need to re-define these things here.
This PR seems to introduce a strange new JSON-LD context https://www.w3.org/ns/didMetadata/v1, even though https://w3id.org/did-resolution/v1 already defines terms for metadata.

…accept header map here.

vitorpamplona · 2022-08-29T21:34:07Z

@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.

mprorock

Not really interested in breaking changes right now

vitorpamplona · 2022-08-29T23:08:18Z

Not really interested in breaking changes right now

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

letmaik · 2022-10-10T09:09:20Z

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

peacekeeper · 2022-10-10T09:22:07Z

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 · 2023-01-13T20:51:22Z

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

OR13 · 2023-03-18T19:31:06Z

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.

vitorpamplona added 2 commits August 22, 2022 09:30

Marking didDocument as required and didDocumentMetadata as optional

90ec662

vitorpamplona mentioned this pull request Aug 22, 2022

Decide what to do about 'proof' section and other DID Doc Metadata #20

Open

Adds a link to DID Resolution Document and fixes a code tag.

556751c

OR13 reviewed Aug 29, 2022

View reviewed changes

index.html Outdated Show resolved Hide resolved

msporny reviewed Aug 29, 2022

View reviewed changes

index.html Show resolved Hide resolved

Correcting the JSON-LD mime type.

7e6191b

Co-authored-by: Orie Steele <[email protected]>

msporny reviewed Aug 29, 2022

View reviewed changes

msporny requested changes Aug 29, 2022

View reviewed changes

vitorpamplona added 5 commits August 29, 2022 16:07

Activating Content Negotiation

a00ec62

Merge branch 'master' of https://github.com/Path-Check/did-method-web

f6734c3

# Conflicts: # index.html

Removing unnecessary colon.

1c10aa1

Minor english corrections.

fb6fe04

Fixing @context of the Did Document Metadata.

cec7183

peacekeeper suggested changes Aug 29, 2022

View reviewed changes

vitorpamplona added 3 commits August 29, 2022 17:29

Referencing DID Resolution's HTTPS Binding instead of describing the …

d042efd

…accept header map here.

Fixing the DID Resolution Metadata context

00b5bcc

Using DID Resolution Result instead of DID Resolution Document.

11d16d8

vitorpamplona changed the title ~~DID:WEB resolves to DID Resolution Document~~ DID:WEB resolves to DID Resolution Result Aug 29, 2022

mprorock requested changes Aug 29, 2022

View reviewed changes

vitorpamplona added 2 commits August 31, 2022 10:21

Moving the ld-proof to the root of DID Document

5b98f1d

Moving dereferencing examples to the read section, not the create

4982cb3

OR13 closed this Mar 18, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

DID:WEB resolves to DID Resolution Result #63

DID:WEB resolves to DID Resolution Result #63

vitorpamplona commented Aug 22, 2022 •

edited

Loading

msporny Aug 29, 2022 •

edited

Loading

gribneau Aug 29, 2022

msporny left a comment •

edited

Loading

peacekeeper commented Aug 29, 2022

peacekeeper left a comment

vitorpamplona commented Aug 29, 2022

mprorock left a comment

vitorpamplona commented Aug 29, 2022

letmaik commented Oct 10, 2022

peacekeeper commented Oct 10, 2022

OR13 commented Jan 13, 2023

OR13 commented Mar 18, 2023

DID:WEB resolves to DID Resolution Result #63

DID:WEB resolves to DID Resolution Result #63

Conversation

vitorpamplona commented Aug 22, 2022 • edited Loading

Impact on current implementers

msporny Aug 29, 2022 • edited Loading

Choose a reason for hiding this comment

gribneau Aug 29, 2022

Choose a reason for hiding this comment

msporny left a comment • edited Loading

Choose a reason for hiding this comment

peacekeeper commented Aug 29, 2022

peacekeeper left a comment

Choose a reason for hiding this comment

vitorpamplona commented Aug 29, 2022

mprorock left a comment

Choose a reason for hiding this comment

vitorpamplona commented Aug 29, 2022

letmaik commented Oct 10, 2022

peacekeeper commented Oct 10, 2022

OR13 commented Jan 13, 2023

OR13 commented Mar 18, 2023

vitorpamplona commented Aug 22, 2022 •

edited

Loading

msporny Aug 29, 2022 •

edited

Loading

msporny left a comment •

edited

Loading