w3c / did-core

W3C Decentralized Identifier Specification v1.0
https://www.w3.org/TR/did-core/
Other
407 stars 96 forks source link

Define DID Document Metadata #203

Closed jricher closed 4 years ago

jricher commented 4 years ago

Metadata for the DID Document returned from the Resolver and Dereferencer needs to be defined, including (but not limited to) the representation type.

OR13 commented 4 years ago

Pulling up the comment @jricher left regarding content sniffing: https://github.com/w3c/did-core-registry/pull/4#discussion_r386638901

Just coming in to this conversation (post-merge, it seems), the goal of the new producer/consumer language was in fact to disallow a JSON producer from including a context field. However, the requirement is also that the document type needs to be indicated outside of the document itself. We can't rely on internal data tags (like the presence/absence of a field) because we're going to have completely different encodings that will have different underlying parsers, let alone processors. That's why I raised the metadata issue w3c/did-core#203

Responding in part to #65 here...

If we are injecting DID Document metadata into the document... how will you know how to parse the did document to access those injected properties? If the metadata is outside of the DID Document and you receive a Buffer supposedly containing a DID Document, how will you know how to parse it?

All software will need to pass around application/json and application/ld+json and application/cbor...

Seems like we are currently aligned on the JSON Schema front, there will be a way to use JSON Schema to sniff for application/ld+json and application/json in the worst case scenario... but ideally these values will be passed around everywhere a did document goes.... as metadata.

Seems like one thing which is pretty much required now is that we define how method resolvers work:

A DID Method Resolver returns { didDocument, metadata }.

For 100% percent of DID Methods today, metadata would include application/ld+json... But now that can change, assuming that the did core spec defines resolution to include metadata....

jricher commented 4 years ago

To be clear: the metadata is separate from the DID document and cannot be internal. For all the reasons above we need to be able to talk about the document before we can process the document, and for that, we need metadata structures, and those come back from DID resolution results. #198

peacekeeper commented 4 years ago

How is this issue here different from #65. Can we close this one and continue discussion in the other one?

jricher commented 4 years ago

This is related to #65 but is fundamentally asking a different question. I think they'll be answered by the same set of work, which is to say the resolution contracts.

jricher commented 4 years ago

Three months later and we're still waiting on contracts to address this

msporny commented 4 years ago

This the topic of the upcoming DID Special Topic call this week.

peacekeeper commented 4 years ago

We added a section on metadata properties in https://github.com/w3c/did-core/pull/347, and we added some concrete metadata properties (e.g. created, updated in https://github.com/w3c/did-core/pull/365).

Can we close this issue?

peacekeeper commented 4 years ago

It seems this issue has been addressed by PRs, so we will close it soon unless there are objections.

brentzundel commented 4 years ago

No comments since marked pending close, closing.