Verifiable Credentials Working Group Telco — Minutes

Date: 2024-04-03

See also the Agenda and the IRC Log

Attendees

Present: Gabe Cohen, Paul Dietrich, Hiroyuki Sano, Ted Thibodeau Jr., Ivan Herman, Michael Jones, Manu Sporny, David Chadwick, Joe Andrieu, Dave Longley, Mahmoud Alkhraishi, Greg Bernstein, Jennie Meier, David Lehn, Will Abramson, Benjamin Young, Kaliya Young, Steve McCown

Regrets:

Guests:

Chair: Gabe Cohen

Scribe(s): Joe Andrieu, Gabe Cohen, Manu Sporny

Content:

Gabe Cohen: anyone for introductions?
… hearing none. work item status updates?

1. Work Item Status Updates/PRs.

Manu Sporny: BBS Cryptosuite approved for publication: https://github.com/w3c/transitions/issues/594.

Manu Sporny: couple of updates. the bbs cryptosuite was approved for publication a few days ago.
… The editors have prepped for publication. Expected to go out tomorrow.
… Moving on to bitstring status list… The spec has 21 open issues. However, the vast majority have PRs or are “during CR” issues.
… 5 we just to track horizontal reviews.
… Most issues are editorial.
… Privacy from PING and some on internationalization. We are addressing those.
… There are a few that deserve a group discussions.
… Open ended status lists.
… VC data model is moving along.
… the long pole in that tent is Jeffrey Yaskin’s editorial changes. They are fairly straightforward.
… We do need to talk about four issues and PRs for bitstring status list.
… Would you rather do that now or during PR review?

Gabe Cohen: Let’s save for the PR review.

Manu Sporny: VC Data model update: we have five pull requests outstanding. One needs some attention, especially David Chadwick’s issuee PR.

Gabe Cohen: Mike can you give an update on JOSE COSE?

Michael Jones: no before CR issues. no PRs outstanding. I think its time for CR.
… Any guidance on what it will take to prepare for CR?

Ivan Herman: You have to generate a final version for the CR using one of two options.
… 1. modify respec header and put the publication status as “CR” and then generate it. In the sense that the upper right hand corner has a menu that can generate a static html.
… . essentially export a final version.
… . What’s typically done is you put that export in a separate folder in the repo, and I take it from there.
… before that, however, you have to run through he two publication tests at the W3C.
… one that looks at format. another that looks at links.
… Doing that might highlight errors that need fixing.
… This is something that normally editors do.
… NOTE: in the header of the document, you’ll also have to put a publication date.

Michael Jones: That makes sense conceptually, but I don’t know concretely how to do it.

Gabe Cohen: No problem, I will help.

Manu Sporny: I’m also happy to help with the mechanics.

Gabe Cohen: thanks.
… for ivan do we send out something for wider review?
… If I remember correctly we sent out emailing folks that a CR has been published.

Ivan Herman: that’s my job. We (as group) have to agree its ready for PR and have a resolution on that.
… then I raise the administrative actions to move forward.
… Unfortunately, next week is an AC meeting in Hiroshima, so we should choose a date the week after at the earliest.
… and even that is tight.
… The important thing is that we need a formal resolution.

Michael Jones: Proposed resolution: vc-jose-cose is ready to go to CR.

Ivan Herman: we should agree on a date and put it in the resolution.
… Publication is usually Tue or Thu. The earliest to be safe would be on the 16th. Let’s try for the 18th of April.

Manu Sporny: I think we need exit criteria.

Ted Thibodeau Jr.: resolution should include datestamped version of document, a la https://www.w3.org/TR/2024/WD-vc-jose-cose-20240403/.

Manu Sporny: and we need to point to some kind of static version of the document.

Ivan Herman: for the resolution, the static version isn’t important, but we do need exit criteria.
… “every feature implemented by at least two implementations”.

Manu Sporny: people objected previously about date stamps.

Ivan Herman: then lets fix resolution and formally go next week.
… because of the AC meeting, this won’t slow anything down anyway.

Ted Thibodeau Jr.: draft resolution should be “draft proposal”.

Gabe Cohen: makes sense.
… move on to review of VC data model issues.

2. VCDM issue and pr processing - https://github.com/w3c/vc-data-model/issues.

Gabe Cohen: looking at issues, they all have assignees except 1360.

2.1. Add mechanism to cryptographically secure non-credential VP properties (contexts etc) (issue vc-data-model#1360)

See github issue vc-data-model#1360.

Manu Sporny: we deferred this to a future WG.

Gabe Cohen: ok. no worries there.
… current issues don’t seem pressing. there are two PRs.

Manu Sporny: can we turn to status list issues?

2.2. Registered Structured Syntax Suffix (pr vc-data-model#1456)

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

Gabe Cohen: quickly on 1456, can we close this?

2.3. Add definition of Issuee (pr vc-data-model#1468)

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

David Chadwick: Heads up. The PR exists for the issuee property, but Ted asked to move the discussion back to the issue.
… because we lose the comments in the PR when it is resolved.
… So, lets talk about the PR in the issue.

Ivan Herman: can you add the issue reference in the minutes?

David Chadwick: 1467.

See github issue vc-data-model#1467.

Gabe Cohen: might be useful to add a comment to the PR stating that.

David Chadwick: It’s there, but it’s buried in the middle.

Ted Thibodeau Jr.: let’s talk about in the issue, then we implement it in the PR (or in a new PR), which likely would be different.

Gabe Cohen: David would you like to discuss this?

2.4. Add issuee definition (issue vc-data-model#1467)

See github issue vc-data-model#1467.

David Chadwick: Yes. One of the issues, is does the issuer issue the credential directly or indirectly?
… currently the text doesn’t have anything one way or another.
… we should bring that up to the WG.
… irrespective of the definition of issuee, should we talk about direct/indirect issuees?

Ted Thibodeau Jr.: I think that’s a different discussion. Should be a different issue and we can talk about it on its own.

Manu Sporny: One of the concerns I have about adding terminology is that it becomes harder for people to talk about the system.
… I agree there is a concept of an issuee, and I wouldn’t oppose mentioning that in the spec, but changing the three-party model is problematic.
… sometimes the distinctions matter, sometimes not.

Greg Bernstein: +1.

Manu Sporny: if we add to many special terms it harms adoption because its harder to explain what we are doing.
… I don’t think the juice is worth the squeeze.
… Its fine if we want to talk about issuees as subclass of holder, but creating a new term and injecting it throughout is problematic.

Dave Longley: +1 to manu.

Ivan Herman: I feel uneasy about the whole discussion.
… As far as I can see, the term and possible changes are in a non-normative section, but we are in CR.
… we are not supposed to come up with new features without a good technical reason.

Gabe Cohen: I see a label of CR1.
… do you suggest we close this, Ivan?

Ivan Herman: non-normative language is fine, but normative language can be in a second CR but still needs a good reason. But I’m not the technical expert.

Gabe Cohen: I think with the new issue, we might benefit from seeing where the discussion might lead.

Dave Longley: I don’t think the current text has any issues wrt direct/indirect language. It was the potential introduction of issuee where that created potential problems.
… the current text is not prescriptive about those things, so we should be careful if we add that.
… I wouldn’t have an issue with talking about special cases, subclasses, etc. but probably not a good idea to modify the generic core text.

Dave Longley: +1 to avoid confusing / changing the primary roles and language around it.

Joe Andrieu: not a big fan of introducing issuee in a way that confuses the three primary roles…we talk about it at a high level and also subclassing. we know it is the holder who is presenting. we can talk about these distinctions (when the holder receives, presents)…
… our architecture we need to retain given the process.

Dave Longley: +1 to Joe.

David Chadwick: As a result, I already removed it from the diagram.
… . Also, agreed that the changes are non normative.
… The other thing is that its there because the role does exist. It’s always been there.
… because we’ve not mentioned it. I’d be happy if we don’t make it a formal definition, but say somewhere that the issuee is a subclass of holder.
… I think the term should be in the VCDM since it is used elsewhere.

Gabe Cohen: Thanks, David. Everyone, please chime in on the issue.

3. bitstring status list PRs.

Gabe Cohen: Let’s move to bitstring status list.

Manu Sporny: there are two brief updates.

3.1. credentialSubject.statusMessage localizable? (issue vc-bitstring-status-list#136)

See github issue vc-bitstring-status-list#136.

Manu Sporny: #136.
… Just a heads up. Spoke with Mahmoud yesterday about this localize status message.
… I’m going to work with Mahmoud to address this.
… I’m confident we can address this.

3.2. Add Privacy Considerations section on “Unnecessary Correlation”. (pr vc-bitstring-status-list#160)

See github pull request vc-bitstring-status-list#160.

Manu Sporny: The other one is a general heads up that there are PRs that are being raised both in the BBS crypto suite and the Bitstring status list for preventing unnecessary correlation.
… This maybe belong in the VCDM.
… Now that we do have a ZKP proposal in the CR phase, we may want to start moving some of this generalized advice to the base specification.
… The advice applies to any securing mechanism that uses unlinkable or selective disclosure.

Gabe Cohen: Manu, would you like to open an issue and tag VC-JOSE-COSE editors to sync up on language.

Manu Sporny: I think that’ll happen automatically when we raise the PR. So I think we can go straight there.

3.3. Add privacy considerations section about decoy values. (pr vc-bitstring-status-list#155)

See github pull request vc-bitstring-status-list#155.

Manu Sporny: three more issues for bitstring.
… there was a request for talking about decoy values. This was requested by PING.
… based on the discussion in that issue, I think we are coming to the conclusion that decoy values undermine privacy.
… but I’d like to get feedback from the group.
… Consider a list with 100,000 entries. Current guidance is to assign that randomly.
… In that way, any observers won’t gain insight into the population.
… but if there are decoys, that reduces the group privacy dynamic.
… this isn’t saying decoy values are bad, but in vc status list it undermines randomizing.

Joe Andrieu: I’ll look at the issue and try and understand it and provide feedback.

Dave Longley: +1 to getting more feedback on that PR.

Manu Sporny: one last issue, 151.

3.4. Remove open ended status messages because it is a layer violation (issue vc-bitstring-status-list#151)

See github issue vc-bitstring-status-list#151.

Manu Sporny: In the bistring status list, we have a feature that allows open-ended status messages, used for supply chain stuff.
… so you can have multiple states for a given VC.
… When PING was doing their review, they said “it looks like the issuer can change the amount of information that is published without notifying the subject”.
… This will lead to a privacy violation where on Day 1 the messages are “pending” and “cancelled” but on Day 2 it becomes “cancelled due to criminal activity”.
… Discussion: is it ok to keep this feature in there. It is marked as “at risk”.
… or would people would object to CR because the feature isn’t useful.

Gabe Cohen: I noticed Brent is assigned.

Manu Sporny: brent added some comments. He’s representing mesur.io. They were an advocate of that feature.

Joe Andrieu: Manu summed up my concerns well. It becomes an avenue for arbitrary content being published w/o the subject being involved. Brent’s argument was that we have same privacy as VCs. I disagree because holder is not in the loop (where they are with wrt. VCs).

Dave Longley: +1 to Joe.

Joe Andrieu: If we had a shared expectation where the user could know w/ shared states, if future version needs new state, individual could use new VC with that knowledge. What we have is a publication architecture that undermines privacy considerations put into VCs.

David Chadwick: +1 to JoeAndrieu.

Gabe Cohen: with chair hat off, can we avoid this problem by noting the status message in the credential itself.

Manu Sporny: Yes, +1 to what decentralgabe that’s what I was on the queue to suggest as well.

Joe Andrieu: Instead of having a multi-bit status list you have multiple entries… status list should be of a constrained set if it’s going to be of a set.

Dave Longley: +1 to Joe again :).

Paul Dietrich: within these status lists, there is nothing from preventing an issuer from adding additional information.

Manu Sporny: two things. If this is the concern, that privacy characteristics change after the fact. Then locking the states into the credential itself, then the holder knows the deal.
… this does make things more complicated.
… if we don’t make that change, then it is true that multi-status allows leakage after the fact.
… which is likely going to lead to objections.
… To Paul’s point, what we write in the spec with affect how people deploy, so while it is true that issuers can add anything they want, but that is very different from the WG saying this is how you can do.

Dave Longley: +1 to Manu, i think Joe’s point is that we don’t need to bless or approve of a particular approach in the standard, we can even speak against it (but we don’t control behavior).

Manu Sporny: instead we can highlight that there is a better way. we can have implementation guidance that explains this privacy risk so that issuers can apply best practices.
… we would be establishing clear guidance.

Dave Longley: a major point of VCs is not to repeat the status quo where a user communicates to a verifier some way for them to then ask an issuer for whatever they want.

Mahmoud Alkhraishi: I don’t think it would be seen negatively to commit to a static list of states.
… Let me talk with the rest of the traceability folks, but I think it can work.

Ivan Herman: q=.

Gabe Cohen: That’s it for the agenda.

3.5. Added changes to the vocabulary per #158 (pr vc-bitstring-status-list#159)

See github pull request vc-bitstring-status-list#159.

Ivan Herman: there is one PR #159 which has to be done before CR.
… this is related to mechanics of the repository.
… the vocab is wrong, we have to change the context file, … there are some changes we need to get in before CR.

Manu Sporny: +1 to making the changes Ivan is suggesting :).

Gabe Cohen: not to folks, please review 159.

Manu Sporny: You have 4 positive reviews now, Ivan. :).

Gabe Cohen: that wraps up the schedule. any other items.
… that’s a wrap. Please review the issues, especially on bitstring status list and VCDM.
… next week VC-JOSE-COSE considered for CR.