Verifiable Credentials Working Group Telco — Minutes

Date: 2024-11-20

Attendees

Present: Brent Zundel, Ivan Herman, Mandy Venables, Manu Sporny, Kevin Dean, Dave Longley, Wesley Smith, Benjamin Young, Will Abramson, Ted Thibodeau Jr., Gabe Cohen, Jennie Meier, Joe Andrieu, David Lehn, Hiroyuki Sano, Dmitri Zagidulin, David Chadwick, Phillip Long

Regrets:

Guests:

Chair: Brent Zundel

Scribe(s): Kevin Dean, Manu Sporny

Content:

1. Controller Document.

Brent Zundel: Next week’s meeting is cancelled.

Gabe Cohen: Now here as invited expert.

1. Controller Document.

Brent Zundel: https://github.com/w3c/controller-document/pulls?q=is%3Apr+is%3Aopen+sort%3Acreated-asc.

1.1. Updates re controller property (pr controller-document#116)

See github pull request controller-document#116.

Brent Zundel: Gratified to see recent activity.

Joe Andrieu: I think it’s going well. David Chadwick created another issue as there were edits he proposed that I didn’t accept.
… There were a few suggestions from tallted that I accepted, some I didn’t, but most were excellent.

Ted Thibodeau Jr.: I can’t say anything about this right now.

Joe Andrieu: The other main thing that we did was move the discussion about identifier ambiguity to security considerations section. That had been in the terminology section but it was too wordy.
… Previous version mentioned the White House and Biden, which was shorthand for me to rewrite into something less political. Rewritten to use teacher.

Brent Zundel: If you haven’t looked in a while, look in PR 116. There have been quite a few changes. As time move forwards, if this PR gets to the point where it has nothing but approvals, it will get merged.

1.2. Explain why one key format is not realistic. (pr controller-document#120)

See github pull request controller-document#120.

Manu Sporny: Issue was raised by Microsoft four years ago, asking us to settle on one key format. Discussed internally, said no, that’s not the way it’s implemented in the field.
… While it would be nice for there to be one, there are multiple key formats in the world and often in one system.
… I think it’s got positive reviews, I think I addressed David Chadwick’s concerns.
… One question I have for the group is that we mention key formats that are more broadly distributed but not mentioned in the document. Should we add SHA public keys and others in the context as something that people can express but not write into the spec?

Ivan Herman: Apologies if this is already in the document. The argument on why we have two key formats in the document… Is there any trace of that in the document itself?
… I want to see something in the document that explains why we do that.

David Chadwick: I was coming at this with a blank sheet and historical knowledge, but not about discussions.
… Back in the 1990s playing with X.509, there were multiple key formats, which was a pain, hence my comment.
… I accept the group’s decision.

Manu Sporny: To Ivan, the text you’re asking for is in the PR.

Ivan Herman: +1.

Manu Sporny: To DavidC’s point, I don’t think we should get into this discussion. We should just merge this and move on. We starting 10 years ago with public key PEM was enough but as people came in and out and as development happened, these were the two key formats we could get people to like.
… These formats don’t do much beyond what PEM does.
… I think we should have stuck with PEM but this is the direction the group has gone.
… I don’t think it’s worth reopening at this point, but we may do so in the future or add an extension.
… It’s very weird that we don’t allow the two most widely distributed key formats.

1.3. Simplify verification method definition. (pr controller-document#121)

See github pull request controller-document#121.

Brent Zundel: To address issue #150. PR has nothing but approvals with only a minor proposed change from TallTed.

Manu Sporny: Mike Jones felt we should simplify it and proposed some text.

Brent Zundel: Very simple and straightforward, please review, will likely be merged in three days.

1.4. Clarify what happens after authentication. (pr controller-document#122)

See github pull request controller-document#122.

Brent Zundel: A couple more comments and a few fewer approvals than last one.

Manu Sporny: Another from Mike Jones, he felt like the description wasn’t adequate. I have tried to apply some of his language to this to clarify the definition.

Brent Zundel: Please review and if you have comments, we can discuss, otherwise onto the next one.

1.5. Clarify that mechanism for capability delegation is application-specific. (pr controller-document#123)

See github pull request controller-document#123.

Brent Zundel: Nothing but approvals.
… I expect this to be merged soon.

1.6. Add example that does not contain `@context`. (pr controller-document#124)

See github pull request controller-document#124.

Brent Zundel: Again, nothing but approvals.

Manu Sporny: This was another request from Mike Jones. The current controller document says that if you don’t want your document to be processed in a JSON-LD environment, you don’t need to include context.
… Organizations that want to verify against JSON-LD can inject context.
… Mike suggested removing context from all other examples but there was resistance.
… Leaves the question of where we include them or not in the spec.
… I would like to include @context in other examples. Right now, it’s sporadic throughout the document.
… Except for the ones that explicitly state that it’s possible to work without a context.
… There are also examples in the appendix that should be updated.

Brent Zundel: I don’t find the lack of consistency to be confusing.

Ivan Herman: +1 to Brent.

Brent Zundel: Folks reading the entire spec will figure it out. My proposal is to do nothing, asking folks to consider that as a path forward.

Kevin Dean: The challenge with examples is that as you move through a specification, you are building up capabilities until by the end of the document you have a complete specification.
… The natural flow for a specification for a feature in this section to be using features in prior sections. There are seldom forward references, having examples follow that pattern, making examples consistent – you can rely on examples, is useful as a way of understanding the specification.
… The absence of a context line in an example, when it’s closely related to example in previous section, could be confusing for neophyte readers, left out because it is an example of how to do this without a context.

Manu Sporny: +1 to what Kevin said.
… What we have in the spec right now are examples created by people who wanted JSON Web Key stuff.
… We have examples with context, then without context, then with context. It can be confusing.

Dave Longley: -1 as that would imply that JsonWebKey won’t work with contexts which is not accurate.

Manu Sporny: I can put together a PR for it. The key here is that we provide examples that are what we believe best practice to be, which can launch another debate I don’t want to get into.
… Can we please get examples that are best practice that don’t get into the JSON/JSON-LD debate.

Brent Zundel: I don’t think we can. Past discussions of best practices have gone long and not reached a resolution.
… Happy to see PR that structures examples aligned with how the specification develops. I would love to see someone restructure the document.
… I haven’t encountered people who are confused by the spec. If there are folks who are, I would like to hear from them.
… Let’s see PR to modify things if folks want to do that.
… As far as this PR goes, I’m not hearing anyone to say not to merge this one.
… Happy to take more comments, or move on to next PR.

1.7. Fix definition of controller and add verification method binding section (pr controller-document#126)

See github pull request controller-document#126.

Brent Zundel: This is a bigger PR than the others in terms of its scope, not size.
… There has been some discussion, but no approvals.

Manu Sporny: Two things. I want to also queue up an issue on the controller that came up on the DID special topic call after this.
… This has to do with the definition of controller. There is confusion around the controller of a document and controller of verification.
… It would have been a class 4 change, which would have prevented the DID WG from using this.
… Let’s just use the definition of controller to say that you have control over a thing.
… Copy verification method binding text over to here. Trying to find the right words to say that a controller controls a thing, be it a controller document or a verification method.

Ivan Herman: There is a PR on the DID spec that proposes additions to the vocabulary.
… I think it’s the only PR over there.
… There was another issue that came up in the discussion. If I have the URL for the verification method, how do I find where is the controller document for that verification method?

Dave Longley: “controller” dereferences to controller document.

Ivan Herman: What we have right now in the specification is very much JSON dependent.
… Or VC dependent structure.
… I’m fine merging this PR but the issue discussion should continue.

Joe Andrieu: It may not be well documented, but I believe it’s in the verification method itself, it’s the URL you dereference to get the controller document.
… I want to support Manu’s point that it’s too big of a lift at this point. We don’t mean that the controller can update the verification method, we do mean it for the document.

David Chadwick: I don’t like the definition as it stands. I have proposed a change that makes the definition of controller symmetrical, that has the same meaning as to what it applies to.
… It’s the same thing on two different objects that have a controller property.

Ivan Herman: Here is an example where the confusion comes.

Dave Longley: -1 to what Ivan is saying …

Dave Longley: controller does refer to the controller document that defines the VM.

Ivan Herman: My understanding, Joe, is that the controller property in the verification method refers to a person, you or me, that has the ability to change to whatever is there. It does not refer to the controller document that refers to the verification method.
… We have to document that properly.

Joe Andrieu: The previous response I wanted to make was a modest one. The class 4 restrictions are on the DID spec, not on the controller document spec.

Ivan Herman: It’s an unusual situation, but I see Manu’s point.

Manu Sporny: On the class 4 changes, it is possible for us to make a pretty drastic change to the controller document, but then there’s a discussion around if DID Core is dependent on the controller document, is it a class 4 change for DID Core?
… Some would argue that it is. Changing something that drastic at this point in time, even if it’s the right thing to do, would cause ecosystem problems.
… To go back to DavidC, I think we open a can of worms if we do it.
… I think the way that “controller” is used right now, is fairly hand-wavy, high-level way.
… It can mean multiple different things. The concern about ambiguity is valid. We could have used more specific terms.
… We don’t want to change it at the property level right now as it’s a class 4 change.
… It is possible to interpret “controller” in the way that you’re interpreting it. There are other interpretations as well.
… We should be specific. When talking about a controller of a controller document, we’re talking about an entity that can change it.
… When talking about a controller of a verification method, we’re talking about an entity that change update a value in certain case and that they have access to private key material to generate a signature.
… I don’t think we have to make them consistent.
… They mean slightly different things in slightly different contexts.

Dave Longley: My first response is to Ivan. I want to say that the controller on a verification method does refer to a controller document that defines who controls the verification method.
… Second, you can’t know definitively who the controller is.
… You can follow the controller to determine if you can use the verification method.

Joe Andrieu: +1 to Dave’s comment.

David Chadwick: +1 dlongley.

Manu Sporny: +1 to JoeAndrieu.

Joe Andrieu: In this case, we’re saying “Go get this controller document so you can determine the validity of the verification method.”.

David Chadwick: We are offering the contents of the associated resource.

Dave Longley: +1 i actually do agree with what DavidC just said.

David Chadwick: My change is trying to say that we’re saying the same thing about each.

Ivan Herman: I look at the controller document itself and it defines the controller for a verification method. It doesn’t say anything about the controller property, just that it is a URL.

Joe Andrieu: that’s the new PR.

Dave Longley: +1 agree that it needs to be said explicitly.

Ivan Herman: I haven’t found anywhere in the document that specifies that the controller property of the verification method refers to the controller document.

Joe Andrieu: +1 to doing better and being explicit.

Joe Andrieu: (because only part of it is in the new PR).

Ivan Herman: It’s a very different kind of definition. I was one of those that raised the possibility of separating those two terms. I accept that it’s too late to do that.

Manu Sporny: yes, +1 to that ^.

Ivan Herman: At least the semantic definition should be clear, and it’s not.

Manu Sporny: I can try to update the PRs to do what Ivan is asking for, and review what David has written (as long as others agree w/ that update).

Brent Zundel: We agree that we can’t make clarifications or normative changes that affect the downstream DID document.
… The feeling I’m getting is that we’re closer than not to language that is satisfactory. Last word to Manu.

Manu Sporny: Ivan is right, the spec doesn’t have that language.

Manu Sporny: I don’t have a strong opinion as long as others can agree on whatever the revised text it.

1.8. Add media type for Controller Documents (issue controller-document#127)

See github issue controller-document#127.

Brent Zundel: I do not see any conflicts with media type application/controller.

Manu Sporny: This is just a request to the group. What do you think about application/controller? I can raise a PR with IANA to register it.

Ivan Herman: I have no problem with application/controller. I don’t really understand how these things work.
… The DID document is essentially a controller document. We define it as application/did.

David Chadwick: I made a comment on another issue. Manu said that there was no clear consensus on changing the name, I pointed out that there was on the last meeting.

Brent Zundel: It was my call, as chair, that while there was consensus that we didn’t like controller document, there was no consensus on an alternative.

Joe Andrieu: I agree with DavidC. I do have a sustained objection to an incorrect call about consensus and I will be filing a formal objection.

Brent Zundel: It sounds like we’re reopening the renaming conversation.

David Chadwick: +1 JoeAndrieu.

Joe Andrieu: Not one person voted against renaming to Identifier Document.

Joe Andrieu: +1 to getting the PR proposed.

Manu Sporny: I’m going to raise a PR, put application/controller in it. People can comment and we can change to application/identifier or something else in the PR.

Proposed resolution: rename the Controller document to Identifier document. (Brent Zundel)

David Chadwick: I also said that application/identifier would be more appropriate than application/controller and it would better align with application/did.

Brent Zundel: I don’t care.

Gabe Cohen: +0.

Brent Zundel: +0.

Joe Andrieu: Apparently you do.

Brent Zundel: Show me the consensus.

David Chadwick: Look at the minutes of the last meeting and the voting.

Joe Andrieu: I don’t think this is a valid proposal. This is my objection to you as chair, you shut down conversation.

Brent Zundel: I’m allowed to say I don’t want to talk about something. Yet, we have. On the calls, on the issues, in the PRs. I have not seen any suggestion made that had universal agreement.
… I said we shouldn’t discuss it any further because we can’t come to agreement. I am doing so in my duty as chair to say that we don’t have consensus and we have to move on.
… Making a resolution today doesn’t shut anything down.
… There’s a proposal on the table to change the name.

David Chadwick: Brent look at the voting from last week.

Brent Zundel: If I didn’t see the consensus before, show it to me now.

Manu Sporny: +0 (due to something Longley said last week that was of concern to me – would like to discuss why “Identifier Document” isn’t the right word).

Brent Zundel: The proposal is on the table.

Dave Longley: +0 (will not block) would prefer Controlled/Controllable in there because Identifier Document is lacking to me.

Joe Andrieu: +1.

David Chadwick: +1.

Brent Zundel: I see three zeros. I don’t see any plus ones.

Ted Thibodeau Jr.: We’re at time. We’ll be past it if we go further.

Phillip Long: As I understand Manu’s suggestion the discussion about this was to take place in the PR.

Joe Andrieu: Let the record show that no one objected.

Brent Zundel: I see four zeros and two plus ones. We’ll come back after Thanksgiving and set an entire meeting to this topic if that’s what’s necessary.
… Tell me what you want and I’ll make it happen.

Joe Andrieu: There is no objection to this poll.