w3c
DID Document Metadata `created` property
The spec states
created DID document metadata SHOULD include a created property to indicate the timestamp of the Create operation. The value of the property MUST be a string formatted as an XML Datetime normalized to UTC 00:00:00 and without sub-second decimal precision. For example: 2020-12-20T19:17:47Z.
I wonder about this "SHOULD include a created property to indicate the timestamp of the Create operation". How many DID methods are there that can provide this value in a in a reliable manner? Not just self attested by the DID controller?
We have some language about this in a section about DID Document Metadata: https://www.w3.org/TR/did-resolution/#output-documentmetadata
(Actually this section should probably be merged into https://www.w3.org/TR/did-resolution/#did-document-metadata).
The sources of this metadata are the DID controller and/or the DID method.
So this means that - as you say - values like created could either come "reliably" from the DID method, or be "self-attested" by the DID controller. But the same is true for everything in the DID document as well, so I'm not sure if we need to say anything special about this. This could perhaps be something that DID Traits or Rubric could express as an aspect of individual DID methods?
(Actually this section should probably be merged into https://www.w3.org/TR/did-resolution/#did-document-metadata).
Is this true of the whole section 8 - https://www.w3.org/TR/did-resolution/#did-resolution-result And potentially section 9 - https://www.w3.org/TR/did-resolution/#did-url-dereferencing-result
I think this is true:
So this means that - as you say - values like created could either come "reliably" from the DID method, or be "self-attested" by the DID controller.
But, the other information DID controller are attesting to like verificationMethods and relationships etc are things they are authorized to attest to. It is their DID document.
But a property like created feels different to me. It is about the DID document as a container, not what is in the DID document.
Perhaps we could speak to some of the limitations of relying on this created property in the security considerations section.
(Actually this section should probably be merged into https://www.w3.org/TR/did-resolution/#did-document-metadata).
Is this true of the whole section 8 - https://www.w3.org/TR/did-resolution/#did-resolution-result And potentially section 9 - https://www.w3.org/TR/did-resolution/#did-url-dereferencing-result
Yes, I just created PR https://github.com/w3c/did-resolution/pull/164 to merge/consolidate these metadata sections.
This was discussed during the #did meeting on 31 July 2025.
View the transcript
w3c/did-resolution#163
Wip: I wonder if `created` property should be included -- don't know if people can rely on it?
markus_sabadello: This is about a broader question, who is authoritative for the values in the DID Document metadata, could be DID Method or controller, metadata like `created` information could come from DID Method, especially blockchain-based DID Methods.
markus_sabadello: There are other DID Methods where metadata could be self-asserted, with web-based DID Methods, in did:web, should it have metadata, could be file on webserver that comes from controller, not be DID Method that enforces that in any way... never really said much about that in spec. We could explain that a bit better, but I don't think it's specific to created property, larger question around metadata.
Wip: I wonder if we could add a Security Considerations about this, people might rely on metadata base don facts that they can depend on, some properties are more dependable than others.
Wip: If you have business processes that depend on that date being correct, you could be misled.
Wip: What do people think, should we add security consideration?
markus_sabadello: The spec already says that source of metadata can be DID Method or controller, but doesn't say what that means wrt. reliability. That makes sense to add a security considerations section to explain that.
Wip: I can take that PR on.
Since #164 has been merged, marking this pending close
That PR re-arranged and consolidated some information about metadata, but I don't think it really addressed this issue here.
The section about DID document metadata is here: https://www.w3.org/TR/did-resolution/#did-document-metadata
It currently says
The sources of this metadata are the DID controller and/or the DID method.
But it doesn't really elaborate on this. For example, it doesn't explain that "created" can sometimes be self-attested, and sometimes verifiable, depending on how the DID method supports this.
This was discussed during the #did meeting on 18 September 2025.
View the transcript
w3c/did-resolution#163
Wip: we are currently stating that a DID document SHOULD include a 'created' property.
… In some cases it will be made up.
markus_sabadello: I created a PR related to this issue, which has been merged.
… It was reorganizing some sections about metadata but I didn't feel it addressed the main topic of this issue.
… The 'created' property is sometimes verifiable, sometimes self-attested.
… There is some language in the spec about this: what's the source of the metadata?
… Built into the DID method? Something the controller can influence?
… Maybe we need more of this.
Wip: I was thinking about this from the perspective of did:ptcr2
<Zakim> JoeAndrieu, you wanted to mention self-attested metadata seems oxymoronic
Wip: In this case, the DID resolver would probably ignore the SHOULD, it has no way to derive the information.
JoeAndrieu: I'm good with the language SHOULD; it allows for some methods to not provide it if they have good reasons.
… That said, a more conceptual question confuses me, about self-attested properties.
… We don't have a way in BTCR2 to allow the controller to put such metadata in the document, so the self-attested idea does not fit here.
markus_sabadello: this came up with did:web, where self-attested metadata about the DID document can be added.
… You would not trust these values very much, but that would be compliant.
… If you compare this to fully blockchain-based DID methods, with verifiable timestamps... this is what this text is about.
… To allow variations across implementations.
<JoeAndrieu> +1 for what is basically a published "sidecar" style metadata like the DID Loge Entry in webvh