Verifiable Credentials Working Group Telco — Minutes

Date: 2023-11-29

See also the Agenda and the IRC Log

Attendees

Present: Ivan Herman, Ted Thibodeau Jr., Greg Bernstein, Brent Zundel, Phillip Long, Dmitri Zagidulin, Manu Sporny, Paul Dietrich, Michael Jones, Dave Longley, Andres Uribe, Orie Steele, Will Abramson, Joe Andrieu, Sebastian Crane, Benjamin Young, Kaliya Young, David Chadwick

Regrets:

Guests:

Chair: Brent Zundel

Scribe(s): Phillip Long

Content:

Brent Zundel: brief agenda review- work item status updates and PRs needing reviews.
… bulk of time on item 1338 to address concerns raised by Google.
… additions or changes?

Manu Sporny: time to discuss Tony’s questions to the mailing list to understand what things need to be in for CR?

Brent Zundel: intros or re-intros?

1. CR proposal timing.

Brent Zundel: currently exists a draft of core data model as per PR, only changes anticipated are issues labelled before CR.

Manu Sporny: Links to the current documents: https://lists.w3.org/Archives/Public/public-vc-wg/2023Nov/0020.html.

Brent Zundel: in a week or so submit proposal to the group saying going into CR with these pull requests.
… an objection was raised saying a final version is ready for review before a proposal is made. What does the group think?
… go forward with all things done or with those in modulo and then CR?

Orie Steele: I think its fine to signal intended timeline, but I agree its better to formally approve CR after changes have landed.

pdl-asu>selfissued: no advantage saying going to CR with changes. Should get all the changes in before going to CR.

Manu Sporny: in the past we’ve said what we’d go into CR with the remaining items to be resolved. If we await on final version this year we won’t be done.

Brent Zundel: the sooner we have a resolution to go to CR that’s when we get things rolling.
… . are timing benefits to craft the proposal with the timing benefits.

Michael Jones: What is W3M?

Ivan Herman: staff contact hat on, we go to W3M with everything done. No one will look at the doc until things are finalized.
… how much time will it take to get to final resolution is the issue. Really no difference in the two approaches.

Michael Jones: Ivan said what needed to be said. Getting it right is more important. The schedule can be addressed later.

Andres Uribe: +1 to what Mike said.

2. Work Item status updates/PRs.

Brent Zundel: editors jump on the queue for status updates.

Manu Sporny: will go through VCDM today.

Brent Zundel: only one today.

Manu Sporny: 1302 and 1320 and 1333 waiting for feedback.
… vc bitstring status list has been made. As soon as we go to CR things will go into the bitstring status list.

Orie Steele: PRs that need reviews:.

Michael Jones: issue 186 about removing uses of multiple suffixes which is more controversial than expected.

Michael Jones: - https://github.com/w3c/vc-jose-cose/pull/186.

Michael Jones: fine with waiting for IETF and flag it at risk for VCDM and VC Jose/Cose best to leave things alone.

Greg Bernstein: VC BBS - only a few mods needed. Things in good shape. PR put in for security considerations.
… working on privacy because it just got updated in IETF and want good advice about data linkage and unlinkability.
… a lot of this about state of things can make at higher layers.

Manu Sporny: agree with Mike, premature to remove multiple suffices. Or should discuss PR in more depth.

Ivan Herman: worth flagging is issue 1338 makes reference to the Spec Directory document. If we go to CR that doc should be published as official doc.
… should start the procedure to get that published.

3. Addressing Google’s concerns.

See github pull request vc-data-model#1338.

Brent Zundel: have PR in place w/ sum review with some requested changes. Goal today is consensus to this PR.

Manu Sporny: Jeffery Yasskin gave a comprehensive review. Pointed out things needed to be addressed.
… if we don’t define verification algorithm Google will formally object.
… this PR will define that algorithm and how you verify the securing mechanism,and how the doc should be secured to the securing specification.
… at this point Jeffrey is happy with what’s going in (no Google objection).
… some people felt some people we’re defining an API, but here we’re defining an algorithm.
… should use different language so it’s clear we’re not defining an API.
… should address Google’s issue, and anyone saying we’re going beyond our charter.

Michael Jones: part of this PR’s problem is a layering violation.
… the data model should define the data model; the securing spec how to secure it.
… this PR should address this data model not the securing spec.

Orie Steele: +1 it is a layering violation, but its possible to accept it, if the algorithm can be made a pure function of the vocabulary terms, and not refer to the securing specs.

Manu Sporny: not a layering violation. But you need to specify what you want to see changed.
… if we move the verification algorithm to the securing spec it will likely deviate.
… securing mechanism checks are properly layered to put the details of the securing mechanism are pushed off to the securing spec.
… if there are mistakes in the securing spec we should fix that.

Michael Jones: in the midst to doing that. Data integrity references need to be excised. But it is within my rights to say this needs to be closed .

Brent Zundel: are you asking for it to be closed?

Michael Jones: no, I’m asking for some things be excised. How to verify securing should be in the securing specs, not here.

Joe Andrieu: confused about where status checks should be placed.

Orie Steele: status checks are validation, that happens after verification.

Manu Sporny: what Orie said ^.

Manu Sporny: Status checks are validation, not verification.

David Chadwick: status checking is part of verification, not validation.

Michael Jones: don’t know what you mean by status check.

Orie Steele: credentialStatus is the property in the data model.

Andres Uribe: ^^.

Joe Andrieu: we check the authenticity and currency (revocation). That should come back so you know what that is.

Orie Steele: part of the problem, if you’re getting a true/false from the verify algorithm.
… a version of this text could make it through but layering pieces need to be adjusted.
… trying to summarize abstract activity after the verification has succeeded.
… you might check a number of attributes of statuses, but describing all of that as a verification result we need to restate the terminology to insure the terms are used in the same way.
… e.g., the concept of the validity of the credential is ambiguous. The data integrity proof or JWT? Could be both or one or the other but not both.
… what’s a verifiable credential vs just a credential but we didn’t resolve that. Likely have to reopen that to clarify it.

Dave Longley: … or you just say which securing mechanism you accept before you run the verification check.

Manu Sporny: don’t think it’s that complicated. Mike asked defer the detail about the securing mechanism. The PR is doing that.

Orie Steele: is the algorithm to check the status concrete?

Orie Steele: is the algorithm to check the schema concrete?

Orie Steele: is the algorithm to check the validity period concrete?

Orie Steele: checking for “conforming documents” is validation….

Orie Steele: that is the problem.

Manu Sporny: the only thing where other specs are referenced is that the securing spec properly protects the payloads, and defer to the securing mechanisms for details.
… JoeAndreiu’s point about status list checking, there are two things we could do. Say that’s validation. Status checking is validation.

Paul Dietrich: +1 status checking is validation, not verification.

Manu Sporny: verification is the integrity of the data, the digital signature check.
… other options make the verification more complex.

Orie Steele: data integrity DOES validation during verification… thats part of its design.

JoeAnrieu: securing mechanism has become verification. Revocation is about the issuer no longer stands by the statement for many reasons.

Orie Steele: +1 joeandrieu.

Andres Uribe: +1 to joeandrieu.

Dmitri Zagidulin: agree that Revocation specifically is part of verification. But not expiry – that part should be in validation. (since it’s verifier-specific).

Joe Andrieu: is this thing what the issuer intended it to be.

Michael Jones: failing to distinguish between credential and verified credential is causing us problem.
… all the language about proof should be in data integrity not in the data model.

David Chadwick: if someone steals a signing key it can’t be considered verifiable. It’s got to be a part of verification. That has to include status and revocation checking. After that you can check the dates and do validation.

Orie Steele: +1 manu, it seems orthogonal.

Manu Sporny: if someone steals a key they can forge the revocation list. Doesn’t address the problem. We have what a verifiable credential is is defined in the document.

Orie Steele: -1 to saying we addressed proof fully… we did merge 1 PR.

David Chadwick: the key for the revocation list should not be the same as the key for the verifiable credential.

Manu Sporny: two things to discuss. Is status checking a part of the algorithnm, but manu is -1 to it but won’t formally object.

Orie Steele: I am also -1 to doing mixing validation and verification… and I am -1000 to doing expensive validation before verification.

Manu Sporny: the other issue is getting concrete changes adjusted.

Dave Longley: if someone steals the revocation list signing key (if it’s different) and revokes VCs that the issuer wouldn’t have revoked.

David Chadwick: doesn’t agree with manu. The key for signing the credential and the revocation list should be separate.

Sebastian Crane: there are multiple use cases. You want to confirm something is a true statement.
… plenty of cases where people want to use old expired credentials as they still have value.

Dmitri Zagidulin: expired - yes. revoked - no.

Joe Andrieu: seabass’s point can be addressed by making the verification is not just binary.
… need to define the securing algorithm separately from the verification algorithm.

Manu Sporny: Revocation lists typically use the same key as the revocation lists but it’s orthogonal to this discussion.
… the algorithm is broken up as Joe has asked. The algorithm has a top level verification, two sublevel algorithm to check the securing mechanism and one that checks the conformance of the document.

Dave Longley: maybe the verification algorithm should just say, after checking conformance and integrity … that credential status checks and other checks can be run thereafter.

Orie Steele: credential status lists are verifiable credentials, they are constrained by this proposed text.

pauld gsu: credential status verification has to be handled by the specification that defines the credential status, NOT the core data mode.

Brent Zundel: moving in the right direction, but what’s beyond concrete change suggestions are the next step.

Paul Dietrich: .

Sebastian Crane: consider an airline flight. You have a ticket that’s a VC issued by the airline.
… the airline has a lounge you can use at the airline. You use the ticket and the destination airport lounge wants to see that you had a valid ticket, but it’s no longer valid.

Dmitri Zagidulin: that’s mixing “one time use” with revocation mechanism.
those are separate.
and again, we’re talking about revocation, not expiry.

David Chadwick: the airline ticket case is that the ticket is no longer verifiable, but validation by the lounge overrules this and accepts the expired credential.

Ted Thibodeau Jr.: (I would not expect airlines, concert venues, etc., to revoke tickets upon use/redemption.).

Ted Thibodeau Jr.: +1 dmitriz.

Orie Steele: I meant that the TR track item this WG is developing is VCs, agree joe.

Joe Andrieu: status lists need not be VCs. Appreciate manu’s clarification wasn’t a part of checking the status list as a part of this algorithm.

Andres Uribe: Agree that we should add checking status list in the algorithm. Where the definition is external to the spec.

Dmitri Zagidulin: @DavidC – not quite. the ticket is STILL verifiable. but not reusable.

Joe Andrieu: should have how you check status list as a part of this algorithm.

Orie Steele: So verification is external, and status checks are external…. so this “verification algorithm” just combines external calls? seems like it might be possible to land this, if we can clarify how proof is handled.

David Chadwick: The issuer can still issue a revocation list to say everything is revoked from now on.

Manu Sporny: can be provided out of band, again it’s orthogonal. Re: next steps. Create a PR as a status check mechanism.

Joe Andrieu: +1 to a separate PR for separate discussion.

Manu Sporny: if that goes well it can be merge into the verification PR.

Orie Steele: -1 to separate PRs, this is hard enough to understand as is.

Orie Steele: lets address proof first.

Manu Sporny: waiting for concrete suggestions, as well.

Manu Sporny: It’s not clear what you’re asking for, Orie ^.

Brent Zundel: hopefully the feedback from today is helpful.

Ivan Herman: see’s Orie’s comment that proof should be addressed first.

Orie Steele: early days of the working group credential was without a proof and a verifiable credential has a proof.
… the verification algorithm is taking an abstract credential and in the case of data integrity it does not contain a proof. Yes in the case of JOSE/COSE.
… is the verification done in the spec or not? If it was only date integrity, yes, things would be fine. If we have other securing spec, the current term defs regarding proofs are problematic, and after this PR worse.

Manu Sporny: It’s not clear what Orie wants to have changed w/ proof in the spec… I don’t have enough to write a PR.
I can guess, but I don’t want to do that.

Orie Steele: Manu, a PR that removed proof from the core data model, and left it defined in data integrity, and referred to it would be acceptable.

Ivan Herman: the proof property is defined in the data integrity spec and referred to from the DM spec. It’s not defined in both places. If that is not clear in the VCDM spec, it should be.

Orie Steele: +1 ivan.

David Chadwick: We should add a status sub process to the verification algorithm.

Manu Sporny: Ok, that’s clear, thanks Orie – -1 to raising a PR that does that.. I can try another PR that makes it clear that proof is an extension mechanism. And that DI uses that extension mechanism in a specific way.

Brent Zundel: trying to get to candidate rec by mid-Dec.