Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Note that this question is not about a) the metadata for the subject of the DID (keys, service endpoints) or b) the metadata about the resolution of a particular DID Document (proof added by a resolver, caching data, what servers/nodes were used for resolution) -- that belongs either in the Resolver metadata or Method metadata sections.
So far, there have been arguments both for and against placing this metadata in the DID Document itself (vs outside of it, say in the Resolver metadata sections).
A) This metadata is already in the registry
A - against: Since much of this metadata (specifically, the
A - for: In many (most?) cases, these are two separate sets of metadata - one about the document itself, and one about the underlying registry mechanism.
Also: The DID Document should be self-contained, in terms of critical metadata, in case it is archived or otherwise separated from its underlying ledger or storage medium.
B) Potential for developer confusion
B - against: If the DID Doc metadata (such as when the document was created) differs from the did registry metadata (when the document was registered on a ledger, for example), this may confuse developers.
B - for: @TallTed
In other words, these two categories of metadata are separate, and developers constantly have to keep this difference in mind anyway.
C) Use cases
C - against: There are no use cases currently for this metadata. (Or, the use cases are unclear.)
Also, as @peacekeeper points out:
D) Offload this topic to DID method specific specs
D - against: Even if this metadata does belong in the DID Document, perhaps we should hand this off to each DID method to decide (rather than the main DID spec).
D - for: @ChristopherA
In other words, this is going to be a common enough problem that we should address this in the main spec.
E) Conceptual elegance
E - against: @dlongley:
E - for: ... an excellent point. Perhaps we can continue to benefit from this conceptual simplicity (of having the DID Doc be mostly about the DID subject) by making it clear via the attribute names that the metadata is about the doc, not the subject? Like, having the field be named