Did-core: DID Document vs. DID Subject

[burnburn]

From Melvin Carvalho (@melvincarvalho) to the CCG mailing list when we asked for reviews:

Just a quick look

There appears to be two key concepts in DIDs

1. DID Document (mentioned about 200 times)
2. DID Subject (mentioned about 100 times)

From the text it appears that these two are separate things, in that the DID Document contains the DID Subject (I could be wrong there)

If so it was not clear the syntax used to relate (1) and (2) ... for example to have an object for the document linking to an object for the subject ... what is the predicate for that?

Practical upshot. The "Created" property can apply to different things including a proof. So it might be the case that the did: was created at some time, and the document was created at another different time.

How would you express that, or is it not possible?

[rhiaro]

The DID document is just the name for a set of properties about the DID subject. The DID subject is whatever the DID identifies. The DID document is what is produced by the DID resolution process, and isn't actually 'a thing', just a shorthand to refer to the resulting set of properties. All of these properties have the DID subject as their subject (in RDF triple terms) unless they are "DID document metadata properties" - of which created is one.

[melvincarvalho]

All of these properties have the DID subject as their subject (in RDF triple terms) unless they are "DID document metadata properties" - of which created is one.

So what is the subject of the created predicate, in this instance?

Edit: And how does that subject relate to the DID subject (ie by which predicate, if at all).

Alternatively, are both the subject and the did subject the same thing?

[rhiaro]

So what is the subject of the created predicate, in this instance?

The DID, as in the identifier, on the verifiable data registry. The DID document is generated as a result of the resolution process, rather than created per se. This is my interpretation anyway; there's some contention about having the created and updated properties at all, it's not required, and different DID methods may handle them differently.

And how does that subject related to the DID subject (ie by which predicate, if at all).

The DID, the identifier, identifies the DID subject.

[melvincarvalho]

Perhaps I could ask the question differently

When we say X (something) was 'updated' at time Y

What was updated? Was the DID document updated, or was the DID (Subject) updated?

On the assumption that they are different entities, which one was updated.

Consider for example a physical passport is a document containing claims. Those claims can be updated, and the passport itself can be updated/renewed. Is this a good analogy here?

If so, does the document (passport in this case) have its own identifier, how is it related to the DID Subject, and when we use the term updated which of the two does it apply to, or does it apply to both?

[iherman]

@melvincarvalho it is worth looking at #373 and the documents referred to from there. Thx.

[melvincarvalho]

@melvincarvalho it is worth looking at #373 and the documents referred to from there. Thx.

Thanks for pointing this out, that was very interesting

It's quite a long thread and I think it's asking a similar question to: do did subject and did document have different URIs?

Is there a consensus?

My main follow-up question: In the case that these two entities have different URIs. Is there a term which links them together (in either direction). For example in a web document you could use:

https://schema.org/mainEntityOfPage
https://schema.org/mainEntity

Which seems to neatly solve the problem. Would it be OK to just use this?

[rhiaro]

Consensus of the WG to date has been that the DID document doesn't have its own URI, only the DID subject has a URI (the DID).

The idea of the subject property is brand new as far as I know.

[melvincarvalho]

@rhiaro thanks. If DID Document has no URI then that answers my question

So that would mean that updated and created apply to the DID Subject

[rhiaro]

So that would mean that updated and created apply to the DID Subject

As it says in the spec, they apply to the when Create and Update operations are performed by the DID method. The Create operation generally means when the DID was generated on the verifiable data registry. The Update operation generally means when some of the data about the DID subject - aka the properties represented by the DID document - has changed. Updated is underspecified just now, and I'm not sure if that is going to change. Create and Update can and should both be better specified in a DID method.

[talltree]

@melvincarvalho You nailed the reason that created and updated were moved to section 8.1.3 of the spec (DID Document Metadata Properties). They do not describe the DID subject; they only describe the DID document. The consensus has been, as @rhiaro said, that the DID document is a collection of properties describing the DID subject which can obtained via DID resolution, but that the DID document does not have it own separate URI.

More about this in the comment I'm adding to #373 next.

[peacekeeper]

The DID document is [...] the resulting set of properties. All of these properties have the DID subject as their subject (in RDF triple terms)

@rhiaro correct me if I am wrong, but I think in the ongoing discussion about the data model and representations, this would support the perspective that @context is NOT a "property"?

[msporny]

How would you express that, or is it not possible?

You express it by creating an outer object/graph and referencing the content in the DID Document in that way. This is out of scope for the DID Core specification but could be in scope for the DID resolution specification.

The questions raised by @peacekeeper will be a topic of discussion for the upcoming virtual face-to-face.

I'm going to mark this issue as pending close because 1) we're not going to add a subject property to the DID Document at this time, the id identifies the DID Subject, 2) if you want to express metadata about the resolution or DID Document, you can do so via resolution metadata OR by wrapping the DID Document in an outer object and then making statements about the outer object.

In short, there is nothing to do here wrt. the DID Core spec. This issue will be closed in 7 days unless there are objections.

[kdenhartog]

No objections seen and 7 days have passed. Closing this issue.