18:57:38 <RRSAgent> RRSAgent has joined #vcwg
18:57:39 <RRSAgent> logging to https://www.w3.org/2022/10/12-vcwg-irc
18:57:41 <Zakim> RRSAgent, make logs Public
18:57:42 <Zakim> please title this meeting ("meeting: ..."), kristina
18:57:46 <kristina> Meeting: Verifiable Credentials Working Group Telco
18:57:52 <brentz> brentz has joined #vcwg
18:57:52 <kristina> Chair: Kristina
18:58:24 <gkellogg> gkellogg has joined #vcwg
18:58:57 <brentz> present+
18:59:23 <kristina> present+
19:00:38 <markus_sabadello> markus_sabadello has joined #vcwg
19:01:12 <mprorock> mprorock has joined #vcwg
19:01:23 <mprorock> present+
19:01:35 <TallTed> TallTed has changed the topic to: VCWG 2022-10-12 Agenda: https://lists.w3.org/Archives/Public/public-vc-wg/2022Oct/0003.html
19:02:07 <selfissued> selfissued has joined #vcwg
19:02:12 <markus_sabadello> present+
19:02:12 <selfissued> present+
19:02:20 <TallTed> present+
19:02:25 <dmitriz> dmitriz has joined #vcwg
19:02:29 <dmitriz> present+
19:02:58 <decentralgabe> decentralgabe has joined #vcwg
19:03:01 <dlongley> present+
19:03:03 <dmitriz> what's the scribe nick incantation?
19:03:05 <manu> present+
19:03:11 <decentralgabe> present+
19:03:12 <dmitriz> scribe+
19:03:43 <dmitriz> kristina: <summary of call agenda>
19:03:49 <manu> q+ to review PRs for vc-data-model and vc-data-integrity
19:04:24 <dmitriz> manu: is now an appropriate time to review PRs?
19:04:27 <kristina> ack manu
19:04:27 <Zakim> manu, you wanted to review PRs for vc-data-model and vc-data-integrity
19:04:42 <dmitriz> kristina: let's do intros / special topics, and then move to PRs
19:04:52 <Logan_Porter> Logan_Porter has joined #vcwg
19:04:57 <Orie> Orie has joined #vcwg
19:05:01 <shawnb> shawnb has joined #vcwg
19:05:01 <Orie> present+
19:05:09 <Logan_Porter> present+
19:05:24 <dmitriz> Pzemek: hi I'm Pzemek from MasterCard (Cyber and Intelligence Division), working on Identity there. Excited to be here.
19:05:49 <shawnb> present+
19:06:03 <Steve_C> Steve_C has joined #vcwg
19:06:07 <dlehn1> present+
19:06:49 <dmitriz> kristina: first item - IRC etiquette
19:07:06 <dmitriz> ... at the last call, Ivan proposed starting a second IRC channel (to contain side-conversations on IRC during the call)
19:07:12 <dmitriz> ... which was a fair observation.
19:07:41 <dmitriz> ... so, we had the discussion with chairs, editors and Ivan. consensus was: we don't want a second IRC channel right now, but want to reinforce the etiquette -- when using IRC, please be mindful to keep the conversation relevant to the topic
19:08:00 <dmitriz> ... what you're typing (without a '/me ' preceding it) will go onto public record, so please be mindful
19:08:20 <dmitriz> ... so if you feel the need to add off-topic comments, please use /me, which won't go into the minutes
19:08:27 <brentz> q+
19:08:31 <Przemek_Praszczalek> Przemek_Praszczalek has joined #vcwg
19:08:40 <Steve_McCown> Steve_McCown has joined #vcwg
19:08:41 <kristina> ack brentz
19:08:49 <dmitriz> brentz: thanks Kristina. I second everything Kristina said; Ivan did admit that proposing an entirely separate IRC channel for snark & side-convos was slightly extreme
19:09:11 <dmitriz> ... but really, we're just asking to do three things. 1) whenever your comment is snark, use emote options.
19:09:39 <dmitriz> ... we want people to feel free to make comments pertinent to the conversation as it happens. you don't need to emote those. but we don't want the IRC conversations and the call's conversation to diverge
19:09:55 <kristina> q?
19:09:56 <dmitriz> kristina: thanks Brent. any questions related to this?
19:10:20 <dmitriz> ... moving onto the next topic
19:10:21 <Orie> In case you want to join the W3C Slack channel, and post your snark there too: https://w3ccommunity.slack.com/archives/C0456S64PPF
19:10:24 <dmitriz> topic: Special Topic Calls
19:10:42 <dmitriz> kristina: this is related to the conversation we had last week, issue #929 "What does JSON-LD compatible mean?"
19:10:51 <dmitriz> ... the chairs are not yet ready to take resolution on this topic.
19:10:58 <dmitriz> ... we'd like to continue the conversation and discussions.
19:11:17 <dmitriz> ... but because we do need to move forward the Data Model & other docs, we would like to organize a Special Topic Call on various issues
19:11:39 <dmitriz> ... and issue #929 was recently closed, and Manu kindly offered to re-open individual issues for separate topics in that thread
19:11:51 <dmitriz> ... and Brent has kindly agreed to organize special topic calls when needed
19:11:51 <kristina> q?
19:12:13 <manu> q+ to review PRs for vc-data-model and vc-data-integrity
19:12:13 <dmitriz> topic: Work Item Status Updates and PRs
19:12:32 <kristina> ack manu
19:12:32 <Zakim> manu, you wanted to review PRs for vc-data-model and vc-data-integrity
19:12:48 <mprorock_> mprorock_ has joined #vcwg
19:12:58 <dmitriz> manu: VC-data-model / #924 -- we'll skip that
19:13:03 <manu> https://github.com/w3c/vc-data-model/pull/924 we're going to discuss today
19:13:11 <dmitriz> ... 943 has been opened as a counter-proposal
19:13:17 <manu> Counterproposal for #924 https://github.com/w3c/vc-data-model/pull/943
19:13:18 <kristina> apologies, related to the previous discussions, but link to the issue that has been closed, which also has links to the new issues that manj broke down into: https://github.com/w3c/vc-data-model/issues/929
19:13:29 <dmitriz> manu: so I expect that we should discuss that today as well; those two issues are just two sides of the same coin
19:13:36 <manu> https://github.com/w3c/vc-data-integrity/pulls
19:13:36 <dmitriz> ... so that's it for data model pulls
19:13:52 <dmitriz> ... as far as Data Integrity pull requests, there is a PR to add an initial JSON-LD context for data integrity
19:13:54 <manu> Add initial JSON-LD Context for Data Integrity -- https://github.com/w3c/vc-data-integrity/pull/61
19:14:02 <dmitriz> ... that is also related to the discussion we want to have today
19:14:14 <manu> Refactor Generate Proof algorithm -- https://github.com/w3c/vc-data-integrity/pull/62
19:14:17 <dmitriz> ... and then there's some cleanup work happening in PR #62, which refactors the Generate Proof algorithm
19:14:40 <dmitriz> ... the take-away at this point is -- there are only 2 more algs that need to be refactored in the Data Integrity work, and then I believe it's ready for a FPWD
19:14:55 <dmitriz> ... so let's say, the end of this month, we're likely to be in a position to call for a First Public Working Draft for Data Integrity and other specs
19:15:06 <gkellogg> gkellogg has joined #vcwg
19:15:15 <manu> Links to implementing Data Integrity streamlining: https://github.com/w3c/vc-data-integrity/pull/61#issue-1402344013
19:15:27 <dmitriz> ... the other thing to pay attention to -- here's a link to implementing Data Integrity streamlining
19:15:39 <dmitriz> ... we discussed the DI spec at W3C TPAC. there is now a JSON-LD context for that
19:15:53 <dmitriz> ... there is an implemented Cryptosuite (something called 'eddsa-crypto' suite) (sp?)
19:16:06 <gkellogg> gkellogg has joined #vcwg
19:16:11 <dlongley> s/eddsa-crypto/eddsa-2022/
19:16:12 <kristina> how is this related to PR 943, counterproposal to removing proofs in vc-data-model
19:16:22 <dmitriz> ... there's going to be a spec very shortly for it
19:16:28 <dmitriz> ... there's an implementation, and a conformance test suite
19:16:48 <dmitriz> ... so pay attention to that, if you haven't been following Data Integrity, since that will be moving faster
19:17:25 <dmitriz> kristina: the PR #61 is similar to vc-data-model PR #943?
19:17:38 <dmitriz> manu: close. One is about establishing a context that has nothing to do with VCs, that's just data integrity related
19:17:49 <dmitriz> ... in the vc-data-model, we're saying -- let's pull the DI context into the core VC context
19:17:58 <kristina> q?
19:17:58 <dmitriz> kristina: thanks
19:18:18 <dmitriz> kristina: editors of JWT VC and JSONSignature2020, can you please report on the status?
19:18:57 <dmitriz> selfissued: Orie and I need to address the comments on the PRs, including those by Kristina,
19:19:02 <dmitriz> ... none of them make normative changes
19:19:12 <dmitriz> kristina: any update on JsonWebSignature?
19:19:27 <dmitriz> Orie: we're almost there. we have a PR that's been open since August 10, and it involves a context change,
19:19:31 <Orie> https://github.com/w3c/vc-jws-2020/pull/24
19:19:33 <dmitriz> ... and it has 3 people who have commented on it.
19:19:39 <dmitriz> ... it's not looking super good in terms of engagement
19:19:54 <manu> q+ to note some synchronization might be needed between jws-2020 and data-integrity.
19:19:58 <dmitriz> ... so either there's not a lot of interest in the group on this, or my pleas for engagement are going unheeded
19:20:09 <dmitriz> ... so please weigh in, add your comments, PR approvals, etc.
19:20:20 <dmitriz> ... and make it clear if you're requesting changes, or if you're against the whole thing
19:20:40 <dmitriz> ... otherwise, it's impossible for the PR author (me in this case) to resolve your feedback
19:21:01 <dmitriz> ... I'd like to merge this PR, to set a foundation for some of the semantic processing associated with WebSignature2020
19:21:12 <dmitriz> ... I've tested it out, it has behavior that I like more than the current implementation
19:21:13 <mprorock_> i would like this merged as well for similar reasons when looking at data in a node graph
19:21:16 <kristina> ack manu
19:21:16 <Zakim> manu, you wanted to note some synchronization might be needed between jws-2020 and data-integrity.
19:21:20 <dmitriz> manu: it's not related to this PR, but in general,
19:21:43 <dmitriz> ... Orie and anyone who's working on the jws-2020 spec -- I've updated the core spec to be more inclusive of other algorithms / different ways of doing things
19:22:01 <dmitriz> ... Orie, you're still using the 'jws' property, and I've made an affordance in the DI spec to account for that
19:22:08 <dmitriz> ... I was wondering if we could unify on 'proofValue'
19:22:17 <dmitriz> ... or would you prefer to continue using 'jws'
19:22:23 <Orie> Is there an issue to track that
19:22:24 <Orie> ?
19:22:25 <dmitriz> ... so, there's something for us to discuss, and I just wanted to raise awareness
19:22:31 <manu> Nope :)
19:22:42 <Orie> I will comment on issues when linked / requested.
19:22:50 <dmitriz> manu: I'll open an issue
19:22:52 <mprorock_> q?
19:22:55 <mprorock_> q+
19:22:59 <dmitriz> kristina: ok, that concludes our updates on PRs and issues for the items
19:23:03 <kristina> ack mprorock_
19:23:13 <dmitriz> mprorock: Manu, are you asking that in the 'proof' block, we change 'jws' to 'proofValue'?
19:23:22 <dmitriz> manu: yeah, there's some upsides & downsides to doing that. I'll raise an issue
19:23:27 <Orie> Related to the open PR... https://github.com/w3c/vc-data-model/pull/943/files#diff-267b7e47789daf9a1d312b42826aa937a1bb5af4312ee90df6b8a64cd6426f4fR146
19:23:44 <dmitriz> kristina: let's move to the next topic
19:23:48 <dmitriz> topic: PR #924
19:23:53 <kristina> subtipic: https://github.com/w3c/vc-data-model/pull/924
19:23:56 <dmitriz> kristina: manu has briefly mentioned it
19:24:07 <dmitriz> ... brief overview -- Orie did a PR removing 'proof' from the VC @context
19:24:19 <brentz> s/subtipic:/subtopic:/
19:24:19 <dmitriz> ... there is another PR that's a counter-proposal (to keep the proof)
19:24:34 <Orie> q+ to make my case / comment.
19:24:40 <dmitriz> ... anyone who would like to speak to move this forward?
19:24:41 <kristina> ack Orie
19:24:41 <Zakim> Orie, you wanted to make my case / comment.
19:24:42 <manu> q+
19:25:10 <dmitriz> Orie: so, in the conversation on that open issue, Manu and I talked about how to move the item forward, and he's implemented a path forward for adding a 'proof' definition for Data Integgrity to the VC context
19:25:17 <Phil-ASU> Phil-ASU has joined #vcwg
19:25:17 <dmitriz> ... this is a valid path forward, and I'm happy to close my PR.
19:25:28 <kristina> ack manu
19:25:29 <dmitriz> ... I asked for a counter-proposal, and it was given. so unless anyone objects I'll close my PR
19:25:50 <dmitriz> manu: does everyone understand the ask?
19:26:06 <dmitriz> ... Orie, not everyone on the call may understand what's being proposed in the PRs
19:26:17 <dmitriz> ... we can ask if anyone has objections, but I'm just concerned people are unclear
19:26:20 <shawnb> I'll sheepishly admit that I don't fully understand - I'm about 60% of the way there.
19:26:21 <dmitriz> kristina: that's a fair point
19:26:34 <manu> q+ to try and cover what's being discussed.
19:26:40 <dmitriz> ... Orie would you like to comment?
19:26:52 <dmitriz> Orie: I invite people to look through the comments / conversation in the issues
19:26:57 <kristina> ack manu
19:26:57 <Zakim> manu, you wanted to try and cover what's being discussed.
19:27:03 <dmitriz> manu: ok, let me see if I can explain
19:27:21 <dmitriz> ... so, fundamentally, the question is -- to what lengths should we go to, to make people's lives easier, when they're developing VCs (using JSON-LD)?
19:27:36 <dmitriz> ... for those developers, do we want to give them an easy way of covering 80% of  the types of proofs that might be attached to a VC
19:27:49 <dmitriz> ... so the whole question is -- do we want to create a base format for a Data Integrity proof, that's batteries included
19:28:04 <dmitriz> ... meaning, when somebody includes the VC v2 context, for most usecases, they can just attach a DI proof
19:28:08 <dmitriz> ... that's what my PR does
19:28:40 <dmitriz> ... basically says - for devs using the v2 context, they don't have to painstakingly look through a registry of proofs, and copy and paste the context for that proof type, they can just use it
19:28:53 <kristina> q?
19:29:03 <dmitriz> ... the counter-argument was -- 'you're favoring DI stuff', to which the reply is -- if you don't care about JSON-LD, then this doesn't affect you
19:29:13 <dmitriz> ... this whole thing does not hurt or affect JWT VCs
19:29:27 <dmitriz> ... it just makes JSON-LD dev experience easier; cuts down on too many cryptosuite contexts from being created
19:29:39 <dmitriz> ... so, it offers upsides for DI users, while not dis-enfranchising JWT users
19:29:42 <shawnb> q+
19:29:50 <kristina> ack shawnb
19:30:01 <dmitriz> shawnb: just wanted to say thank you, Manu, that was helpful, and I see the connection between the PRs. I think this is great
19:30:22 <Phil-ASU> +1 to the explanation and support closing 924, as well.
19:30:30 <dmitriz> kristina: so, what's on the table is closing #924
19:30:40 <dmitriz> ... any objections?
19:30:43 <manu> +1 to close #924
19:30:47 <dmitriz> +1 to close
19:30:49 <dlongley> +1 to close #924
19:30:52 <Logan_Porter> +1 to close
19:30:54 <shawnb> +1
19:30:54 <Orie> I opened it, I closed it.
19:30:58 <Orie> :)
19:31:00 <markus_sabadello> +1
19:31:12 <dmitriz> kristina: I see multiple +1s in the chat, let's give it a moment. Oh, I see Orie closed it (since he's the one who opened the PR)
19:31:42 <dmitriz> kristina: ok, the counter-PR was opened 3 days ago, let's give people a few more days to comment on it
19:31:49 <dmitriz> ... ok, let's move to issues discussion
19:31:52 <dmitriz> topic: Issues Discussion
19:31:58 <kristina> subtopic: https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+label%3Adiscuss+sort%3Aupdated-asc
19:32:27 <dmitriz> kristina: I looked through the issues, and I wanted to cover -- so, most of them we have covered once already, in these WG calls within the last 2 months
19:32:40 <dmitriz> ... and most of them don't have activity after that
19:32:58 <dmitriz> ... so, I picked several that have enough new comments that we haven't discussed
19:33:07 <kristina> subtopic: https://github.com/w3c/vc-data-model/issues/914
19:33:08 <dmitriz> ... the first one was #914 where Brent added the label 'discuss'
19:33:17 <dmitriz> kristina: de-referencing relative to issuer
19:33:23 <dmitriz> .... Brent was asking the question
19:33:29 <dmitriz> ... Orie or Brent -- any comments?
19:33:36 <dmitriz> Orie: an issuer is a well-understood term at this point
19:33:45 <dmitriz> ... you can use the term definition from VC spec 1.1
19:34:06 <dmitriz> ... in the case of a Data Integrity proof, there's a wel-defined relationship between the issuer, the verificationMethod, and the proof
19:34:07 <dwaite> dwaite has joined #vcwg
19:34:16 <dmitriz> ... so in a DI proof, as a developer, I know what to do with a key and how to verify
19:34:24 <dmitriz> ... in the context of JWTs, it's completely un-defined
19:34:40 <dmitriz> ... this may be shocking, you may ask -- how can I use JWTs if I don't know how to obtain the public key?
19:35:00 <dmitriz> ... I'm confused as well. I've worked on some documents at DIF a while ago, to make it easier to understand how to obtain the key material, with a JWT VC
19:35:17 <kristina> present+ dwaite
19:35:18 <dmitriz> ... there's a few options we discussed, the most widely adopted is unfortunately my fault, it's to use a 'kid' value that is an absolute reference to the key material
19:35:40 <dmitriz> ... that you use to verify the VC. the security risk there is -- if you're just de-referencing the material from kid, there's a chance that the kid and issuer don't agree
19:36:12 <dmitriz> ... so, you can see here in that example, if we take the 'iss' and 'kid' together and use those, that might work, but it's different from what I've seen in the wild
19:36:21 <dmitriz> ... which was - an absolute 'kid' vs relative url
19:36:22 <mprorock_> +1 orie
19:36:30 <brentz> zakim, who is here?
19:36:30 <Zakim> Present: brentz, kristina, mprorock, markus_sabadello, selfissued, TallTed, dmitriz, dlongley, manu, decentralgabe, Orie, Logan_Porter, shawnb, dlehn, dwaite
19:36:34 <Zakim> On IRC I see dwaite, Phil-ASU, gkellogg, mprorock_, Steve_McCown, Przemek_Praszczalek, Steve_C, shawnb, Orie, Logan_Porter, decentralgabe, dmitriz, selfissued, markus_sabadello,
19:36:34 <Zakim> ... brentz, RRSAgent, Zakim, kristina, Karen, TallTed, tzviya, npd, Mike5Matrix, cel1, cel[m], Github, bumblefudge, stonematt, shigeya, dlehn1, Dongwoo, dlehn, bigbluehat,
19:36:34 <Zakim> ... hadleybeeman, dlongley, manu, rhiaro
19:36:38 <manu> q+ to note concern both ways -- but issuer + proof.verificatioNMethod seems dangerous.
19:36:40 <dmitriz> ... but basically, we need a consistent definition of how to obtain a public key for a JWT
19:36:41 <dmitriz> kristina: thanks Orie
19:36:44 <kristina> ack manu
19:36:44 <Zakim> manu, you wanted to note concern both ways -- but issuer + proof.verificatioNMethod seems dangerous.
19:36:48 <dmitriz> manu: +1 to providing guidancfe
19:36:59 <dmitriz> ... we should do that, since this has come up multiple times, and we keep making different decisions
19:37:14 <dmitriz> ... the thing that stands out to me that feels dangerous, is the whole 'iss' + 'kid' approach
19:37:23 <dmitriz> ... which presumes that the verification method is always relative (or can be relative)
19:37:33 <dmitriz> ... this is dangerous because it presumes that the 'iss' property always exists
19:37:45 <dmitriz> ... but for Data Integrity proofs, they can be applied to non-VC objects
19:37:46 <Orie> q+ point of order, issuer is required
19:37:52 <Orie> q+ tp point of order, issuer is required
19:37:55 <dmitriz> ... in use cases where there's no issuer
19:37:57 <Orie> q+ to point of order, issuer is required
19:38:04 <brentz> present+ kdean
19:38:13 <dmitriz> manu: if 'kid' is /always/ a relative URL and it's enforced, then that might be ok..
19:38:40 <dmitriz> ... I'll also note that there are valid concerns about putting absolute URLs everywhere
19:38:43 <dmitriz> ... where the key that's signed is different from the 'iss'uer URL
19:38:49 <dmitriz> ... some people look at that as a feature, some as a bug
19:38:50 <brentz> present+ Phillip_Long
19:38:52 <kristina> ack Orie
19:38:52 <Zakim> Orie, you wanted to point of order, issuer is required
19:39:04 <dmitriz> Orie: so, the example that I've shown, with 'iss' + proof verificationMethod was confusing
19:39:18 <dmitriz> ... in a VC that uses a DI proof, you only need proof.verificationMethod to obtain the key material
19:39:20 <manu> ok, thanks Orie, that's helpful.
19:39:36 <markus_sabadello> q+
19:39:36 <decentralgabe> +1 Orie, ran into this exact issue this week when implementing resolving keys + verifying jwt-vcs
19:39:43 <brentz> present+ Steve_C
19:39:45 <dmitriz> ... as far as I'm aware, you're not required to enforce that the key used to sign a VC is controlled by the issuer
19:39:54 <dmitriz> ... I've seen libraries that check for this, and I've implemented that myself
19:39:56 <dlongley> +1 to Orie, thanks for clarifying
19:40:06 <dmitriz> ... anyways, so this issue is -- how did you get to that key material in the first place
19:40:13 <brentz> present+ Steve_McCown
19:40:19 <manu> ah, I think I see...
19:40:21 <dmitriz> Orie: the other point I don't agree with that Manu made
19:40:40 <dmitriz> ... is that DI proofs apply to things that aren't VCs. I agree that that's true, but VCs /require/ issuers
19:40:52 <dlongley> q?
19:40:58 <dmitriz> ... so one is not going to encounter a situation, in the context of this WG, where that would happen, unless we make normative changes
19:41:01 <kristina> ack markus_sabadello
19:41:13 <dmitriz> markus_sabadello: I agree, it feels like this should be defined (wrt relative IDs)
19:41:28 <decentralgabe> q+
19:41:30 <dmitriz> ... in the JSON-LD perspective, such a relative ID would be resolved relative to the 'id' field, rather than the 'issuer' field
19:41:36 <manu> q+ to note why issuer and verificationMethod might be different.... and yes, "relative to what" is one of the issues here.
19:42:00 <kristina> ack decentralgabe
19:42:04 <dmitriz> decentralgabe: I'm curious where the normative change needs to be. is this something that the VC JWT spec can handle?
19:42:11 <manu> q+ to note "JSON-LD is relative to document BASE"
19:42:12 <kristina> ack manu
19:42:13 <Zakim> manu, you wanted to note why issuer and verificationMethod might be different.... and yes, "relative to what" is one of the issues here. and to note "JSON-LD is relative to
19:42:13 <Zakim> ... document BASE"
19:42:13 <Orie> To be clear, I am NOT suggesting `proof.verificationMethod` be ANYTHING other than an absolute IRI to a verificationMethod
19:42:39 <Orie> I am pointing out that people still have questions about relationship to issuer.
19:42:40 <dmitriz> manu: ok, so what Orie just said (in chat) -- great, I totally agree with that
19:42:49 <dmitriz> ... so what's our further question...
19:42:50 <dlongley> q+ to ask if we can say that this is specific to VC-JWT
19:43:02 <Orie> manu, we are talking about this: https://github.com/digitalbazaar/vc-js/blob/main/lib/CredentialIssuancePurpose.js#L72
19:43:03 <dmitriz> manu: how about this -- let me try and state a question and provide an ansewr
19:43:21 <dmitriz> manu: do we want relative URLs associated with any kind of key material in DI proofs. and the answer is, absolutely not. we should have absolute URLs everywhere
19:43:27 <dmitriz> ... does anyone object or disagree?
19:43:37 <selfissued> q+
19:43:38 <Orie> q+ to explaint CWT / JWT use cases.
19:43:39 <dmitriz> ... introducing relative URLs, especially around key material in DI proofs, is asking for trouble
19:43:49 <dmitriz> ... since as Markus points out, there are ways to change the base URL
19:44:15 <dmitriz> ... all that to say, for DI proofs, absolute IRIs are required any time there's key material. not sure what to do for JWTs
19:44:17 <kristina> ack dlongley
19:44:17 <Zakim> dlongley, you wanted to ask if we can say that this is specific to VC-JWT
19:44:30 <dmitriz> dlongley: if we haven't done this already (in the DI spec, we were going to specify this)
19:44:43 <dmitriz> ... that the base URL for a VC /must/ be null
19:44:48 <dmitriz> ... which would enforce the usage of absolute URLs
19:44:56 <Steve_McCown> +1 for absolute URLs in proofs, etc.
19:45:01 <Orie> iss: did:example:123, kid: #key-1 .... is safer.
19:45:04 <dmitriz> ... what I wanted to ask about -- is what Orie asking specific to JWTs?
19:45:13 <kristina> +1 to ack selfissued
19:45:17 <kristina> ack selfissued
19:45:20 <dmitriz> selfissued: this may be more of an analogy to think about,
19:45:34 <dmitriz> ... rather than directly actionable, but - JWT key ids just tend to be locally unique IDs, not URLs
19:45:46 <dmitriz> ... you get the key from a .well-known off of the issuer, or something along those lines
19:45:59 <dmitriz> ... so I'm sympathetic to 'kid's being local to the context of key retrieval
19:46:04 <Orie> yep... the DIF vc-jwt implementation made it up... because there was no guidance.
19:46:09 <dmitriz> ... I know that doesn't answer the question of where do you get the keys.
19:46:12 <Orie> which hurt us all.
19:46:18 <kristina> ack Orie
19:46:18 <Zakim> Orie, you wanted to explaint CWT / JWT use cases.
19:46:23 <dmitriz> ... but I think that should be separate from requiring kid from being absolute URLs. that would be overkill
19:46:42 <dmitriz> Orie: as many of you, I'm interested in compact representations, where we don't repeat information, and I'm also interested in building safe APIs
19:46:55 <dmitriz> ... in the context of VCs -- I'm going to focus on JWTs and JOSE for a sec
19:47:04 <dmitriz> ... there are some usages, in the JOSE spec, that are more or less safe
19:47:14 <dmitriz> ... and we should discuss on whether we should allow both, or ONLY require safe usages
19:47:37 <dmitriz> ... and Mike is right -- the definition for 'kid' is that it's an opaque hint, it's not a direct absolute IRI, it doesn't provide key resolution advice
19:47:53 <dmitriz> ... if we were to say nothing (in the VC spec), in my opinion it would be very harmful, in using JOSE with JWT
19:48:04 <dmitriz> ... because 'kid' is something a developer expects to be helpful
19:48:18 <manu> +1 to "we should explain exactly how to use iss/kid in VC-JWT"
19:48:19 <dmitriz> ... we should explain why 'kid' is valuable and helpful, and how we should use it to get the key material
19:48:22 <selfissued> q+
19:48:30 <dmitriz> ... regarding the duplicate info piece, I propose that we should break the convention
19:48:42 <manu> q+ to ask "what's the security issue"?
19:48:44 <dmitriz> ... that 'kid' should be an absolute URL, and I think that's a mistake now
19:48:59 <dmitriz> ... so I would propose we use 'iss' + 'kid' together, instead
19:49:10 <dmitriz> ... it's safer, and would allow us to have clearer guidance for implementers
19:49:18 <mprorock_> +1 to iss and kid
19:49:19 <dmitriz> ... if we don't give that guidance, they could do multiple different things
19:49:29 <dmitriz> ... but devs will for sure be doing extra work
19:49:50 <dmitriz> ... so we should plan to make their lives easier by dictating one consistent way of how to obtain the key materials for a JWT
19:50:03 <dmitriz> ... so while it's possible to leave optionality in, wrt key resolution, I don't think we should
19:50:08 <dmitriz> kristina: thanks, Orie
19:50:11 <manu> +1 to removing optionality wrt. key resolution with respect to VC-JWT.
19:50:31 <dmitriz> ... so, do we want to provide guidance on what to do with 'kid's in a JWT VC?
19:50:35 <kristina> ack selfissued
19:50:42 <dmitriz> selfissued: again, I'll make an analogy to other solutions
19:50:51 <dmitriz> ... in OIDC4VC work, we do retrieve the keys based on the issuer
19:50:59 <dmitriz> ... now, there is a case statement, which I think is ok,
19:51:19 <dmitriz> ... if the URL of the issuer is a DID, you retrieve the DID keys. if the URL is an https:// url, you tack on a .well-known/ identifier, and get the keys from that place
19:51:27 <dmitriz> ... and I think we'd do well in the VC 2.0 spec to do something similar
19:51:37 <dmitriz> ... recognizing the different affordances with DIDs and HTTP URLs
19:51:47 <dmitriz> ... but it would be good to have a normative retrieval method, yes
19:51:51 <kristina> ack manu
19:51:51 <Zakim> manu, you wanted to ask "what's the security issue"?
19:51:53 <Orie> +1 to normative guidance on retrieving public keys.
19:51:54 <dlongley> +1 for normatively described ways to get the keys
19:52:07 <dmitriz> manu: real quick, +1 to what Mike was saying, and to what Orie was saying -- we should be super clear, eliminate optionality
19:52:16 <dmitriz> ... and that's what people are suggesting, let's provide guidance for VC JWTs
19:52:40 <dmitriz> ... my concern is that we may not be thinking --- iterating though every single scheme (did, http) might be difficult. but what about people who want to use other schemes, IPFS, etc?
19:52:48 <dmitriz> ... that's challenging (the 'case' statement grows)
19:52:49 <Orie> We can't comment on identifier formats that are not standards.
19:52:57 <dmitriz> ... presuming we might do a relative URL thing might also be problematic
19:53:11 <dmitriz> ... this may not match every type of protocol scheme
19:53:20 <dmitriz> ... the only way you could be sure, is by having an absolute URL in 'kid'
19:53:29 <dlongley> Orie: well, we can comment on that -- we could say that how you fetch the keys depends on the identifier format and only these N are defined by the spec
19:53:31 <dmitriz> ... I think we're presuming a security issue
19:53:48 <dmitriz> ... the only thing I can think of here is -- 'iss' is a totally different URL from the URL in 'kid'
19:53:59 <dmitriz> ... like, if the issuer is a university, then the issuer URL would be the homepage
19:54:12 <Orie> FWIW, I could live with `kid` MUST be absolute or `kid` MUST be relative to `iss`... I can't live with both.
19:54:13 <kristina> q?
19:54:14 <dmitriz> ... but if the university is using an HSM to sign it, or a hosted key provider, then the 'kid' might be on a totally different domain
19:54:23 <dmitriz> ... so that's my concern -- in the rush to provide clear guidance
19:54:40 <dmitriz> ... (such as 'one of them is relative to the other one'), we'll eliminate valid use cases
19:54:49 <dmitriz> ... to be clear, I think absolute IRIs are the thing to do, but I'm interested in people who disagree
19:54:58 <Orie> q+
19:55:01 <markus_sabadello> +1 to absolute IRIs
19:55:03 <kristina> ack Orie
19:55:23 <dmitriz> Orie: concretely, the security issue is -- I create a JWS signature tomorrow, and I have 'iss' that's one value, and the 'kid' is a DID key URL,
19:55:31 <dmitriz> ... then it will always resolve, and there's no way to revoke it
19:55:35 <dmitriz> ... so the VC will always verify
19:55:51 <dmitriz> ... and to protect against that, we'd need to add additional text, such as 'hey, make sure this key is controlled by the issuer'
19:55:52 <dlongley> there needs to be a trusted link between the issuer and the key.
19:56:01 <manu> ^^ yes, that.
19:56:05 <dmitriz> ... and we'd need to have a per-protocol discussion for the relationship between iss and kid
19:56:11 <dwaite> q+
19:56:22 <dmitriz> ... the comment about that we don't know the various identifier schemes, I don't think that matters --
19:56:30 <manu> q+ to propose a security model that Data Integrity uses as a solution for this problem.
19:56:40 <dmitriz> ... we can define the schemes we expect to see in the wild. if somebody can make a case for another type of identifier, let them come forth
19:56:40 <selfissued> +1 to defining key retrieval methods for the URL types that we do expect to be used
19:56:49 <dmitriz> ... we shouldn't wait, to provide clear guidance
19:56:56 <kristina> ack dwaite
19:57:18 <dmitriz> dwaite: the reason 'kid' is defined as a hint, is because you need to know, for a given kid, is that it's something an issuer vouches for
19:57:25 <dmitriz> ... DIDs provide a way to enforce this
19:57:33 <dmitriz> ... for OIDC4VC, we provided a different mechanism
19:57:36 <Orie> dwaite is giving a good argument for why `kid` and `iss` should be used together IMO... it would be safer to use relative.
19:57:45 <Orie> +1 dwaite
19:57:59 <dmitriz> ... the issue with having absolute URIs -- we still have to define how does somebody enforce / check that the issuer controls the kid?
19:58:14 <dlongley> Orie: it being "relative" is just a shortcut to getting a trusted link / attestation from the issuer that the key is, in fact, theirs and intended to be used to sign a VC.
19:58:14 <dmitriz> ... so, they can be relative, maybe the 'kid' is not a URI but a fragment, but there still has to be a way
19:58:26 <kristina> ack manu
19:58:26 <Zakim> manu, you wanted to propose a security model that Data Integrity uses as a solution for this problem.
19:58:27 <dmitriz> ... of how to go from an issuer to the key, or if the key is trusted by the issuer
19:58:47 <dmitriz> manu: here's how this is solved Data INtegrity -- you HAVE to ensure there's a bi-directional link between issuer and key
19:59:02 <dmitriz> ... so, you go to the controller document (such as the DID doc), and you verify that the key is authorize3d
19:59:13 <dmitriz> ... clearly we need to have further discussion, but I'm confident we can unify the guidance
19:59:25 <dmitriz> kristina: thank you, everyone. Orie, anything we can do in this issue, to clarify?
19:59:49 <dmitriz> Orie: comment on the issue, make concrete proposals we might discuss on the follow-up call
19:59:55 <dmitriz> ... we need more engagement on issues
19:59:58 <dmitriz> kristina: agreed
20:00:12 <dmitriz> ... we encourage everyone to make proposals, add comments to the issue, so we can make progress
20:00:19 <decentralgabe> decentralgabe has left #vcwg
20:00:43 <kristina> rrsagent, draft minutes
20:00:43 <RRSAgent> I have made the request to generate https://www.w3.org/2022/10/12-vcwg-minutes.html kristina
20:00:51 <kristina> zakim, end meeting
20:00:51 <Zakim> As of this point the attendees have been brentz, kristina, mprorock, markus_sabadello, selfissued, TallTed, dmitriz, dlongley, manu, decentralgabe, Orie, Logan_Porter, shawnb,
20:00:54 <Zakim> ... dlehn, dwaite, kdean, Phillip_Long, Steve_C, Steve_McCown
20:00:54 <Zakim> RRSAgent, please draft minutes
20:00:54 <RRSAgent> I have made the request to generate https://www.w3.org/2022/10/12-vcwg-minutes.html Zakim
20:00:56 <Zakim> I am happy to have been of service, kristina; please remember to excuse RRSAgent.  Goodbye
20:01:00 <Zakim> Zakim has left #vcwg
20:01:04 <kristina> rrsagent, bye
20:01:04 <RRSAgent> I see no action items