Did-core: Should we restrict the value of `id` when used to identify a subject?

Created on 6 Mar 2020 · 10Comments · Source: w3c/did-core

(This is a spin-off of issue #183.)

At the moment, the value of id has some restrictions which the JSON-LD does not have. Quoting from https://github.com/w3c/did-core/issues/183#issuecomment-587018974:

§7.2 DID Subject says that the value of id _MUST_ be a single valid DID. In light of the definitions that is the way it should be. However, when getting to JSON-LD land, where id is aliased to @id, the situation becomes a bit complex: in JSON-LD/RDF land @id is the (RDF) identifier of the (RDF) subject which, per the RDF Concepts and Abstract Syntax spec is a URI (more exactly, to make things even more complex, an IRI…). I.e., it would be a perfectly fine, in JSON-LD, to _use a DID URL as a value of id in a DID document._ However, I believe that this would _not_ make sense from a DID point of view. I can see two possibilities:

The DID spec makes it _very_ explicit that, in a did-ld-json document, the value of id is _restricted_, compared to the general JSON-LD term (the same holds for the value of controller).

We use a separate subject key, disjoint from the id (i.e., @id) term. This has the extra complication that each DID Document object becomes identified by a blank node:-(

I believe (1) above is o.k., but must be made very explicit in the spec (currently, this issue is not mentioned).

I presume it would not be appropriate, in a DID document, to use an http url as the value of id (i.e., designating the subject).

As @peacekeeper said above, this is an area of active discussion for the did:web DID method.

Specifically, it _is_ appropriate (for a did:web document) to have an http URL as the value of the id/subject. The active discussion is whether or not a URL _with a path_ is allowed as the subject. The current consensus is leaning towards 'no'. (Which incidentally means that if one wants to have different DIDs at different paths of a single domain, those paths would need to be encoded into the _authority_ part of the DID.

@msporny @peacekeeper @dmitrizagidulin

editorial pending close

Source

iherman

Most helpful comment

But the spec already says:

The value of id MUST be a single valid DID

Is this not enough? We could maybe change it to something like this?

The value of id MUST be a single valid DID. Note that even though JSON-LD allows any IRI as node identifiers, DID documents are explicitly restricted to only describe DIDs.

peacekeeper on 12 Mar 2020

👍2

All 10 comments

https://w3c.github.io/did-core/#did-subject currently says:

DID documents MUST include the id property.
The value of id MUST be a single valid DID.

I think one possible perspective is this:

Nothing needs to be changed. The whole point of defining the structure of the (JSON-LD representation of the) DID document is to introduce "restrictions" which generic JSON-LD doesn't have. And since DID documents describe the entity identified by the DID, it makes sense that the id is always a DID.

Another perspective may be:

The DID document data model (and its JSON-LD representation) could be useful for other (non-DID) identifiers as well. But this would require us to decouple the concept of the DID as an identifier, and the DID document as a broader discovery format (similar to JRD, WebID profile, etc.). This discussion has come up before when we were talking about centralized identifiers such as Facebook usernames; we were wondering if the DID document could be used to describe identifiers that are not DIDs.

peacekeeper on 10 Mar 2020

👍1

@peacekeeper,

I would stay away from decoupling DIDs and DID documents. It may open up floodgates derailing our work in the WG.

The upcoming core spec will have a separate data model, where an id for a subject MUST be a DID, just like now. I guess what I am missing, and what we will have to do, is to make it clear, in the JSON LD part, what the _restictions_ are on the general JSON LD model (there may be more). These MUST be clearly stated, and in between the lines. This is all the more important because off-the-shelf JSON LD processors cannot check that.

iherman on 11 Mar 2020

I would stay away from decoupling DIDs and DID documents. It may open up floodgates derailing our work in the WG.

I completely agree.

make it clear, in the JSON LD part, what the _restictions_ are on the general JSON LD model (there may be more). These MUST be clearly stated, and in between the lines. This is all the more important because off-the-shelf JSON LD processors cannot check that.

I'm just not sure if I would call this a "restriction on the general JSON-LD model", it's just how we happen to use JSON-LD to represent a DID document. The JSON-LD processor only checks if it's valid JSON-LD, if everything is defined in a context (e.g. check if "id" is defined in the context), etc. And then after that step, the DID document processor checks if JSON-LD is used in accordance with the spec (e.g. check if "id" contains a valid DID). The layering seems pretty clear to me.

As an analogy, in the plain JSON representation, we will also define how JSON will be used to represent a DID document, what keys and values to use, etc., but I think we would not call this a "restriction on the general JSON model"?

peacekeeper on 12 Mar 2020

👍1

@peacekeeper saying "restriction on the general JSON-LD model" may indeed not be the right terminology. But calling out very explicitly that there is a restriction on the usage of JSON-LD (here and elsewhere if there are other such restrictions) must be made very explicit, otherwise this is a source of potential problems. No big deal, though.

iherman on 12 Mar 2020

👍1

But the spec already says:

The value of id MUST be a single valid DID

Is this not enough? We could maybe change it to something like this?

The value of id MUST be a single valid DID. Note that even though JSON-LD allows any IRI as node identifiers, DID documents are explicitly restricted to only describe DIDs.

peacekeeper on 12 Mar 2020

👍2

I think that the extra statement is better. Thanks.

iherman on 12 Mar 2020

@peacekeeper @msporny I presume the relevant sections should still change significantly (editorially) with the new setup; I do not think making a PR right now makes sense. We should leave this issue open and incorporate that tiny change at some point when things are more stable. WDYT?

iherman on 13 Mar 2020

👍1

+1 to holding off on this PR for a bit while these particular sections stabilize.

kdenhartog on 18 Mar 2020

I think mentioning JSON-LD in the abstract data model section would now create more problems than it solves. Instead I've added this text to the JSON-LD section, but it appears as normative language now rather than a note. I think this is okay though.