Underspecified semantics of "updated" property

[selfissued]

The specification does not give any sense of what kinds of actions constitute an update to the DID that should result in a change to the "updated" time. For instance, does resolving the DID constitute an update? This property will be virtually useless unless there's a common understanding of what actions constitute an update.

[rhiaro]

I believe this would depend on the particular DID method, and should be specified in the DID method specification, but this should be clarified.

[jandrieu]

This is a meta-data issue.

[OR13]

@csuwildcat you may want to add some details about sidetree here...

Sidetree is very restrictive in terms of what can be updated.

[selfissued]

Even if this is method specific, the core spec needs to add the requirement on method specifications that they clearly define what updated means and does.

[OR13]

I consider DID Methods that don't allow a controller to make full content updates to be a separate class of methods... as a did controller, I like to be able to control :)

[peacekeeper]

"Update" is one of the 4 operations that DID methods must define. But I think the semantics of "updated" are NOT method-specific. I agree with @jandrieu that this is related to metadata, see #65

[csuwildcat]

@csuwildcat you may want to add some details about sidetree here...

Sidetree is very restrictive in terms of what can be updated.

This is not true. The base protocol for Sidetree only strictly handles the DID Document modification keys, because it has to know which are allowed to modify the Doc. The base Sidetree protocol allows a Sidetree-based method implementer to merge literally anything they want into a DID Doc, or limit what can be put in on a per-Method basis, for example: one Sidetree-based DID Method could disallow string values in the doc larger than 1k, because they want to keep people from dropping a gig of base64'd cat pics into a DID Doc.

Sidetree does not limit you as an implementer, you decide this aspect of your Method. Some will allow a free-for-all and get dunked on if they ever achieve any significant scale, while others will be more specific/deliberate in how each of the DID Document's fields/values is modified. This doesn't mean you are not the controller of the Doc because the protocol you use attempts to codify rules that hinder dropping a GB of cat pics on the network.

[csuwildcat]

For this question, of what Update means, I believe this might be a good start for a definition:

"An Update to a DID shall be considered any change made to a DID, in the scope of its Method implementation, that results in the modification of values that control operations on the DID or what is produced from resolution of the DID, such as the output DID Document."

[OR13]

@csuwildcat You are correct, Sidetree Method implementers can choose what features to support, and their coverage of the terms in the did core spec, represents the degree to which they have restricted funtionality, for either security, performance or political reasons...

In Sidetree Methods, properties of the did core registry can only be supported on a case by case basis by each DID Method, and the method implementers are the ones who decide what a controller can update.

What I am trying to say is that the ability to update is governed by the following:

DID Core Spec > Method Spec > Method Implementation > Controller

A controller can only update what the method allow, which the implementer decide based on what the method spec allows, which is determined by what the did core spec allows.

In the case of did:key updates are not even allowed based on the current method spec.

did:web lets the user update a json file, and so is far less restrictive.

Sidetree Methods fall somewhere in between, leaning more towards restrictive because of the decentralized nature / performance / scale concerns.

[OR13]

"An Update to a DID is any change in the data used to produce a DID Document. DID Method Implementers are responsible for defining what constitutes an update, and what properties of the DID Document are supported by a given DID Method."

There will be cases where an "Update" occurred but the representation did not change.

[peacekeeper]

I like @OR13 's definition, maybe you want to add that to https://w3c.github.io/did-core/#update ?

[rhiaro]

I believe resolving this issue is blocked by #65

[selfissued]

We could define the semantics without solving the general metadata issue if we choose to. I'd love to have input from people and use cases actually using this to understand what it's for and what the semantics need to be.

[msporny]

The updated property is supposed to be about when the DID Document was updated and will be a part of the metadata special topic discussion.

[peacekeeper]

I created PR #365 which states:

DID document metadata SHOULD include an updated property to indicate the timestamp of the last Update operation.

I believe this is the correct definition of the updated property.

If additional clarification or discussion is needed, then I think this should be on the "Update" operation, not on the updated property.

[peacekeeper]

@selfissued following up on my previous comment, I think this can be closed. Do you agree?

[kdenhartog]

pending close label has been on greater than 7 days without seeing any objections. Going to close this assuming that the PRs and commits referenced above have addressed this issue. Please reopen or file follow up issues if you're unsatisfied.