Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Define DID Document Metadata #203

Closed
jricher opened this issue Feb 21, 2020 · 9 comments
Closed

Define DID Document Metadata #203

jricher opened this issue Feb 21, 2020 · 9 comments
Assignees
Labels
metadata issues and PRs related to metadata pending close Issue will be closed shortly if no objections

Comments

@jricher
Copy link
Contributor

jricher commented Feb 21, 2020

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

@rhiaro rhiaro added the discuss Needs further discussion before a pull request can be created label Feb 25, 2020
@OR13
Copy link
Contributor

OR13 commented Mar 4, 2020

Pulling up the comment @jricher left regarding content sniffing: w3c/did-extensions#4 (comment)

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 #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
Copy link
Contributor Author

jricher commented Mar 5, 2020

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
Copy link
Contributor

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

@jricher
Copy link
Contributor Author

jricher commented Mar 12, 2020

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
Copy link
Contributor Author

jricher commented Jun 9, 2020

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

@msporny
Copy link
Member

msporny commented Jul 14, 2020

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

peacekeeper added a commit to peacekeeper/did-core that referenced this issue Jul 30, 2020
@peacekeeper peacekeeper added pr exists There is an open PR to address this issue and removed discuss Needs further discussion before a pull request can be created labels Jul 30, 2020
peacekeeper added a commit to peacekeeper/did-core that referenced this issue Aug 10, 2020
msporny pushed a commit that referenced this issue Aug 11, 2020
@peacekeeper
Copy link
Contributor

We added a section on metadata properties in #347, and we added some concrete metadata properties (e.g. created, updated in #365).

Can we close this issue?

@peacekeeper peacekeeper added pending close Issue will be closed shortly if no objections and removed pr exists There is an open PR to address this issue labels Sep 20, 2020
@peacekeeper
Copy link
Contributor

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

@brentzundel
Copy link
Member

No comments since marked pending close, closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
metadata issues and PRs related to metadata pending close Issue will be closed shortly if no objections
Projects
None yet
Development

No branches or pull requests

6 participants