Proposed Appendices on DID Identification Architecture #373
Comments
|
The proposed Appendix A: What Does a DID Identify? includes this statement:
@burnburn made this comment in response:
In the Google doc I responded as follows: @peacekeeper and I started down that path to resolve the non-information resource URI dilemma (the whole subject of the W3C TAB's 2007 Cool URIs for the Semantic Web document). However we ran into numerous issues with trying to avoid treating a DID document as an information resource. The most intransigent of those was the fact that, by definition in RFC 3986, any URL that accepts a fragment is a primary information resource, and the fragment identifies a secondary resource (of some kind). We could not figure out any way around that. So in the end we found it easier to accept that the DID document is an information resource identified by the DID, and the DID document in turn functionally identifies the DID subject, as shown in Figure 1 of the proposed Appendix A (included below for easy reference).
|
|
A second statement included in Appendix A (right below the first one referenced above) is:
@brentzundel made this comment in response:
To which I posted this response: The DID doc describes attributes of you (the keys) and methods of interacting with you (the service endpoints). This is especially clear when you look at the JSON-LD version of a DID document—it is an RDF (Resource Description Framework) graph describing you as the RDF subject. |
|
Nice work!
I seek clarification on the situation where the DID enables a
non-repudiable signature by the DID Subject. If the DID Subject is the sole
DID Controller (Appendix B Set 1), no problem. However, if the DID is
controlled by other or others (as in B Set 2 or Appendix C #1 or #3) then
the DID Subject can repudiate their signature. Partial Aggregate Control
(C#3) is a valuable feature for account recovery. What might we say about
this?
- Adrian
…On Tue, Aug 11, 2020 at 8:11 PM Drummond Reed ***@***.***> wrote:
A second statement included in Appendix A (right below the first one
referenced above) is:
Secondly, although by itself the DID document is an information resource
with one or more representations as defined by this specification, *these
representations are always a description of the DID subject*. The DID
document is never a *representation* of the DID subject.
@brentzundel <https://github.com/brentzundel> made this comment in
response:
I'm not sure I agree with this statement. For example, if I am the DID
Subject, how is it that the DID Document (as a set of public keys and
endpoints) describes me?
To which I posted this response:
The DID doc describes attributes of you (the keys) and methods of
interacting with you (the service endpoints). This is especially clear when
you look at the JSON-LD version of a DID document—it is an RDF (Resource
*Description* Framework) graph describing you as the RDF subject.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#373 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABB4YPGJKYEWY2KMBLPXETSAHMZ5ANCNFSM4P3X37MA>
.
|
|
@talltree amazing writeup! While I'm sure there's parts of this that could be contentious in general I appreciate the effort you spent in writing and it seems to further clarify what I intuited about DIDs. Thanks for putting it all into such a well written document. One of the stickier questions I've come across which I can't seem too wrap my head around is best put like this:
Similarly, I think this model further simplifies how this solution might work, but I'll still pose the second question (and attempt to answer it after).
Given that we have lineage this seems like a potential conflict (subject of For me this seems that the correct answer would be to structure it something like this: did:example:123 and {
"id": "did:example:123",
"authentication": ["did:example:456#key1"],
"service": [ "did:example:456#contact-details"],
...
}and did:example:123?version=2` would look like: {
"id": "did:example:123",
"authentication": ["did:example:789#key1"],
"service": [ "did:example:789#contact-details"],
...
}In this way all URIs only identify a single non-information resource, while still keeping the most accurate model where the current sitting president controls the office of the presidency did document. Is that the correct way to solve for this? |
@kdenhartog It's almost bedtime so let me just answer the first question you posed because that an easy one: a DID (and the associated DID document) can by definition identify exactly one DID subject. Period. Full stop. End of story. Anything else is an error. If a DID controller claims that one DID identifies more than one DID subject, any requesting party should reject (and blacklist) that DID. Let me clarify that it's fine for a DID to identify a group that contains two or more member entities. In this case the group is assigned its own DID, and each member entity in the group may or may not be assigned their own DID. But the group as an entity is its own DID subject. Make sense? (Your second question is a doozy and one I have to sleep on before trying to answer. But I'll point out that it is questions like these that are exactly why I think this set of appendices are needed.) |
|
@talltree I have put some comments into the document, also echoing what @burnburn commented, on the section titled "How DID architecture addresses this challenge". Instead of putting a longer set of comment into the document, I jot down my thoughts... What about replacing the bullet items there by
I have the impression that this would simplify things. Some notes:
Discussions to have... :-) |
|
@iherman Thank you!! This is exactly the discussion I was hoping this draft of the appendices would produce. I am very open to each of your suggestions—ironically, what you suggest was the way I wrote the first and second drafts before @peacekeeper pointed out the RFC 3986 problem and we decided to treat the DID document as an information resource. @peacekeeper, what do you think? I invite others in the WG to read the documents and weigh in on your views on Ivan's proposal. @iherman Are you going to be able to attend the special meeting at noon ET on Thursday? I really look forward to the discussion there. |
I plan to be there |
|
I wanted to elaborate a bit on what I wrote at the end of my #373 (comment). I realize what I say here may be impossible to consider by now because it would force most implementations to change, but I think we should still consider this as a possibility. Here is what I meant:
What this does is to reflect in the syntax the fact that we have two, very distinctive notions and many of the complications come from the fact that we try to hide the differences. I realize that this distinction may sound very theoretical and therefore unnecessary for many, but looking at the complications in this Appendix trying to explain what happens shows that we may still want to consider this... |
|
@iherman said:
@burnburn said:
I don't think we can be RFC3986 compliant if the DID document is not an information resource with its own URL, since RFC3986 says: The semantics of a fragment identifier are defined by the set of representations that might result from a retrieval action on the primary resource. Therefore, the DID document must be considered an information resource, and it must have its own URL. At the same time, we want to maintain our core assumption that the DID identifies the DID subject (I agree that if we change this, a lot of things break). Therefore, the DID document needs a URL that is not the DID (unless we want to accept that we are conflating things, which is what we have been doing so far). |
|
While working on the DID chapter for the Manning SSI book (see preview), @talltree and I discussed what a URL for the DID document could look like. We considered adding a single fragment (e.g. At that time I thought that adding a single slash (e.g. During a series of DID Resolution calls last year, we discussed several more options, see here. I think @iherman 's idea to introduce another URI scheme (e.g. |
Ooof, this statement has incredibly far reaching implications... it's highly problematic for a number of reasons. I'm just going to point out a few below... @burnburn wrote:
@iherman wrote:
Agree with Dan and Ivan, everything was good right up to this point, and then it goes off of the rails. The issue is with the TAG finding... it presumes a lack of context when interpreting an identifier. It comes from time where there were no RDF Datasets and everything was being merged together in databases. That is, a time when context around information wasn't a core part of RDF and the Semantic Web. It is today, and that changes the TAG finding. That said, I have no interest in prosecuting this via TAG as the make up of the TAG has changed and they tend to not care about these sorts of things because they tend to not have a practical effect on the Web... yes, you can shoot yourself in the foot by doing the wrong thing, but you quickly find out that your foot is missing. Pages 1-4 is a great backgrounder on where things were left almost a decade ago... Here be dragons, and we should leave those dragons alone. We are squarely back in HTTP Range 14 territory... https://en.wikipedia.org/wiki/HTTPRange-14 ...which is a horrible place to be... because it's Computer Science catnip, where the conversation never terminates. :) |
|
First, thanks for all the excellent feedback and suggestions. The DID WG had a very good special topic call about this today. In this post I'll first summarize my key takeaways and then provide a link to a revised proposal (here in this Google doc for the impatient ;-). My key takeaways from today's discussion:
Now, per these takeaways, on the call I shared that, while the original proposal was based on the first of the three options listed above, last night I prepared a revised proposal (of all 3 appendices) based on the second option (DIDs always identify the DID subject as a non-information resource). Since that appears to be the direction everyone wants to do, I suggest we shift further discussion to this second version. (Note that is a second Google doc—I have added a note to the first Google doc redirecting to the new one.) Here is a PDF of that revised version for anyone who does not have access to Google docs. Lastly, I will next write up next a possible answer that @peacekeeper and I discussed after the call about how we can deliver on the third solution above (two variants of a DID, one that identifies the DID subject as a non-information resource and another that identifies the DID document as an information resource). |
|
Per my last comment, @iherman has proposed in this thread—and we discussed on today's special topic call—that the ideal solution is one where, for any DID, there are two variants, one that identifies the DID subject as a non-information resource and another that identifies the DID document as an information resource. This is literally how we could "have our cake and eat it too", i.e., use DIDs as abstract identifiers to solve a longstanding conundrum of the Semantic Web due that is very difficult if you have only concrete identifiers. The challenge has been to figure out a solution to algorithmically relating those two variants of the DID that is also easy, intuitive, and practical for developers and implementers. While having two different scheme prefixes ( So @peacekeeper and I put our heads to this and there is an option that's very simple to describe:
I can post a much longer justification of how this can be interpreted as consistent with RFC 3986, but first, let's just do a sniff test on this thread about how folks feel about this potential solution. (Feel free to just use a thumbs up or thumbs down.) |
To avoid any misunderstandings: I acknowledge that. Personally, I still believe that this approach should have been the clean approach back when DIDs and DID URLs were conceived (I do not think that the implementation complications are that high) but this particular ship has probably sailed, and we do not want to force all method implementations to change on this issue. For the three solutions quoted above: don't we have similar issues with the paths? I.e., if I want to add a and, because the fragment id must be added to the end, we get: and we get to the same problem, don't we? @peacekeeper referred to, in #373 (comment): wouldn't that be a better option? It makes it a bit awkward, e.g., but this is not unlike, say, |
|
(This comment is on the revised Appendix A proposal.) First of all, I like the approach and, personally, I believe this is a direction to go. My comments are on details an not a criticism of the document as a whole. I am a bit bothered by the differentiation of
Isn't exactly what we expect from My proposal would be to use You say
And I guess I am not sure what "representations" mean here, and I believe we would have a hard time explaining this in the spec. How would you explain, if And how would you explain the difference between that and In your case, the first approach is erroneous but only because you know (out of band) that Are we overcomplicating things? What I am getting at, I guess, is that it may be much simpler to express everything with a single term, and that is |
|
@iherman wrote:
Agreed with @iherman here. I also don't think the media type is required, you typically content negotiate for that. So, that would make the solution look like this: ... and really, we should be using more specific relationships like this: ... and really, that is a massive GDPR violation if placed on a Verifiable Data Registry. What you should be doing instead is publishing "url", "seeAlso", and "image" via a Verifiable Credential served up via a service endpoint or other means, like this: |
|
After a long hiatus to consolidate all the feedback, I have produce a new version of these Appendices. Appendix A was rewritten completely to reflect the consensus of the DID WG. The only changes needed in Appendices B and C were tweaks to the diagrams to align with the revisions in Appendix A. These are still Google docs until we have one more round of review from WG members, then I will turn them into PRs. The direct links to the Google docs are (note that these are NEW links):
I have attached this PDF of the current Google doc for anyone who does not have access to Google docs. Although you could make comments directly in the Google doc, please put them in this issue thread instead. |
Don't quote directly, link to the section of the specification and summarize.
Again, quoting is problematic as guidance has changed throughout the years -- we should link to the text.
This text should be in the section on Should be capital 'P' -- https://schema.org/Person
This is a bit strange... it's correct, but may be viewed as jumping the shark as they could just express that home page as a relationship to their (the author's) DID. Overall, very minor nits, the overall direction and content is solid. Thank you for putting this together, Drummond! The "don't quote other specs" is just a warning, not going to stand in the way if others want to do that -- I agree that it improves readability to have things inline. The introductory parts about |
I wouldn't start out by suggesting that it's confusing... it's not really, reword to summarize the section in the introduction.
Don't bring OWL into this... let's try to avoid it entirely, you don't need it to talk about the concept... talk about the concept in a more general sense without binding it to OWL Semantics. |
Hmm, just noticed something about the arcs -- the actual arcs for
Change to "A cryptographic algorithm that requires multiple digital signatures." for those that don't know what a multisig is...
Change to "when using a cryptographic algorithm that requires a threshold of multiple digital signatures."
Avoid OWL, no need to open that can of worms... the concept stands on its own without pulling in OWL. |
|
Overall, great work @talltree -- just minor nitpicks, almost all editorial, feels like it's ready for a PR. Have you considered moving this into a separate document? I'm on the fence about it. It adds a significant amount of content to the core specification... making it longer and feel more heavyweight... on the other hand, these are some core concepts that folks have been getting tripped up on for a while. Feels akin to this section -- which, I argue should never have gone into the VC spec: https://www.w3.org/TR/vc-data-model/#subject-holder-relationships |
Appendix A, In bullets after A1.1,it says:
This actually raises a major modeling issue. In the current setting we have (I put it in Turtle, because I find it cleaner from a modeling point of view): this is in line with what you write, and it is a translation to the RDF model of all the examples we have in the document. This is because we use the Also, what is, in the Semantic Web sense, a DID Document? It is not really a resource because we use the In my comment on §5.1 in #401 I already expressed a bad feeling about the structure, but it is reading your document that I realize that we may actually be on a wrong path (and it is not only an editorial issue as I said there). I believe the right way of modeling what we want is, rather: and if we want to express what you said we can then do: I used a blank node for the DID document. Which is fine, because that identifier does not really play an important role. We could, of course, do something like: but that is not really of importance. If we translate this back to JSON-LD, because that is what we want to use, we would get {
"type" : "DIDDocument",
"alsoKnownAs" : "https://www.example.org/ASDFGH/",
"subject" : "did:xyz:12345",
"controller" : "did:abc:WERTYUI",
"authentication" : { ... }
}and, respectively {
"type" : "DIDDocument",
"alsoKnownAs" : "https://www.example.org/ASDFGH/",
"subject" : {
"id" : "did:xyz:12345",
"type" : "https://schema.org/Person"
},
"controller" : "did:abc:WERTYUI",
"authentication" : { ... }
}The important difference here is that we use the |
|
If the term you describe above |
It doesn't at the moment... it is a question to discuss. |
Got it! I like the sound of Also we might not need an extra solution here, given that DID already uses schema.org. Perhaps it's simply possible to use: Instead of However, if indeed |
|
@melvincarvalho Your comments amplifying those of @iherman are deeply appreciated—some of us on the DID WG have been discussing this semantic modeling question for many months (which is why I've actually written four different drafts of Appendix A). What we ended out deciding was that the DID document did not have a separate URI because, as @rhiaro has pointed out in #413, the DID document is a collection of properties describing the DID subject that can be obtained via DID resolution. This is also why we are adding a What @iherman pointed out—and I think he's absolutely correct—is that once we arrived at this conclusion, we need to be rigorous that all of the properties describe the DID subject. So the one property I'm aware of that remains in question, as @iherman suggests, is
Lastly:
That's an extremely good point and one which I will make much clearer in my fifth revision. |
|
@talltree I am still a bit worried that, as @msporny put it in another comment, there may be lots of dragons out there even if we rename the controller property. Actually, I do not know whether just renaming would cut it: if I say that still means that
(Emphasis is mine). This is a case for “If it looks like a duck, swims like a duck…”, ie, that the controller controls the DID document not the DID subject! I could tweak my mind and accept that the other properties, like Also, if we "just" use the RDF triple, then it does not mean any sense to restrict the value of As I said, lots of dragons there... |
|
The controller property allows a DID controller to express other parties that may have verification methods (in their DID Documents) that SHOULD be accepted as authoritative, such that proofs that satisfy those verification methods are to be considered equivalent to proofs provided by the DID Subject. These other parties may therefore generate cryptographic proofs on behalf of the DID subject -- and it is in this sense that they may act on behalf of the DID subject, thereby directing certain behaviors. DID methods that use verification methods to enforce their rules may use the I don't think there's a problem with the term as-is. |
@dlongley I do not have any problem with what you say. My discomfort comes from the way all this is expressed in RDF which seems to be odd in my view (see my examples above) and which does not seem to be in line with the way it is specified in the spec either. |
|
@iherman I thought about this further and IMHO the
In my mind, this makes it even clearer that a controller relationship is very similar—in some cases—to a legal guardian relationship (which in fact plays a hugely important in self-sovereign identity—see this white paper). This also fits with the clarifications I've been discussing with you and @melvincarvalho about:
You are the much deeper RDF expert—do you see any issue with this? |
From an RDF point of view my only reservation is my last remark about the restriction on the URI used for a DID subject:
I do not see any ways to properly restrict the URI format used for a subject within the RDF world. In other words, this type of restriction is "out of bands", somehow. I am not sure how to handle that. If we go that way (and let us say we find a solution or we disregard the URI restriction issue above) then the spec text has to be clarified because, as of now, it really reads that the "control" is on the DID Document. I also think that if we go this way, we would not need some sort of a generic RDF type of the sort (I plan to review my vocabulary and SHACL files anyway because I found some bugs, so I will try to make these things more explicit.) |
I think the "RDF subject value must be a DID" is a restriction that only applies to the DID Document, when you are talking about the DID subject. It is not an RDF vocabulary restriction and it is not specific to "controller". It is a statement to help producers of DID Documents create them properly without having to understand more details about RDF. You must use a DID in the subject position for statements made about the DID subject. It is not a statement about valid RDF domains for RDF predicates. The predicates mentioned may be used elsewhere when not talking about other RDF subjects (and the RDF subject values needn't be DIDs). I tried to clarify this with an additional sentence in the spec here:
https://w3c.github.io/did-core/#json-ld So this is the "out of bands" restriction you mentioned -- which is really just instructing producers to use the DID in their statements in DID Documents when they want to talk about the DID subject. |
|
@dlongley, we define an RDF vocabulary with terms like controller, authentication, etc. This means that somebody in the LD community may come up with the following RDF graph: Whatever tool we use (OWL, SPARQL, SHACL, whatever) this graph will be a valid "DID graph", whether it is encoded in JSON-LD or not. What we say is that this is not a valid set of statement from a DID processing point of view. What I am looking for is a proper statement, note, whatever somewhere in the spec that makes it clear that this is a restriction on an RDF graph that cannot be expressed via the standard RDF(S)+OWL+... toolset. Your statement above is fine for spec text, I am looking for some extra notes there. And we may have some hard-core LD people (not me! :-) raise their eyebrows... |
|
I have to say that semantically, We want to express that someone else controls my DID document or acts on my behalf, but I hope we don't want to say that e.g. one individual controls another individual. Maybe "controller" should go into DID document metadata rather than the DID document. |
we should also remember that the term |
@peacekeeper Did you see my post earlier where I described that controller is just a type of relationship like any other relationship that might exist between two RDF subjects? For example, Let me give an even more specific example:
A cite this example because power of attorney is in fact very similar to what the DID spec means by "controller", especially in a legal sense. By that I mean:
Of course, the DID subject may not be a person. Say it's a drone. Now it seems even more natural to say:
My point is: the fact that the |
|
related #421 |
|
Tl;DR: Change From reading through this, I'm thinking that the issue here is in the semantics of agency that's imbued by our choice of In the examples that @talltree provides above they all share the common pattern that the RDF subject acts on behalf of the RDF object in some manor expected by the object. However, due to the varying nature of the entities that can be RDF objects the term I'm thinking that by changing the RDF predicate from Additionally, the For example let's say that is an IT Admin (did:example:123) acting on behalf of corp A (did:example:456) and corp A owns an IoT Sensor (did:example:789) that publishes data. Now let's say that corp A has a policy that the IoT device needs the admin to rotate the keys of the IoT Device every 12 months. In the current case, what we're saying is that the did:example:123 controller did:example:456 controller did:example:789
In this sense it seems fine, to use the term controller because it accurately represents the relationships between the pairs of entities and by extension the controller predicate accurately represents the transitive relationship between the IT Admin and the IoT device. However, imagine we have the case where a lawyer (did:example:321) at large law firm A (did:example:654) represents a client (did:example:987). In this case, the predicate
|
|
-1 to changing the word controller, although I do agree that RDF is playing a critical role here, I am against changing terminology that is already used in the VC Data Model as well as Linked Data Proofs and many DID Methods. |
I agree it's getting a bit late to change properties at this point. Just wanted to point out the reason the predicate feels incorrect is because it is incorrect in certain scenarios. |
|
@kdenhartog what is incorrect?
one of these reads much more correctly... objects was an option, see: https://w3c.github.io/wot-thing-description/#property-serialization-json that ship has sailed. |
The discussion about As for the usage of object, I don't mean object in the sense of a JSON object. I meant it in the sense of the term of object in RDF. Do to the semantics of what a did represents (it's an identifier for the DID Subject) the semantics of
seems incorrect where as
does not. In the first example, alice doesn't control bob. She may represent him as a guardian or a custodian for his keys, but Bob still has sovereignty of himself which is where the semantics are miss modeled to the actual relationship of Bob and Alice. That's all I was trying to point out in the past post which was talking about how the DIDs represent the subjects and not the DID Document (which we agreed to in the past). So the controller property needs to either be moved to metadata about the DID Document (such that it's Alice controls Bob's DID Document) or the property should be renamed to accurately represent the semantics if it remains in the DID Document. |
|
@kdenhartog the controller is most often seen as a property of the verificationMethod... the verificationMethod is a property of the did subject. IMO, its fine as is, and changing it would be harmful at this time. Here is a clearer example with a couple properties: not all the properties are about the did subject.... for example....
if the did doc supported https://w3c.github.io/did-core/#dfn-did-controllers
Here we can see that Of course, this interpretation assumes we are being honest about RDF being the abstract data model. See #439 |
Taking into account our conversation about implementations that are trying to firm things up I tend to agree that changing it at this point would likely be too late. Especially since this discussion really only popped up past feature freeze which makes it harder to defend without objection. With that in mind, I still think it's fair to say that the base Does that still seem contreversial to you @OR13 ? |
|
The base controller property has always confused me... I have not seen any real examples of it.... It appears to actually be sorta like
|
|
This discussion needs to result in a concrete PR before we go into CR. If we don't see a PR before we go into CR, this issue will be closed or deferred until the next version of the specification. |
|
@msporny I was working on that PR this weekend but then was informed by the Chairs that I needed to lead a 90 minute section on Privacy in the first day of the virtual F2F tomorrow, so I had to prioritize preparing content for that first. I plan to submit the PR later this week. |
|
@talltree - Just checking on status of this (draft) PR... |
|
This issue will be closed once PR #460 is merged. |
|
PR #460 was merged a while ago, closing. |
Several current issues including #355 and #348 (and W3C CCG Security Vocab issue 45) depend on understanding how DID identification architecture works from a graph and semantic model standpoint. This is not currently explained anywhere in the spec. However it has been argued that this content is needed someplace in the spec in order to support a full understanding of how to use DIDs.
Since there isn't another section that feels like a natural home for this content (which is entirely explanatory in nature and contains several diagrams), it has been proposed to add it as one or more appendices to the spec. I have draft three such appendices for this purpose. I have not yet submitted them as PRs yet because it is a lot of content that is more easily reviewed and discussed first in a traditional document format. So all three are currently in a single Google doc. The direct links are:
I have attached this PDF of the current Google doc for anyone who does not have access to Google docs.
Although you can make comments directly in the Google doc (and some already have), it would be best for visibility, access, and archiving to carry on any substantial discussions here, in this issue thread. I will start by answering a few of the comments that have already been made in the Google doc.
Lastly, many thanks to @peacekeeper for helping to think through and review early drafts of this content. He and I have been struggling with these issues regarding Internet identifiers for 15+ years together, and on these questions he is wise way beyond his years.
The text was updated successfully, but these errors were encountered: