15:36:06 <RRSAgent> RRSAgent has joined #vcwg
15:36:10 <RRSAgent> logging to https://www.w3.org/2024/02/14-vcwg-irc
15:36:10 <Zakim> RRSAgent, make logs Public
15:36:41 <Zakim> please title this meeting ("meeting: ..."), ivan
15:36:41 <ivan> Meeting: Verifiable Credentials Working Group Telco
15:36:41 <ivan> Date: 2024-02-14
15:36:41 <ivan> Agenda: https://www.w3.org/events/meetings/0d074559-1457-4540-857b-24b1be7a8d7f/20240214T110000/
15:36:41 <ivan> chair: brent
15:36:41 <ivan> ivan has changed the topic to: Meeting Agenda 2024-02-14: https://www.w3.org/events/meetings/0d074559-1457-4540-857b-24b1be7a8d7f/20240214T110000/
15:55:52 <ivan> present+
15:57:56 <brent> brent has joined #vcwg
16:01:13 <TallTed> TallTed has joined #vcwg
16:01:29 <ivan> present+ TallTed, brent
16:02:39 <ivan> present+ gabe
16:02:45 <ivan> present+ pauld_gs1
16:02:52 <ivan> present+ selfissued
16:03:06 <decentralgabe> decentralgabe has joined #vcwg
16:03:11 <selfissued> selfissued has joined #vcwg
16:03:11 <decentralgabe> present+
16:03:12 <selfissued> present+
16:03:23 <ivan> present+ manu
16:03:54 <ivan> present+ dlongley
16:06:58 <decentralgabe> scribe+
16:07:06 <decentralgabe> brent: agenda for today is to go over work status updates, look at PRs, then go for issue processing on the core data model
16:07:06 <decentralgabe> selfissued: there are a few vc-jose-cose issues that would be good to discuss
16:07:06 <decentralgabe> brent: sounds good as a part of our 2nd topic
16:07:39 <manu> q+
16:07:44 <decentralgabe> ... happy valentines day! let's jump into work status updates.
16:07:49 <brent> ack manu
16:08:32 <ivan> present+ dmitriz
16:08:36 <brent> Topic: Work Item Status Updates
16:08:39 <manu> subtopic: https://github.com/w3c/vc-data-integrity/pull/244
16:08:53 <decentralgabe> manu: processed a number of PRs across VCDM, DI, cryptosuites. need to talk about Jeffery Yaskin's PR (#244) to create an interface for all DI specs
16:09:15 <manu> https://github.com/w3c/vc-di-ecdsa/pull/57
16:10:05 <decentralgabe> ... that broke interfaces b/w DI specs. trying to get them re-aligned. 2 PRs - 1 for DI, 1 for ECDSA-SD. heads up to the group we're trying to align these interfaces
16:10:43 <decentralgabe> ... some misalignment on how they would work. have a plan forward to address this. plan is for an interface in all DI specs that all have 'functions' each cryptosuite executes to create/verify proofs. a standard interface.
16:10:55 <decentralgabe> ... the functions to expose was under debate. based on discussion we will only define 2 functions on the interface: create proof and verify proof.
16:11:45 <ivan> q+
16:11:46 <decentralgabe> ... will require changes to algorithms across these specs. pushing more details into the cryptosuite specs. less in DI the spec. should not impact implementations. we know we will go through a 2nd CR. the interfaces are changing, not the algorithms.
16:12:01 <decentralgabe> ... are there any concerns/guidance before I start making those changes?
16:12:05 <dlongley> +1 to those changes
16:12:08 <brent> ack ivan
16:12:09 <selfissued> q+
16:12:19 <manu> q+
16:12:26 <manu> q-
16:12:32 <decentralgabe> ivan: presume that ECDSA then EDDSA and then DS?
16:12:35 <decentralgabe> manu: correct
16:12:45 <brent> ack selfissued
16:12:47 <ivan> s/DS/BBS/
16:13:06 <manu> q+
16:13:10 <decentralgabe> selfissued: think it takes us down a bad path to build interfaces that no one will build. we should not be creating APIs, that is out of scope
16:13:16 <brent> ack manu
16:13:26 <decentralgabe> manu: agree that APIs are out of scope, but that's not what we're creating here
16:13:31 <decentralgabe> selfissued: that is what you described
16:14:01 <decentralgabe> manu: have discussed this before. we're discussing interfaces, which is what the w3c does, not in web IDL which would define an API. implementations are implementing in this way. they are abstract, not concrete web IDL interfaces
16:14:12 <decentralgabe> selfissued: I am missing context. what else are you planning to do?
16:14:30 <decentralgabe> manu: changing the interfaces that we had months ago, which Jefferey asked for. that PR had weeks of review and already went in
16:14:56 <decentralgabe> brent: any other comments?
16:15:07 <decentralgabe> manu: no - that's the major PR I need feedback on
16:15:09 <decentralgabe> #244
16:15:30 <decentralgabe> brent: vc-jose-cose update?
16:15:35 <decentralgabe> q+
16:15:42 <dlongley> scribe+
16:15:55 <brent> subtopic: vc-jose-cose
16:16:00 <brent> ack decentralgabe
16:16:17 <dlongley> decentralgabe: We merged a number of PRs that were open for review and had approvals the past few days, mostly editorial.
16:16:57 <dlongley> decentralgabe: There are 6 PRs open, a few opened yesterday, a few long standing around examples. There is a problem with some rendering Orie had worked on. The editors discussed and found a path forward. We will remove Orie's custom logic in the meantime and unblock some issues.
16:17:12 <dlongley> decentralgabe: We're making progress on the pre-CR list and we have 13 open that have 4-5 PRs.
16:17:21 <dlongley> decentralgabe: That's it unless Mike has anything to add.
16:17:26 <dlongley> scribe-
16:17:47 <decentralgabe> selfissued: created an easy PR yesterday. appreciate Brent adding some PRs. see some suggestions were merged, need to take another look
16:18:39 <decentralgabe> brent: yes, this is on conformance classes. fixing a build issue. would appreciate feedback on #231
16:18:50 <ivan> q+
16:18:55 <decentralgabe> q+
16:18:56 <selfissued> https://github.com/w3c/vc-jose-cose/pull/231
16:19:03 <brent> ack ivan
16:19:29 <decentralgabe> ivan: agreed to bring JOSE back into the mix. haven't seen that yet
16:19:46 <decentralgabe> selfissued: yes, that's assigned to me and I will work on it this week. I have been traveling but now am domestic for a month.
16:19:50 <decentralgabe> ivan: thanks
16:19:52 <TallTed> s/JOSE/JWT/
16:19:55 <brent> ack decentralgabe
16:19:57 <dlongley> scribe+
16:20:05 <selfissued> Can someone look at https://github.com/w3c/vc-jose-cose/actions/runs/7903974484/job/21573159514?pr=231 and indicate what's breaking the build?
16:20:19 <decentralgabe> https://github.com/w3c/vc-jose-cose/pull/220
16:20:20 <dlongley> decentralgabe: One thing I forgot to mention -- there's some outstanding discussion around 220 ... around the JsonWebKey text that we should discuss to get clarity around some confusion that came up.
16:20:26 <brent> subtopic: https://github.com/w3c/vc-jose-cose/pull/220
16:22:07 <ivan> present+ dlehn
16:22:08 <dlongley> decentralgabe: This PR is clarifying language on the JsonWebKey spec on how to use the JsonWebKey type. There was discussion on a call a few weeks ago on whether we should add language on including properties like `alg` and `kid` and at first there was agreement to add back normative guidance on those properties.
16:22:19 <TallTed> q+
16:22:29 <dlongley> decentralgabe: But then Mike and I agreed we didn't want to repeat language from another RFC -- and so we removed that. Ted said he wanted the language back.
16:22:33 <dlongley> scribe-
16:22:47 <brentz> brentz has joined #vcwg
16:22:50 <brentz> q?
16:22:54 <brentz> ack TallTed
16:23:13 <manu> q+
16:23:18 <brentz> ack manu
16:23:24 <decentralgabe> TallTed: the language that was removed was removed during misunderstanding of what was being discussed...point being the four words were added with intent and removed without that intent, which is why I've asked them to be re-added
16:24:57 <decentralgabe> manu: the language being modified is normative language that is significant. need to update the title of the PR, since it's broader than the example. somewhat confused...had said we'd have explicit guidance on iss, kid, etc. that guidance was not provided...may be a different issue. if we're talking about keys and just a JWT, and if we're just repeating what's said in the other spec we don't need to repeat it here. somewhat c
16:24:57 <decentralgabe> onfusing...since kid matters
16:25:01 <decentralgabe> q+
16:25:06 <dlongley> scribe+
16:25:09 <TallTed> q+
16:25:32 <decentralgabe> https://github.com/w3c/vc-jose-cose/pull/226
16:26:01 <dlongley> decentralgabe: The changes you're referring to Manu, went into 226. The changes we're talking about ... the PR is unfortunately named. The language I moved was originally in an example.
16:26:14 <dlongley> decentralgabe: The issue was to move it to normative guidance, outside of the example.
16:26:31 <manu> q+
16:26:34 <dlongley> decentralgabe: The PR adds some guidance around using the JsonWebKey.
16:26:59 <dlongley> TallTed: On Jan 18th, I said optional or required should be clearly stated for all properties, that's generally true what's happening but not true for the couple that were added with this PR.
16:27:15 <brentz> ack TallTed
16:27:17 <dlongley> TallTed: Those changes went in and were merged but then Mike said that some requirements were wrong.
16:27:22 <manu> q-
16:27:36 <dlongley> TallTed: `alg` is optional in JWKs -- and that's what I want put back.
16:27:46 <dlongley> selfissued: Are we talking about a change to header params or JWKs?
16:27:48 <dlongley> decentralgabe: JWKs.
16:27:57 <dlongley> selfissued: It's optional there, what does it say now?
16:28:03 <dlongley> decentralgabe: Nothing.
16:28:08 <dlongley> selfissued: It's fine to say that.
16:28:14 <brentz> ack decentralgabe
16:28:22 <dlongley> selfissued: This is one of the PRs I was trying to get a sense of ... is this one controversial or is that another one?
16:28:39 <dlongley> decentralgabe: It sounds like we're clear on this one, I'll apply Ted's suggestion and then we're good.
16:28:46 <dlongley> decentralgabe: The other has a rendering script problem.
16:28:52 <dlongley> selfissued: Ok, 220 should be ready once we get the suggestion in.
16:29:03 <dlongley> scribe-
16:29:30 <decentralgabe> selfissued: unfortunately respec has an error that we are trying to fix
16:29:52 <manu> q+
16:30:05 <decentralgabe> ivan: I have just looked at it and do not understand it either... not sure it is a respec issue. there is a warning to take care of and I can export an HTML file without problem. unsure where the issue is
16:30:08 <decentralgabe> selfissued: thank you
16:30:12 <brentz> ack manu
16:30:41 <decentralgabe> manu: have an undefined value somewhere (it doesn't say what). would look at the custom tooling you're using, or pull up the JS console.
16:30:44 <decentralgabe> q+
16:30:54 <decentralgabe> selfissued: something in this PR that causes it to not build
16:31:03 <decentralgabe> q-
16:31:10 <decentralgabe> brentz: I will try to figure this out today
16:31:26 <brentz> Topic: VCDM Issue Processing
16:31:34 <brentz> https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc
16:31:38 <decentralgabe> ... moving on to issue processing
16:31:57 <brentz> subtopic: https://github.com/w3c/vc-data-model/issues/1303
16:31:57 <manu> q+
16:32:10 <decentralgabe> ... looking at 1303 first Remove the at risk issue marker for Evidence
16:32:24 <brentz> ack manu
16:32:55 <manu> https://w3c.github.io/vc-specs-dir/#evidence
16:33:02 <decentralgabe> manu: question for the group: Jefferey Yaskin asked for a mini-registry and to be done with this. we could do that. w.r.t tests what did we say we would do? I have two recollections
16:33:42 <ivan> q+
16:33:53 <decentralgabe> ... have to demonstrate there is a spec using the property. there are multiple impls. 1EdTech have an evidence property. thought the tests we were writing were just testing the 'type' for evidence. need to ask what are we testing for these extension points
16:34:49 <decentralgabe> ... normative guidance we give is : it can't be empty, have to specify it's type, id should be a URL, ... 1EdTech has multiple impls. at what point do we remove the at risk marker? when we create tests?
16:35:07 <decentralgabe> ... is that the bar we're trying to hit?
16:35:08 <brentz> ack ivan
16:35:48 <manu> q+
16:35:53 <decentralgabe> ivan: from a practical point of view, the only obligation we have is to remove these markers and feature itself when we go to PR. at this point there is no rush. at some point we'll have to look at the whole test suite report and then risk markers.
16:36:07 <decentralgabe> ... issue was raised before CR. why bother at this point? went to CR with marker in.
16:36:18 <brentz> ack manu
16:36:28 <decentralgabe> brentz: less a post-CR and then a pre-PR?
16:36:30 <decentralgabe> ivan: yes
16:36:37 <manu> https://github.com/w3c/vc-data-model/pull/1295#pullrequestreview-1657956871
16:37:20 <decentralgabe> manu: agree, but still need clarity. Orie said the example needs to be updated and covered in tests. what does 'covered' mean? ... having input/output that looks like the example. then we can remove the at risk flag. concretely we update the example to use the IMS Global evidence property
16:37:32 <ivan> q+
16:37:50 <decentralgabe> ... there will be a test for that in the core data model. to make sure there's a type and to make sure nobody throws an error (or at least 2 don't.) and then at if at the end of CR two impls are doing this, we remove the issue marker
16:37:58 <decentralgabe> +1 to that proposal
16:38:04 <brentz> ack ivan
16:38:08 <decentralgabe> ... does anyone disagree with that proposal?
16:38:30 <manu> +1 for it being for how we evaluate /all/ properties.
16:38:39 <manu> (all "at risk" properties)
16:38:51 <decentralgabe> ivan: fine with that. need to be clear this is not for the evidence property only. what's being described is 'how do we accept that a given property/term stays in the spec as a normative thing' need a general approach to do that
16:39:13 <decentralgabe> brentz: labeled as before-PR. manu has outlined a clear course of action. no one assigned yet
16:39:26 <decentralgabe> ivan: Manu has outlined ... but needs to be documented somewhere
16:40:10 <manu> q+
16:40:17 <decentralgabe> ... will there be some document that says this is the way we remove the markers?
16:40:25 <decentralgabe> brentz: do you have a proposal?
16:41:12 <decentralgabe> ivan: at the end of the CR process we need a report. to say whether we are fine or not. criteria may differ, this is not in the same category as other issues. my proposal is to have a document and record this in it
16:41:18 <brentz> ack manu
16:42:03 <decentralgabe> manu: I have raised an issue to track this (#1437), will add details. to remove at risk issue markers & properties. will be a before-PR thing. will document the process and track at risk properties
16:42:17 <manu> https://github.com/w3c/vc-data-model/issues/1437
16:42:29 <decentralgabe> brentz: can anyone take the issue?
16:42:32 <decentralgabe> manu: yes, I will
16:42:44 <brentz> subtopic: https://github.com/w3c/vc-data-model/issues/1309
16:43:11 <decentralgabe> brentz: Include credentialSubject examples that use URLs rather than DIDs #1309. some agreement by manu, raised by selfissued. who can be assigned?
16:43:24 <decentralgabe> q+
16:43:33 <brentz> ack decentralgabe
16:43:36 <manu> q+
16:43:46 <decentralgabe> decentralgabe: I can take it
16:43:47 <dlongley> notably, a DID *is* a URL ... but i presume this means "HTTPS" URLs.
16:44:02 <brentz> ack manu
16:44:27 <brentz> subtopic: https://github.com/w3c/vc-data-model/issues/1348
16:44:44 <decentralgabe> brentz: Non-normative changes from Jeffrey Yasskin's review #1348. currently assigned to manu
16:45:21 <decentralgabe> manu: I will do this one. in theory all editorial changes. will take me a while since there are so many of them.
16:45:38 <manu> q+
16:46:19 <decentralgabe> manu: 1431 we should talk about if we have time. re:envelope verifiable credential to the data model/context. also a big change. ask from Orie
16:46:21 <brentz> subtopic: https://github.com/w3c/vc-data-model/issues/1402
16:46:32 <decentralgabe> brentz: first, #1402 phrasing and/or punctuation for input "inputBytes or inputDocument and inputMediaType" needs work
16:46:44 <decentralgabe> ... raised to and assigned to TallTed. how is it going?
16:47:12 <decentralgabe> TallTed: on my list. not a complex thing, just needs to be done. hope to get it done in the next couple days.
16:47:20 <brentz> subtopic: https://github.com/w3c/vc-data-model/issues/1431
16:47:25 <manu> q+
16:47:41 <decentralgabe> prevents consistent RDF interpretation of presentations secured without data integrity proofs.
16:47:42 <brentz> ack manu
16:47:46 <decentralgabe> brentz: next is #1431 EnvelopedVerifiablePresentation missing in data model
16:48:40 <decentralgabe> manu: today we have this concept of an enveloped verifiable credential, with a presentation inside of it. this would add a presentation. should be fine to do this. it is something that is missing. it is a normative change. saying "if you want to, you can wrap it in multiple b64 payloads" to get a blob that secures the entire data model using any media type
16:49:16 <decentralgabe> brentz: clarifying...the enveloped cred was 'I want to use vc-jose-cose to sign a credential' this is 'I want to use vc-jose-cose to sign a presentation'
16:49:21 <decentralgabe> manu: yes correct and I can take it
16:49:25 <decentralgabe> ivan: I will take the vocab part
16:49:37 <decentralgabe> brentz: thanks to both. time for at least one more...#1408
16:49:42 <brentz> subtopic: https://github.com/w3c/vc-data-model/issues/1408
16:50:20 <decentralgabe> ... reconsider @id for mediaType term. looks like this was addressed?
16:50:35 <ivan> q+
16:50:40 <brentz> ack ivan
16:51:33 <decentralgabe> ivan: my impression is that this was solved, we can close it. we are sticking here to what schema.org does
16:51:40 <manu> q+
16:51:42 <decentralgabe> brentz: proposal to close with no action?
16:51:47 <brentz> ack manu
16:52:24 <decentralgabe> manu: currently there is a conflict b/w activity streams and verifiable credentials. activity pub wants to use VCs. they will be blocked/have a bad experience with things as-is. we have the easiest ability to change this. shouldn't just close. we should do something about it
16:52:59 <decentralgabe> ... easiest for us to rename the term from mediatype to ianamediatype or similar. then a question of whether we should re-use the schema.org term for it
16:53:09 <ivan> q+
16:53:11 <decentralgabe> ... or create our own. then it gets complex
16:53:23 <brentz> ack ivan
16:54:02 <decentralgabe> ivan: don't want to get into the weeds of defining/creating types. we can change the term we use to map to schema.org, but would leave this to schema.org, they are already doing this. we can use whichever term we want in our vocab
16:54:12 <bigbluehat> bigbluehat has joined #vcwg
16:54:33 <manu> q+
16:54:33 <brentz> ack manu
16:54:48 <decentralgabe> manu: let's rename our term to 'IANAMediaType' and keep the schema.org URL the same
16:55:22 <decentralgabe> ... we should do this and then be done, and we will be fine
16:55:35 <decentralgabe> ivan: change to be made is in the spec text and context file, right?
16:55:35 <dlongley> q+
16:55:36 <decentralgabe> manu: yes
16:55:45 <decentralgabe> ivan: never touched this but should be able to do it
16:55:49 <brentz> ack dlongley
16:56:02 <manu> I'm fine w/ "encodingFormat"
16:56:06 <decentralgabe> dlongley: do we want to use encoding format as the term? since we're using it as the schema.org property? avoid inventing a new term
16:56:15 <decentralgabe> ivan: perfectly fine
16:56:19 <decentralgabe> brentz: any opposition?
16:56:28 <manu> Only argument against would be: "People don't call these things "encoding format" usually? They say media type?
16:56:39 <dlongley> they also don't say "ianaMediaType"
16:56:45 <manu> true story
16:56:45 <decentralgabe> ... none heard. Ivan is assigned. that is our meeting for today.
16:57:03 <decentralgabe> ... please jump on PRs that need feedback in vc-jose-cose and others. if you are assigned in the data model please get a PR in for that
16:57:04 <manu> "iana" -> "I Am Not A" Media Type
16:57:38 <decentralgabe> ... getting to the point where we could mark things as 'future' ... people will need to be assigned to address them
16:57:49 <decentralgabe> ... thank you everyone, we could not do this without you. see you next week
16:58:04 <ivan> rrsagent, draft minutes
16:58:06 <RRSAgent> I have made the request to generate https://www.w3.org/2024/02/14-vcwg-minutes.html ivan
16:59:09 <ivan> rrsagent, bye
16:59:09 <RRSAgent> I see no action items