invert mapping between proof purposes and verification methods?

[dhh1128]

The current approach is to create a top-level field in the DID doc for authentication, keyAgreement, capabilityInvodation and so forth, and then to add verification methods to an array that is that top-level key's value. Example 14 shows this nicely.

However, I am concerned that this structure is unnecessarily verbose/repetitive if the same verification method is usable in many different verification relationships. Have a look at a canonical expansion of a did:key, where the same key value shows up over and over again.

When the verification method is a cryptographic key, perhaps this is just a minor annoyance. But where the verification method is something that requires more than a single string to specify (as, for example, when we're listing 7 keys and saying that any 3 of them must sign), repeating the verification method gets really ugly. This is particularly true because other verification methods don't have a publicKeys section where a key can be defined once, then referenced repeatedly thereafter.

One way to clean this up is to simply invert the relationship between methods and purposes: put a root-level field called "verificationMethods" in the DID doc, and then, under each verification method, list the proof purposes they should be used for. This would result in a much terser did:key expansion something like the following:

{
  "@context": ["https://w3id.org/did/v0.11"],
  "id": "did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH",
  "verificationMethods": [
    {
      "id": "did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH#z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH",
      "type": "Ed25519VerificationKey2018",
      "controller": "did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH",
      "publicKeyBase58": "B12NYF8RrR3h41TDCTJojY59usg3mbtbjnFs7Eud1Y6u",
      "proofPurposes": ["authentication", "assertionMethod", "capabilityDelegation", "capabilityInvocation"]
    },
    {
      "id": "did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH#zBzoR5sqFgi6q3iFia8JPNfENCpi7RNSTKF7XNXX96SBY4",
      "type": "X25519KeyAgreementKey2019",
      "controller": "did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH",
      "publicKeyBase58": "JhNWeSVLMYccCk7iopQW4guaSJTojqpMEELgSLhKwRr",
      "proofPurposes": ["keyAgreement"]
    }
  ]
}

As I said, the terseness when only key values are being used isn't super compelling -- but when the method in question is multisig or something else that is not easily specified with a single string value, I think the terseness gets more compelling.

Tagging @kdenhartog and @ewelton, both of whom have raised issues that touch on verification methods and their semantics and that thus intersect slightly with this topic. Also @ChristopherA , who has been interested in multisig.

[dlongley]

Establishing a relationship from the DID subject to the verification method is intentional. The authority to say which verification method can be used and what it can be used for extends from the DID subject. The approach above would invert that, making it such that a verification method would express what it can be used for -- which runs counter to the point of expressing the relationship in the first place. We don't want verification methods to express what they can be used for -- we want DID subjects to express that.

The original concern around cases where there may be more than a minor annoyance from repetition can be addressed by referencing verification methods by ID instead of expressing all of their contents repeatedly. This doesn't require changing the model.

[dhh1128]

@dlongley : Your first paragraph doesn't compute for me. First, it seems to me that the authority comes from the DID controller, not the DID subject. Never, at any point in the DID's lifecycle -- even before it is registered (if at all), is the DID subject required to be capable of exercising authority. Only the DID controller ever, ever can be assumed to do that. It seems to me that this is necessarily true; @jandrieu has been at pains to point out that a DID can refer to anything whatsoever -- even to a thing that's categorically inert -- as long as it's controlled. Doesn't that imply that the controller is the basis of the authority?

But setting that aside, how does inverting the relationship between methods and purposes (essentially, going from "here are things that can be done, and ways to do them" to "here are ways to do things, and what can be done with them" alter the basis of authority? The controller is still the one creating the linkage between the two constructs using the permissive verb "can".

Your second paragraph assumes that there is a place and a way to declare verification methods other than keys. No such place is contemplated in the spec, though the spec doesn't preclude it, either. So the DID controller inserts a declaration of a method somewhere undefined, and includes in the definition an id property that can be used to reference it later? I could go for this, but do we need to invent places for those declarations to go, analogous to publicKeys where declarations of keys go? And are we to assume by analogy that non-key-oriented methods can also be inlined inside verification relationships like "capabilityDelegation" and "keyAgreement" -- or does the spec need to be updated to explicitly acknowledge or preclude that possibility?

[dlongley]

Sorry, I understand the confusion. My comments are really about being able to convert an abstract data model into a concrete representation in a consistent way rather than in an ad hoc way that forces the entire DID Document to be read holistically in order for relationships to be understood properly (as opposed to working cleanly with linked data and graph models). Also, if we keep the current design we don't have to preclude a whole variety of unexplored verification method representations -- or one's ability to potentially externalize them.

In short, DID Documents are currently modeled such that a subject has properties and those properties have values. This is compatible with both a graph and a tree model. The "top-level" subject is the DID subject. Any property it has relates it to a value or to another subject mentioned in the DID Document. If you follow the property relationship to another subject, then the properties you find there are properties of that subject, identified by its id, if present. This is consistent.

In this sense, your suggestion would fundamentally alter the "verification relationship" that is presently in use or the consistency just described. Presently, a verification relationship is one that expresses that a verification method is authorized to be used for a specific purpose by/on behalf of the DID subject. Yes, this expression always comes from the DID controller, that is not in dispute. Either the consistency described above will be lost or the relationship must change to become one that expresses that a verification method can be used for a particular purpose, however, there is no longer any linkage in that statement to the DID subject. Instead, this information must be inferred from an ad hoc rule regarding the fact that the verification method's definition happens to live in a DID Document that is about the DID subject. This adds cognitive load and breaks the consistency described above. I don't like that trade off; this is the complaint.

[dhh1128]

Dave: Thank you for taking the time to clarify. I was interpreting "DID subject" from the problem domain of DIDs without respect to RDF/Semantic web; it seems that you were equating the term "subject" in the two domains? Let me restate to see if I understood:

You want the doc to consist entirely of RDF triples: subject, predicate, object. You want to analyze the doc as having a single top-level subject (RDF subject = DID subject) and to have all JSON keys off the root be predicates (roughly, verbs) for that same subject. If we switch so verification methods are off the root, you feel this would be inconsistent.

Did I get that right?

If so, this sort of hangs together for me, except that the publicKey section is already a canonical anomaly. So we already have inconsistency. Or are you analyzing publicKey as a predicate in some way?

I don't mind going the direction you are recommending, IF we truly achieve consistency. But if we're going to already have inconsistency, the argument kind of falls apart for me. I also note that part of my problem -- gaps in what the spec documents -- remains unresolved:

Your second paragraph assumes that there is a place and a way to declare verification methods other than keys. No such place is contemplated in the spec, though the spec doesn't preclude it, either. So the DID controller inserts a declaration of a method somewhere undefined, and includes in the definition an id property that can be used to reference it later? I could go for this, but do we need to invent places for those declarations to go, analogous to publicKeys where declarations of keys go? And are we to assume by analogy that non-key-oriented methods can also be inlined inside verification relationships like "capabilityDelegation" and "keyAgreement" -- or does the spec need to be updated to explicitly acknowledge or preclude that possibility?

[ewelton]

I've been focusing on VCs anchored in non-DID URIs and wondering about what drives the structure of the document sitting beyond the URI. I believe that the structure comes from the VC use of Linked Data Signatures and would love some clarification about that - hearing that was a particular eureka moment for me at IIW, but I have not had time to investigate further - perhaps an expert could weigh in?

What are the other, specific, code-driven use-cases that constrain our structure right now?

Once upon a time I remember discussion about "non-key verification methods" - but I don't recall a strong sense of "oh, we gotta have that" - and in the interests of driving the spec forward, I suspect that non-key verification methods can be deferred to V2 DIDs.

I'd also love to hear a bit more about the implementation details relative to @dhh1128 's proposed structure above, and spec Example 14 - specifically how swapping the location of the word "authentication" would impact existing libraries, specs, and proposals.

Personally, I like the proposed structure over the hyper-repetition and anti-elegance of the current DID-docs. On the other hand, I think that the community needs DID V1 spec released and stable ASAP, so I am willing to postpone cleaning up this hot-mess until V2. If DIDs are no longer attractive for use in VCs, I think the value proposition of DIDs is significantly diminished.

On that basis I propose we look at the most expeditious structure for that use case and take solace in the knowledge that we can structure DID document models in our internal processing libraries however we want and do not often have to rely on the DID document structure, except when they are used in a web access context.

[dlongley]

@dhh1128,

Or are you analyzing publicKey as a predicate in some way?

Yes, it is a predicate and has been since the WebID days. It is for expressing that the subject has one or more public keys. That being said, I'd be happy for us to move away from using it and embrace more deliberate/explicit verification relationships.

[ewelton]

@dlongley I would have loved that a year ago - but not so much today. We need to remember that there is a huge gap between this level of discussion abuut DIDs, their relationship to VCs, the history of the spec - and the rest of the world.

In general, the DID-core specification is exceptionally sparse when it comes to "Verification Methods" - and moving to "express more deliberate/explicit verification relationships" is problematic in that context. This is because a lot of the world is pragmatically driven to "support W3C DID standard" while secretly terrified by what that might mean.

I know of multiple companies with "hidden DID methods" who are reluctant to express DID support beyond that single statement - precisely because the W3C DID community is largely an internal discussion held in a public arena - they are waiting for the timer to run out and then look at the published spec and adapt.

Relying upon "publicKey" is the one thing that is minimally contentious has been a saving grace for that community - whether they use it correctly or not.

Most of them pair the DID document (e.g. key material) with an additional document that expresses the information they need to manage those keys. With the loss of semantic flexibility the game is now to wait until the W3C decides what a DID is and what is in the DID document, and look at the various "registries" - and after that, figure out what part of their "peer documents" can move into the "DID Document"

I urge the clarity of expressing the specific, code-driven use case - because I do not think the community reading the spec is quite aware of why it is in the state it is in now. At this point, removing "publicKey" and replacing it with some melange of top-level and arbitrarily dictated verification methods will continue to drive people away from DIDs as anything other than an obligatory part of the "we need to say we are standards compliant" game.

[dhh1128]

@dlongley:

Or are you analyzing publicKey as a predicate in some way?

Yes, it is a predicate and has been since the WebID days. It is for expressing that the subject has one or more public keys. That being said, I'd be happy for us to move away from using it and embrace more deliberate/explicit verification relationships.

Okay, fine. So would I be correct to assume that it would also be fine to add another predicate/verb off the root, a sibling to "hasAPublicKey", called "hasAGroupOfFriendsVerificationMethod"? The problem with my original suggestion, if I understand it correctly, is not with putting verification methods at the root; it's with putting proof purposes (also predicates) underneath them because they're not objects in an RDF subjectpredicateobject triple?

If that's true, then a DID doc structure that looks like this would feel less obnoxious?

{
    "publicKey": []
    "groupsOfFriends": [] <-- all this list does is define groups of friends, NOT say how they are used
    "proofPurpose1": [ ref to public key A, ref to groupOfFriends B]
}

Note that I'm NOT advocating such a structure at the moment. I get that I could define groupsOfFriends verfication methods inline under a proof purpose just as easily. I'm just trying to understand what you consider the heart of the inconsistency. Have I diagnosed it correctly?

[ewelton]

@dhh1128 how is that different from the Example 14 model - or is the 'groupsOfFriends' a non-key verification method?

[agropper]

Much of @eric's sentiment resonates with me. I want to *use* SSI not develop it and it's almost impossible.I'm lost in the details in DIF and W3C and really can't keep the players straight. I've spent seven months in a glossary committee trying to define three words - with no end in sight. There's no reference implementation. The only commercial use-cases seem to be government mandates. I'm used to working commercially at the bleeding edge of standards. The product-market fit model for SSI seems particularly fraught and needs more love. - Adrian

…

On Wed, May 6, 2020 at 8:04 PM ewelton ***@***.***> wrote: @dhh1128 <https://github.com/dhh1128> how is that different from the Example 14 model - or is the 'groupsOfFriends' a non-key verification method? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#273 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABB4YOBIO5D6G6PIWUBEUTRQH3KTANCNFSM4MZWYYEA> .

[dlongley]

@dhh1128,

Note that I'm NOT advocating such a structure at the moment. I get that I could define groupsOfFriends verfication methods inline under a proof purpose just as easily. I'm just trying to understand what you consider the heart of the inconsistency. Have I diagnosed it correctly?

I don't know what "groupsOfFriends" means -- but without getting into those details, so far what you've suggested seems perfectly reasonable. You're creating a relationship "groupsOfFriends" and linking the DID subject (the root "RDF subject") to these groups via that relationship and then in each of those groups you can express other properties to define them further whereby the "RDF subject" associated with those properties would be the identifier for the group. Then you can reference those groups by ID via a verification relationship (what you've called proofPurpose1 in your example). That's all consistent and reads ok to me. Yes, I think we're on the same page now.

[OR13]

Aren't we now calling these things "verification relationships"... seems potentially a stale issue.

related: #308

https://w3c.github.io/did-core/#verification-relationships

[dhh1128]

I'm content to close this issue. I learned what I needed to learn as the discussion unfolded. I agree that its current title is no longer a good one.

I don't know what the procedure is for closing issues. Since I opened the issue, am I allowed to close it?

[OR13]

@dhh1128 my understanding is yes, but since there has been productive debate I think its best to ask for a pending close tag, and then close it after some time... theoretically people are reviewing pending close issues, and objecting if they think further discussion is warranted.

@burnburn is this correct?

[kdenhartog]

Marked it as pending close as a conservative approach and alert other readers of the issues status. @dhh1128 you can close this early if you're satisfied with the outcome. We'll give it 7 days to close otherwise.

[brentzundel]

No comments raising objections to closing this issue