Closed jricher closed 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....
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
How is this issue here different from #65. Can we close this one and continue discussion in the other one?
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.
Three months later and we're still waiting on contracts to address this
This the topic of the upcoming DID Special Topic call this week.
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?
It seems this issue has been addressed by PRs, so we will close it soon unless there are objections.
No comments since marked pending close, closing.
Metadata for the DID Document returned from the Resolver and Dereferencer needs to be defined, including (but not limited to) the representation type.