Verifiable Credentials Working Group Telco — Minutes

Date: 2023-09-27

See also the Agenda and the IRC Log

Attendees

Present: Ted Thibodeau Jr., Kristina Yasuda, Phillip Long, Sebastian Crane, Dave Longley, Benjamin Young, Gabe Cohen, Orie Steele, Manu Sporny, David Chadwick, Michael Jones, David Waite, Shigeya Suzuki, Dmitri Zagidulin

Regrets:

Guests:

Chair: Kristina Yasuda

Scribe(s): Andres Uribe

Content:

Kristina Yasuda: Our agenda today is focusing on a PR in vc-jose-cose.
… Then we’ll cover 3 issues.
… Time permitting, we’ll continue with vc-data-model issues.
… Any other topics?

Sebastian Crane: Will brent be able to attend? If not, when will he be back?

Kristina Yasuda: Back next week. Out on vacation. Why?

Sebastian Crane: Related to GSMA.

Kristina Yasuda: We talked about this. We can keep forming the liaison. That’s orthogonal to CR.
… Let’s start with vc-jose-cose.

1. controller documents.

1.1. Add support for DIDs (pr vc-jose-cose#144)

See github pull request vc-jose-cose#144.

Kristina Yasuda: We discussed at TPAC.
… vc-jose-cose and vc-di are adding text on how to retrieve the controller verification documents when a credential is being signed using DIDs.
… We’ve seen discrepancies. As a chair, I’d like to see both specifications citing directly did-core, and clarifying what additional requirements are needed on top of it.
… If editors can agree, cool, let’s move on. If not, let’s discuss.

Orie Steele: I wasn’t in TPAC. Got an update. If the WG consensus is to have DI and vc-jose-cose controller defined documents, then they both say the same things or not.
… You can’t simply cite did-core.
… A controller document is different than a did document.
… The former has URLs in it. The latter has DIDs.
… Let’s make sure we don’t miss that distinction.
… Our specs have URLs, not DIDs with fragments.
… Let’s ensure that securing specifications are capable of specifying examples in the spec.
… We need to extend did-core if we’re allowing URLs.

Orie Steele: dlongley noted (via remote): a DID document is essentially a subclass of a controller document – we just had to define these things in reverse order in standards space for a variety of reasons.

Kristina Yasuda: Alternative path forward - don’t cite did-core.
… Make it clear it’s URLs. I think that’s what DI does.
… Then vc-jose-cose should do the same.
… manu are you ok with that?

Manu Sporny: Agree with any direction that doesn’t bifurcate what controller documents are.
… If vc-jose-cose subclasses more what DI does, that’s fine.
… ONe way is to say which bits are on top of did-core. Another is to repeat a lot of text with specific deviations. We would need to be very careful.

Orie Steele: +1 manu.

Manu Sporny: Summary, fine with the concept. Want to make sure that the message is that both definitions are compatible with one another, just profiling did-core differently.

Orie Steele: manu that sounds good, afaik we have only removed text from data integrity.

Orie Steele: we are already duplicating text.. because URLs are not DID URLs.

Orie Steele: data integrity duplicated text first, vc-jose-cose just copied it, and removed data integrity specific language.

Kristina Yasuda: Base controller doc definition, before any profiling, are there disagreements there?

Orie Steele: I think I agree.
… It’s weird to say that VCWG is defining the controller document.
… But as long as everyone’s clear, this is an improvement.
… I’m supporting of that framing in language.
… But unsure if we can, or if there’s consensus.
… To be clear, I think the section that DI defined is better than what’s in did-core. Wouldn’t like to see it taken out.
… Are we allowed to do it in the DI spec? If so, and we do it as well in vc-jose-cose, should we move it do VCDM?

Dave Longley: +1 it’s weird, yes, but it’s an artifact of history and standards process stuff, not technology … and it was expected to happen.

Michael Jones: “Better than DID Core” :-).

Kristina Yasuda: I’ll take an AI to confirm that it’s in scope for this WG to be able to define the base controller document.

Orie Steele: turns out that being better than DID Core is a pretty low bar : ?

Orie Steele: +1 to moving the section to the core data model…. if we can.

Dave Longley: DID core and the work in this ecosystem had some pretty big constraints put onto it that had some adverse outcomes :).

Kristina Yasuda: Assuming it’s true, any concerns for general controller document definition going to vcdm? And then DI and vc-jose-cose adding on top of it?

Manu Sporny: I don’t think it belongs in the VCDM. This is about the securing mechanisms, and doesn’t feel like the right place to put it.

Dave Longley: +1 “controller documents” has always been part of the data integrity / LD proofs work – it makes sense to have it be there.

Manu Sporny: Agreed with everything except that one piece.
… I think it would be ok to duplicate.

Orie Steele: Google folks mentioned wanting to see verification in scope, and i thought i saw possible FO if we don’t address it… seems like keeping controller documents in data integrity and duplicating text will open us up to some risk of FO.

Manu Sporny: As background, these concepts used to be part of linked data signature.

Dave Longley: some of this “let’s put it in kinda the wrong place” arguments … are how DID core got to be the way it is :).

Manu Sporny: Just so happened that they were also in did-core.
… But because of chartering reasons, we couldn’t do it at the time.

Orie Steele: yeah, i agree dlongley, but sometimes you have to break legs to fix them.

Manu Sporny: So +1 to everything except putting in the VCDM.

Dave Longley: i’m saying DID core got its legs broken to begin with by this sort of thing.

Dmitri Zagidulin: @Orie - Google folks mentioned they’d be fine with it if verification was described in /parallel/ specs that would go to CR at the same time as VC DM 2.0. Which they are.

Dave Longley: Orie: it’s fine if other things want to use controller docs that DI defines, those things should refer to that text – or if those things don’t want to just refer for some reason, they can copy the exact same text.

Orie Steele: dlongley yeah, i guess it seems like people don’t like refering to data integrity to use controller documents… that seems to be the problem.

Orie Steele: if the definitions are shared, it makes sense to decouple imo.

Michael Jones: Generic comment. If we want something common, it should be in one place. We can create a key discovery spec.
… That’s probably better than duplicating the text, which will likely get out of sync.

Manu Sporny: If everyone can agree that we lift the text from DI and put it in a different spec, this would lead into a long drawn out debate.
… And it would put us in a worst position.

selfissue: I hear you, procedurally.
… I was thinking of possible ways of doing so (in the base common doc). And then each spec defined how they’re securing it.

Sebastian Crane: If there is going to be objection in a separate spec, is there going to be disagreement between implementers?

Dave Longley: Orie: yeah, one resolution to that would be to compromise and let that go so we can proceed.

Sebastian Crane: Are we kicking the can down the road and doing a disservice to others?

Orie Steele: Json ld signatures were used in a couple of places.
… Still used in many places. It’s valuable to put things where they can be shared without bias.
… Controller documents are the grandfathers of dids. We should make it clear that people can refer to that.
… If we can give that to the community, potentially a better outcome.
… More work for us, but a better outcome.

Kristina Yasuda: For now, let’s have vc-jose-cose duplicate the text from DI with it’s own requirements. That should be the starting point.
… Then I’ll consult if we’re willing to entertain an additional doc.

Manu Sporny: +1 on kristina’s current proposal.

Kristina Yasuda: I’ll come back to the WG after.
… Any objections?

Orie Steele: +1.

Michael Jones: +1.

Andres Uribe: +1.

Phillip Long: +1.

Dmitri Zagidulin: +1.

Dave Longley: +1 sounds like an ok way to proceed.

Kristina Yasuda: PR unblocked. Let’s move to work item updates.

Michael Jones: Does that mean we can merge 144?

Manu Sporny: It’s not just a copy/paste. It doesn’t clarify what’s being subclassed.

Orie Steele: sounds like the PR is still blocked.

Orie Steele: and there is no consensus on how to proceed, pending discussion on controller documents in the abstract.

Kristina Yasuda: Orie can you comment on the modified parts from DI?

Orie Steele: The PR started with a copy. Then there were many sections that were removed related to DI.
… After several rounds of suggestions, seems like the PR is irrecoverable. It will not achieve consensus.
… That’s fine. Best path forward is giving us a single place that both specs can refer to.
… Not sure how to resolve. But the PR is blocked.

Kristina Yasuda: manu, What are the normative changes that were made that you are concerned about?

Michael Jones: +1.

Orie Steele: I can put in an issue marker.

Manu Sporny: That’s not the concern. I would suggest to put an issue marker explaining that the WG is attempting to align the definitions between DI and vc-jose-cose.

Kristina Yasuda: Sounds like a way forward.

Michael Jones: Thanks all.

Kristina Yasuda: manu, if you can open an issue where you explain what text you’d like to be better aligned, that would be helpful.

Orie Steele: sounds good!

Orie Steele: PR will be unblocked after issue marker is added.

Kristina Yasuda: Sorry, ivan, some cleanup will need to be done :-).

2. work item updates/PRs.

Kristina Yasuda: Any PRs that need attention?

Manu Sporny: I’d like to move forward to the DI issues… (as that is PRs/updates that need to be discussed).

Kristina Yasuda: On VCDM, there were a handful of PRs that were merged. If you missed those, PTAL.
… Otherwise, there are a few PRs addressing horizontal review. Thanks decentralgabe.
… We marked PR 1271 as do not merge.
… And we’ll invite the i18n group to have a discussion.

2.1. Remove references to MULTIBASE and MULTICODEC (issue vc-di-ecdsa#39)

See github issue vc-di-ecdsa#39.

Kristina Yasuda: tldr; there was an issue coming in about normative references about multibase and multicodec. We agreed to fix that in the vcdm. Now there are issues about addressing them in the cryptosuite spec docs.
… manu did a PR in which selfissued is asking for changes.

2.2. Remove normative dependency on Multibase and Multihash. (pr vc-data-integrity#196)

See github pull request vc-data-integrity#196.

Manu Sporny: selfissued suggested we removed normative dependencies on any multiformats specifications, because they aren’t standards.
… I heard consensus during f2f where we agree to make those references non-normative.
… This is what the PRs I raised are doing.
… I think what selfissued is asking for is the complete removal to any reference. Even if they are non-normative.
… As for the other issues raised with other cryptosuites, they say what the normative values should be.

Michael Jones: The core of the discussion wasn’t about normative vs non-normative references. It was about required features needing to be normatively defined.
… They have to be defined before going to CR.

Manu Sporny: https://pr-preview.s3.amazonaws.com/w3c/vc-data-integrity/pull/196.html#dfn-proofvalue.

Manu Sporny: ^ normatively defined right there.

Michael Jones: I’m still seeing that the value is defined, which cannot be defined since multiformats isn’t a standard.
… I think we should be able to normatively defined the contents of every spec without referring to the multiformats spec.
… Adding a note stating that it’s compatible is ok.

Kristina Yasuda: To clarify, you are asking the DI document to redefine multibase/multicodec instead of referring to the internet draft?

Michael Jones: Yes, with the subset that actually matters.

Manu Sporny: That’s exactly what it does.
… <manu reads the pr preview>.

Michael Jones: “The contents of the value MUST be a [MULTIBASE]-encoded binary value with a header and encoding as described in 2.4 Multibase.” retains normative use.

Kristina Yasuda: Why do you need a reference to multibase?

Manu Sporny: Because it’s useful for implementers. Explains the background.
… Useful as pointing to any non-normative document.

Manu Sporny: “[MULTIBASE]-encoded”.

Manu Sporny: I’m confused what’s being objected to.

Michael Jones: quoted the sentence that’s objected to.

Manu Sporny: I’ll make the changes to remove the multibase bit.
… The other PRs point to the section that will be fixed.
… That’s how they refer to it normatively.

Michael Jones: See https://github.com/w3c/vc-di-eddsa/pull/63/files.

Manu Sporny: I’ll make sure that all similarly worded phrases refer to the normative spec (i.e. DI).

Kristina Yasuda: same for https://github.com/w3c/vc-di-eddsa/issues/62 and https://github.com/w3c/vc-di-bbs/issues/92..

Michael Jones: That also has a sentence.

Manu Sporny: I can remove that as well.
… we have a path forward.

Sebastian Crane: Pointing out the multibase isn’t a protected trademark.
… We should be specific and define everything that we need.
… We can still call it multibase.

Orie Steele: https://twitter.com/multibase_co is a YC company, doing web3 analytics…. which i get ads from constantly.

Kristina Yasuda: might be confusing, but that’s fine.
… got 3 minutes, any issue/PR?