14:31:58 <RRSAgent> RRSAgent has joined #vcwg
14:32:02 <RRSAgent> logging to https://www.w3.org/2024/06/12-vcwg-irc
14:32:02 <Zakim> RRSAgent, make logs Public
14:32:03 <Zakim> please title this meeting ("meeting: ..."), ivan
14:32:12 <ivan> Meeting: Verifiable Credentials Working Group Telco
14:32:12 <ivan> Date: 2024-06-12
14:32:12 <ivan> Agenda: https://www.w3.org/events/meetings/1d0b6bbc-baef-4450-9ec3-72adeaf498a0/20240612T110000/
14:32:12 <ivan> chair: brent
14:32:13 <ivan> ivan has changed the topic to: Meeting Agenda 2024-06-12: https://www.w3.org/events/meetings/1d0b6bbc-baef-4450-9ec3-72adeaf498a0/20240612T110000/
14:32:14 <ivan> regrets: msporny, dlongley, Wes-Smith
14:54:26 <brent> brent has joined #vcwg
14:58:21 <TallTed> TallTed has joined #vcwg
14:59:11 <ivan> present+ brent
14:59:14 <ivan> present+
14:59:42 <hsano> hsano has joined #vcwg
15:00:45 <ivan> present+ tallted, hsano
15:01:02 <ivan> present+ bigbluehat
15:02:00 <ivan> present+ davidc
15:02:11 <DavidC> DavidC has joined #vcwg
15:02:17 <ivan> present+ phil
15:02:23 <PL-ASU> PL-ASU has joined #vcwg
15:02:25 <DavidC> present+
15:02:29 <PL-ASU> present+
15:02:29 <ivan> present+ selfissued
15:02:53 <ivan> present+ will
15:02:56 <selfissued> selfissued has joined #vcwg
15:03:05 <bigbluehat> bigbluehat has joined #vcwg
15:03:10 <selfissued> present+
15:03:53 <ivan> present+ dmitriz
15:04:13 <ivan> present+ gabe
15:04:22 <decentralgabe> decentralgabe has joined #vcwg
15:04:25 <decentralgabe> present+
15:04:28 <ivan> q+
15:04:50 <ivan> q-
15:05:13 <decentralgabe> scribe+
15:05:34 <dmitriz> dmitriz has joined #vcwg
15:05:54 <ivan> guest+ anthony
15:06:05 <decentralgabe> brent: 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!
15:06:23 <decentralgabe> ... anyone who would like to recommend additions to the agenda?
15:06:34 <JoeAndrieu> JoeAndrieu has joined #vcwg
15:06:37 <ivan> present+ mccown
15:06:41 <ivan> present+ joe
15:06:52 <ivan> present+ jennie
15:06:53 <brent> Topic: media types
15:06:58 <smccown> smccown has joined #vcwg
15:08:19 <decentralgabe> ... 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
15:08:25 <WillAbramson> WillAbramson has joined #vcwg
15:08:32 <bigbluehat> present+
15:08:59 <ivan> https://github.com/w3c/vc-data-model/pull/1478
15:09:05 <decentralgabe> ... 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
15:09:52 <decentralgabe> ... 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
15:10:11 <JennieM> JennieM has joined #vcwg
15:10:21 <brent> Topic: Work Item Status Updates/PRs
15:10:24 <decentralgabe> ... no one on the queue. moving to the next topic... work item status updates/pull requests
15:11:03 <decentralgabe> ... please jump on the queue if you have items you would like to cover
15:11:27 <decentralgabe> selfissued: we need to update the media types in vc-jose-cose and I assume data-integrity
15:11:49 <decentralgabe> brent: will merge the media types PR after the call and after conflicts are resolved
15:11:59 <decentralgabe> selfissued: Gabe or I need to update vc-jose-cose accordingly
15:12:32 <ivan> present+ steele
15:12:58 <decentralgabe> brent: for specs in CR have not gotten a ton of feedback, but some. test suites are next. then working toward a proposal
15:13:14 <ivan> q+
15:13:16 <decentralgabe> ... we have accomplished a lot. 9 rec track specs. that's a lot of work. big props to you all!
15:13:28 <ivan> q-
15:13:40 <brent> subtopic: https://github.com/w3c/vc-data-model/pull/1498
15:14:34 <decentralgabe> ... 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
15:15:05 <decentralgabe> ... all of those PRs have approvals except 1498. David would like to keep it in the spec. please state your position
15:15:26 <ivan> i/brent: for specs/Topic: VCDM Issues and PR-s/
15:16:05 <decentralgabe> DavidC: 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.
15:17:10 <decentralgabe> ... 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
15:17:35 <bigbluehat> q+ to ask about test and use
15:17:40 <decentralgabe> brent: David makes a good case - there are a couple implementations. what do folks think?
15:17:45 <brent> ack bigbluehat
15:17:45 <Zakim> bigbluehat, you wanted to ask about test and use
15:18:15 <decentralgabe> bigbluehat: 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?
15:18:31 <TallTed> q+
15:19:04 <DavidC> q+
15:19:06 <ivan> q+
15:19:36 <decentralgabe> brent: 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
15:19:57 <brent> ack ivan
15:20:53 <decentralgabe> ivan: 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
15:20:58 <brent> ack TallTed
15:22:03 <decentralgabe> TallTed: 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.
15:22:16 <decentralgabe> ... unless David is participating with another group, I do not think it carries the same weight
15:22:28 <brent> ack DavidC
15:22:31 <decentralgabe> q+
15:23:34 <bigbluehat> q+ to ask about testing "rigor" related to extensions generally and this one specifically
15:23:41 <decentralgabe> DavidC: 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
15:23:42 <decentralgabe> q-
15:24:17 <decentralgabe> ... 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.
15:24:26 <brent> ack bigbluehat
15:24:26 <Zakim> bigbluehat, you wanted to ask about testing "rigor" related to extensions generally and this one specifically
15:26:19 <decentralgabe> bigbluehat: 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?
15:27:13 <decentralgabe> brent: 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
15:27:51 <decentralgabe> ... 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.
15:28:28 <bigbluehat> q+ to clarify what's being tested based on what's in the spec
15:28:40 <decentralgabe> ... 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
15:29:07 <brent> ack bigbluehat
15:29:07 <Zakim> bigbluehat, you wanted to clarify what's being tested based on what's in the spec
15:29:57 <decentralgabe> bigbluehat: 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
15:31:10 <decentralgabe> brent: 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.
15:31:38 <decentralgabe> ... 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.
15:32:03 <decentralgabe> ... last time we had the test suite but folks came and said 'yeah well but!' and we need to surpass that bar this time
15:32:12 <DavidC> q+
15:32:37 <brent> ack DavidC
15:32:42 <decentralgabe> ... 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
15:33:12 <decentralgabe> DavidC: 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
15:33:23 <decentralgabe> q+
15:33:26 <dmitriz> just to be clear - will termsOfUse still remain in the @context?
15:33:30 <decentralgabe> brent: how do folks feel about that?
15:33:40 <brent> ack decentralgabe
15:33:55 <ivan> s/@context/`@context`/
15:34:25 <decentralgabe> decentralgabe: we are planning on implementing at TBD. how can I show that?
15:34:42 <decentralgabe> brent: are you planning on implementing this as EBSI are?
15:34:52 <decentralgabe> decentralgabe: I will take a closer look at the PR.
15:35:27 <decentralgabe> brent: let's continue with David's suggestion. with that we have 1 more PR to look at quickly, then issues.
15:35:31 <brent> subtopic: https://github.com/w3c/vc-data-model/pull/1501
15:35:49 <ivan> https://github.com/w3c/vc-data-model/issues/1481
15:36:53 <decentralgabe> ... 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.
15:37:14 <decentralgabe> ... want to give folks a chance to look at it if they have not yet. it will be merged.
15:37:26 <brent> Topic: VCDM Issue Processing
15:37:31 <brent> https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+-label%3Afuture+sort%3Aupdated-asc
15:37:57 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/1239
15:38:14 <decentralgabe> ... 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.
15:38:49 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/1462
15:39:23 <decentralgabe> ... Ivan will take this. next we have 1462 - we have already talked about w.r.t. media types. will be closed soon.
15:39:32 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/1479
15:39:41 <PL-ASU> PL-ASU has joined #vcwg
15:39:53 <PL-ASU> present+
15:40:02 <dmitriz> (still workin' on it!) :)
15:40:15 <decentralgabe> ... 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?
15:40:52 <decentralgabe> dmitriz: currently working on an example at Digital Credentials Consortium. Should be done end of next week, if that's not too late
15:40:58 <decentralgabe> brent: sounds good - look forward to seeing that
15:41:10 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/1437
15:41:56 <DavidC> q+
15:42:00 <decentralgabe> ... 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
15:42:10 <brent> ack DavidC
15:42:11 <decentralgabe> ... question to the group - who will reach out to folks from EBSI?
15:43:08 <decentralgabe> DavidC: 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.
15:43:34 <decentralgabe> brent: 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.
15:43:54 <decentralgabe> ... not hearing anyone say they work closely with EBSI, at this point DavidC you are best positioned to do this. Would be appreciated.
15:43:59 <decentralgabe> DavidC: ack will do this
15:44:05 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/1485
15:44:14 <ivan> q+
15:44:22 <brent> ack ivan
15:44:22 <decentralgabe> brent: Next 1485 - VC JWT examples are out of data. we have 3 folks assigned. I believe a solution is under way
15:44:23 <decentralgabe> q+
15:44:57 <decentralgabe> ivan: Gabe has a PR in respec-vc (https://github.com/w3c/respec-vc/pull/30) which will solve this
15:45:07 <brent> ack decentralgabe
15:45:30 <decentralgabe> decentralgabe: linked the PR that will fix this. I will update the examples after it is merged.
15:45:55 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/1500
15:46:19 <decentralgabe> brent: beautiful! 1481 - talked about it already, have a PR in place (re: JADES). the last issue!! 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
15:46:35 <decentralgabe> ... 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
15:46:42 <ivan> q+
15:46:48 <brent> ack ivan
15:47:35 <decentralgabe> ivan: 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.
15:47:39 <bigbluehat> q+
15:48:07 <brent> ack bigbluehat
15:48:09 <decentralgabe> ... 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.
15:49:01 <decentralgabe> bigbluehat: 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
15:49:21 <ivan> q+
15:49:35 <decentralgabe> ... this is really what is already in the VCDM spec, but not a handy/quick reference, like what is in the v2 vocab documentation.
15:50:07 <decentralgabe> ... 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.
15:50:10 <brent> ack ivan
15:50:44 <bigbluehat> q+ to mostly agree ;)
15:50:46 <decentralgabe> ivan: 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.
15:51:09 <brent> ack bigbluehat
15:51:09 <Zakim> bigbluehat, you wanted to mostly agree ;)
15:51:18 <decentralgabe> brent: 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?
15:51:52 <decentralgabe> bigbluehat: 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?
15:52:03 <dmitriz> q+
15:52:29 <decentralgabe> ... 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
15:52:39 <decentralgabe> brent: thank you and thanks for volunteering
15:52:41 <brent> ack dmitriz
15:53:11 <decentralgabe> dmitriz: if the poster's aim is documentation, could we point him to the VC 2.0 JSON Schema? each term has documentation there
15:53:18 <decentralgabe> ivan: yes, great idea
15:53:31 <brent> https://github.com/w3c/vc-data-model/blob/main/schema/verifiable-credential/verifiable-credential-schema.json
15:53:42 <decentralgabe> brent: yes it does exist. not sure if it is the answer but let's suggest it
15:53:46 <gkellogg> gkellogg has joined #vcwg
15:53:56 <decentralgabe> ... any other comments before we close?
15:55:11 <decentralgabe> ... 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
15:55:34 <selfissued> q+
15:55:34 <decentralgabe> ... 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
15:55:44 <decentralgabe> ... pleasure working with you all - thank you!
15:55:46 <selfissued> https://github.com/w3c/vc-jose-cose/pull/277
15:55:47 <brent> ack selfissued
15:56:13 <selfissued> https://www.specref.org/?q=RFC9596
15:56:27 <decentralgabe> selfissued: 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?
15:56:43 <decentralgabe> ivan: it should be automatic. it should take a few days to update (was just updated yesterday).
15:56:59 <decentralgabe> ... if not yet there on monday let's open an issue. in theory this should be done automatically
15:57:05 <decentralgabe> selfissued: ack
15:57:28 <decentralgabe> brent: look forward to seeing you all next week!
15:57:30 <ivan> rrsagent, draft minutes
15:57:32 <RRSAgent> I have made the request to generate https://www.w3.org/2024/06/12-vcwg-minutes.html ivan
17:37:46 <gkellogg> gkellogg has joined #vcwg
17:54:03 <gkellogg> gkellogg has joined #vcwg
18:06:44 <jyasskin> jyasskin has joined #vcwg
18:25:18 <gkellogg> gkellogg has joined #vcwg
18:47:19 <gkellogg> gkellogg has joined #vcwg
18:55:53 <Zakim> Zakim has left #vcwg
19:11:45 <gkellogg> gkellogg has joined #vcwg
19:32:38 <gkellogg> gkellogg has joined #vcwg
19:40:33 <gkellogg> gkellogg has joined #vcwg
21:10:20 <gkellogg> gkellogg has joined #vcwg
21:26:38 <gkellogg> gkellogg has joined #vcwg
21:48:22 <gkellogg> gkellogg has joined #vcwg
22:06:41 <gkellogg> gkellogg has joined #vcwg
22:30:48 <gkellogg> gkellogg has joined #vcwg
22:44:39 <gkellogg> gkellogg has joined #vcwg
23:03:22 <gkellogg> gkellogg has joined #vcwg
23:26:01 <gkellogg> gkellogg has joined #vcwg
23:44:22 <gkellogg> gkellogg has joined #vcwg