Verifiable Credentials Working Group Telco — Minutes

Date: 2024-01-17

Attendees

Present: Brent Zundel, Nicholas Steele, Wesley Smith, Manu Sporny, Gabe Cohen, Dave Longley, David Lehn, Phillip Long, Dmitri Zagidulin, Ted Thibodeau Jr.

Regrets:

Guests: Jeffrey Yasskin

Chair: Brent Zundel

Scribe(s): Manu Sporny, Dave Longley

Wesley Smith: Wes-smith has joined #vcwg.

Brent Zundel: Welcome to the VCWG meeting, agenda is work item status updates and PRs that Editor’s want us to look at. We’ll jump into issue post-CR issue processing next.
… We’ll do some triage as well. Any changes to agenda?

1. Work Item status updates/PRs.

Brent Zundel: Let’s do work item status updates.

Manu Sporny: Real quick run down. VCDM has no PRs open…

Manu Sporny: See VCDM PR-s.

Manu Sporny: No PRs open, the request to CR went in early this week. PLH / team will process probably on Friday, we’ll look at that on Monday for any possible changes.
… The vc-specs-dir will be published as a NOTE that can be updated continuously and the VCDM will be published as CR.

Manu Sporny: See VC DI PRs.

Manu Sporny: The other items are the DI specs … those are in CR now. There are no real big PRs open. There are two to look at.
… One big change we have to make to VC-DI around the interface Jeffrey Yaskin wanted us to spec out.

Manu Sporny: See ECDSA PRs.

Manu Sporny: See EDDSA PRs.

Manu Sporny: There continue to be … looking at the other cryptosuites. ECDSA has two PRs that Greg has raised, nothing major, take a look.
… EDDSA doesn’t have anything.

Manu Sporny: See BBS PRs.

Manu Sporny: There are PRs to look at, 11, on VC-DI-BBS as we do implementations on it.
… Digital Bazaar has an implementation independent from Greg’s that we’re working on.
… For ECDSA we have 5 implementations there.
… We’re trying to get the test suites aligned, getting all the statements in, etc. There’s a bit of change between the VCDM and VC-DI that is requiring us to update the test suites. We have new implementers incoming, finding out about new ones every week or so, that’s good.

Manu Sporny: See Bitstring list PRs.

Manu Sporny: Finally BitstringStatusList … we were going to be done with it and go into CR, but we found out that unfortunately the horizontal reviews weren’t filed for security and others, we only filed for TAG, we thought we filed back in June.
… Unless we’re missing something here, we need to file those.
… It could take 3 months to get those reviews back, we’ll ask nicely to try and get them sooner.
… If not, BitstringStatusList will be in limbo until then. We will probably ask implementers to implement anyway as it seems feature complete and we’re done.
… Hopefully when we get into CR we’ll have multiple independent implementations already.

Brent Zundel: Thank you Manu.
… There are a couple of PRs open on core data model, they have yet to find consensus and are really out of date, I marked both of them pending close today. If those PRs are things you’d like to engage with, please do.

Brent Zundel: See JOSE-COSE PRs.

Gabe Cohen: An update on vc-jose-cose, meeting at end of last week to process all issues opened with thanks to Ivan and Manu for detailed review. Mike’s out this week in Japan for a conference. There are some PRs opened, more PRs in next week, we’ll keep going through those issues. Hoping to get them wrapped up before the end of the month.

Brent Zundel: Great, thanks for that update. Anything else on updates?

Manu Sporny: I think everyone … there was an email that went out about this and there’s a Privacy WG charter up for vote that will presumably cover quite a bit.
… The Privacy group has an interest in the work we’re doing here and would like to engage with and have commentary on the stuff we do here in a deeper capacity. I think it’s a great idea for W3C to have an official Privacy WG. I suggest W3C members go and vote and provide input on that charter.

Brent Zundel: Yes, check it out if you haven’t yet.

2. VCDM Issue Processing.

2.1. Does the specification need a normative “Credential Specifications” section? (issue vc-data-model#1410)

See github issue vc-data-model#1410.

Brent Zundel: We’re going to start with a non-triaged issue.
… Is this something we feel is an issue that needs to be addressed, if so, who is going to work on it?

Manu Sporny: Yes, I can provide insight but Jeffrey is here too.
… We’re trying to provide guidance on things that … people who extend the data model and write specifications about credentials, like specific types of credentials like driver’s licenses, passports, coupons, whatever.
… I think Jeffrey’s concern was that there are times when it’s ok using credential type-specific processing and there may times when that’s not ok. I think Jeffrey you wanted us to give clearer guidance on that – on things you should and shouldn’t be doing. Like avoid these features / throw errors on this stuff, you should be producing a JSON schema that should be doing xyz and whether the VCDM gives guidance to people writing credential.
… specs and what they should say about type-specific processing.
… We give guidance on securing specs and this would give guidance for credential spec writers that say things like “provide a JSON schema for type-specific processors, provide a semantically immutable context, etc.”.

Jeffrey Yasskin: Yeah, that does basically capture what I’m worried about. My core worry was broader. If you secure something w/ JSON-LD and process it w/ JSON there are footguns, or vice versa, I didn’t find attacks but doesn’t mean there aren’t any. So guidance so people don’t write vulnerabilities.

Brent Zundel: It seems like this is something important to work on, is this something that could be handled editorially, or does it require normative changes?

Manu Sporny: I’m pretty sure we need normative text. This is normative text for credential specifications.

Jeffrey Yasskin: +1.

Manu Sporny: I think you should argue that the text you could write would not affect software implementations, but it would affect credential spec writers / specs. I think it’s arguable. I think we need to write normative text about it, but I don’t know how CR is handled with respect to normative text that only applies to specs and not implementations.
… That’s it.

Brent Zundel: Yes, I also don’t have a good answer there. This is something that shouldn’t implement the implementations of the core data model, that’s main concern during CR, but would affect implementations for credential type specifications.

Manu Sporny: It wouldn’t affect securing specs. It would affect credential type specs.
… Like IMS global, etc.

Manu Sporny: pdl-ASU: The HR Open standards organization is in the process of trying to move their schema for HR standards, and orgs that use them, into form to issue Verifiable Credentials. This would apply directly to 21 or more JSON objects that are a part of their resume WG’s scope. It would be valuable to them.

Jeffrey Yasskin: With respect to HR Open standards specs, I would hope that any requirements in this document either don’t affect them, or will point out security concerns that they would like to have pointed out.

Phillip Long: +1 Jeffrey.

Manu Sporny: Not opposed, we might want CR-2, CR-3, CR-4 tags to better track this. They might go back and check and we are supposed to highlight in our revision history.

Brent Zundel: Let’s create a “CR2” label for this, then.

Jeffrey Yasskin: https://www.w3.org/2023/Process-20231103/#revising-cr.

Brent Zundel: who’s willing to take a shot at this issue?

Manu Sporny: I can take the issue if Jeffrey can help me.

Jeffrey Yasskin: ok, happy to help review.

Brent Zundel: The question here – is this something we need to do? Who will work on it?

2.2. ManualRefreshService2018 - what exactly is it? (issue vc-data-model#981)

See github issue vc-data-model#981.

Brent Zundel: This is assigned to you, manu, is this still an issue?

Manu Sporny: No, unfortunately, it’s still in the spec. We do have a CCG credential refresh spec that we can point to.
… I know there are two implementations of the CCG credential refresh mechanism in production around the TruAge program.
… The proposal here would be to use that value because that value is in production, would that be enough to address this issue?

Brent Zundel: Refresh service is a reserved term, not defined?

Manu Sporny: See term definition.

Manu Sporny: We have a section for it, it’s marked at-risk.

Brent Zundel: Unless we can get an equivalent set of specs, then we’re going to remove it?

Manu Sporny: I’m reading the at-risk marker. This feature is at-risk and removed from the spec if at least two independent implementations don’t exist by the end of CR. We do have those right now for the extension point and the feature.
… So it shouldn’t be at-risk anymore, unless I’m misunderstanding something.

Brent Zundel: And those are based on the community group thing and what’s the status of that?

Manu Sporny: They might be based on the Conexxus retail standard for TruAge.
… Which reuses the CCG spec.
… Uses parts of it.
… I don’t know what we want to do here, the CCG spec continues to exist. I don’t know what we want to do here. We haven’t been very clear here about what the state needs to be.

Brent Zundel: It’s my understanding that in order to point normatively to another spec, that spec needs to be recognized as relatively mature, but does need to be stable, needs to have link that isn’t going to change, etc.

Jeffrey Yasskin: See normative references in W3C.

Brent Zundel: Bar we set as a group, is we have a number of extension points that we wrote into previous versions of the spec, and it was recognized that those extension points were valuable while things were being incubated, and those difficult to test because there are not normative specs to test extension points are one of the things we’re hoping to correct in v2. We’ve done that w/ securing specs, done w/ JSON schema, done w/ other extension points, whether or not we can claim this appropriate level of interop w/ refresh property is unclear to me.
… Getting a bit far afield – this is editorial – broader issue about refresh service, open issue, we’ll get there.

Manu Sporny: I don’t disagree with any of that. I thought this issue was about the example.
… +1 to what you said, it feels like we need get clarity … totally agree that credentialRefresh, the CCG spec itself, I don’t think you could say it’s stable, but the usage is. We would not be able to make any normative reference to the CCG spec at this time. But did we say we had to be able to do that to keep the extension point around in the spec or did we have to just say people are using it in a significant capacity?
… I don’t remember what we said the minimum bar was, but having a normative spec is certainly at / above that bar. I don’t know if that’s required vs. a clear signal it’s good enough.
… This is a bit far afield, maybe there’s another issue for this.

Brent Zundel: For this particular issue, I think the plan is to modify the example to something other than ManualRefresh2018, Manu’s assigned to make that change. If we’re ok w/ that course of action, we can move forward.

Jeffrey Yasskin: I think it would be a shame to lose the list of reserved extension points just because you can’t normatively refer to specifications for each one. IETF deals w/ this w/ “provisional” registrations. The W3C now has enough processes to have reserved extension points a registry for stuff that’s not standardized.

Brent Zundel: I like that suggestion, so let us keep that in mind as we continue having this discussion. We have a number of “at risk” statements that are tracking this for us.

2.3. Clarify what “reserved properties might be more formally defined in future versions” means (issue vc-data-model#1098)

See github issue vc-data-model#1098.

Manu Sporny: I think what we meant with this text – this was before we marked things at-risk and had the table of reserved properties…
… I think we get rid of the statement “might be more formally defined in future versions” if we remove things from the spec. Either we formally define and have a concrete thing to point to or not – and not say it might be more formally defined in the future.
… Orie said that once we make the vocab normative and so on it might be easier to achieve but that didn’t end up happening, we have a normative vocab and context, it doesn’t change the fact that we probably shouldn’t be saying…
… Now that I’m reading this … in the reserved properties section we say that the properties might be more formally defined in the future. I think we need David.

Jeffrey Yasskin: Another case where making this a registry would help you. If this is a registry with some expert review and status column that is provisional/standardized, that by itself implies that they’re expected to get more formally defined. Then things can move between different specifications, but registry deals with that for you.

Brent Zundel: Chair hat off, registries would be a sensible methodology for this WG to engage with.

Manu Sporny: We have vc-specs-dir and could have extensions put there. We do have a core vocab, but the question is whether anyone can just come along and register in that core vocab and we have to add it to the vocab officially and so on.
… Maybe that’s ok – I don’t know. A registry would be easy to deal with, I agree, but the other challenge for people who are new, we did define these extension points in 1.1.

Jeffrey Yasskin: https://www.w3.org/2023/Process-20231103/#reg-pub has “Registries can be published either as a stand-alone technical report on the Registry Track called a registry report, or incorporated as part of a Recommendation as a registry section.”, so you don’t even need to move it to the extensions report.

Manu Sporny: Some are clearly being used. There’s a question around “at what point does it become a part of the core spec”. I think we need that other issue to talk about.
… +1 to having a registry generally that would be one way of dealing with some of these properties.

Brent Zundel: We could have a “registries” section of the spec, based on what Jeffrey said above.

2.4. What is the action associated with issuing/creating a Verifiable Presentation? (issue vc-data-model#887)

See github issue vc-data-model#887.

Brent Zundel: I would love to close this.

Manu Sporny: We ran a poll and everything! It’s fine though :). We gathered data from this group.
… We previously had said … that you just “create” a presentation and be done with it.
… I think both Orie and Oliver were ok with “create” to refer to the action.

Phillip Long: +1 for create and move on.

Manu Sporny: Concrete suggestion is “go with ‘create’” define and be done with it.

Brent Zundel: Chair hat firmly on, if someone wants to come up with a strong opinion about not using “create” right now – we can go the official route if needed so they can object.
… Otherwise, let’s just go with “create”.
… You comfortable with next steps, Manu?
… Chair hat on, if you DO NOT want to create, let it be known.

Manu Sporny: Yes.

2.5. Clarify role of Holder (was: Create the new role of issuee) (issue vc-data-model#942)

See github issue vc-data-model#942.

Brent Zundel: Is there still clarification around the role of holder that is necessary?
… I feel pretty confident about what a “holder” is…
… Do we need to do anything or close it?

Manu Sporny: +1 to close it, don’t need more.

Brent Zundel: Anyone on call opposed to pending close?
… Hearing no opposition, I’ll mark it “pending close”.

2.6. Define `verification material` find replace `public keys` (issue vc-data-model#1197)

See github issue vc-data-model#1197.

Brent Zundel: I believe everywhere we’re saying “public keys” use “verification material”?
… There are four instances of “public key” to “verification material” in the spec.

Ted Thibodeau Jr.: be sure to match all plurals/singulars!

Nicholas Steele: I’ll take it.

Ted Thibodeau Jr.: Verification Material (singular) everywhere is probably ok.

Manu Sporny: All this is fine. A couple of suggestions, Nick. We use the word “cryptographic material” for public/private/secret key.
… We say “verification material” if it’s a public key or some mechanism that verifying some other proof of X (work, time) etc.
… For some people it might be weird so we could pull the definition from the VC-DI spec and put it in the VCDM. So we say “when we say verification material, it’s anything to verify a proof” that includes public keys, inputs to an algorithm, anything like that.
… It doesn’t make it that much more difficult and I can help with the PR on how to do that.

2.7. Definition of evidence should align with NIST (issue vc-data-model#926)

See github issue vc-data-model#926.

Brent Zundel: This was raised by Orie, it is assigned to MikeP, the issue recommends where possible, that we should align w/ NIST definition (and link to it).

Manu Sporny: https://csrc.nist.gov/glossary/term/evidence.

Manu Sporny: NIST has a glossary where they define “evidence” and I think it aligns with our usage of it. I don’t know if we even … NIST also has entries in their glossary where they have multiple different definitions.
… NIST understands that when they use a word even they are not consistent in how it’s used across every document they have. They have all of the definitions cross reference. Luckily with “evidence” there is just one definition and it seems to align.
… We could point to the NIST definition but I don’t know what that would accomplish.

Jeffrey Yasskin: Just a suggestion, it seems like one of the “at risk” things that doesn’t have a firm spec behind it, could put it in registry entry, don’t have to worry about it for this document.

Manu Sporny: I think this issue is just about our use of the word “evidence”, not the extension point. I agree with you Jeffrey for the extension point, but I think this is just about how we use the word.

Brent Zundel: Of the 30-odd uses of the term, only two are related to the extension point.

Jeffrey Yasskin: One is in the introduction / non-normative.

Brent Zundel: It is my opinion, that we’re not using “evidence” in a way that’s outside the standard english definition. While it would be simple to link to NIST, I don’t think there’s anyone to do here.
… Anyone opposed to marking this “pending close”?

Ted Thibodeau Jr.: just for fun… https://csrc.nist.gov/glossary/term/public_key … https://csrc.nist.gov/glossary/term/secret_key … https://csrc.nist.gov/glossary/term/cryptographic_material …

Phillip Long: +1 to pending close.

Manu Sporny: +1 to pending close.

Brent Zundel: thanks everyone for your time today!