Verifiable Credentials Working Group Telco — Minutes

Date: 2024-06-12

See also the Agenda and the IRC Log

Attendees

Present: Brent Zundel, Ivan Herman, Ted Thibodeau Jr., Hiroyuki Sano, Benjamin Young, David Chadwick, Phillip Long, Michael Jones, Will Abramson, Dmitri Zagidulin, Gabe Cohen, Steve McCown, Joe Andrieu, Jennie Meier, Nicholas Steele

Regrets: Manu Sporny, Dave Longley, Wesley Smith

Guests: Anthony Lopreiato

Chair: Brent Zundel

Scribe(s): Gabe Cohen

Content:

Brent Zundel: agenda review, starting with media types, then status updates for work items - pull requests that are open, then the core data model. only 10 open issues. many of which we have PRs for. we are very close!
… anyone who would like to recommend additions to the agenda?

1. media types.

Brent Zundel: last time we talked about media types we were unsure the folks at IETF would register the types we wanted. for multiple suffixes, the document has much back and forth. considered pulling back and a simpler approach.

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

Brent Zundel: instead considering application/vp and application/vc. we finally heard back and heard “no” for multiple suffixes. may change in the future. at this point the media types we have been wanting are not able to be registered.
… we have a PR #1479 - our media types are application/vc and application/vp. it is fully approved. happy to talk about it if folks want. otherwise, let’s merge it has been open a while.

2. Work Item Status Updates/PRs.

Brent Zundel: no one on the queue. moving to the next topic… work item status updates/pull requests.
… please jump on the queue if you have items you would like to cover.

Michael Jones: we need to update the media types in vc-jose-cose and I assume data-integrity.

Brent Zundel: will merge the media types PR after the call and after conflicts are resolved.

Michael Jones: Gabe or I need to update vc-jose-cose accordingly.

Brent Zundel: for specs in CR have not gotten a ton of feedback, but some. test suites are next. then working toward a proposal.
… we have accomplished a lot. 9 rec track specs. that’s a lot of work. big props to you all!

2.1. Removes the termsOfUse section from the specification and reserves the property. (pr vc-data-model#1498)

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

Brent Zundel: looking at PR 1498. Manu raised this to help clean up the “this might be removed” type of extension points. if we can show there are specs/impls using this extension we can keep it in the spec. if we cannot claim others are using them, we will keep them as reserved terms but they won’t formally be a part of the spec.
… all of those PRs have approvals except 1498. David would like to keep it in the spec. please state your position.

David Chadwick: there is terms of use in the VC and terms of use in the VP. in the latter case don’t believe anyone has documented it–happy to remove. for issuing, several groups have implemented it, like EBSI. they have multiple independent implementations of it.
… the v1 termsOfUse had ‘dummy’ VCs/examples. I spent time researching what EBSI had done, and documented that. Note I am not a member of EBSI. I believe it should stay, since there are at least 2+ implementers of the feature. for VPs, I believe it can be removed.

Brent Zundel: David makes a good case - there are a couple implementations. what do folks think?

Benjamin Young: when we mention that it is in use, do those features need to be analyzed in test suites, or can we point to them in the wild, in docs, etc?

Brent Zundel: I have my own opinion on this but would love to hear from folks in the group. my take is the WG said we would demonstrate multiple implementations of each feature, and do that by the test suite. so yes it would be useful to have tests for this.

Ivan Herman: for the W3C requirement. we have had cases for terms in a vocab..if there are no actionable semantics on the term - just a vocab requirement - there should be 2 implementations. I don’t know whether the usage has additional semantics around it.

Ted Thibodeau Jr.: usually evidence of implementation comes from the implementer. not usually a 3rd party reportage of that usage. part of the reason for that is unless the implementer submits it, there’s no guarantee it will survive the next week, let alone the spec. I question whether it is the right thing to allow 3rd party usage. they could submit it.
… unless David is participating with another group, I do not think it carries the same weight.

David Chadwick: I believe every impl that is using the test suite will conform. If you don’t recognize the identifier ‘termsOfUse’ you can ignore it. It is a good test … more preferable that the EBSI folks come and say this themselves.
… in the original PR, someone pointed me to the EBSI people. there have been folks here more familiar than I was. only because I was editor of the PR that I went and documented it.

Benjamin Young: I linked to one of the tests we have now. there is a test that only Digital Bazaar is passing now. question around testing rigor. if just vocab terms, then these can be there. the test will be the same. even if the extension is in the future. looking for feedback from the group - is what we’re testing now sufficient? would it change depending on how termsOfUse is defined?

Brent Zundel: in the past there have been concerns raised about the end-to-end interoperable nature of the VCDM. with all extension points, including, at the time, the proof extension point. v1 eeked by in spite of folks voicing those concerns. going into this version those concerns were re-raised.
… led to the intention we’ve been following all along. for these extension points to stick around there need to be actual implementations. testing it simply as a vocabulary item is not sufficient - my understanding and the group’s.
… for this particular item, the path we’re on, if folks that have implemented this come to the group and show their implementations, then the group would be OK keeping the feature. seeing it exists and pointing to it is not sufficient.

Benjamin Young: want to clarify, the automated tests focus on the ‘must’ language in the spec. since we’re testing json docs and not human brains, we are just saying ‘the thing doesn’t choke’ - if there is more wanted EBSI/whomever would need to come and demonstrate usage.

Brent Zundel: here’s how I expect the conversation to go: we have a test suite, which tests acceptance of the data model. for extension points, which in the past were tested this way, we see the data model and its limitations, but where are the impls? the specs we can follow? can it truly be end-to-end interoperable.
… we can say it has vc-json-schema, multiple ways to secure the spec, etc. we can point to specs in addition to the report generated by the test suite.
… last time we had the test suite but folks came and said ‘yeah well but!’ and we need to surpass that bar this time.
… so what do we do about termsOfUse? do we remove it? or do we keep it in the spec and hope that the folks from EBSI come and demonstrate its usage.

David Chadwick: I would like to suggest another way: we leave terms of use for issuance, remove for holder/presentation. we try to make contact with EBSI to make their case.

Dmitri Zagidulin: just to be clear - will termsOfUse still remain in the @context?

Brent Zundel: how do folks feel about that?

Gabe Cohen: we are planning on implementing at TBD. how can I show that?

Brent Zundel: are you planning on implementing this as EBSI are?

Gabe Cohen: I will take a closer look at the PR.

Brent Zundel: let’s continue with David’s suggestion. with that we have 1 more PR to look at quickly, then issues.

2.2. Add reference to JAdES standard in Ecosystem Compatability. (pr vc-data-model#1501)

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

See github issue vc-data-model#1481.

Brent Zundel: pull request 1501. the related issue is 1481. 1481 says – we have a JADES impl of securing a VC, and think the spec should note that. this PR adds a link to JADES for ecosystem compatibility – already has anoncreds, ACDC, many other ‘vc-like’ things that should be compatible with this spec.
… want to give folks a chance to look at it if they have not yet. it will be merged.

3. VCDM Issue Processing.

Brent Zundel: https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+-label%3Afuture+sort%3Aupdated-asc.

3.1. expires header for https://www.w3.org/2018/credentials/v1 is in the past (issue vc-data-model#1239)

See github issue vc-data-model#1239.

Brent Zundel: moving on to the last topic of the day - VCDM issue processing. there are 7 issues. let’s look briefly at 1239 - it’s something that needs to be done before PR. need to fix the expires header for our links. Ivan will take this.

3.2. Revisit Verifiable Credential media types (issue vc-data-model#1462)

See github issue vc-data-model#1462.

Brent Zundel: next we have 1462 - we have already talked about w.r.t. media types. will be closed soon.

3.3. Consider explicitly allowing/recommending language maps for use in internationalisation. (issue vc-data-model#1479)

See github issue vc-data-model#1479.

Phillip Long: PL-ASU has joined #vcwg.

Dmitri Zagidulin: (still workin’ on it!) :).

Brent Zundel: next we have 1479 … Consider explicitly allowing/recommending language maps for use in internationalisation. we had a conversation about this in May and then again later in May. Dmitri and Mahmoud are working on it. What’s the status?

Dmitri Zagidulin: currently working on an example at Digital Credentials Consortium. Should be done end of next week, if that’s not too late.

Brent Zundel: sounds good - look forward to seeing that.

3.4. Remove at risk issue markers for property extension points. (issue vc-data-model#1437)

See github issue vc-data-model#1437.

Brent Zundel: next - 1437 - remove at risk issue markers for property extension points. related to the TOU conversation we just had. all extension points we have clarification. those PRs are either merged or ready to merge. we have a path for termsOfUse–we will axe the VP part, open the doors for hearing about impls for VCs.
… question to the group - who will reach out to folks from EBSI?

David Chadwick: I can try to do that. Is there someone in the group better placed to do this? The PR that is there will need editing, who will do that? We can do that now and merge it, or we can wait and hear back from EBSI.

Brent Zundel: manu has been assigned to address this, will leave it to him whether or not to raise a 2nd PR for termsOfUse in VPs or see if we can get EBSI folks here.
… not hearing anyone say they work closely with EBSI, at this point DavidC you are best positioned to do this. Would be appreciated.

David Chadwick: ack will do this.

3.5. VC-JWT examples are out-of-date (issue vc-data-model#1485)

See github issue vc-data-model#1485.

Brent Zundel: Next 1485 - VC JWT examples are out of data. we have 3 folks assigned. I believe a solution is under way.

Ivan Herman: Gabe has a PR in respec-vc (https://github.com/w3c/respec-vc/pull/30) which will solve this.

Gabe Cohen: linked the PR that will fix this. I will update the examples after it is merged.

3.6. Could not define “name” and “description” as attributes of my type (issue vc-data-model#1500)

See github issue vc-data-model#1500.

Brent Zundel: beautiful! Issue 1500 - “Could not define “name” and “description” as attributes of my type” - question raised by an implementer. may not be a member of our group or even the W3C.
… I believe their question is pretty much answered. this issue is not calling for any changes to the spec. if that read is not correct please correct me.

Ivan Herman: You are not wrong. He did respond but is not happy with our answer. There is a feature in the LD context that has been used extensively. It does not let you define your own term where it has been defined in the document (protected). He wants to make his own spec, and is unhappy he cannot do that.
… the terms in question, however, are not terms that we have defined, but have been defined by schema.org. It is not very wise to re-define these terms anyway. I am not sure what we can answer. Maybe Benjamin has a better answer.

Benjamin Young: yes, this is a common misconception. vocab vs context. what he wants is documentation on what is in our context file. what he is referencing is the new vocab terms unique to the v2 data model–which are not all the terms in the context file. he wants a more complete set of data points around what these fields are.
… this is really what is already in the VCDM spec, but not a handy/quick reference, like what is in the v2 vocab documentation.
… he would have to do this in a different way instead of re-creating terms, which is what he was doing. a bit of a heavy-handed change. it is a common misunderstanding about vocab documentation.

Ivan Herman: we have a more general problem - which is not our problem - but the JSON-LD people - we have no way of properly documenting LD contexts. good documentation here would be very useful. this is not up to this working group to deal with.

Brent Zundel: I am not hearing anyone say we have to change anything here. also not hearing the opener of the issue can walk away satisfied. what can we do?

Benjamin Young: happy to follow up with the issue. I agree there is missing documentation in a ‘cheat-sheet’ style. the VCDMv2 is kind of that documentation, but not quickly digestible. what can I/not do with it?
… it is a tool that has been attempted by many companies. Spruce has one, YAML to Vocab almost has one (others too). There is not anything actionable for this group to do relative to the data model.

Brent Zundel: thank you and thanks for volunteering.

Dmitri Zagidulin: if the poster’s aim is documentation, could we point him to the VC 2.0 JSON Schema? each term has documentation there.

Ivan Herman: yes, great idea.

Brent Zundel: See JSON Schema for VCDM.

Brent Zundel: yes it does exist. not sure if it is the answer but let’s suggest it.
… any other comments before we close?
… we have nearly completed all open issues on the data model. we will be in a position where we are ready to go to PR modulo the test suites reporting that there are independent impls of each feature. expect in the coming weeks less focus on the core data model. more focus on controller doc, the only in-flight-spec not yet in CR.
… expect us to talk more about test suites, and impl feedback. at TPAC hoping to move all into PR, or a 2nd CR phase if needed.
… pleasure working with you all - thank you!

4. Update reference for COSE “typ” (type) Header Parameter (pr vc-jose-cose#277)

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

Michael Jones: https://www.specref.org/?q=RFC9596.

Michael Jones: there is a PR in vc-jose-cose that updates a reference to use the new RFC (rather than a draft). it is failing because we are dependent on something called specref which is not up-to-date. is this automatically updated or do we need to do a PR to fix that?

Ivan Herman: it should be automatic. it should take a few days to update (was just updated yesterday).
… if not yet there on monday let’s open an issue. in theory this should be done automatically.

Michael Jones: ack.

Brent Zundel: look forward to seeing you all next week!