07:26:52 <RRSAgent> RRSAgent has joined #vcwg
07:26:57 <RRSAgent> logging to https://www.w3.org/2023/09/14-vcwg-irc
07:26:57 <ivan_> ivan_ has joined #vcwg
07:27:38 <ivan_> Meeting: Verifiable Credentials Working Group F2F at TPAC, 1st day
07:27:39 <ivan_> Date: 2023-09-14
07:27:39 <ivan_> Agenda: https://www.w3.org/events/meetings/f665e720-f28a-4d5c-b4d0-8454a85e9a44/
07:27:39 <ivan_> chair: kristina, brent
07:27:39 <ivan_> ivan_ has changed the topic to: Meeting Agenda 2023-02-14: https://www.w3.org/events/meetings/f665e720-f28a-4d5c-b4d0-8454a85e9a44/
07:27:54 <ivan_> present+
07:28:22 <ivan_> present+ brent, kristina, phila, shigeya, andres, gabe
07:28:23 <brent> brent has changed the topic to: TPAC Meeting Day 1, 2023-09-14: https://www.w3.org/events/meetings/f665e720-f28a-4d5c-b4d0-8454a85e9a44/
07:29:00 <TallTed> TallTed has joined #vcwg
07:29:49 <hsano> hsano has joined #vcwg
07:29:55 <hsano> present+
07:30:44 <Jay> Jay has joined #vcwg
07:30:48 <ivan_> present+ pchampin
07:30:51 <manu> present+
07:31:08 <Jay> present+
07:31:51 <DavidC> DavidC has joined #vcwg
07:32:02 <TallTed> present+
07:32:06 <DavidC> present+
07:32:34 <kdenhartog> kdenhartog has joined #vcwg
07:32:53 <Eric_Siow> Eric_Siow has joined #vcwg
07:33:06 <pauld_gs1_> pauld_gs1_ has joined #vcwg
07:34:05 <dmitriz> dmitriz has joined #vcwg
07:34:45 <Geun-Hyung> Geun-Hyung has joined #VCWG
07:35:35 <pchampin> pchampin has joined #vcwg
07:35:49 <decentralgabe> decentralgabe has joined #vcwg
07:35:53 <decentralgabe> present+
07:35:55 <pchampin> present+
07:36:07 <nick_lansley_GS1> nick_lansley_GS1 has joined #vcwg
07:36:36 <Eric_Siow> Yes.
07:36:43 <Geun-Hyung> present+ GeunHyung_Kim
07:37:14 <hyojin> present+
07:37:16 <seabass> present+
07:37:30 <seabass> I could scribe later.
07:37:43 <andres> andres has joined #vcwg
07:37:43 <seabass> I would like to make sure that I can hear sufficiently before scribing remotely.
07:38:01 <andres> present+
07:38:16 <dezell> dezell has joined #vcwg
07:38:17 <KevinDeanGS1> KevinDeanGS1 has joined #vcwg
07:38:27 <dezell> present+ David_Ezell
07:38:41 <y-sakuma> y-sakuma has joined #vcwg
07:38:47 <LaurensDebackere> LaurensDebackere has joined #vcwg
07:38:53 <LaurensDebackere> present+
07:39:02 <y-sakuma> present+
07:39:18 <rhiaro> present+
07:40:51 <JoeAndrieu> JoeAndrieu has joined #vcwg
07:40:56 <ivan_> pressent+ dmitriz
07:41:19 <ivan_> present+ selfissued
07:42:11 <bumblefudge> present+
07:42:16 <ivan_> present+ dwaite
07:42:18 <kristina> kristina has joined #vcwg
07:42:48 <ivan_> Topic: VCDM PR-s
07:42:52 <andres> scribe+
07:43:19 <andres> kristina: a link to the agenda is in the IRC. If you can volunteer, please add your name.
07:43:25 <dmitriz> dmitriz has joined #vcwg
07:43:35 <ohmata> ohmata has joined #vcwg
07:43:36 <osamu-> osamu- has joined #vcwg
07:43:43 <dmitriz> present+
07:43:47 <andres> ... Scribes will interrupt to make sure they hear.
07:43:59 <jsalvachua> jsalvachua has joined #vcwg
07:44:04 <kristina> here is a URL, please use column G to sign up to scribe: https://docs.google.com/spreadsheets/d/114z14u-8B2w3iuutcSf5ln-slNz9Q07jXTvB5rhpPrw/edit
07:44:23 <dwaite> dwaite has joined #vcwg
07:45:02 <brent> Topic: VCDM PRs
07:45:03 <andres> brent: Currently 12 open PR in the vcdm repo. We'll go through all. If we can't get consensus, we'll mark as pending-close.
07:45:03 <brent> https://github.com/w3c/vc-data-model/pulls?q=is%3Apr+is%3Aopen+sort%3Acreated-asc
07:45:16 <manu> q+
07:45:18 <helen_> helen_ has joined #vcwg
07:45:24 <helen_> present+
07:45:29 <andres> ... first one is 1199
07:45:30 <brent> subtopic: https://github.com/w3c/vc-data-model/pull/1199
07:45:34 <morimori> morimori has joined #vcwg
07:45:34 <dwaite> present+
07:46:07 <manu> q-
07:46:09 <andres> ... Raised by orie. Good review and a number of comments. 1 open request for changes from TallTed. Are you're changes unaddressed?
07:46:22 <andres> TallTed: Haven't had the chance to review.
07:46:38 <andres> brent: If it meets your approval, we can merge.
07:47:10 <brent> subtopic: https://github.com/w3c/vc-data-model/pull/1260
07:47:13 <andres> ... Next one is 1260.
07:47:22 <manu> q+
07:47:33 <andres> ... Raised by Orie. Open for some time. Currently 1 pending change request from manu.
07:47:36 <brent> ack manu
07:47:50 <selfissued> selfissued has joined #vcwg
07:47:58 <selfissued> present+
07:49:02 <andres> manu: It's a general objection to the PR. We have a use case where expressing public and private keys in the context. It would change if we had something like confidence method to the base context. -1 until that's the case.
07:49:20 <ivan_> q+
07:49:36 <brent> ack ivan_
07:49:39 <andres> brent: Since no approvals, there is no consensus and one objection. We plan on closing.
07:50:00 <manu> q+
07:50:05 <phila> phila has joined #vcwg
07:50:09 <andres> ivan_: the secret is already in the vocabulary. Just noting that.
07:50:10 <brent> ack manu
07:50:14 <phila> present+
07:50:23 <andres> manu: We might want to look at that, it might be a mistake.
07:50:54 <andres> brent: We need an open issue to track a possible change to the vocab. We intend to close this PR due to lack of consensus.
07:51:00 <andres> ... Next is 1269.
07:51:01 <brent> subtopic: https://github.com/w3c/vc-data-model/pull/1269
07:51:19 <andres> ... Raised by JoeAndrieu, suggesting changes to terminology.
07:51:50 <andres> ... Few approvals, one request for changes from TallTed.
07:52:05 <andres> TallTed: If changes are done, I'm ok merging.
07:53:26 <andres> brent: not merging yet, close to being merged. We'll move on.
07:53:26 <andres> ... Next is 1270
07:53:26 <brent> subtopic: https://github.com/w3c/vc-data-model/pull/1270
07:53:58 <selfissued> q+
07:53:58 <andres> ... Explain json-ld further. A section that was widely asked for. Has had comments back and forth, no approvals. More work to be done. We'll time box to 10 minutes what changes are needed from folks.
07:54:06 <brent> ack selfissued
07:54:09 <manu> q+
07:54:13 <andres> selfissued: This PR is a lot of philosophy and not a lot that helps implementers.
07:54:13 <brent> ack manu
07:54:16 <seabass> q+
07:54:44 <brent> ack seabass
07:54:49 <andres> manu: The group asked us to write this. They asked for "we want to see a section that explains json-ld". We have other places in the spec that explain why some choices were made.
07:55:00 <selfissued> q+
07:55:31 <TallTed> q+
07:56:29 <manu> q+ to request concrete changes via the PR
07:56:39 <JoeAndrieu> FYI edits for #1269 accepted. https://github.com/w3c/vc-data-model/pull/1269
07:56:42 <andres> seabass: It looks good on a first impression. I would prefer for it to be cut back. Not because it is incorrect, but it includes some things that sounds like opinions. This makes folks uncomfortable. I would suggest som word smithing. I would object to merging now, but ok in the future.
07:57:00 <andres> brent: Suggestion is to make concrete suggestions.
07:57:14 <andres> selfissued: There are 14 new paragraphs. Please cut it down accordingly.
07:57:30 <wonsuk_> wonsuk_ has joined #vcwg
07:57:36 <andres> TallTed: The entire section is informative. It might be better as an appendix.
07:58:23 <kristina> we need something in main text as opposed to appendix
07:58:23 <andres> ... It doesn't talk about JSON, but it's utilization. That's the way it is.
07:58:23 <shigeya> +1 kristina
07:58:23 <kristina> q+
07:58:25 <andres> ... If Mike really thinks it could be said in a single paragraph, please suggest how to concretely do it.
07:58:27 <seabass> q+
07:58:33 <andres> brent: Happy to hear thought about the appendix suggestion.
07:58:37 <kristina> q+
07:58:38 <kristina> q?
07:58:49 <kristina> ack selfissued
07:58:52 <kristina> ack TallTed
07:59:09 <TallTed> s/but it's utilization/but its use/
07:59:09 <brentz> brentz has joined #vcwg
07:59:12 <kristina> ack manu
07:59:12 <Zakim> manu, you wanted to request concrete changes via the PR
07:59:29 <brentz> ack kristina
07:59:31 <andres> manu: +1 what TallTed said. It's really difficult to understand the changes requested without suggested changes. Please either write a PR, or make concrete github suggestions.
08:00:24 <seabass> q-
08:00:43 <andres> kristina: Re: moving to appendix. I do believe we need a few short and sweet paragraphs in the main text. More details can go in the appendix. Doesn't need to be pre-cr. Bottom line, the goal is to give folks some background on JSON-ld before sections that work off of it.
08:00:46 <manu> +1 kristina, keep shorter section in the main spec... but don't feel super strongly about it.
08:00:59 <andres> brent: Since this PR is non-normative, it's not urgent to merge this PR.
08:01:10 <brentz> subtopic: https://github.com/w3c/vc-data-model/pull/1271
08:01:22 <seabass> q+
08:01:35 <andres> ... Raised 4 days ago. Within window of review.
08:01:42 <manu> q+
08:01:47 <brentz> ack seabass
08:01:48 <jose-gataca> jose-gataca has joined #vcwg
08:01:58 <andres> ... Some approvals already, one change request.
08:02:38 <brentz> ack manu
08:02:40 <andres> seabass: Issue 1264, which this PR quotes, doesn't need to be merged for this to be merged.
08:02:58 <dtluu> dtluu has joined #vcwg
08:03:15 <andres> manu: BigBlueHat just want some rewording. Can be done and merged after that.
08:03:22 <TallTed> just to note -- I have not reviewed this PR yet
08:03:27 <andres> brent: PR is on course to be merged soon.
08:03:33 <andres> ... next is 1272
08:03:34 <brentz> subtopic: https://github.com/w3c/vc-data-model/pull/1272
08:03:46 <manu> q+
08:03:59 <brentz> ack manu
08:04:02 <andres> ... primarily editorial, raised a few days ago.
08:04:10 <ivan_> q+
08:04:17 <andres> manu: Yes to all of that, just need to merge TallTed's changes.
08:04:28 <brentz> ack ivan_
08:05:13 <andres> ivan: For the record, I did 1278 yesterday.
08:05:17 <brentz> https://github.com/w3c/vc-data-model/pull/1278
08:05:28 <andres> ... it's on top of 1272
08:05:44 <andres> manu: agree to merge on top of it.
08:05:57 <andres> brent: merged, back to 1272
08:06:02 <brentz> q?
08:06:02 <seabass> q+
08:06:04 <samuelgoes> samuelgoes has joined #vcwg
08:06:07 <andres> ... still have 3 more days for reviews.
08:06:07 <brentz> ack seabass
08:07:35 <jquemada> jquemada has joined #vcwg
08:07:49 <andres> brent: manu to look at suggestions made, anticipating that the PR will be merged soon.
08:07:54 <brentz> subtopic: https://github.com/w3c/vc-data-model/pull/1276
08:07:54 <andres> ... next is 1276
08:08:06 <manu> q+
08:08:25 <andres> ... Few requests for changes from TallTed. Not a lot of review yet, raised 2 days ago.
08:08:28 <brentz> ack manu
08:08:33 <andres> ... We'd like to see how to move this forward.
08:09:07 <seabass> What I was saying is that the ease of merging Ivan's PR illustrates how useful it is to push to a 'personal' branch within the W3C repository, not to your GitHub fork. It is not possible to push to someone else's GitHub fork, so that discussion would have involved lots of git commands if Manu hadn't pushed to the main repository.
08:09:07 <andres> manu: This is in response to an issue that DavidC raised.
08:10:18 <andres> ... We're suggesting to people that they do not use full URLs for things that have json-ld terms. Doing so would harm interop. Not illegal, just a suggestion to not do it.
08:10:18 <brentz> q?
08:10:18 <DavidC> ack Manu
08:10:18 <andres> brent: Please review folks.
08:10:18 <andres> ... moving on to 1277
08:10:49 <brentz> subtopic: https://github.com/w3c/vc-data-model/pull/1277
08:10:55 <andres> ... This is a cleanup PR. Much appreciated. Don't expect it's open long before it's merged.
08:11:09 <andres> ... Editorial, thanks DavidC. Looking forward to merging.
08:11:15 <andres> ... Next is 1279
08:12:23 <brentz> subtopic: https://github.com/w3c/vc-data-model/pull/1279
08:12:23 <andres> ... PR was raised 16 hours ago. Manu clearly is bored.
08:12:23 <andres> ... Can you give us an intro?
08:12:23 <andres> manu: We've made a decision to be more strict about how we specify the json-ld context and vocab documents used.
08:12:23 <ivan_> q+
08:12:23 <andres> ... I believe it's because we want to be more strict about what a VC is.
08:13:08 <andres> ... We now are very specific for the semantics for all terms. And the contents of the files that describe it.
08:13:29 <andres> ... This PR does it in the vocabulary files themselves.
08:14:12 <andres> ... This PR points to the DI vocab and the VC vocab. This is us being very specific about which vocab documents are used.
08:14:16 <brentz> ack ivan_
08:14:43 <andres> ivan: I'll just repeat here the same comment I made earlier.
08:15:27 <andres> ... If we start putting hash values in schema, then we'll have to put them everywhere. There is no chance that people will change existing items. Getting to calculate the hash for a vocabulary is unnecessary.
08:15:28 <kristina> +1 ivan
08:15:48 <andres> ... It overcomplicated our lives to do so.
08:16:02 <andres> ... It's different for things we control. But for schema.org, we shouldn't do so.
08:16:02 <manu> q+ to agree with ivan and note that this PR is an attempt to be consistent.
08:16:10 <brentz> ack manu
08:16:10 <Zakim> manu, you wanted to agree with ivan and note that this PR is an attempt to be consistent.
08:16:45 <andres> manu: +1 to ivan. I wasn't a fan to use crypto hashes for vocab files. I wrote it because it was requested. Trying to be consistent. But where should we draw the line?
08:16:50 <cbiesinger> cbiesinger has joined #vcwg
08:16:51 <kristina> i am ok drawing the line whether this wg controls or not
08:17:06 <andres> ... Definitely not for SSD, but let's not include schema.org from there.
08:17:24 <andres> ... I don't think it matters (?). I don't know if it matters that much.
08:17:37 <andres> ... Anyone using them can always decide to ignore the guidance.
08:17:59 <andres> ... I'm fine if we remove schema.org from the list, and only refer to vocab documents that this group is publishing.
08:18:16 <ivan_> q+
08:18:27 <andres> ... Just noting that we are picking an arbitrary line.
08:18:56 <andres> ivan: The way I would formulate it is that there are vocabs which are part of the core system. schema.org is one of them, along others. It's already part of the infra.
08:19:26 <andres> brent: We have a path forward. Please others give feedback.
08:19:39 <andres> ... Moving on to 1280
08:20:00 <ivan_> q+
08:20:22 <manu> q+
08:20:25 <kristina> q?
08:20:29 <brent> brent has joined #vcwg
08:20:36 <kristina> ack ivan_
08:20:38 <ivan_> subtopic: https://github.com/w3c/vc-data-model/pull/1280
08:20:41 <kristina> ack manu
08:21:14 <andres> manu: Giving some background. Orie requested that we document what a VC graph is, and why it's in the spec. This PR does this. The short of it is that when you have a VP, you can include multiple VC within it.
08:21:31 <andres> ... We want to make sure the data within the VC is not comingled.
08:21:44 <andres> ... It's important when you have multiple objects that looks the same.
08:21:49 <kristina> s/many/manu
08:22:39 <andres> ... the problem is that in JSON-LD you cannot be sure that objects are talking about the same thing.
08:22:52 <andres> ... This PR prevents that, so data isn't comingled.
08:23:25 <andres> ... If you aren't doing json-ld processing, you should not merge information unless you are absolutely sure.
08:23:26 <ivan_> q+
08:23:31 <brent> ack ivan_
08:23:48 <andres> ivan: I made some comments already.
08:24:05 <manu> q+ to agree w/ Ivan on proof graph
08:24:19 <helen__> helen__ has joined #vcwg
08:24:19 <andres> ... One is that if we take this PR, then something similar has to be done for the context integrity (which is a different repo).
08:24:34 <andres> ... Second is that, manu, you may want to change additional vocab files.
08:25:13 <andres> ... There is one question about being precise. It's a restriction about VC within a proof.
08:25:28 <brent> q?
08:25:31 <brent> ack manu
08:25:32 <Zakim> manu, you wanted to agree w/ Ivan on proof graph
08:26:05 <andres> manu: Agree on doing a parallel PR on the proof graph in the data integrity spec. Agree on making additions to the vocab file.
08:26:21 <andres> ... Agree on the restrictions and limitations as well.
08:26:30 <andres> brent: Who will raise taht issue in DI?
08:26:33 <andres> manu: I'll do it.
08:26:49 <andres> brent: Down to our last PR, open 13 hours ago
08:26:50 <brent> subtopic: https://github.com/w3c/vc-data-model/pull/1281
08:27:00 <manu> q+
08:27:35 <brent> ack manu
08:27:35 <andres> manu: Orie requested that, because context is normative, we explain what that means.
08:28:41 <andres> ... this PR says that if you utilize the context when doing full json-ld processing, and it results in an error, then all further operations should also result in an error.
08:29:02 <andres> ... In other words: if there is an error, you should bubble it up.
08:29:06 <seabass> q+
08:29:31 <brent> ack seabass
08:29:34 <andres> ... We know exactly what the contents of the context should be, so errors should be detected and raised across the stack.
08:29:55 <manu> q+
08:30:00 <andres> seabass: From a security perspective you don't want to have errors leaking through. What is the difference between the context and any other validation?
08:30:03 <brent> ack manu
08:30:57 <andres> manu: One example is the daterange validFrom and validUntil. E.g. a validFrom value that said use "value from tuesday". It has nothing to do with context. It's a non-context based error. Validation would fails.
08:31:15 <JoeAndrieu> q+ to say this is a difference of verification & validation. @context is required for verification
08:31:17 <andres> ... We do have that throughout the spec. they have nothing to do with the context.
08:31:29 <pchampin> s/value from tuesday/validFrom tuesday
08:31:44 <andres> ... That's spearate from the context file. It comes into play when doing full json-ld processing. But it's something that's optional.
08:31:44 <seabass> q+ to respond to manu
08:32:10 <andres> ... not sure if that answers your question. Just noting that we have places in the spec where we expect errors to be raised.
08:32:11 <brent> ack JoeAndrieu
08:32:11 <Zakim> JoeAndrieu, you wanted to say this is a difference of verification & validation. @context is required for verification
08:32:44 <andres> JoeAndrieu: I think your question is the difference between verification vs validation. I don't think you can verify with an invalid context.
08:32:46 <brent> ack seabass
08:32:46 <Zakim> seabass, you wanted to respond to manu
08:33:16 <manu> q+ to note you can verify w/o a valid context
08:33:17 <andres> seabass: Why is it so specific to the context file?
08:33:22 <brent> ack manu
08:33:22 <Zakim> manu, you wanted to note you can verify w/o a valid context
08:33:58 <andres> manu: I think you are correct in suggesting "any validation errors should be bubbled up".
08:34:37 <andres> ... Some orgs may keep processing the VC even if an error happens.
08:34:56 <andres> ... the reason this PR doesn't call this out is because this is only about what @context should have.
08:35:31 <JoeAndrieu> q+ to disagree
08:35:40 <brent> q?
08:35:49 <andres> ... To Joe's point, the context comes into play when you're verifying, but only when you're doing full JSON-ld processing. When you're not doing it, you assume that the context is correct.
08:36:23 <andres> ... This means that you might miss point in time errors for a VC.
08:36:34 <kristina> q?
08:36:46 <andres> ... Validation is similar in this case.
08:37:00 <kristina> ack JoeAndrieu
08:37:00 <Zakim> JoeAndrieu, you wanted to disagree
08:37:18 <andres> JoeAndrieu: I want to disagree when the processing you're suggesting to do when you're not doing json-ld processing.
08:37:35 <manu> q+ to note that you won't do full processing, regardless
08:37:35 <kristina> q?
08:37:41 <kristina> ack manu
08:37:41 <Zakim> manu, you wanted to note that you won't do full processing, regardless
08:37:51 <andres> ... My understanding was that you should fails if the context is something you don't expect to understand.
08:38:10 <JoeAndrieu> q+
08:38:23 <brentz> brentz has joined #vcwg
08:38:30 <brentz> q?
08:38:31 <andres> manu: the full json-ld processor will utilize the full extent of the @context file.
08:38:53 <andres> ... Without full processing, you presume that someone has done that elsewhere.
08:39:26 <manu> q+
08:39:28 <brentz> ack JoeAndrieu
08:39:29 <brentz> q+
08:39:38 <brentz> ack manu
08:39:47 <andres> JoeAndrieu: I understand that nuance. You still need to understand that context even if you aren't doing full processing.
08:40:03 <andres> manu: that does not happen. You presume it's valid.
08:40:06 <JoeAndrieu> we are talking past each other
08:40:53 <JoeAndrieu> I'm not talking about processing in a JSON-LD manner, I'm talking about processing of the context property. If MUST be checked to confirm that you think you understand it. Not that you apply those contexts.
08:41:03 <brentz> ack brent
08:41:11 <manu> ah, yes ^
08:41:28 <andres> ... It's happening in the web right now. the same file may yield different results depending on whether full processing is doing.
08:41:34 <manu> q+
08:41:36 <brentz> q?
08:41:39 <brentz> ack manu
08:41:46 <andres> brent: the VCDM already states that context needs to have certain values.
08:41:57 <JoeAndrieu> yep
08:42:20 <andres> manu: I think Joe, you're saying that the @context property is always checked, even if you're not looking as the contents of the dereferenced file (or all the values).
08:42:35 <andres> ... What changes do you think should be made, in order to address your concern?
08:43:02 <brentz> q?
08:43:07 <andres> JoeAndrieu: Not sure yet, but I think we need to still look at the property. Will look at the PR and m ake suggestions.
08:43:17 <andres> brent: We are through all the PRs
08:43:37 <manu> +1 for issue processing
08:43:51 <brentz> Topic: VCDM before-CR Issues
08:44:17 <kristina> https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+label%3Abefore-CR+-label%3A%22pr+exists%22+
08:44:42 <andres> kristina: This link has all issues labeled before-cr, without the label pr-exists.
08:45:06 <andres> ... We need to agree how to proceed with 9 of them.
08:45:22 <tminamii_> tminamii_ has joined #vcwg
08:45:31 <andres> brentz: Goal is to know who is going to raise a PR, and by when.
08:45:37 <andres> ... We want to go into CR by the end of this month.
08:45:44 <DavidC> q+
08:46:01 <MacTed> MacTed has joined #vcwg
08:46:25 <andres> ... That will be the primary focus. Ideally PRs within the next week, maybe 2.
08:46:55 <andres> DavidC: Will take one, doing so already.
08:47:01 <brentz> subtopic: https://github.com/w3c/vc-data-model/issues/1275
08:47:02 <kristina> this issue, DavidC? https://github.com/w3c/vc-data-model/issues/1010
08:47:04 <andres> brentz: Thanks, noted.
08:47:13 <manu> q+
08:47:22 <brentz> ack DavidC
08:47:22 <kristina> ack DavidC
08:47:25 <brentz> ack manu
08:47:27 <andres> ... manu can you comment on this issue?
08:48:16 <andres> manu: This came up when we were processing fix ups to the base context. We were getting it in the proper shape to go into CR. We noticed that Orie had set some of the jwk properties to let them be URL, where the JWK doesn't allow that.
08:48:41 <andres> ... An example is "kid". It's currently defined as "it must be a URL" in the base context.
08:48:53 <andres> ... JWK says that it's a string.
08:49:03 <MacTed> RRSAgent, draft minutes
08:49:04 <RRSAgent> I have made the request to generate https://www.w3.org/2023/09/14-vcwg-minutes.html MacTed
08:49:06 <andres> ... We shouldn't deviate, we should align.
08:49:10 <selfissued> q+
08:49:15 <brentz> ack selfissued
08:49:31 <andres> selfissued: I agree with manu that "kid" needs to be able to be any string.
08:49:36 <manu> q+
08:49:57 <brentz> ack manu
08:50:07 <andres> manu: I can take it. It will likely be objected, though. Can someone from the vc-jose-cose world do it?
08:50:30 <andres> ... We should align. That's what I'd like to see.
08:50:41 <dwaite> dwaite has joined #vcwg
08:50:54 <andres> selfissued: I can review the PR.
08:51:07 <andres> brentz: Assigning to both manu and selfissued.
08:51:16 <andres> selfissued: manu, please ping me out of band.
08:51:32 <andres> brentz: Any more comments? <silence>
08:51:37 <brentz> subtopic: https://github.com/w3c/vc-data-model/issues/1265
08:51:42 <andres> ... Moving on
08:51:53 <manu> q+
08:52:03 <andres> ... Raised by Orie, who isn't able to attend today.
08:52:04 <brentz> ack manu
08:52:15 <andres> ... Is it a good idea? Why?
08:52:25 <andres> manu: we. have the concept of relatedResource
08:52:32 <JoeAndrieu> q+ to say isn't this a new feature?
08:52:50 <andres> ... It allows us to refer to files outside a VC using a cryptographic hash.
08:53:08 <seabass> q+
08:53:10 <andres> ... E.g. instead of embedding an image, you can refer to it with a cryptohash.
08:53:31 <andres> ... We have that capability in VC, we don't have it for VPs.
08:53:51 <andres> ... Unclear to me what the use case is for this. But sounds like a generally useful thing to have.
08:54:27 <brentz> ack JoeAndrieu
08:54:27 <Zakim> JoeAndrieu, you wanted to say isn't this a new feature?
08:54:29 <andres> ... I don't think it causes any harm having that feature. I'd be interested in hearing from the group on whether it's useful to have.
08:54:53 <brentz> ack seabass
08:54:57 <andres> JoeAndrieu: Sounds like a new feature after the feature freeze. There are other ways of doing this by adding it to a presented VC.
08:55:21 <manu> q+ to agree with seabass and note we have no way of holder to say relatedResource
08:55:21 <andres> seabass: I would like to raise a potential issue that this means that a VP cannot be understood fully offline.
08:55:29 <brentz> ack manu
08:55:29 <Zakim> manu, you wanted to agree with seabass and note we have no way of holder to say relatedResource
08:55:40 <MacTed> MacTed has joined #vcwg
08:55:53 <JoeAndrieu> just make a VC that says here's a related resource
08:55:56 <andres> manu: that's correct. This also happens if you haven't cached the context.
08:56:10 <JoeAndrieu> holders can issue VCw
08:56:14 <JoeAndrieu> VCs
08:56:31 <brentz> +1 that handling this differently than the way additional data about the VP is handled would be inconsistent
08:56:33 <andres> ... realted to what JoeAndrieu said, we don't have a way for the holder to do that.
08:56:34 <brentz> q?
08:56:37 <brentz> q+
08:56:40 <JoeAndrieu> q+ to say you've already argued that of course holders can just make a VC to make statements about the presentatio
08:57:07 <manu> q+
08:57:14 <JoeAndrieu> q-
08:57:19 <brentz> ack brentz
08:57:24 <ivan_> q+
08:57:24 <andres> brentz: we agreed on the mechanism in which the holder can make statements about the presentations
08:57:25 <brentz> ack manu
08:57:35 <andres> manu: yes, that's a good point. Had forgotten about that.
08:57:52 <andres> ... that's a mark against this feature.
08:58:03 <brentz> q+
08:58:06 <JoeAndrieu> q+ for use cases. Sebastian's concern is strong
08:58:08 <brentz> ack ivan_
08:59:00 <andres> ivan: We have an open issue to look at all the properties that we have in the VC, to see which ones can be applied to VPs as well. Couldn't find the actual issue.
08:59:12 <andres> ... I just translated what is in the spec to the vocab.
08:59:23 <brentz> q?
08:59:23 <andres> brentz: We'll get to it as some point today.
08:59:27 <brentz> ack brentz
08:59:31 <brentz> ack JoeAndrieu
08:59:31 <Zakim> JoeAndrieu, you wanted to discuss use cases. Sebastian's concern is strong
09:00:14 <andres> JoeAndrieu: If we had a good use case, it would be a different convo. Agree with seabass that we need a way to comm images. Will be tough with feature freeze.
09:00:41 <andres> brentz: Wrap up, thanks all. Back in 30 min.
09:00:57 <andres> scribe-
09:02:01 <TallTed> TallTed has joined #vcwg
09:03:47 <phila> phila has joined #vcwg
09:19:05 <Jem> Jem has joined #vcwg
09:32:26 <Jay> Jay has joined #vcwg
09:32:38 <dmitriz> dmitriz has joined #vcwg
09:32:58 <phila> phila has joined #vcwg
09:33:21 <kristina> kristina has joined #vcwg
09:34:09 <Eric_Siow> Thanks.  I was about to ask.
09:34:35 <decentralgabe> decentralgabe has joined #vcwg
09:37:58 <NickLansleyGS1> NickLansleyGS1 has joined #vcwg
09:39:52 <brentz> q?
09:40:30 <JoeAndrieu> scribe+
09:40:30 <JoeAndrieu> present+
09:41:03 <JoeAndrieu_> JoeAndrieu_ has joined #vcwg
09:41:03 <Dingwei> Dingwei has joined #vcwg
09:41:03 <kristina> q+
09:41:03 <andres> andres has joined #vcwg
09:41:03 <JoeAndrieu_> present+
09:41:03 <JoeAndrieu_> scribe+
09:41:03 <brentz> ack kristina
09:41:03 <andres> present+
09:41:03 <Dingwei> present+
09:41:03 <hsano> hsano has joined #vcwg
09:41:03 <selfissued> selfissued has joined #vcwg
09:41:03 <hsano> present+
09:41:03 <selfissued> present+
09:41:03 <JoeAndrieu_> kristina: I looked at the issue. Its a bit different than what we talked about before break
09:41:03 <manu> q+
09:41:36 <brentz> ack manu
09:41:36 <JoeAndrieu_> ... there's a broader application of a common feature, then that's viable
09:41:36 <bumblefudge> present+
09:41:36 <JoeAndrieu_> manu: looking at it again, I think Kristina is right. The intention is to do something different from what linkedResource does in DIDs.
09:41:42 <JoeAndrieu_> ... this is badly titled.
09:42:01 <JoeAndrieu_> ... This points to graphs by id. So that's problematic.
09:42:08 <dmitriz> q+
09:42:17 <JoeAndrieu_> ... still struggling to understand the use case
09:42:18 <kristina> +1 to ask Orie for clarification
09:42:24 <brentz> ack dmitriz
09:42:34 <JoeAndrieu_> dmitriz: use case-wise I think I understand.
09:42:56 <JoeAndrieu_> ... not sure about the graph node. its the ability to include non VC resources in a VP
09:43:05 <Barry_> Barry_ has joined #vcwg
09:43:05 <JoeAndrieu_> ... like here is PDF that is a part of something
09:43:11 <calvin> calvin has joined #vcwg
09:43:15 <manu> q+
09:43:16 <JoeAndrieu_> ... and bind that to the same authentication
09:43:25 <brentz> q+ to ask about credential attachments
09:43:34 <brentz> ack manu
09:43:36 <JoeAndrieu_> ... the same thing that linkedResources does
09:43:48 <JoeAndrieu_> manu: each time I re-read  the issue, my understanding changes
09:44:03 <brentz> ack brentz
09:44:03 <Zakim> brentz, you wanted to ask about credential attachments
09:44:07 <JoeAndrieu_> ... What you said Dimitri suggests it is related to relatedResources
09:44:11 <LaurensDebackere> LaurensDebackere has joined #vcwg
09:44:25 <dmitriz> yes! attachments!
09:44:27 <JoeAndrieu_> brentz: another interpretation? Gen has been discussing how to add attachments to credentials and presentations
09:44:58 <brentz> q?
09:44:58 <pauld_gs1> pauld_gs1 has joined #vcwg
09:44:58 <manu> q+ to note attachments falls back to previous VC-based relatedResource use case
09:44:58 <JoeAndrieu_> ... the primary response is that we need more clarity from Orie
09:44:58 <JoeAndrieu_> q+ about feature freeze
09:44:58 <kristina> q+
09:44:58 <brentz> ack manu
09:44:58 <Zakim> manu, you wanted to note attachments falls back to previous VC-based relatedResource use case
09:45:34 <kristina> q-
09:45:34 <JoeAndrieu_> manu: plus one for the attachment use case
09:45:34 <JoeAndrieu_> ... we can do that withthe VC
09:45:34 <JoeAndrieu_> q+
09:45:34 <manu> scribe+
09:45:34 <brentz> ack JoeAndrieu_
09:45:34 <dmitriz> the binding time is different, for a VC vs VP
09:45:41 <manu> JoeAndrieu: I think the attachment use case is more problematic w/ feature freeze, we should table this for the next version.
09:45:44 <jsalvachua> jsalvachua has joined #vcwg
09:46:00 <manu> scribe-
09:46:08 <JoeAndrieu_> brentz: any objection to adding this as future
09:46:20 <jose-gataca> jose-gataca has joined #vcwg
09:46:26 <JoeAndrieu_> brentz: chairs will have a conversation about feature freeze
09:47:17 <brentz> subtopic: https://github.com/w3c/vc-data-model/issues/1263
09:47:17 <JoeAndrieu_> ... domain & range question
09:47:20 <ivan_> q+
09:47:22 <brentz> ack ivan_
09:47:25 <JoeAndrieu_> ... In addition to the JWk properties and the context, there are a lot of properties that have a domain and range expressed. some might not be correct
09:47:31 <JoeAndrieu_> ivan_: let's put the RDF issues aside
09:48:04 <JoeAndrieu_> ... just looking at recommended proposal, there are a number of properties, such as issuer, that are described in the spec only in VCs.
09:48:19 <JoeAndrieu_> ... There is no line between what is only in VCs or VPs and what are usable in both.
09:49:11 <JoeAndrieu_> ... This manifested when I translated the spec into the vocab and created a diagram. it became very visible.
09:49:11 <JoeAndrieu_> ... What I need as a vocab expert is for each of them a clear statement in the specification, somewhere, that says it is usable in a VP as well as VC or not.
09:49:14 <JoeAndrieu_> ... The rest would be me doing editorial work
09:49:32 <dmitriz> it would be incredibly useful to also allow termsOfUse in a VP, in addition to VC
09:49:38 <JoeAndrieu_> ... The range is similar, but there aren't many specified in the spec.
09:49:53 <brentz> q+
09:49:59 <JoeAndrieu_> ... I'd propose that someone looks at all the properties defined and does a triage to identify what needs more work
09:50:05 <brentz> ack brentz
09:50:20 <manu> q+
09:50:24 <JoeAndrieu_> brentz: would folks be opposed to, in general, saying any property in the data model could be used in either VCs or VPs
09:50:25 <dmitriz> +1 to that :)
09:50:41 <manu> q-
09:50:42 <JoeAndrieu_> ivan_: I would. we have some like credentialSubject should not be in the presentation
09:50:49 <manu> Correct, we definitely don't want to do that.
09:50:49 <JoeAndrieu_> brentz: so the answer is no. ;)
09:51:02 <TallTed> for those, it seems we need parallel presentationSubject, etc.
09:51:13 <TallTed> q+
09:51:20 <brentz> ack TallTed
09:51:20 <JoeAndrieu_> ... so we need a volunteer to do the triage, AND we'll need it added to the spec
09:51:46 <manu> q+ to not expand scope this late in the game
09:51:48 <JoeAndrieu_> TallTed: concern: credentialSubject suggests maybe there's a parallel for PresentationSubject
09:51:51 <brentz> ack manu
09:51:51 <Zakim> manu, you wanted to not expand scope this late in the game
09:52:13 <JoeAndrieu_> manu: this sounds like... the scope of this is rapidly expanding and we're going into CR. so big -1
09:52:22 <JoeAndrieu_> ... too hard to consider this late in the game
09:52:36 <JoeAndrieu_> ... for example, presentationStatus wouldn't make same. Issuer for VPs, etc.
09:52:50 <JoeAndrieu_> ... the idea that VCs and VPs are the same thing is a bad path to go down.
09:52:55 <brentz> q?
09:53:36 <JoeAndrieu_> ... Yes, we need to look at the domain  range
09:53:36 <TallTed> q+
09:54:09 <JoeAndrieu_> brentz: then lets limit this to makes sure the ... this issue is seeking reconciliation between the vocabulary and the specification.
09:54:22 <JoeAndrieu_> ivan_: at the moment, there is no reconciliation needed. They are in sync. TODAY.
09:54:32 <brentz> ack TallTed
09:54:33 <JoeAndrieu_> ... the question is whether or not thats ok
09:55:16 <jquemada> jquemada has joined #vcwg
09:55:16 <brentz> q+ to suggest the scope of this issue
09:55:16 <JoeAndrieu_> TallTed: my concern is that what's in the spec may not be correct/as intended. I trust that Ivan has accurantely reflected in the spec,  in the vocab and diagram
09:55:49 <JoeAndrieu_> ... that revealed my concerns. With simpathy for the can of worms, that's when things come up
09:55:49 <ivan_> s/accurantely/accurately/
09:55:49 <JoeAndrieu_> q+ to say can of worms is about VCs = VPs
09:55:50 <JoeAndrieu_> ... some properties make sense on both VCs and VPs.
09:56:00 <JoeAndrieu_> ... Some don't. We should state that clearly.
09:56:12 <manu> q+
09:56:21 <brentz> ack brentz
09:56:22 <Zakim> brentz, you wanted to suggest the scope of this issue
09:56:24 <JoeAndrieu_> ... just because their named in a particular way isn't enough
09:56:48 <manu> scribe+
09:56:55 <JoeAndrieu_> brentz: so the scope of this issue is, this is what the scope says looking at the vocab. we need to make sure it is what we meant. Not an increase in scope.
09:56:55 <brentz> ack JoeAndrieu_
09:56:55 <Zakim> JoeAndrieu_, you wanted to say can of worms is about VCs = VPs
09:56:55 <TallTed> +1 to brentz's understanding and restatement
09:57:13 <ivan_> +1 to what Brent said
09:57:30 <manu> JoeAndrieu: The can of worms to avoid is not what we just talked about, we have to do the work that you clarified Brent... trying to harmonize VCs and VPs is problematic, they are different things... we shouldn't even assume that any properties are common.
09:57:33 <brentz> ack manu
09:57:57 <JoeAndrieu_> manu: that sounds right. +1 that we need to make sure the vocabulary expresses what we meant to express
09:58:30 <brentz> q?
09:58:38 <JoeAndrieu_> ... if implementers are telling us we need property x or y, that's one thing. but if we start doing that to add new properties to one or the other
09:59:36 <JoeAndrieu_> brentz: the action now: we need a number of volunteers to go through the spec and compare it to the diagram and see if it says what we meant it to say
09:59:36 <JoeAndrieu_> ... I'm willing to assign myself and work on it on Saturday
09:59:36 <manu> q+
09:59:36 <bumblefudge> i can do it with you this weekend, brent
09:59:36 <brentz> ack manu
09:59:47 <JoeAndrieu_> manu: I'm happy to be added to that list. I've gone through, I do think it says what the spec meant.
10:00:40 <phila> phila has joined #vcwg
10:00:40 <JoeAndrieu_> brentz: for those who have signed up to review. let's get those in no less than a week from today so Ivan can act on that feedback
10:01:21 <JoeAndrieu_> ivan_: I will be out from next Sunday.
10:02:34 <JoeAndrieu_> brentz: so less than a week, so Ivan has a chance to review before next week
10:02:34 <phila_> phila_ has joined #vcwg
10:02:34 <brentz> subtopic: https://github.com/w3c/vc-data-model/issues/1262
10:02:34 <manu> q+
10:02:39 <JoeAndrieu_> ... next issue: 1262. add revoked and expired to verificationMethod classes
10:02:55 <brentz> ack manu
10:02:56 <JoeAndrieu_> ... been conversation, but no one assigned. can anyone give a summary
10:03:15 <JoeAndrieu_> manu: there was a misalignment in the data integrity between multikey and jsonwebkey
10:03:33 <JoeAndrieu_> ... we've added those properties to json web key. now the same properties
10:04:09 <JoeAndrieu_> ... so that's fixed in DI, but we think Orie wanted that change reflected into the base context
10:04:40 <JoeAndrieu_> ... it is unlikely that that PR is going to be merged. The one that defines those keys.
10:04:40 <JoeAndrieu_> ... as a result, this issue is a bit moot.
10:04:45 <JoeAndrieu_> ... If we don't define the RDF classes for JWK and multikey in the base context (and we aren't), then we don't need to do anything with this issue.
10:04:54 <JoeAndrieu_> ... and the misalignment has been fixed in data integrity
10:05:04 <JoeAndrieu_> brentz: sounds like once that PR is closed, this issue should be closed.
10:05:17 <JoeAndrieu_> manu: i believe so, but we need to check if Orie agrees
10:05:55 <seabass> q+ to explain 1247
10:06:44 <JoeAndrieu_> brentz: having closed that PR. we should close this one. (after checking that we did in fact do that)
10:06:58 <JoeAndrieu_> ... any opposition to adding Pending-Close on this issue?
10:07:07 <JoeAndrieu_> ... hearing none. I'm going to add the tag
10:07:25 <brentz> subtopic: https://github.com/w3c/vc-data-model/issues/1247
10:07:38 <JoeAndrieu_> ... next up 1247. Verifier stored data vulnerabilities
10:07:42 <brentz> ack seabass
10:07:42 <Zakim> seabass, you wanted to explain 1247
10:07:54 <JoeAndrieu_> seabass: there's a lot here.
10:08:20 <JoeAndrieu_> ... we wanted to discuss the needed storing of PII.
10:09:18 <JoeAndrieu_> ... one of the requirements for that... the W3C has ... something about age verification and we have Zero Knowledge Proofs that can do verification without exposing the PII
10:09:25 <JoeAndrieu_> ... so this is not a technical issue, but a political one
10:09:57 <JoeAndrieu_> ... Not all of the VC users want to minimally implement this. They will take this as an opportunity to exploit this
10:10:30 <JoeAndrieu_> ... not necessary to correlate the age verification with the identity. all they need to know if their users are old enough, as required by law
10:10:46 <JoeAndrieu_> ... to accomodate that with the identity of the user is very invasive of privacy
10:10:55 <brentz> q+
10:11:07 <JoeAndrieu_> ... services that want to harvest data are going to use this as a justification for correlating individuals
10:11:17 <manu> q+
10:11:23 <JoeAndrieu_> ... the issue here is that the normative requiremetns for data processing are currently limited in our spec
10:11:42 <manu> q+ to note that we can provide guidance on best practices -- don't harvest data, minimal disclosure for transaction, etc.
10:12:03 <JoeAndrieu_> ... Governance can... gaurantee that verifiers maintain a record of age verification. we, as W3C, have to decide what we want to say about data processing
10:12:26 <JoeAndrieu_> ... we have to communicate to regulators the state of the latest technology
10:12:37 <JoeAndrieu_> ... There hasn't been enough communications with governments around the world
10:12:58 <JoeAndrieu_> q+ to ask about privacy considerations section
10:13:03 <kristina> i don't think we should overcomplicate this. a privacy consideration to say verifier must be very careful when storing PII is pretty standard and not too political
10:13:13 <manu> yes ^
10:13:19 <JoeAndrieu_> brentz: as far as the scope about what we can make recommendations for, we can make recommendations for those who are users of our data model
10:13:32 <JoeAndrieu_> ... we do not define processes (and cannot by our charter).
10:13:35 <osamu-n> osamu-n has joined #VCWG
10:13:35 <kristina> something like this: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-05#name-storage-of-signed-user-data
10:14:22 <JoeAndrieu_> ... we can add something in the privacy considerations sections, but its not in our scope to normatively address processing concerns
10:14:22 <seabass> q+
10:14:22 <JoeAndrieu_> ... the data model is our cutoff
10:14:22 <kristina> q-
10:14:22 <brentz> ack brentz
10:14:22 <brentz> ack manu
10:14:22 <Zakim> manu, you wanted to note that we can provide guidance on best practices -- don't harvest data, minimal disclosure for transaction, etc.
10:14:22 <JoeAndrieu_> manu: +1 to Kristina put into chat
10:14:22 <JoeAndrieu_> ... we shouldn't overcomplicate this
10:14:40 <kristina> i am ok being assigned to this
10:14:45 <JoeAndrieu_> ... What PING did in the review is that we say something about it. Not that we need to fix it, but add something to the privacy considerations.
10:15:04 <JoeAndrieu_> ... We already talked about data minimization, selective disclosure, and other mechanism to reduce data collection.
10:15:13 <JoeAndrieu_> ... This new sections should just speak to that.
10:15:15 <JoeAndrieu_> q-
10:15:31 <brentz> q?
10:15:33 <JoeAndrieu_> ... and it should say verifiers shouldn't ask for anything more than you need
10:15:52 <JoeAndrieu_> ... only collect the minimal
10:16:07 <JoeAndrieu_> ... PING just wanted us to cover that situation when VC data stores *are* compromised
10:16:41 <JoeAndrieu_> seabass: I agree with you. This is something the PING group is not asking us to address. So tentatively, we could mark this as Ready for PR
10:16:43 <brentz> ack seabass
10:17:05 <JoeAndrieu_> ... however, I'm concerned the privacy guarantees of VCs are going to be compromised by how we share this data.
10:17:22 <JoeAndrieu_> ... most web users understand the complexity of uploading a DL or passport.
10:17:46 <JoeAndrieu_> ... VCs are less visible than that, and we need to make sure we can communicate to end users the risks of what is happening
10:17:46 <brentz> q?
10:18:20 <JoeAndrieu_> brentz: it sounds like you could introduce a PR that would address this issue. So, if that's right, let's label it ready for PR.
10:18:47 <JoeAndrieu_> seabass: that's ok. but to take advantage of this meeting, we need to do as much as possible within this charter to help privacy
10:19:22 <JoeAndrieu_> ... we aren't allowed to create normative statements about what processing happens, but look at cookies
10:19:33 <JoeAndrieu_> ... Outside this group, we need a venue to address this.
10:19:50 <JoeAndrieu_> brentz: what's the timeline for a PR.
10:20:04 <JoeAndrieu_> seabass: I can make it a priority to get it by the end of next week
10:20:36 <JoeAndrieu_> ... The sooner we can have that text, the sooner we can realize if there might be objections later in the Process
10:20:50 <JoeAndrieu_> kristina: Are you going to object?
10:20:57 <JoeAndrieu_> seabass: no. but I'm concerned there may be
10:21:07 <JoeAndrieu_> brentz: next step: PR. Sooner is better.
10:21:45 <JoeAndrieu_> brentz: next issue is 1232. Revisit validations versus verification
10:21:50 <manu> scribe+
10:22:00 <brentz> subtopic: https://github.com/w3c/vc-data-model/issues/1232
10:23:11 <manu> brentz: Raised by Orie on behalf of Joe... what do you need to write a PR here?
10:23:11 <seabass> Scribe note: please replace 'users understand the complexity of uploading a DL or passport' with 'users understand the privacy risks of uploading a DL or passport'. My concern was not about complexity itself. Thank you.
10:23:21 <manu> JoeAndrieu: We have text in use cases document now, if people can look at the use case document, that would be helpful.
10:23:35 <manu> JoeAndrieu: PR 149 use cases has that document
10:23:58 <manu> https://github.com/w3c/vc-use-cases/pull/149
10:24:47 <osamu-n> osamu-n has joined #VCWG
10:24:52 <brentz_> brentz_ has joined #vcwg
10:25:03 <brent> q?
10:26:22 <TallTed> s/most web users understand the complexity of uploading a DL or passport/most web users understand the privacy risks of uploading a DL or passport/
10:26:44 <KyleHuang> KyleHuang has joined #vcwg
10:27:08 <KevinDeanGS1> KevinDeanGS1 has joined #vcwg
10:28:07 <manu> The group reads through PR 149...
10:28:16 <LaurensDebackere> LaurensDebackere has joined #vcwg
10:29:43 <JoeAndrieu_> +1 to Phila and DMV. Please comment and I'll work on it
10:30:06 <manu> brent: To summarize -- verification checks syntax and cryptography checks out, validation has to do with business logic, and that's how verification and validation are different from one another.
10:30:08 <manu> q+
10:30:28 <brent> ack manu
10:30:50 <manu> brent: If there was a PR in the core data model, that aligned with the use cases text, would that be appropriate to those in the WG?
10:31:11 <JoeAndrieu_> manu: The only thing that jumps out is the use of normative language in the use cases document
10:31:15 <JoeAndrieu_> ... it's a bit confusing
10:31:19 <selfissued> selfissued has joined #vcwg
10:31:19 <JoeAndrieu_> is it normative language or not?
10:31:21 <selfissued> present+
10:31:35 <JoeAndrieu_> ... The core seems correct and is a clarification the VCDM would benefit from
10:31:43 <JoeAndrieu_> q+ about normative
10:31:49 <manu> brent: any other comments from folks?
10:31:50 <manu> q- about
10:31:53 <manu> q- normative
10:32:00 <seabass> q+
10:32:00 <manu> q+ Joe
10:32:06 <shigeya> +1 on reference to DMV.
10:32:29 <manu> brent: I hear concern about normative language, much broader concern about use cases document -- issue on use cases document would be a good way to track that.
10:32:41 <manu> manu: I'd be fine w/ an issue to track that ^
10:32:55 <TallTed> q+ to suggest that normative language might best be replaced by REQUIREMENTS, turning this into a UCR
10:32:55 <JoeAndrieu_> brentz: the normative language is bigger than just this PR. so a separate issue on the use cases document is probably the right place to go
10:33:17 <manu> brent: With that, Joe, do you feel like issue 1232 -- do you feel confident moving forward with a PR at this point?
10:33:27 <brent> q?
10:33:57 <brent> ack seabass
10:34:00 <manu> JoeAndrieu: Yes, seniment feels like this is the right direction. Would like to hear from others on the queue. Challenge with normative language is that this is requirements for the spec, that's why we use normative language.
10:34:17 <manu> q+ to note he's fine w/ normative statements on requirements for spec, we might want to clarify that.
10:34:27 <JoeAndrieu_> q-
10:34:32 <TallTed> ack TallTed
10:34:32 <Zakim> TallTed, you wanted to suggest that normative language might best be replaced by REQUIREMENTS, turning this into a UCR
10:34:36 <JoeAndrieu_> q- Joe
10:35:12 <manu> TallTed: We might want to use requirements language instead of normative statements.
10:35:18 <manu> brent: PR within the next week?
10:35:54 <kristina> q?
10:37:08 <kristina> ack manu
10:37:08 <Zakim> manu, you wanted to note he's fine w/ normative statements on requirements for spec, we might want to clarify that.
10:37:08 <JoeAndrieu_> +1 manu I agree we should add that. A note on this PR or in a new issue would tag it for me to follow up on
10:37:08 <brent_> brent_ has joined #vcwg
10:37:08 <JoeAndrieu_> brent: next issue 1155 to track the internationalization review
10:38:10 <brent_> subtopic: https://github.com/w3c/vc-data-model/issues/1155
10:38:10 <brent_> q?
10:38:10 <manu> manu: Lets clarify that normatie statements for use cases docment is requirements on VC Data Model.
10:38:18 <JoeAndrieu_> ... there was a conversation about this issue because other issues track those concerns more directly, then more conversation happened here
10:38:18 <seabass> q+
10:38:18 <manu> q+
10:38:18 <JoeAndrieu_> ... so what needs to happen to say that we have addressed this issue
10:38:18 <brent_> ack seabass
10:38:31 <brent_> ack manu
10:38:31 <JoeAndrieu_> seabass: this is a traffic issue so its convenient to keep it open
10:38:31 <NickLansleyGS1_> NickLansleyGS1_ has joined #vcwg
10:38:31 <manu> https://github.com/w3c/vc-data-model/issues/1264
10:38:33 <JoeAndrieu_> manu: i agree with Sebastian. The other data point is that conversation started here, but moved to 1264.
10:38:42 <JoeAndrieu_> ... specifically that issue. We do have an outstanding concern.
10:38:55 <JoeAndrieu_> ... Namely what are we telling people to do about language strings
10:39:06 <manu> https://github.com/w3c/vc-data-model/issues/1264#issuecomment-1712807665
10:39:09 <JoeAndrieu_> ... I'll put a link to the options
10:39:56 <JoeAndrieu_> ... we can close or open. This issue: just one more item we need to resolve before CR.
10:39:56 <shigeya> +1 on keeping this issue open.
10:39:56 <JoeAndrieu_> ... the way we sorted the issues we have a PR, but it doesn't address all the language options
10:41:01 <JoeAndrieu_> ... so we need to talk about this still
10:41:01 <manu> q+
10:41:01 <JoeAndrieu_> brent_: if we need to talk about this in this phase, we should have it now
10:41:01 <brent_> ack manu
10:41:01 <JoeAndrieu_> manu: thanks. The internationalization group asked us to specify how a default language for a document is specified.
10:41:01 <JoeAndrieu_> ... we responded by saying we have name & description in the base context, so we can use that as an example.
10:41:34 <JoeAndrieu_> ... we explain that in the spec today.
10:41:41 <manu> https://github.com/w3c/vc-data-model/issues/1264#issuecomment-1712807665
10:41:41 <JoeAndrieu_> ... They came back and said that he felt uncomfortable because we were not specifying a default language for the VC
10:41:41 <JoeAndrieu_> ... That led to different proposal, each with different tradeoffs
10:41:41 <seabass> q+
10:41:45 <JoeAndrieu_> ... options A, B, C, D
10:41:54 <JoeAndrieu_> ... I don't think we have time to go over all of these today
10:42:05 <JoeAndrieu_> ... I think what we are doing in the spec is the best that we can do.
10:42:17 <JoeAndrieu_> ... but that depends on what the i18n group feels
10:42:28 <manu> s/C, D/C, D, and E/
10:42:31 <dmitriz> what is the difference between options A and C?
10:42:33 <manu> q+ to talk about the options
10:43:38 <ivan_> q+
10:43:38 <kristina> ack seabass
10:43:38 <JoeAndrieu_> brent_: I don't know that we can avoid talking about the options
10:43:38 <kristina> q?
10:43:38 <JoeAndrieu_> seabass: thank you manu for creating the issue with the clear options
10:43:38 <JoeAndrieu_> ... option C is what I proposed a resolution for
10:43:38 <JoeAndrieu_> ... I think we are close to consensus on this issue
10:43:38 <kristina> ack manu
10:43:38 <Zakim> manu, you wanted to talk about the options
10:43:38 <JoeAndrieu_> manu: I can go through the options ...
10:43:46 <JoeAndrieu_> brentz: since Sebastian thinks C might be a winner, let's start there.
10:43:59 <JoeAndrieu_> manu: Option C uses JSON-LD language features
10:44:08 <JoeAndrieu_> ... @value for value of a string
10:44:15 <JoeAndrieu_> ... @language and @direction
10:44:21 <JoeAndrieu_> ... benefit is already in JSON-LD
10:44:31 <JoeAndrieu_> ... drawback is that people who don't like JSON-LD might not like this option
10:44:42 <JoeAndrieu_> ... So we need to hear back from people who want to use something else
10:44:53 <brent> brent has joined #vcwg
10:44:56 <brent> q?
10:45:02 <JoeAndrieu_> ... also Option C doesn't set a base language for the document. That's not clear if the international WG will go for that.
10:45:07 <brent> ack ivan_
10:45:35 <JoeAndrieu_> ivan_: I have a comment on the tech. but a practical comment. Ed? is around, so let's try to talk to him.
10:45:49 <JoeAndrieu_> brentz: That's right. We can take advantage of TPAC
10:45:55 <brent> s/Ed?/Addison/
10:45:57 <seabass> q+
10:46:06 <JoeAndrieu_> ivan_: on the technical side, the title is misleading because the JSON-LD language features are more than what is in option C.
10:46:35 <JoeAndrieu_> ... we can use JSON-LD features the way its used in 1.0 and we can set the direction for the whole file if we want (using JSON-LD)
10:47:07 <JoeAndrieu_> ... But I think we should not spend to much on this. JSON-LD has gone to great efforts to work out language with the i18n group.
10:47:16 <pchampin> https://www.w3.org/TR/string-meta/
10:47:21 <JoeAndrieu_> ... So we should not cherry pick
10:47:47 <JoeAndrieu_> ... There are not thousands of ways to do that in JSON either. We may have a long conversation (with some beer) to include an @ sign or alias that out.
10:48:03 <JoeAndrieu_> ... That's the only question for me that's really relevant (the aliasing).
10:48:23 <JoeAndrieu_> ... We know (from HTML) in many actors in countries where people will ignore these language features.
10:48:27 <JoeAndrieu_> ... That's life.
10:48:43 <manu> q+ to note that setting @language for entire document would be the wrong thing to do. If we make this change, we'll have to change the way @language and @direction works for name/description.
10:48:47 <brent> q+
10:49:04 <brent> ack seabass
10:49:08 <JoeAndrieu_> seabass: I'd like to agree. Two things: we are providing the option to do language support correctly. We can't force it, but we can enable it.
10:49:31 <ivan_> q+
10:49:43 <JoeAndrieu_> ... second, the idea of a JSON-LD only idea. There's nothing in JSON-LD that requires "full JSON processing" for these language features
10:50:01 <brent> ack manu
10:50:01 <Zakim> manu, you wanted to note that setting @language for entire document would be the wrong thing to do. If we make this change, we'll have to change the way @language and @direction
10:50:04 <Zakim> ... works for name/description.
10:50:05 <JoeAndrieu_> ... So for those here with no interest in RDF, this shouldn't add any complexity
10:50:26 <JoeAndrieu_> manu: this comes about because some implementers look at the @sign and freak out
10:50:29 <dmitriz> well so wait, why dont we alias out the @ sign?
10:50:41 <JoeAndrieu_> ... so if no one is complaining about that, we can just adopt it
10:51:07 <JoeAndrieu_> ... If we alias out the @sign and we apply that against all VCs everywhere, then nobody can have a property named "language", which is prolematice
10:51:13 <ivan> q?
10:51:18 <JoeAndrieu_> s/prolematice/problematic
10:51:52 <JoeAndrieu_> ... The other thing.. Ivan said we could just depend on the JSON-LD properties.
10:52:02 <JoeAndrieu_> ... there are examples where that would clearly be wrong
10:52:39 <JoeAndrieu_> ... if we allow @language in the context, @langauge="es" at the top. That would apply that language to every text string in the document, including base64 encoded values, etc.
10:53:04 <JoeAndrieu_> ... so we need to provide guidance that doesn't lead to meaningless decoration
10:53:24 <brent> ack brent
10:53:24 <JoeAndrieu_> ... If people are good with @value, @langauge, and @direction we're good. Aliasing is ok, but not great.
10:53:58 <JoeAndrieu_> brent: If we were to proceed as mentioned, if we go with those @values, is there anyone who would be opposed to that?
10:54:12 <dmitriz> q+
10:54:17 <JoeAndrieu_> brent: I'm not seeing any opposition, so I think this is read for PR
10:54:17 <brent> ack ivan
10:54:26 <manu> q+ to note we'll have to change the way name and description works
10:54:58 <JoeAndrieu_> ivan: JSON-LD scares the hell out of people sometimes because they are nervous about RDF. I have to emphasize what is in JSON-LD for the language has nothing to do with RDF
10:55:33 <JoeAndrieu_> ... The features themselves, these are generic features that can be used for ANY JSON vocabulary.
10:55:37 <JoeAndrieu_> ... No magic or hidden RDF
10:55:48 <JoeAndrieu_> ... We can haggle around the @sign.
10:55:54 <JoeAndrieu_> ... Personally I prefer keeping it, but that's me
10:56:10 <JoeAndrieu_> ... we have done that for id & type
10:56:13 <brent> ack dmitriz
10:56:40 <ivan> q+
10:56:46 <JoeAndrieu_> dmitriz: re: alias. I'd argue we have a better way than flipping a coin. We know there is signifcant pushback on @s
10:56:51 <JoeAndrieu_> ... can we have a poll
10:56:51 <manu> q+ to be really concerned around aliasing @value to value
10:57:00 <brent> ack manu
10:57:00 <Zakim> manu, you wanted to note we'll have to change the way name and description works and to be really concerned around aliasing @value to value
10:57:05 <brent> q+ to poll
10:57:27 <seabass> q+
10:57:28 <andres> q+
10:57:28 <JoeAndrieu_> manu: two things. If we decide to use JSON-LD keywords, we'll have to change the way name & description work
10:58:13 <JoeAndrieu_> ... two: I'm concerned about aliasing "value". I'd feel better if we had that for a while, I'd feel better.
10:58:13 <andres> Is it possible to alias "lang_value" to "@value" ?
10:58:13 <andres> q-
10:58:44 <JoeAndrieu_> ... I do agree with dmitriz that there is an allergic reaction to seeing @signs in JSON
10:58:44 <JoeAndrieu_> ... Don't think its an easy answer. We should be ready to trigger another CR later
10:58:55 <brent> ack ivan
10:59:18 <JoeAndrieu_> ivan: I forgot to react to Manu about setting global language. From the JSON-LD point of view, that's not really a problem. Because we can specific that language doesn't apply.
10:59:29 <manu> q+
10:59:30 <JoeAndrieu_> ivan: for JSON only users they would ignore it.
10:59:36 <brent> ack brent
10:59:36 <Zakim> brent, you wanted to poll
10:59:58 <brent> POLL: we will use keywords @language, @direction, and @value for language and alias them to 'language', 'lang_direction' and 'lang_value'
11:00:06 <andres> +1
11:00:10 <decentralgabe> +1
11:00:14 <dmitriz> +1 (though would much prefer 'direction' and 'value')
11:00:22 <seabass> +1 for one option, +1 for the other. I think that counts as abstaining, but I will definitely not oppose either option :)
11:00:22 <TallTed> +0.5
11:00:23 <DavidC> +1
11:00:25 <ivan> +1 (like dmitriz)
11:00:25 <JoeAndrieu_> 0
11:00:29 <NickLansleyGS1_> +1
11:00:33 <manu> +0.5 (with severe trepidation wrt. stomping on existing data models out there) -- also, language/direction/value (not what was mentioned)
11:00:46 <shigeya> +1
11:00:47 <phila> -1
11:00:50 <pauld_gs1> +1
11:01:06 <bumblefudge> +1
11:01:07 <Jay> +1
11:01:20 <osamu-n> osamu-n has joined #vcwg
11:01:28 <manu> q+ to ask ivan to clarify what he said
11:01:28 <dmitriz> can Phil and Manu explain why dangerous? and what holes?
11:01:36 <JoeAndrieu_> phila: I agree with Manu's comments, it's dangerous. but my participation here is minimal, so I understand
11:01:43 <JoeAndrieu_> ... this could impact things in unintended ways
11:01:54 <dmitriz> 'id' and 'type' are also very common words
11:01:58 <JoeAndrieu_> ... using a common word like value to mean something that other people don't use it for
11:02:52 <brent> q?
11:02:52 <DavidC> I would be -1 if the alias was 'value' and not 'lang_value'
11:02:52 <JoeAndrieu_> brentz: clarification the proposal is for lang_value and lang_direction, not "value"
11:03:00 <andres> ditto to what DavidC said above
11:03:00 <JoeAndrieu_> phila: Ah... that's much better
11:03:00 <pauld_gs1> agree DavidC.
11:03:05 <manu> also, let's not use underscores since none of our other properties have underscores :)
11:03:07 <brent> ack seabass
11:03:15 <manu> langString <-- would be better
11:03:23 <JoeAndrieu_> seabass: The aliasing of @ to something else simply makes the @sign is implicit
11:03:34 <brent> ack manu
11:03:34 <Zakim> manu, you wanted to ask ivan to clarify what he said
11:03:56 <JoeAndrieu_> manu: ivan said some stuff I didn't understand. I'd like to.
11:03:56 <dmitriz> +1 camel case vs snake case
11:04:12 <JoeAndrieu_> ... If we alias to lang_string, lang_direction, then that's probably fine
11:04:29 <JoeAndrieu_> ... it would be nicer if people didn't get all bent out of shape about @signs
11:04:54 <ivan> +1 to camel, to be slignes with the style used for other properties in VCDM
11:04:57 <JoeAndrieu_> ... Also, what Phil said: there's a lot of data out there that already uses value and it would trigger a lot of confusion
11:05:15 <ivan> s/slignes/alignes/
11:05:22 <JoeAndrieu_> ... The problem is @value means something more than just language
11:05:26 <dmitriz> q+
11:05:32 <seabass> q+ to say goodbye and a last point in a hurry
11:05:40 <JoeAndrieu_> ... That means ... it's not a straightforward decisions
11:05:41 <seabass> Can I queue jump please
11:06:09 <JoeAndrieu_> brentz: we can keep going it.
11:06:17 <brent> ack seabass
11:06:17 <Zakim> seabass, you wanted to say goodbye and a last point in a hurry
11:06:25 <brent> ack dmitriz
11:06:25 <JoeAndrieu_> seabass: I'm happy to help with PR
11:06:39 <pchampin> manu, people can still use `@value` when `lang_value` does not make sense. But you can't always prevent them to shoot themselves in the foot if they want to.
11:06:56 <JoeAndrieu_> dmitriz: to clarify, if we alias value to something else. It's the other direction. Aliasing from lang_value to @langauge, but you can still use @language elsewhere.
11:07:33 <JoeAndrieu_> manu: if you compact using the VC context and you have @value throughout your JSON-LD, all those @value will be changed
11:07:52 <brent> q?
11:08:11 <JoeAndrieu_> ivan: if you make the alias an embedded context for a property.
11:08:24 <JoeAndrieu_> ... for every property that is potential language and you scope the context.
11:08:40 <JoeAndrieu_> ... That's what we suggesting is to not make it scoped
11:08:51 <JoeAndrieu_> ... Option C is global, unscoped
11:09:10 <pchampin> oh, yes, compaction will mess it up :-(
11:09:12 <dmitriz> so why not use option A?
11:09:16 <JoeAndrieu_> ivan: so for the other properties, you can make it null
11:09:30 <JoeAndrieu_> manu: we need a deeper conversation and I don't know if we can get through this in 20 minutes
11:09:43 <manu> option A /is/ what we're doing in the spec today :)
11:09:56 <JoeAndrieu_> brent: this is a before CR issue. Is that because there will be normative changes to the spec?
11:10:00 <dmitriz> ok. and what is the problem with it today? just the @ signs?
11:10:06 <JoeAndrieu_> manu: yes. this has normative impact
11:10:15 <JoeAndrieu_> brent: so we will add time for this during TPAC
11:10:18 <ivan> rrsagent, draft minutes
11:10:19 <RRSAgent> I have made the request to generate https://www.w3.org/2023/09/14-vcwg-minutes.html ivan
11:10:52 <JoeAndrieu_> brentz: Break for lunch! Back in 80 minutes with or without Brent
11:11:02 <manu> no, it doesn't provide a language for the entire VC and it requires context authors to do scoped language stuff
11:11:04 <ivan> ivan has joined #vcwg
11:11:23 <bumblefudge> present -
11:11:47 <dmitriz> @manu - what do you mean by scoped language stuff? what will it require them to do?
11:12:31 <manu> this: https://github.com/w3c/vc-data-model/blob/main/contexts/credentials/v2#L122-L127
11:12:39 <manu> (which, btw, I think is fine ^)
11:14:34 <dmitriz> interesting.
12:11:23 <Jay> Jay has joined #vcwg
12:13:12 <pauld_gs1> pauld_gs1 has joined #vcwg
12:27:30 <ivan> ivan has joined #vcwg
12:30:04 <decentralgabe> decentralgabe has joined #vcwg
12:30:16 <brent> brent has joined #vcwg
12:30:23 <phila> phila has joined #vcwg
12:31:36 <Jay> Jay has joined #vcwg
12:32:06 <decentralgabe> scribe+
12:32:30 <decentralgabe> brent: next topic: data integrity, 25m each - core, ecdsa, eddsa, then more issue triage or json schema early
12:32:45 <brent> Topic: Data Integrity - Core Spec
12:32:59 <manu> Slides here: https://docs.google.com/presentation/d/1a2T1gEuJvgPXsuWaniM8k4jJtu0nbsqsxRGpYrjKzJs/edit#slide=id.p
12:33:13 <jose-gataca> jose-gataca has joined #vcwg
12:33:15 <decentralgabe> ... data integrity is close to CR. manu will walk through the status & scope of remaining work for CR & beyond
12:33:28 <dmitriz> dmitriz has joined #vcwg
12:33:51 <andres> andres has joined #vcwg
12:34:06 <LaurensDebackere> LaurensDebackere has joined #vcwg
12:34:14 <bigbluehat> present+
12:34:23 <LaurensDebackere> present+
12:34:29 <decentralgabe> manu: slides in chat. VC Data Integrity - 3 passes: 1 - base spec, 2 - ecdsa suites, 3 - eddsa suites
12:34:38 <selfissued> selfissued has joined #vcwg
12:34:48 <selfissued> present+
12:34:55 <dlongley> present+
12:35:01 <decentralgabe> ... proposals for each to transition to CR. first some background to catch everyone up. what does the spec do? ensure authenticity and integrity of a VC
12:35:43 <kristina> kristina has joined #vcwg
12:35:43 <dtluu> dtluu has joined #vcwg
12:36:25 <decentralgabe> ... secures a VC using a digital signature and related proofs. 3 usages today. 1 truage in the US, 150k retail stores, 50M age checks per day. using W3C VCs
12:39:01 <tzviya> tzviya has joined #vcwg
12:40:13 <decentralgabe> ... sharing to establish this is used in the real world today, will get to open issues shortly
12:44:44 <brent> q?
12:46:42 <nadalin_> nadalin_ has joined #vcwg
12:47:27 <przemek> przemek has joined #vcwg
12:47:29 <decentralgabe> ... CR is ready for the base spec, no pre-CR issues left
12:47:38 <JoeAndrieu> JoeAndrieu has joined #vcwg
12:48:15 <decentralgabe> ... any questions on status/state? want to request publication to go to CR
12:48:15 <Jay> q+
12:48:15 <brent> ack Jay
12:48:15 <phila> q+
12:48:26 <DavidC> DavidC has joined #vcwg
12:48:36 <DavidC> present+
12:49:50 <decentralgabe> Jay: re 2nd slide, result can be valid/invalid ... from verify -> valid/invalid, how do you understand the result?
12:49:50 <LaurensDebackere> LaurensDebackere has joined #vcwg
12:49:50 <decentralgabe> manu: meant to speak directly to the verification process. should change to say verified/failed verification. validation is something different that happens in the VC process after verifying the digital signature
12:49:53 <dlongley> language should say "verified" / "not verified" or "success" / "failure", not bring in "valid/invalid" language.
12:50:00 <decentralgabe> ... should change the diagram so it says verified / not verified
12:50:05 <brent> ack phila
12:50:23 <selfissued> q+
12:50:35 <selfissued> https://github.com/w3c/vc-data-integrity/issues/191 should be tagged pre-CR but I don't have the rights to do it
12:50:45 <decentralgabe> phila: from canonicalization/hash wg, we resolved monday to take it to CR. Sebastian pointed out something not so great. Should be able to go to CR in 2 weeks time, so we are aligned.
12:50:46 <brent> ack selfissued
12:51:03 <decentralgabe> selfissued: filed issue 191 and 192 which should be considered pre-CR, don't have the rights to tag since not an editor
12:51:05 <brent> q?
12:51:34 <decentralgabe> manu: they were just filed, can you elaborate?
12:51:37 <selfissued> q+
12:51:39 <pauld_gs1> q+
12:51:46 <pauld_gs1> q-
12:51:58 <seabass> q+
12:52:01 <decentralgabe> brent: will take an opportunity to look at issues on data integrity, then go into the sub specs
12:52:02 <brent> subtopic:https://github.com/w3c/vc-data-integrity/issues/191
12:53:03 <decentralgabe> selfissued: in doing due diligence on IETF standardization on mutlibase I discovered a normative dependence on multibase in DI, even though it's not a standard. we shouldn't be doing that. we shouldn't take normative deps on non-standards. requesting in #191 the definition of proof be changed to not use multibase
12:53:10 <brent> q?
12:53:16 <brent> ack selfissued
12:53:20 <dlongley> https://w3c.github.io/vc-data-integrity/#resource-integrity <-- see "At risk" on what selfissued just said.
12:53:22 <brent> ack seabass
12:53:28 <dlongley> q+
12:53:50 <decentralgabe> seabass: been discussing a lot on how to proceed. one option is to include the definitions inside the specification, since multibase is not a complex format and it is stable. can be in DI itself
12:54:01 <decentralgabe> ... in the future can add an IETF normative dependency
12:54:03 <brent> ack dlongley
12:54:28 <manu> q+
12:55:09 <decentralgabe> dlongley: as seabass said, we have a feature at risk in the spec for exactly this reason. don't think it's a pre-CR issue. we can change the current CR to fix this language as necessary
12:55:10 <brent> ack manu
12:55:10 <selfissued> q+
12:55:10 <JoeAndrieu> JoeAndrieu has joined #vcwg
12:55:25 <brent> q+
12:55:34 <decentralgabe> manu: to Mike - was your objection to the normative reference or the use of multibase at all? it is marked at risk. currently all implementers we have are using multibase. asking them to change their implementations would be problematic. would like to understand your concerns more
12:55:44 <brent> ack selfissued
12:56:41 <decentralgabe> selfissued: I have objections to both. procedurally, normative reference is a stronger argument for the working group since we agreed to not normatively use non standard features - so it has to go. many of you are aware, I wrote a piece 'multiformats are considered harmful' and asked it not be a candidate for IETF standardization. currently being discussed on the mailing list
12:56:54 <dmitriz> q+
12:56:59 <andres> Details in https://self-issued.info/?p=2408
12:57:09 <seabass> q+
12:57:22 <manu> q+ to note that normative references to values that are not going to change is fine. Also, that is not how Multibase is used at all in our specifications.
12:57:26 <brent> ack brent
12:57:27 <decentralgabe> ... philosophically against multiformats since it does not make a choice. different impls may make different choices - base10,32,58,64... they won't interoperate. interoperation is facilitated by making a choice, multibase is a failure to make a choice. make a choice!
12:57:28 <dmitriz> q-
12:57:59 <selfissued> q+
12:58:03 <decentralgabe> brent: appreciate that there's a feature at risk tag. is the intention, should multibase not be standardized by the time this moves from CR to REC, would the current link be moved to a non normative reference?
12:58:12 <brent> ack seabass
12:58:43 <manu> q+ to remove reference if spec doesn't exist in IETF
12:58:50 <Hendry__IMDA_> Hendry__IMDA_ has joined #Vcwg
12:59:11 <decentralgabe> seabass: (responding to Mike) the more choices the more interop you get ... need to facilitate ease of interop. having metadata is useful. would it be acceptable, if in data integrity, we limited which encodings would be used? e.g. saying you must use base64, but encode with the right multibase header
12:59:11 <brent> ack manu
12:59:11 <Zakim> manu, you wanted to note that normative references to values that are not going to change is fine. Also, that is not how Multibase is used at all in our specifications. and to
12:59:15 <Zakim> ... remove reference if spec doesn't exist in IETF
13:00:13 <GregB> GregB has joined #vcwg
13:00:27 <GregB> present+
13:00:27 <decentralgabe> manu: 3 things. Mike said that WGs can't cite things that are not at the same level of maturity from a standards perspective - not correct. if a WG can demonstrate that a normative dep wont change, then it's fine to cite it. we're doing that with JSON Schema - not an IETF RFC, but we have a specification, went through a lot of discussion at the W3C, has way more dependencies which could be changed
13:01:13 <decentralgabe> ... don't think this is a reason to not have normative dependencies. we use 2 multibase values: z and u, that's it. we could get rid of the normative link, define the headers in our spec to address it, but the normative dep is defensible since those values haven't changed in years and wont change since they're used in other production systems
13:01:44 <decentralgabe> ... as Ivan notes, schema.org is used. allowed to normatively reference it if its not expected to change and this isnt
13:02:38 <wonsuk_> wonsuk_ has joined #vcwg
13:02:42 <decentralgabe> ... you asked for a single base encoding on what we're using, not allow any random base encoding...this is what we do in our suites. a different crypto suite may choose a different encoding. limiting what every cryptosuite can do seems problematic. in this WG we have picked one base encoding format. the basis for your objection is unfounded
13:02:51 <Kkoiwai> Kkoiwai has joined #vcwg
13:02:58 <ivan> present+ identitywoman
13:03:04 <kristina> kristina has joined #vcwg
13:03:07 <ivan> present+ bigbluehat
13:03:15 <decentralgabe> ... (to Brent) ... can we remove the ref at a later date if it doesn't surface at IETF? yes we can do that, and we can specify the 'z' and 'u' values in our specification
13:03:27 <brent> q?
13:03:30 <brent> ack selfissued
13:04:14 <manu> q+
13:04:14 <decentralgabe> selfissued: you could remove the reference now and not break uses of b64 encoding if you said the value is the character 'u' + b64 proof value. I could live with that, but think its unnecessary. choosing one is making a choice, then won't need the ref at all.
13:04:17 <brent> ack manu
13:04:54 <seabass> q+
13:05:27 <dmitriz> q+ to ask about base64url
13:05:27 <decentralgabe> manu: I am hearing you would not object to us using a header, and pick b64 for everything. the reality for the implementations is not that. implementers have gone another way. we provide a header so people know what the base encoding format is. we could remove the normative ref to multibase and then have a header as a compromise
13:05:27 <brent> ack seabass
13:05:35 <decentralgabe> seabass: if that satisfies Mike I am happy to make that compromise myself and make it an informative reference. we are waiting for the spec to catch up
13:05:41 <brent> ack dmitriz
13:05:41 <Zakim> dmitriz, you wanted to ask about base64url
13:06:02 <decentralgabe> dmitriz: Is b64url itself an RFC?
13:06:07 <decentralgabe> brent: answer is yes
13:06:21 <brent> q?
13:07:06 <decentralgabe> ... are you and Sebastian as editors ok with addressing this issue?
13:07:08 <decentralgabe> manu/seabass: yes
13:07:10 <ivan> q+
13:07:26 <decentralgabe> seabass: not sure the comparison to b64url ...
13:07:34 <decentralgabe> selfissued: you can read about it in RFC 7515
13:07:38 <brent> ack ivan
13:07:49 <decentralgabe> ivan: vocab has to change as well, since multibase is in the vocab now
13:08:09 <decentralgabe> ... you don't have to answer now, tell me when you go to change the PR
13:08:15 <seabass> +1 then.
13:08:15 <decentralgabe> manu: I will think about you Ivan
13:08:21 <ivan> :-)
13:08:45 <seabass> q+ to summarise
13:08:55 <dlongley> +1 to run proposal inclusive of the changes being discussed
13:09:00 <decentralgabe> ... let's run a proposal and then given that...advance to CR
13:09:11 <decentralgabe> brent: next up 192, link in chat
13:09:58 <brent> ack seabass
13:09:58 <Zakim> seabass, you wanted to summarise
13:10:12 <decentralgabe> seabass: (to summarize) - we are going to, in the cryptosuites, to have a specific encoding, for the spec text we are using a format compatible with multibase, so that if it becomes a standard we will use it normatively. we won't publish a normative ref if it's not ready by REC
13:10:17 <decentralgabe> manu: yes matches my understanding
13:10:18 <brent> subtopic: https://github.com/w3c/vc-data-integrity/issues/192
13:10:19 <bigbluehat> +1 to seabass's summary
13:10:29 <manu> q+ to agree w/ mike's changes
13:11:12 <decentralgabe> selfissued: the spec includes a note saying multibase/hash are being standardized at the IETF in a multiformats WG. for the record, there is no multiformats WG, there is a mailing list. it is up to the IESG to create a group. we should be accurate in what we're saying
13:11:26 <seabass> +1 to these changes for clarity. Happy to be assigned.
13:11:29 <decentralgabe> ... change to say 'it may be standardized' and another to correctly cite its a mailing list not a wg
13:11:32 <brent> ack manu
13:11:32 <Zakim> manu, you wanted to agree w/ mike's changes
13:11:38 <decentralgabe> manu: +1 to those changes
13:12:10 <decentralgabe> brent: can continue on with manu's presentation and move towards proposals
13:12:16 <ivan> subtopic: CR proposals
13:12:50 <decentralgabe> manu: (resuming @ slide 13)
13:12:58 <ivan> q+
13:13:19 <andres> q+
13:13:38 <brent> ack ivan
13:14:00 <nadalin_> what about test suite?
13:14:27 <decentralgabe> ivan: I would propose to not write the final URL, do not commit ourselves in the proposal to a specific date. it will depend on changes that were just mentioned, and myself - has to go through me. and I have some time off in 10 days. editors and I can agree on a final date
13:14:35 <brent> ack andres
13:14:36 <seabass> nadalin_: we have a test suite ready for all the mandatory features.
13:14:38 <Hendry> Hendry has joined #Vcwg
13:14:49 <manu> q+
13:14:55 <decentralgabe> andres: this proposal references that the implementations must each implement each mandatory MUST feature, can you comment on the state of the test suite which will be used?
13:14:56 <brent> ack manu
13:16:03 <decentralgabe> manu: this is standard language at the w3c, for the test suites we have ... for each crypto suite we are already testing each normative statement. have a bit of work to do, and need to find out things through implementations that we need to fix.
13:16:23 <decentralgabe> ... to be clear we have many implementations at this point. need to make sure each one is accurate. did that answer your question?
13:16:31 <decentralgabe> andres: yes...will the test suite change during the process?
13:16:39 <decentralgabe> manu: yes, it's expected to change based on implementer feedback
13:17:05 <decentralgabe> ivan: process wise, we can go into CR without the tests themselves, if we know how we want to test. tests can change up to CR
13:17:08 <ivan> q+
13:17:22 <brent> ack ivan
13:18:23 <decentralgabe> ... when we submit the CR request, and put a minimum time for outside review, within which we're not allowed to go to PR
13:18:36 <brent> q?
13:18:38 <decentralgabe> manu: believe text reflects what Ivan wants (text updated)
13:18:52 <brent> PROPOSAL: Request the publication of the Verifiable Credential Data Integrity 1.0 specification, with resolutions to issues 191 and 192 integrated, as a Candidate Recommendation with a CR period ending two months after publication and with exit criteria requiring two independent implementations of each mandatory (MUST) feature in the specification.
13:18:58 <manu> +1
13:18:59 <seabass> +1
13:18:59 <dlongley> +1
13:18:59 <phila> +1
13:18:59 <pauld_gs1> +1
13:18:59 <ivan> +1
13:19:00 <decentralgabe> +1
13:19:00 <JoeAndrieu> JoeAndrieu has joined #vcwg
13:19:01 <dmitriz> +1
13:19:01 <andres> +1
13:19:03 <selfissued_> selfissued_ has joined #vcwg
13:19:04 <bigbluehat> +1
13:19:07 <brent> 0
13:19:07 <JoeAndrieu> +1
13:19:08 <GregB> +1
13:19:09 <TallTed> +1
13:19:14 <shigeya> +1
13:19:17 <selfissued_> 0
13:19:18 <Jay> +1
13:19:18 <DavidC> +1
13:19:22 <hsano> +1
13:19:22 <nadalin_> 0
13:19:43 <LaurensDebackere> LaurensDebackere has joined #vcwg
13:19:49 <brent> RESOLVED: Request the publication of the Verifiable Credential Data Integrity 1.0 specification, with resolutions to issues 191 and 192 integrated, as a Candidate Recommendation with a CR period ending two months after publication and with exit criteria requiring two independent implementations of each mandatory (MUST) feature in the specification.
13:20:00 <selfissued_> present+
13:20:11 <decentralgabe> manu: moving onto the crypto suites
13:20:28 <decentralgabe> ... (back to presentation)
13:20:45 <osamu-n> osamu-n has joined #vcwg
13:22:24 <kristina> q?
13:23:18 <kristina> PROPOSAL: Request publication of the Data Integrity EdDSA Cryptosuites v1.0 specification as a Candidate Recommendation with a CR period ending two months after the publication date and with exit criteria requiring two independent implementations of each mandatory (MUST) feature in the specification.
13:23:19 <ivan> q+
13:24:05 <kristina> ack ivan
13:25:39 <kristina> q?
13:25:39 <nadalin_> so plans for wide review period?
13:25:39 <decentralgabe> nadalin_: is there a wide review before a CR?
13:25:39 <decentralgabe> kristina: horizontal review was done
13:25:39 <decentralgabe> nadalin_: for what manu is suggesting?
13:26:13 <decentralgabe> manu: all horizontal reviews have been completed. i18n, a11y, privacy, security, TAG, believe that's all
13:26:20 <decentralgabe> ... going to CR is a way to get further review, implementer feedback, and more review
13:26:35 <kristina> q?
13:27:16 <kristina> PROPOSAL: Request publication of the Data Integrity EdDSA Cryptosuites v1.0 specification as a Candidate Recommendation with a CR period ending two months after the publication date and with exit criteria requiring two independent implementations of each mandatory (MUST) feature in the specification.
13:27:16 <manu> +1
13:27:16 <dlongley> +1
13:27:16 <decentralgabe> +1
13:27:16 <pauld_gs1> +1
13:27:16 <GregB> +1
13:27:16 <ivan> +1
13:27:16 <dmitriz> +1
13:27:16 <TallTed> +1
13:27:16 <phila> +1
13:27:16 <bigbluehat> +1
13:27:16 <andres> +1
13:27:16 <seabass> +1
13:27:16 <selfissued_> 0
13:27:16 <nadalin_> 0
13:27:16 <hsano> +1
13:27:16 <JoeAndrieu> +1
13:27:25 <Jay> +1
13:27:54 <decentralgabe> kristina: resolved!
13:27:57 <kristina> RESOLVED: Request publication of the Data Integrity EdDSA Cryptosuites v1.0 specification as a Candidate Recommendation with a CR period ending two months after the publication date and with exit criteria requiring two independent implementations of each mandatory (MUST) feature in the specification.
13:28:12 <decentralgabe> manu: moving on to the last cryptosuite, ECDSA
13:30:58 <pauld_gs1> title on this slide is also incorrect
13:30:58 <kristina> q?
13:31:12 <brent> PROPOSAL: Request the publication of the Data Integrity ECDSA Cryptosuites v1.0 specification as a Candidate Recommendation with a CR period ending two months after publication and with exit criteria requiring two independent implementations of each mandatory (MUST) feature in the specification.
13:31:16 <andres> +1
13:31:16 <manu> +1
13:31:17 <seabass> +1
13:31:17 <ivan> +1
13:31:17 <dlongley> +1
13:31:18 <TallTed> +1
13:31:18 <phila> +1
13:31:18 <GregB> +1
13:31:19 <decentralgabe> +1
13:31:19 <Jay> +1
13:31:20 <pauld_gs1> +1
13:31:20 <brent> 0
13:31:20 <bigbluehat> +1
13:31:22 <hsano> +1
13:31:23 <JoeAndrieu> +1
13:31:24 <dmitriz> +1
13:31:30 <selfissued_> 0
13:31:54 <brent> RESOLVED: Request the publication of the Data Integrity ECDSA Cryptosuites v1.0 specification as a Candidate Recommendation with a CR period ending two months after publication and with exit criteria requiring two independent implementations of each mandatory (MUST) feature in the specification.
13:32:33 <ivan> rrsagent, draft minutes
13:32:34 <RRSAgent> I have made the request to generate https://www.w3.org/2023/09/14-vcwg-minutes.html ivan
13:32:42 <decentralgabe> kristina: have not talked about the BBS+ cryptosuite for data integrity. it is unlikely it will make CR
13:33:17 <decentralgabe> brent: we have 10m left in your allotted time, we can put forward a conversation about BBS, and whether we, as a group, have interest to see it through to CR and whether it is a practical effort
13:33:29 <manu> q+
13:33:35 <brent> ack manu
13:33:36 <GregB> q+
13:34:31 <DavidC> DavidC has joined #vcwg
13:34:38 <DavidC> present+
13:34:49 <decentralgabe> manu: we have a little less than a year left in the group. the primitives we've created are applicable to BBS. people are working on it. I know the current editors haven't made much progress. achieving BBS still feels doable, since we were able to take DI specs to CR. those editors can now work on BBS
13:35:16 <ivan> subtopic: Fate of the BBS spec
13:35:31 <decentralgabe> ... still think its very doable, but cutting it close. depends on IETF progress. feels like a missed opportunity to give up on the work item given the progress we've seen today. I suggest we keep it open and see if there are implementations before the EOY
13:35:51 <brent> q+
13:36:20 <kristina> q+
13:36:38 <brent> ack GregB
13:36:39 <decentralgabe> ... then we could pick it up. [Digital Bazaar] is interested as long as the IETF work continues to progress and review happens. the GSMA request asked what we intended to do, having some BBS+ mechanism is desirable given the primitives for ecdsa, we should not close the work item off
13:38:17 <decentralgabe> GregB: going to re-iterate what Manu says. I have been working on impls for BBS+ with DIF and IETF. know it is making very good progress, and going to last call soon. new set of SD primitives helped a ton. not an LD person, and I used them with BBS. very helpful. the folks working on BBS know you have to keep things unlinkable, even within BBS...many other things which can make things linkable on top of base signatures
13:38:57 <brent> ack brent
13:38:58 <decentralgabe> ... will add more guidance with the IETF spec, which we'll add to the W3C spec. depending on the structure of the cred, what's in it, you'll be able to get unlinkability or not. the new primitives that came out make life easy for us doing the crypto, so I think it's doable
13:39:13 <manu> q+ to describe what the plan could be
13:39:43 <decentralgabe> brent: want more clarity on what the plan will be. which interpretation - (1) wait and see if anything happens, if nothing by december we'll stop (2) editors focusing on prior specs will now focus on BBS and get it into shape by December. which is more correct?
13:39:44 <brent> ack kristina
13:40:34 <GregB> q+
13:40:37 <decentralgabe> kristina: have been saying BBS+ is still a draft in CFRG - highly doubt that a new cryptographic scheme will go to last call after only 3 iterations in CFRG. even if it goes to last call now it will take more than 6mo with review and publishing
13:40:39 <manu> q- later
13:41:26 <KevinDeanGS1> KevinDeanGS1 has joined #vcwg
13:41:31 <decentralgabe> ... when the fundamental piece the draft depends on is still in review, I have concerns. I know it's a work item. not sure it's a question of editors on other work items switching. the problem is not only # of people, but the underlying scheme not being final in IETF
13:41:31 <seabass> q+
13:41:38 <manu> q- later
13:41:44 <brent> ack GregB
13:41:48 <decentralgabe> ... when we adopted we agreed we wouldn't take it to final unless it progressed through CFRG
13:42:24 <selfissued_> q+
13:42:59 <decentralgabe> GregB: how quickly it gets through the IETF I can't say. the cryptography is well establish, goes back many years, most recent was from 2016 in the cryptography community. have 4 impls, full set of test vectors in the IETF, if it doesn't make it through as a standard that's that. nothing doubtful about the cryptography itself. well established, for many years
13:43:07 <brent> ack seabass
13:43:11 <decentralgabe> brent: no one suggesting otherwise, pointing normatively is the question
13:44:04 <brent> ack manu
13:44:04 <Zakim> manu, you wanted to describe what the plan could be
13:44:06 <decentralgabe> seabass: could still create a wrapper format. have not been directly involved with BBS in the W3C, see no reason to stop
13:45:06 <brent> Is the goal to get to CR and then hold it until underlying specs are ready?
13:45:16 <decentralgabe> manu: no one is saying if BBS is not an RFC we would proceed with the DI/BBS suite. if there's no RFC we can't use it. let's not push it faster than IETF...it's a fundamental thing that needs to happen. does it have value for us to front-load and make sure we're ready?
13:46:04 <decentralgabe> ... last I heard from Tobias the format's pretty much done. continuing the work in this group, advancing through WDs would be a fine thing to do, even CR may be OK. but clearly not beyond that. this WG is approved to work on BBS, we said we'd do it, have been working on it
13:46:25 <kristina> when we chartered, we were very clear that being chartered to do something does not mean we have an obligation to work on it
13:46:44 <brent> q?
13:46:49 <decentralgabe> .... if it turns out BBS will take 6-8+ months, at least we have made progress and would just be waiting on IETF approval, not starting the work in general. if IETF will take more time we could always do a charter extension...know none of us really want to do that, but it's an option
13:46:51 <brent> zakim, close the queue
13:46:51 <Zakim> ok, brent, the speaker queue is closed
13:47:12 <decentralgabe> ... killing off the work item is premature
13:47:13 <brent> ack
13:47:57 <decentralgabe> selfissued_: have been following somewhat because of JWP work. Tobias tells me representations of BBS proofs have changed between CFRG drafts multiple times. not stabilized. not debating that it may be worth getting volunteers. but still in flux
13:48:40 <decentralgabe> brent: want to see that by october, a group of people willing to be assigned as editors, want to see a solid plan that covers likely eventualities. what are possibilities and plans dependent on them?
13:48:51 <decentralgabe> ... we will move to the next topic which is json schema
13:48:59 <manu> scribe+
13:49:11 <brent> Topic: VC JSON SCHEMA
13:49:28 <brent> zakim, open the queue
13:49:30 <Zakim> ok, brent, the speaker queue is open
13:50:02 <manu> decentralgabe: Going to give an overview of work done and going to CR -- makes use of credentialSchema in data model... two types, JsonSchema type -- expresses a JSON Schema.
13:51:05 <manu> decentralgabe: second type, JsonSchemaCredential -- if you care about authorship of schema, expose status, anything else credential might offer, spec is in good shape, addressed all but one pre-CR issue -- Block and Transmute working on implementations.
13:51:05 <manu> decentralgabe: If there are no major blockers or concerns, we could go to CR today.
13:51:38 <decentralgabe> https://github.com/w3c/vc-json-schema/pull/216
13:51:38 <manu> brent: Can we look at PR?
13:51:38 <brent> subtopic: https://github.com/w3c/vc-json-schema/pull/216
13:51:38 <manu> brent: PR 216 - can you walk us through this, Gabe?
13:52:21 <manu> decentralgabe: Manu had gone through normative references, suggest reducing some JSON Schema references... we only want to normatively refer to the most recent one. Make other refs non-normative, cleans up some other language.
13:52:21 <manu> q+
13:52:31 <brent> ack selfissued_
13:52:33 <brent> ack manu
13:53:12 <andres> manu: Went through the spec, looks good.
13:53:12 <andres> ... as to the changes suggested in the PR.
13:53:46 <brent> q?
13:53:46 <andres> ... The goal here is to reduce the number of normative references to ease going into CR. Happy with it.
13:53:49 <manu> decentralgabe: Open to other questions on the spec, other than that, looking forward to proposal.
13:54:17 <seabass> q+
13:54:21 <manu> brent: any changes for that proposal in IRC?
13:54:49 <brent> ack seabass
13:54:54 <manu> seabass: Wanted to clarify, will test suite be publicly available? Reproducable by an individual?
13:55:00 <morimori> morimori has joined #vcwg
13:55:05 <decentralgabe> https://github.com/w3c/vc-json-schema-test-suite
13:55:05 <manu> decentralgabe: Yes, that's already the case.
13:55:32 <manu> decentralgabe: There is the link to the test suite above. We have a number of test vectors for each normative statement.
13:55:34 <brent> PROPOSAL: Request the publication of the Verifiable Credentials JSON Schema specification, after merging PR #216, as a Candidate Recommendation with a CR period ending two months after publication and with exit criteria requiring two independent implementations of each mandatory (MUST) feature in the specification.
13:55:38 <ivan> +1
13:55:38 <manu> +1
13:55:39 <Jay> +1
13:55:40 <dlongley> +1
13:55:40 <andres> +1
13:55:40 <decentralgabe> +1
13:55:42 <pauld_gs1> +1
13:55:44 <shigeya> +1
13:55:45 <DavidC> +1
13:55:47 <brent> +1
13:55:47 <phila> +1
13:55:47 <TallTed> +1
13:55:48 <JoeAndrieu> +1
13:55:50 <bigbluehat> +1
13:55:53 <dmitriz> +1
13:56:01 <hsano> +1
13:56:11 <manu> manu: +1
13:56:14 <manu> seabass: +1
13:56:31 <brent> RESOLVED: Request the publication of the Verifiable Credentials JSON Schema specification, after merging PR #216, as a Candidate Recommendation with a CR period ending two months after publication and with exit criteria requiring two independent implementations of each mandatory (MUST) feature in the specification.
13:56:32 <ivan> q+
13:56:49 <brent> ack ivan
13:58:12 <manu> ivan: practical things -- can you sync w/ Manu to make sure 4 CRs are published at the same time. Manu, you prepared advanced CR submissions, but CR submission reviewers prefer to have 1 issue submitted for several documents intead of 4 separate issues submitted.
13:58:12 <manu> ivan: Everything should go together.
13:58:40 <brent> Topic: more VCDM Issue triage
13:58:51 <manu> brent: we have 4 more before CR issues to process today
13:59:09 <manu> scribe-
13:59:13 <seabass> scribe_
13:59:14 <seabass> scribe+
13:59:27 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/1152
14:00:20 <seabass> brent: Mike Prorock cannot continue, so we need another volunteer.
14:01:05 <manu> q+
14:01:18 <seabass> ivan: I believe there are multiple ongoing discussions. I cannot make a PR, because I don't see a consensus here.
14:01:18 <brent> ack manu
14:02:34 <ivan> q+
14:02:34 <brent> q+
14:02:37 <seabass> manu: There are multiple places we could put this. I would suggest the Data Integrity vocabulary, as that can be re-used by non-VC formats.
14:02:59 <seabass> ... The first decision that we need to make, therefore, is whether this is exclusive to VCs.
14:03:38 <seabass> q+
14:03:38 <brent> ack ivan
14:05:08 <brent> ack brent
14:05:50 <manu> scribe+
14:05:58 <brent> ack seabass
14:06:01 <manu> q+ on point of contention wrt being in DI
14:06:27 <brent> ack manu
14:06:28 <Zakim> manu, you wanted to comment on point of contention wrt being in DI
14:08:07 <identitywoman> identitywoman has joined #vcwg
14:08:07 <identitywoman> present+
14:08:07 <ivan> q+
14:08:11 <seabass> ivan: The current vocabulary there is a multibase value in the document and the diagram. There was an open question as to whether to add a reserved term for SRI. The range of that digest should be a special datatype, referencing the SRI specification. I don't know whether we want one or both.
14:08:17 <seabass> brent: I'm remembering opposition in discussions about whether to have this in Data Integrity or the VC data model.
14:09:35 <brent> ack ivan
14:09:35 <seabass> manu: There have indeed been concerns on both sides. I'm not sure whether it matters much where the vocabulary lives. I think that the least-friction way is to define this in the VC data model, and let Data Integrity redefine them.
14:10:09 <seabass> ivan: If I get clear statements, I am happy to make the required changes. It is not my decision to make.
14:10:41 <brent> q?
14:10:56 <seabass> ivan: The only downside to putting it into Data Integrity is that's supposed to be going to CR. But then again, the multibase datatype is defined in the security vocabulary.
14:11:23 <manu> q+
14:11:32 <brent> ack manu
14:11:44 <andres> q+ to ask about relatedResource
14:12:18 <brent> ack andres
14:12:18 <Zakim> andres, you wanted to ask about relatedResource
14:12:28 <seabass> manu: I don't think we're going to easily make a decision on this. Thus I don't want to delay CR for an indeterminate amount of time.
14:12:30 <manu> q+
14:13:07 <brent> ack manu
14:13:22 <ivan> q+
14:13:42 <brent> q+
14:13:52 <pauld_gs1> Can vc-json-schema use digestsRI? or would I put a signed json+schema into a relatedResource?
14:13:58 <brent> ack ivan
14:14:05 <seabass> manu: If we want these to be general, they should go into Data Integrity, but if we want it to be specific to VCs, they should go into the data model.
14:14:20 <seabass> q+
14:14:27 <DavidC> both digests should be in the same place
14:14:36 <manu> scribe-
14:14:39 <manu> agree ^
14:15:05 <seabass> ivan: Ideally, the SRI specification should define a term. If it did, it would be much cleaner.
14:15:19 <bigbluehat> +1 to ivan's framing
14:15:23 <brent> ack brent
14:15:25 <manu> agree with ivan, this is a general feature
14:16:19 <pauld_gs1> I agree with ivan as well. a general feature
14:16:19 <brent> ack seabass
14:16:19 <seabass> brent: In my own capacity, both are adequate.
14:16:19 <manu> scribe+
14:16:22 <manu> seabass: missed a previous comment from andres
14:16:42 <manu> andres: Important to separate conversation of related resource in VCDM... digestSRI vs digestMultibase.
14:16:50 <manu> scribe-
14:16:51 <dmitriz> @pauld_gs1 - you should q to ask that question
14:17:58 <andres> q+
14:17:58 <pauld_gs1> q+
14:17:58 <seabass> brent: Am I correct that Digest SRI is 'looking for a home'?
14:17:59 <manu> +1 that it should go into Data Integrity
14:18:17 <manu> +1 to note gate-keep DI on this.
14:18:30 <dmitriz> +1 from me.
14:18:35 <dlongley> +1 to not gate keep, but noting it seems to be the right thing to do to put it into the same vocab
14:20:07 <dmitriz> @dlongley - that's a good point. let's put it in both
14:20:07 <seabass> brent: Let's attempt to move the vocabulary item into Data Integrity. If it is controversial, we will not block Data Integrity's CR.
14:20:07 <dlongley> i wasn't saying put it into two different vocabs -- just one :)
14:20:07 <dmitriz> (ok not sure how I misread that :) )
14:20:14 <pauld_gs1> q-
14:20:14 <brent> ack andres
14:20:14 <dmitriz> q?
14:20:32 <seabass> andres: Media type is something that isn't part of Data Integrity, which could be a problem.
14:21:46 <brent> q?
14:21:46 <seabass> brent: OK, let's move it back.
14:21:53 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/1047
14:22:02 <manu> q+
14:22:09 <manu> seabass: What is this PR supposed to be for?
14:22:20 <brent> ack manu
14:23:06 <seabass> manu: Orie suggested that we added an informative section to disambiguate the terms.
14:23:27 <seabass> brent: I'll mark this as ready for PR with that.
14:23:29 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/1010
14:23:49 <DavidC> q+
14:23:55 <brent> ack DavidC
14:24:43 <seabass> DavidC: The Terms Of Use should be automatically processable, and it should be more general. I've added some draft text. If there is agreement on that, I'll create a PR.
14:25:09 <seabass> q+
14:25:14 <brent> ack seabass
14:25:38 <manu> seabass: I know I haven't done background reading on this... would like to discuss w/ DavidC on this topic.
14:25:47 <manu> DavidC: Waiting on hearing more from you
14:26:13 <seabass> brent: We'll look forward to feedback, and move on now.
14:26:15 <brent> subtopic: https://github.com/w3c/vc-data-model/issues/870
14:26:56 <dmitriz> q+
14:27:37 <brent> ack dmitriz
14:27:37 <seabass> brent: Everyone please read this issue.
14:28:11 <seabass> dmitriz: The issue of stating domain and range for all vocabulary items is not relevant to this GitHub issue, in my opinion.
14:28:43 <ivan> q+
14:28:55 <dmitriz> that's my recollection as well
14:28:58 <brent> ack ivan
14:28:59 <seabass> brent: I recollect that we would keep it as a reserved term even if the specification text is dropped.
14:29:08 <DavidC> q+
14:29:30 <manu> q+ to note that things have changed since this issue was raised, suggest closing it.
14:29:32 <brent> zakim, close the queue
14:29:32 <Zakim> ok, brent, the speaker queue is closed
14:30:47 <oliver> oliver has joined #vcwg
14:30:47 <oliver> present+
14:30:56 <brent> ack DavidC
14:30:56 <seabass> ivan: I recollect us deciding that the corresponding item in the vocabulary would not have an explicit domain. It's very easy to implement, but it is a recursing point of disagreement.
14:31:22 <brent> ack manu
14:31:22 <Zakim> manu, you wanted to note that things have changed since this issue was raised, suggest closing it.
14:32:21 <seabass> DavidC: I think that if there are two interoperable implementations for it, it should stay.
14:33:01 <seabass> manu: I think we could just close this issue, because we have a default situation: if there is no normative document, we'll reserve the property and drop the text.
14:46:54 <ryuichi> ryuichi has joined #vcwg
14:53:39 <hsano> hsano has joined #vcwg
14:53:42 <hsano> present+
14:58:27 <Dongwoo> Dongwoo has joined #vcwg
14:58:28 <Jem> Jem has joined #vcwg
14:59:01 <tzviya> tzviya has joined #vcwg
14:59:08 <bigbluehat> bigbluehat has joined #vcwg
14:59:18 <hadleybeeman> hadleybeeman has joined #vcwg
14:59:54 <TallTed> RRSAgent, draft minutes
14:59:55 <RRSAgent> I have made the request to generate https://www.w3.org/2023/09/14-vcwg-minutes.html TallTed
15:00:40 <TallTed> RRSAgent, make logs public
15:00:41 <dmitriz> dmitriz has joined #vcwg
15:01:59 <dmitriz> present+
15:04:00 <pauld_gs1> pauld_gs1 has joined #vcwg
15:04:01 <ivan> ivan has joined #vcwg
15:04:03 <andres> andres has joined #vcwg
15:04:41 <oliver_> oliver_ has joined #vcwg
15:04:42 <oliver_> present+
15:04:48 <brent> Topic: VC-JSOE-COSE
15:04:56 <andres> present+
15:04:58 <ivan> s/JSOE/JOSE/
15:05:31 <decentralgabe> decentralgabe has joined #vcwg
15:05:34 <brent> https://github.com/w3c/vc-jose-cose/pulls?q=is%3Apr+is%3Aopen+sort%3Acreated-asc
15:05:47 <kristina> kristina has joined #vcwg
15:05:58 <selfissued> selfissued has joined #vcwg
15:05:59 <hadleybeeman> Present+ as a TAG lurker :)
15:06:01 <selfissued> present+
15:06:14 <selfissued> https://github.com/w3c/vc-jose-cose/pull/144
15:06:24 <ivan> subtopic: https://github.com/w3c/vc-jose-cose/pull/144
15:06:27 <DavidC_> DavidC_ has joined #vcwg
15:06:33 <DavidC_> present+
15:06:39 <kristina> scribe+
15:06:44 <morimori> morimori has joined #vcwg
15:07:02 <brent> subtopic: https://github.com/w3c/vc-jose-cose/pull/144
15:07:05 <JoeAndrieu> JoeAndrieu has joined #vcwg
15:07:12 <manu> q+
15:07:23 <kristina> selfissued: very discussed PR to-date. some requested changes - many addressed. manu is the person requesting changes now.
15:07:24 <brent> zakim, open the queue
15:07:24 <Zakim> ok, brent, the speaker queue is open
15:07:29 <manu> q+
15:07:32 <JoeAndrieu> could we get the github URL again?
15:07:33 <brent> ack manu
15:08:17 <selfissued> q+
15:08:27 <kristina> manu: one of the concerns are it duplicates content from DID-Core and data integrity specification and rewrites some of it. uses normative statements from did-core and puts DI content on top of it. DI spec is clear on the reason
15:08:36 <jsalvachua> jsalvachua has joined #vcwg
15:09:00 <kristina> ... since this PR is about DIDs to the specification, adding a normative dependency on DID-Core makes sense
15:09:50 <kristina> ... request is to make clear that the content is largely copy past from other 2 documents, explain what is being changed from those text and why.
15:09:50 <kristina> ... or just copy paste
15:11:02 <kristina> ... redefining DID-Core might be out of scope of the charter
15:11:02 <brent> q?
15:11:02 <brent> ack selfissued
15:11:02 <brent> q+ to ask so is this a profile of the controller document section?
15:11:02 <brent> ack brent
15:11:02 <Zakim> brent, you wanted to ask so is this a profile of the controller document section?
15:11:02 <kristina> selfissued: normative change to DID-Core. subsetting normative statements in DID-Core. if you want to use controller doc with JOSE-COSE, refer to jwks and should not use multibase part, it is not a breaking change to did-core.
15:12:06 <manu> q+ to note it's specifically disallowing certain options.
15:12:06 <kristina> brent: is it profile of DID controller section of did-core?
15:12:06 <kristina> selfissued: yes
15:12:06 <brent> ack manu
15:12:06 <Zakim> manu, you wanted to note it's specifically disallowing certain options.
15:12:06 <kristina> brent: manu, does clarifying that alleviate your concerns?
15:12:06 <selfissued> q+
15:12:06 <ivan> q+
15:12:06 <kristina> manu: no, because the profile makes normative changes to did-core
15:12:06 <kristina> ... if we were just to subset, putting a normative reference to did-core and clearly state what subsetting is
15:12:48 <bigbluehat> +1 to normative references + subsetting
15:12:48 <kristina> ... completely disagree that the PR is ready to be merged today
15:12:49 <brent> ack selfissued
15:12:52 <kristina> ... if this is a profile with subsetting - great, but please say so
15:13:01 <kristina> selfissued: could you state that in the PR?
15:13:40 <kristina> manu: I think I said it in the PR comment
15:13:40 <brent> q+ kristina
15:13:40 <brent> ack ivan
15:13:40 <kristina> kristina: looks like we have a way forward
15:13:40 <kristina> ack kristina
15:14:21 <kristina> ivan: there is currently no normative reference to did-core rn, which should be from your description
15:14:21 <brent> q?
15:14:32 <kristina> selfissued: i will consult other editors
15:14:44 <selfissued> https://github.com/w3c/vc-jose-cose/pull/149
15:14:44 <brent> subtopic: https://github.com/w3c/vc-jose-cose/pull/149
15:15:37 <manu> q+
15:15:42 <kristina> selfissued: given that in ietf, there is work on sd-jwt that both allow an option with and without selective disclosure. editors felt that just using sd-jwt covers only jwts.
15:15:44 <jquemada> jquemada has joined #vcwg
15:15:51 <brent> ack manu
15:16:07 <kristina> manu: this feels like a significant change in direction.
15:16:13 <osamu-n> osamu-n has joined #vcwg
15:16:38 <kristina> ... using JWTs to secure has been a thing for a while. but now it looks like now using sd-jwts will be a must if one is trying to secure VCs using JOSE stack
15:16:49 <brent> q+
15:16:53 <kristina> ... then the whole point of a stack does not match the purpose
15:17:17 <brent> ack brent
15:17:21 <kristina> ... please clarify if the point is not to support regular JWTs and how using SD-JWT enables CWT or CBOR based securing mechanisms
15:17:25 <selfissued> q+
15:17:55 <kristina> brent: i had a similar thoughts. comments in this PR seemed that SD-JWT is a superset of a JWT so it is possible to have a JWT with or without SD components
15:18:10 <dlongley> +1 to hear more about the state of SD-JWT in the standards process
15:18:19 <brent> ack selfissued
15:18:20 <dlongley> and where it is relative to something like where BBS is
15:18:23 <kristina> ... my concern with this concern is similar to the concerns for BBS - whether sd-jwt is in a state where we can refer to it normatively
15:18:32 <manu> q+
15:18:41 <brent> ack manu
15:18:43 <kristina> selfissued: what we a doing is changing a media type, there is no normative reference to sd-jwt ietf draft
15:19:00 <kristina> manu: that does not answer the question. in order to use sd-jwt, you have to put normative changes to it
15:19:26 <kristina> ... we need to understand where in the standardization process sd-jwt is
15:19:30 <selfissued> q+
15:19:46 <kristina> ... understand that editors want to move away from jwts and focus on sd-jwt
15:19:56 <TallTed> There's a whole lot more than media types changed in https://github.com/w3c/vc-jose-cose/pull/149/files
15:20:05 <kristina> ... several implementers using vc-jwt as defined in vcdm 1.1 who might be surprised with this change.
15:20:22 <brent> ack selfissued
15:20:23 <oliver> oliver has joined #vcwg
15:20:26 <TallTed> q+
15:20:27 <oliver> present+
15:20:46 <oliver> q+
15:20:49 <manu> q+ to say we're removing the media type for regular JWTs
15:20:54 <seabass> q+
15:20:58 <manu> q- later
15:21:08 <brent> +1 with JWTs still being in scope according to my understanding.
15:21:09 <brent> q?
15:21:12 <kristina> selfissued: disagree with the characterization that we are taking away the option to use JWTs that is in scope - we are only removing largely duplicative option, since one is a superset - trying to reduce the number of media types
15:21:13 <brent> ack TallTed
15:21:13 <dlongley> notes the PR is called "Remove JWT references (keep SD-JWT)" ... it would be good to change that if that's not what's happening
15:21:25 <bigbluehat> q+ to ask about `sd-jwt` being a superset of `json`
15:21:25 <kristina> tallted: to be clear there is more text change than media types
15:22:23 <brent> ack oliver
15:22:43 <brent> ack seabass
15:22:50 <kristina> oliver: agree with what was said: sd-jwt is superset of jwt. agree with using sd-jwt, the rest is redundant
15:23:18 <brent> q+ to answer
15:23:22 <brent> ack manu
15:23:22 <Zakim> manu, you wanted to say we're removing the media type for regular JWTs
15:23:25 <kristina> seabass: understand that it is subset. why it is called sd-jwt?
15:23:48 <oliver> q+
15:23:54 <seabass> q+
15:24:16 <kristina> manu: this PR removes a media type for regular JWTs - understand that sd-jwt is a superset. it feels like we are removing support for JWTs.
15:24:16 <kristina> q+
15:24:45 <brent> q+ to say you can make a regular JWT and call it an SD-JWT
15:24:47 <kristina> ... you can take a subclass of jwts and point to jwt processor, but that is not the case with sd-jwt
15:25:07 <kristina> ... we are telling people that we are telling people to support sd-jwts.
15:25:22 <brent> ack bigbluehat
15:25:22 <Zakim> bigbluehat, you wanted to ask about `sd-jwt` being a superset of `json`
15:25:36 <bigbluehat> q+ to ask about `sd-jwt` being a superset of `json`
15:25:37 <brent> ack brent
15:25:38 <Zakim> brent, you wanted to answer and to say you can make a regular JWT and call it an SD-JWT
15:26:09 <kristina> brent: respond to sebastian - sd-jwt is considered a jwt because it adds functionality to jwts, but does not remove
15:26:37 <manu> q+
15:26:39 <kristina> ... my understanding is that i can take a normal library, generate a JWT, append ~ and call it an sd-jwt
15:27:01 <brent> ack oliver
15:27:01 <manu> q+ to say I didn't say "impossible to use" -- I'm saying -- it's different enough that implementers need to be aware of the difference.
15:27:02 <kristina> ... so using regular jwt libraries to do sd-jwts is possible. that was all chair hat off
15:27:11 <dlongley> regular JWT lib gets a JWT with `~` at the end ... not a major problem but it does sound like we need a normative reference to SD-JWT?
15:27:38 <kristina> oliver: agree with brent. can use regular jwt libraries. one need to upgrade to v2.0 from v.1.1 anyway. no reason to maintain vc-jwt as in 1.1
15:27:41 <brent> ack seabass
15:27:56 <brent> qq+ selfissued
15:27:57 <kristina> seabass: question to mike. any change to cbor support?
15:28:04 <brent> ack selfissued
15:28:04 <Zakim> selfissued, you wanted to react to seabass
15:28:12 <kristina> selfissued: no change to cbor support.
15:28:15 <brent> scribe+
15:28:17 <brent> ack kristina
15:28:57 <brent> kristina: I think the direction is correct. We experimented a lot with the best way to secure a payload that enables switching selective disclosure on and off.
15:29:41 <Bruno> Bruno has joined #vcwg
15:30:07 <manu> q+ to say it's not good to say "it's a JWT and continue to use JWT libraries" -- feels like it'll lead to interop failures.
15:30:09 <brent> ... we first tried JWT and SD-JWT switching off. But having experimented and implemented, they are not different, it is just appending a ~ to a regular JWT. Those who are currently using JWT and want to contuinue and those who want to use SD with JWT both are there (chaIR HAT OFF).
15:30:19 <brent> ... however PR could explain more, happy to help with that.
15:30:20 <brent> q?
15:30:22 <kristina> q+
15:30:24 <brent> scribe-
15:30:28 <brent> ack bigbluehat
15:30:28 <Zakim> bigbluehat, you wanted to ask about `sd-jwt` being a superset of `json`
15:31:15 <kristina> bigbluehat: question around media type declarations. is sd-jwt a superset of json processing?
15:31:28 <kristina> ... and that is expressed in this PR?
15:31:29 <brent> ack manu
15:31:29 <Zakim> manu, you wanted to say I didn't say "impossible to use" -- I'm saying -- it's different enough that implementers need to be aware of the difference. and to say it's not good to
15:31:32 <Zakim> ... say "it's a JWT and continue to use JWT libraries" -- feels like it'll lead to interop failures.
15:31:57 <seabass> q+
15:32:04 <kristina> manu: this have to do with multiple suffixes thing - current formulation is a correct formulation based on what is happening in the ietf.
15:32:25 <kristina> ... multisuffixes WG in IETF.
15:33:00 <kristina> ... I did not say it is impossible to use. it is different enough and it is dangerous to say sd-jwt is a jwt.
15:33:20 <kristina> ... fine if the PR made it very clear that you should be using a library sd-jwt that can process media type.
15:33:25 <oliver> q+
15:33:34 <kristina> ... suggesting that jwt library can be used as-is is not ok
15:34:03 <kristina> ... not clear if the group wants to abandon jwts and focus on sd-jwt
15:34:07 <dlongley> +1 to manu, fine to do SD-JWT, but normative reference and stability required
15:34:19 <kristina> ... need to add normative reference to sd-jwt
15:34:20 <brent> ack kristina
15:34:20 <oliver> q-
15:34:22 <brent> scribe+
15:34:34 <brent> kristina: I don't disagree
15:35:08 <manu> +1 to kristina -- add a validation/processing section that tell people they should use SD-JWT libraries to do the processing.
15:35:20 <pauld_gs1> q+
15:35:28 <brent> ... all the SD-JWT implementations I've seen use JWT libraries, but adding something to make it clear would be good. I don't think we're abandoning JWTs. Correct framing is moving on we're enabling using JWT with or without selective disclosure.
15:35:39 <brent> zakim, close the queue
15:35:39 <Zakim> ok, brent, the speaker queue is closed
15:35:41 <brent> q?
15:35:45 <brent> scirbe-
15:35:48 <brent> ack seabass
15:35:50 <brent> scribe-
15:36:01 <kristina> not sure the validate section should talk about libraries, but yes
15:37:04 <kristina> seabass: concerned about adding sd-jwt.
15:37:34 <kristina> ... agree with manu's concerns and proposed path forward
15:37:38 <brent> ack pauld_gs1
15:38:44 <brent> scribe+
15:39:03 <kristina> paul_gs1: you can create an sd-jwt to add a ~. easy for the issuer. how does the verifier know when it is the same media type whether ther eis SD or not?
15:40:03 <pauld_gs1> q+
15:40:07 <brent> kristina: You would need to look at the number of tildes. The processing section could clarify. If a verifier gets something with no selective disclosure there one tilde at the end. with SD there are more tildes at the end. The verifier would need that logic to determine.
15:40:20 <ivan> s/ther eis/there is/
15:40:23 <kristina> paul_gs1: a way to ask something without a SD?
15:40:56 <brent> zakim, open the queue
15:40:56 <Zakim> ok, brent, the speaker queue is open
15:41:37 <bigbluehat> q+ to ask about the plans for getting SD-JWT to be a normative reference
15:41:39 <kristina> kristina: depends on the protocol used to request a credential. presentation exchange would allow to request a thing without SD wihtout using media types
15:41:40 <brent> selfissued: given we're trying to move toward CR. There's 6 approvals and minor call for suggested changes. Can we raise an issue for the remaining concerns?
15:41:42 <manu> q+
15:41:52 <pauld_gs1> q-
15:41:52 <brent> ack pauld_gs1
15:42:11 <kristina> selfissued: can we merge this PR and open issue on the path forward we agreed upon
15:42:32 <brent> ack bigbluehat
15:42:32 <Zakim> bigbluehat, you wanted to ask about the plans for getting SD-JWT to be a normative reference
15:42:34 <kristina> bigbluehat: sd-jwt has to be a normative reference.
15:42:39 <brent> ack manu
15:43:12 <kristina> manu: raising another issue that will have to be tagged pre-CR
15:43:22 <kristina> ... would be nice to fix in this PR
15:43:23 <brent> q?
15:44:00 <kristina> brent: noting that mikeJ's way forward is not manu's favorite, we can do merge that PR.
15:44:58 <selfissued> https://github.com/w3c/vc-jose-cose/pull/151
15:44:59 <manu> q+
15:44:59 <brent> subtopic: https://github.com/w3c/vc-jose-cose/pull/151
15:45:08 <kristina> kristina: please open issues before merging that PR
15:45:42 <kristina> selfissued: this PR clarifies how iat/exp should be used. very small
15:45:47 <brent> ack manu
15:45:59 <jyrossi> jyrossi has joined #vcwg
15:46:05 <kristina> manu: +1 to this PR. makes good distinction between dates associated with proof and VCs. +1 to merge
15:46:13 <jyrossi> present+ J-Y Rossi
15:46:28 <kristina> brent: no objections. open for more then a week - merge it
15:46:39 <brent> subtopic: https://github.com/w3c/vc-jose-cose/pull/153
15:46:52 <manu> q+
15:47:07 <Jay> Jay has joined #vcwg
15:47:29 <kristina> selfissued: similarly simple. this simplifies one sentence and adds another one. kid must be present when issuer is expressed as a DID
15:47:43 <brent> ack manu
15:47:43 <kristina> ... 6 approvals no objections
15:48:45 <selfissued> q+
15:48:55 <kristina> manu: i think current text as-is is probably ok, except 2 things - we still have an issue in core data model. does not say what is the value of kid, tho seems to assume it is a DID. some assume it is a relative DID. other implementers put absolute DIDs. probably need to specify which one.
15:49:09 <kristina> ... this seem to assume absolute DID with an entire DID.
15:49:09 <brent> ack selfissued
15:49:29 <manu> q+
15:50:18 <kristina> selfissued: from a conversation earlier where we agreed that kid is a string. so intentionally not making a decision
15:50:18 <brent> ack manu
15:50:21 <kristina> kristina: there is a separate issued on absolute vs relative DID
15:50:29 <JoeAndrieu> q+
15:50:40 <brent> ack JoeAndrieu
15:50:41 <kristina> ... the purpose is to address the issue in another PR
15:51:28 <kristina> JoeAndrieu: calling it DID URL is better. will make a suggestion
15:51:32 <brent> subtopic: https://github.com/w3c/vc-jose-cose/pull/155
15:52:36 <kristina> selfissued: the deletion is removing sentence that never made sense
15:53:25 <kristina> brent: just a day old, please review. adds a normative reference to 7800. not normative
15:53:25 <brent> q?
15:53:34 <brent> subtopic: https://github.com/w3c/vc-jose-cose/pull/156
15:54:46 <kristina> selfissued: last PR. editorial. fixes things that should have been fixed
15:54:52 <kristina> brent: action is to review
15:55:07 <manu> PR looks good, in general, good to call things by the right name.
15:55:27 <kristina> ... nothing controversial, expect to go in in few days
15:55:29 <brent> subtopic VC-JOSOE-COSE issues
15:55:47 <brent> https://github.com/w3c/vc-jose-cose/issues?q=is%3Aopen+label%3Abefore-CR+sort%3Acreated-asc
15:55:49 <ivan> Topic: VC-JOSOE-COSE issues
15:55:59 <brent> subtopic: https://github.com/w3c/vc-jose-cose/issues/118
15:56:00 <ivan> s/JOSOE/JOSE/
15:56:21 <JoeAndrieu> Also, Kristina, I'm not sure I answered your earlier question correctly. A purely relative component would only make sense if the base is set to the DID. "#key1" would only make sense if you're in a context where the base is well-defined and hence maps to a fully qualified URL. So, if the fragment is in a DID Document, we're all good.
15:56:47 <kristina> selfissued: this issue will be closed when the PR is merged
15:56:55 <brent> subtopic: https://github.com/w3c/vc-jose-cose/issues/30
15:56:56 <kristina> thank you, Joe!
15:57:18 <manu> yes, what Joe said above ^ relative URLs only work when you're in a DID Document
15:57:33 <manu> but it's not clear if that works for everwhere we'd find a kid
15:58:36 <kristina> selfissued: PR that clarifies kid is merged, this issue can be cosed.
15:58:47 <kristina> q+
15:58:52 <brent> ack kristina
15:58:57 <brent> scribe+
15:59:17 <manu> q+
15:59:17 <brent> kristina: this is the issue that talks about using vs absolute DID URLs. DIF was recommending something there.
16:00:00 <selfissued> q+
16:00:16 <brent> ... If we incorporate Joe's suggested language and close this issue after the PR is merged, then that means we've agreed  consciously to do that.
16:00:21 <brent> scribe-
16:00:25 <brent> ack manu
16:00:34 <andres> q+ to say we should provide explicit guidance
16:00:42 <kristina> manu: need to understand better where these kid values exist
16:01:28 <JoeAndrieu> you could specify a base
16:01:39 <dlongley> -1 to using relative, just do absolute and avoid all the trouble.
16:01:39 <kristina> ... in the controller documents? if we have relative kid value, that kid value will be interpreted might be wrong, because the base of the document lives in the domain. you will end up with an https value
16:01:56 <kristina> ... give clear guidance when to use one over the other
16:01:58 <andres> +1 to dlongley
16:02:00 <bigbluehat> +1 it's unclear how the absolute URL of the document (on which the relative URL will be calculated) will actually be know and calculated against and (as manu's stated) will shift around based on retrieval...and completely lost when stored
16:02:13 <kristina> ... need to prevent interop issues
16:02:30 <brent> q?
16:02:37 <kristina> ... concerned that the way you are approaching kid and giving guidance is not looking at all places where kid can be used
16:02:52 <kristina> ... -1 to choosing one over the other, but need clear guidance
16:03:09 <kristina> brent: merging the PR does not close this issue
16:03:20 <brent> ack selfissued
16:03:45 <JoeAndrieu> q+ to explore adding a base property that is the DID
16:03:46 <kristina> selfissued: from cose/jose perspective kid is an opaque string.
16:03:57 <manu> q+ to remove has-pr label, DIDs are not opaque strings when talking about keys inside DID Documents
16:04:07 <kristina> ... there might be profiles that give more guidance
16:04:17 <andres> q-
16:04:20 <brent> ack andres
16:04:22 <kristina> ... but it is not role of this spec to give guidance
16:04:26 <brent> ack JoeAndrieu
16:04:26 <Zakim> JoeAndrieu, you wanted to explore adding a base property that is the DID
16:04:26 <oliver> +1 mike
16:04:29 <kristina> ... will make a comment on this
16:04:45 <selfissued> q+
16:04:52 <brent> ack selfissued
16:04:55 <kristina> JoeAndrieu: is there a way to say that the base is a DID
16:05:08 <kristina> selfissued: there is not standard that says what is the base
16:05:09 <kristina> q+
16:05:20 <brent> ack kristina
16:05:22 <brent> scribe+
16:06:18 <brent> kristina: two things happening. 1 PR clarifies how kid is used in general. There is a key that can be a key set where kid can pick one. 2 there can be a DID and within the DID Doc  you use a kid to find a refernce in there.
16:06:56 <brent> ... the second topic is: what is the key that is expressed when the kid is a DID. Mike's comment that kid is okay and opaque is true, but when used as a DID needs to be clarified more.
16:07:03 <brent> scribe-
16:07:05 <selfissued> q+
16:07:07 <brent> ack manu
16:07:07 <Zakim> manu, you wanted to remove has-pr label, DIDs are not opaque strings when talking about keys inside DID Documents
16:07:42 <kristina> manu: +1 to what kristina said. not talking about just a general kid properties. have very specific usage in controller documents - where it is ok and where it is not ok.
16:08:10 <brent> q?
16:08:14 <kristina> ... when you are expressing information within a DID Doc. if you are expressing a key outside a DID Doc, using relative DID url is highly problematic
16:08:14 <kristina> ...
16:08:30 <kristina> ... we need to be more specific here.
16:08:51 <brent> ack selfissued
16:08:52 <kristina> ... please remove the has-PR label from this issue
16:09:28 <manu> q+
16:09:36 <brent> q+ kristina
16:09:39 <brent> ack manu
16:09:40 <kristina> selfissued: we should not make a decision of the format of kid. if DID spec makes a decision, we should reference that, but let's not profile DID spec
16:10:02 <kristina> manu: you said you are opposed to profiling DID spec, but you have another PR that does that.
16:11:10 <kristina> ... failing to provide this kind of guidance might result in rejection of the document
16:11:10 <brent> ack kristina
16:11:10 <brent> scribe+
16:11:10 <manu> q+
16:11:10 <brent> kristina: question, is there a place where that guidance now sits? Where are the best practices for this?
16:11:13 <brent> ack manu
16:11:21 <bigbluehat> q+ there has to be a way to calculate the identifier
16:11:47 <brent> manu: Whent his has come up before I recal the JOSE space being opposed to defining it.
16:11:57 <brent> ... I don't think it exists
16:11:59 <ivan> s/recal/recall/
16:12:44 <manu> yes, what Joe said
16:12:44 <bigbluehat> https://www.w3.org/TR/did-core/#did-syntax
16:12:44 <brent> JoeAndrieu: DID Core references a spec
16:12:44 <brent> scribe-
16:12:47 <bigbluehat> https://www.w3.org/TR/did-core/#did-url-dereferencing
16:12:50 <brent> q?
16:13:11 <brent> subtopic: https://github.com/w3c/vc-jose-cose/issues/31
16:14:04 <kristina> selfissued: looks similar to a previous issue, but this one is actually addressed by a PR
16:14:07 <brent> q?
16:14:24 <manu> agree with selfissued analysis of this issue and having a PR.
16:14:36 <brent> subtopic: https://github.com/w3c/vc-jose-cose/issues/39
16:14:48 <kristina> selfissued: this one has a PR too, we agreed to merge that
16:15:08 <kristina> ... already
16:15:18 <brent> subtopic: https://github.com/w3c/vc-jose-cose/issues/52
16:15:55 <manu> q+
16:16:02 <brent> ack manu
16:16:10 <kristina> selfissued: this issue has PR too, closing once merging that one
16:16:28 <kristina> manu: rfc7800 defines how to use cnf claim for proof of possession.
16:16:41 <kristina> s/,/?
16:16:51 <kristina> ... is that what you are saying/
16:16:57 <kristina> selfissued: yes
16:17:01 <brent> subtopic: https://github.com/w3c/vc-jose-cose/issues/35
16:17:50 <kristina> selfissued: this is terminology. we already done a good job in the specs on terminology.
16:17:54 <manu> +1 to close this issue :)
16:17:58 <kristina> brent: this one is post-cr
16:18:09 <kristina> brent: any objections to close?
16:18:41 <kristina> brent: no objections, closing after script has been generated
16:19:13 <brent> subtopic: https://github.com/w3c/vc-jose-cose/issues/106
16:19:24 <kristina> selfissued: overtaken by the decision to re-do controller doc PR
16:19:32 <brent> subtopic: https://github.com/w3c/vc-jose-cose/issues/117
16:19:45 <kristina> selfissued: has PR
16:19:48 <pauld_gs1> q+
16:19:58 <kristina> ... gets closed after the PR is merged
16:20:02 <brent> ack pauld_gs1
16:20:25 <kristina> pauld_gs1: this issue asks to define that it is more than a hint
16:20:26 <kristina> q+
16:20:33 <brent> ack pauld_gs1
16:20:35 <brent> ack kristina
16:20:35 <kristina> ... so the PR is not enough
16:20:38 <brent> scribe+
16:20:40 <brent> kristina:
16:21:19 <brent> when writing the PR I realized there was an additional ask, so I tried to express that a kid isn't just a hint, but a hint for a hint, checking that wasn't enough?
16:21:21 <brent> pauld_gs1: yes
16:21:24 <brent> scribe-
16:21:42 <brent> subtopic: https://github.com/w3c/vc-jose-cose/issues/133
16:22:37 <kristina> brent: matching PR has been merged. this issue can be closed.
16:22:43 <brent> q?
16:22:53 <brent> ack pauld_gs1
16:22:59 <brent> ack pauld_gs
16:23:17 <kristina> JoeAndrieu: validation section references VCDM
16:23:26 <kristina> ... , correct?
16:23:29 <kristina> selfissued: yes
16:23:47 <brent> subtopic: https://github.com/w3c/vc-jose-cose/issues/135
16:24:09 <pauld_gs1> q?
16:24:37 <kristina> q+
16:24:54 <kristina> selfissued: my new PR has correct names for the things. implicitly that answers the question.
16:25:01 <brent> ack kristina
16:25:03 <brent> scribe+
16:25:06 <brent> kristina:
16:25:26 <brent> ... I don't think that PR addresses this issue, and it changes what Orie originally intended.
16:25:44 <selfissued> q+
16:26:00 <brent> ... There are claims like kid that can only exist in Header, but claims like iss where the optionality was intentionally left, whether header or body.
16:26:07 <manu> q+
16:26:27 <brent> ... I was asking for clarification . If both are possible the processor will need to know what to expect.
16:26:34 <ivan> rrsagent, draft minutes
16:26:36 <RRSAgent> I have made the request to generate https://www.w3.org/2023/09/14-vcwg-minutes.html ivan
16:26:50 <brent> ... If addressed byt eh PR, then iss can only exist in claim, so we need more than open PR.
16:26:54 <brent> scribe-
16:26:56 <brent> q?
16:26:59 <brent> ack selfissued
16:27:30 <brent> ack manu
16:27:33 <kristina> selfissued: understand what you are saying. will note that you can optionally put JWT claims in the header. that's why I felt the PR answers the issue
16:27:34 <manu> https://github.com/w3c/vc-data-model/blob/main/contexts/credentials/v2
16:27:52 <kristina> .... defined by an RFC
16:28:30 <kristina> manu: +1 to what kristina is saying. if you look at the context, iss, exp, etc. can be present in both places (header and the body). )
16:28:48 <selfissued> q+
16:28:50 <kristina> ... this has been an issue for a while. I have been objecting for it for a while because the optionality will hurt interop
16:30:10 <brent> q?
16:30:10 <brent> ack selfissued
16:30:10 <pauld_gs1> +1 manu. I though we were fixing this.
16:30:19 <kristina> ... not even sure there is issue for this. might lead to the problem that we had with an approach in vcjwt 1.1 that duplicated fields  in "in addition to" approach
16:30:49 <manu> +1 to correcting things in the way that selfissued proposed.
16:30:54 <kristina> selfissued: agree that clarification is needed, can do a simple PR.
16:30:59 <brent> q?
16:31:01 <kristina> q+
16:31:02 <brent> scribe+
16:31:04 <brent> kristina:
16:32:07 <brent> I don't think this is ready for PR. I don't think we have an agreement. I'm leaning toward those claims can be present in the header. If now we believe we have enough implementatiion experience that puts them in the header, that's where we shoudl say they should be.
16:32:07 <manu> agree with kristina, we need to make a decision here.
16:32:13 <manu> here is the issue: https://github.com/w3c/vc-data-model/blob/main/contexts/credentials/v2#L9-L58
16:32:33 <brent> selfissued: no place says JWT claims can be in the header. We shouldn't start that.
16:32:43 <brent> ... my PR says follow JWT spec guidance
16:32:53 <kristina> I think Orie will object to that but we will see
16:32:55 <brent> ... It deprecates the practive of duplicating them
16:33:03 <ivan> rrsagent, draft minutes
16:33:04 <RRSAgent> I have made the request to generate https://www.w3.org/2023/09/14-vcwg-minutes.html ivan
16:33:11 <manu> thanks all!
16:33:15 <manu> Thanks a ton to Chairs and scribes! :)
16:33:39 <kristina> brent: thank you all! especially those who stayed up weird hours
16:33:57 <kristina> ... take a note that agenda has slightly changed. we have some guests coming
16:33:58 <ivan> zakim, end meeting
16:33:58 <Zakim> As of this point the attendees have been ivan_, brent, kristina, phila, shigeya, andres, gabe, hsano, pchampin, manu, Jay, TallTed, DavidC, decentralgabe, GeunHyung_Kim, hyojin,
16:33:59 <seabass> :) and, I think, stayed up really really late, in the case of shigeya
16:34:01 <Zakim> ... seabass, David_Ezell, LaurensDebackere, y-sakuma, rhiaro, selfissued, bumblefudge, dwaite, dmitriz, helen_, Wonsuk_Lee, JoeAndrieu, JoeAndrieu_, Dingwei, bigbluehat, dlongley,
16:34:01 <Zakim> ... GregB, identitywoman, selfissued_, oliver, oliver_, as, a, TAG, lurker, :), DavidC_, J-Y, Rossi
16:34:01 <Zakim> RRSAgent, please draft minutes
16:34:03 <RRSAgent> I have made the request to generate https://www.w3.org/2023/09/14-vcwg-minutes.html Zakim
16:34:09 <kristina> ... we are in a different room tomorrow
16:34:09 <Zakim> I am happy to have been of service, ivan; please remember to excuse RRSAgent.  Goodbye
16:34:09 <Zakim> Zakim has left #vcwg
16:34:13 <kristina> ... we are in magnolia tomorrow
16:34:19 <ivan> rrsagent, bye
16:34:19 <RRSAgent> I see no action items