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 created and updated timestamps and the proof which includes authorship metadata and document integrity protection) will also likely reside in the underlying DID registry mechanism (distributed ledger, etc), a Resolver should be able to figure out this data from the registry, and include it in the resolution metadata.
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
You want to talk about "confused developers"? Check out "last accessed", "last modified", and "created", among other Unix-y timestamps attached to documents in Unix-y filesystems.
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.)
C - for: There are use cases -- this topic is highly relevant to any DID registry using a mutable storage mechanism, such as the BTCR mutable extension documents or did:web method documents.
Also, as @peacekeeper points out:
Perhaps the strongest argument for a proof on a DID Document is to link DIDs to already existing PKI such as X.509 or the E.U.'s eIDAS infrastructure. You could include an eIDAS signature (this is called "eSignature" or "eSeal") on a DID Document to link the DID to a legal identity.
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
However, if there are any other DID methods that use mutable storage for DID Documents, they would need to solve the same problem we do, and they might do it different ways which could be good (for innovation) or bad (for security if they don't understand it well as our scenario is complicated).
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:
I want to point out that the way that we've avoided the HTTP-Range-14 argument (which we should absolutely continue to do) is by deciding that you can, for most practical purposes, conflate a DID Document and a DID subject (they have the same identifier). There's a danger that we may lose this simplicity by encouraging expressing information in a way that stretches the limits of that conflation.
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 docCreated instead of just created, to prevent ambiguity?
Does metadata about the DID Document (such as when it was created, updated, or who it was signed by) belong in that DID Document?
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
createdandupdatedtimestamps and theproofwhich includes authorship metadata and document integrity protection) will also likely reside in the underlying DID registry mechanism (distributed ledger, etc), a Resolver should be able to figure out this data from the registry, and include it in the resolution metadata.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.)
C - for: There are use cases -- this topic is highly relevant to any DID registry using a mutable storage mechanism, such as the BTCR mutable extension documents or
did:webmethod documents.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
docCreatedinstead of justcreated, to prevent ambiguity?