Verifiable Credentials Working Group Telco — Minutes

Date: 2022-10-12

See also the Agenda and the IRC Log

Attendees

Present: Brent Zundel, Kristina Yasuda, Michael Prorock, Markus Sabadello, Michael Jones, Ted Thibodeau Jr., Dmitri Zagidulin, Dave Longley, Manu Sporny, Gabe Cohen, Orie Steele, Logan Porter, Shawn Butterfield, Przemek Praszczalek, David Lehn, Phillip Long, David Waite, Kevin Dean, Steve Cole, Steve McCown

Regrets:

Guests:

Chair: Kristina Yasuda

Scribe(s): Dmitri Zagidulin

Content:

Kristina Yasuda: (summary of call agenda).

Manu Sporny: is now an appropriate time to review PRs?.

Kristina Yasuda: let’s do intros / special topics, and then move to PRs.

Przemek Praszczalek: hi I’m Przemek Praszczalek from MasterCard (Cyber and Intelligence Division), working on Identity there. Excited to be here..

1. IRC etiquette.

Kristina Yasuda: at the last call, Ivan proposed starting a second IRC channel (to contain side-conversations on IRC during the call).
… which was a fair observation..
… 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.
… what you’re typing (without a ‘/me ‘ preceding it) will go onto public record, so please be mindful.
… so if you feel the need to add off-topic comments, please use /me, which won’t go into the minutes.

Brent Zundel: thanks Kristina. I second everything Kristina said; Ivan did admit that proposing an entirely separate IRC channel for snark & side-convos was slightly extreme.
… but really, we’re just asking to do three things. 1) whenever your comment is snark, use emote options..
… 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.

Kristina Yasuda: thanks Brent. any questions related to this?.
… moving onto the next topic.

Orie Steele: In case you want to join the W3C Slack channel, and post your snark there too: https://w3ccommunity.slack.com/archives/C0456S64PPF.

2. Special Topic Calls.

Kristina Yasuda: this is related to the conversation we had last week, issue #929 “What does JSON-LD compatible mean?”.
… the chairs are not yet ready to take resolution on this topic..
… we’d like to continue the conversation and discussions..
… 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.
… and issue #929 was recently closed, and Manu kindly offered to re-open individual issues for separate topics in that thread.
… and Brent has kindly agreed to organize special topic calls when needed.

3. Work Item Status Updates and PRs.

4. PRs.

Manu Sporny: VC-data-model / #924 – we’ll skip that.

Kristina Yasuda: apologies, related to the previous discussions, but link to the issue that has been closed, which also has links to the new issues that manu broke down into: https://github.com/w3c/vc-data-model/issues/929.

Manu Sporny: we’re going to discuss today https://github.com/w3c/vc-data-model/pull/924.

Manu Sporny: 943 has been opened as a counter-proposal.

Manu Sporny: Counterproposal for #924 https://github.com/w3c/vc-data-model/pull/943.

Manu Sporny: so I expect that we should discuss that today as well; those two issues are just two sides of the same coin.

Manu Sporny: https://github.com/w3c/vc-data-integrity/pulls.

Manu Sporny: so that’s it for data model pulls.
… as far as Data Integrity pull requests, there is a PR to add an initial JSON-LD context for data integrity.

Manu Sporny: Add initial JSON-LD Context for Data Integrity – https://github.com/w3c/vc-data-integrity/pull/61.

Manu Sporny: that is also related to the discussion we want to have today.

Manu Sporny: Refactor Generate Proof algorithm – https://github.com/w3c/vc-data-integrity/pull/62.

Manu Sporny: and then there’s some cleanup work happening in PR #62, which refactors the Generate Proof algorithm.
… 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.
… 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.

Manu Sporny: Links to implementing Data Integrity streamlining: https://github.com/w3c/vc-data-integrity/pull/61#issue-1402344013.

Manu Sporny: the other thing to pay attention to – here’s a link to implementing Data Integrity streamlining.
… we discussed the DI spec at W3C TPAC. There is now a JSON-LD context for that.
… there is an implemented Cryptosuite (something called ‘eddsa-2022’ suite).

Kristina Yasuda: how is this related to PR 943, counterproposal to removing proofs in vc-data-model.

Manu Sporny: there’s going to be a spec very shortly for it.
… there’s an implementation, and a conformance test suite.
… so pay attention to that, if you haven’t been following Data Integrity, since that will be moving faster.

Kristina Yasuda: the PR #61 is similar to vc-data-model PR #943?.

Manu Sporny: close. One is about establishing a context that has nothing to do with VCs, that’s just data integrity related.
… in the vc-data-model, we’re saying – let’s pull the DI context into the core VC context.

Kristina Yasuda: thanks.
… editors of JWT VC and JSONSignature2020, can you please report on the status?.

Michael Jones: Orie and I need to address the comments on the PRs, including those by Kristina,.
… none of them make normative changes.

Kristina Yasuda: any update on JsonWebSignature?.

Orie Steele: we’re almost there. we have a PR that’s been open since August 10, and it involves a context change,.

Orie Steele: See The PR I was referring to.

Orie Steele: and it has 3 people who have commented on it..
… it’s not looking super good in terms of engagement.
… so either there’s not a lot of interest in the group on this, or my pleas for engagement are going unheeded.
… so please weigh in, add your comments, PR approvals, etc..
… and make it clear if you’re requesting changes, or if you’re against the whole thing.
… otherwise, it’s impossible for the PR author (me in this case) to resolve your feedback.
… I’d like to merge this PR, to set a foundation for some of the semantic processing associated with WebSignature2020.
… I’ve tested it out, it has behavior that I like more than the current implementation.

Michael Prorock: i would like this merged as well for similar reasons when looking at data in a node graph.

Manu Sporny: it’s not related to this PR, but in general,.
… 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.
… Orie, you’re still using the ‘jws’ property, and I’ve made an affordance in the DI spec to account for that.
… I was wondering if we could unify on ‘proofValue’.
… or would you prefer to continue using ‘jws’.
… so, there’s something for us to discuss, and I just wanted to raise awareness.

Orie Steele: Is there an issue to track that?.

Manu Sporny: Nope :).

Orie Steele: I will comment on issues when linked / requested..

Manu Sporny: I’ll open an issue.

Kristina Yasuda: ok, that concludes our updates on PRs and issues for the items.

Michael Prorock: Manu, are you asking that in the ‘proof’ block, we change ‘jws’ to ‘proofValue’?.

Manu Sporny: yeah, there’s some upsides & downsides to doing that. I’ll raise an issue.

Orie Steele: Related to the open PR… https://github.com/w3c/vc-data-model/pull/943/files#diff-267b7e47789daf9a1d312b42826aa937a1bb5af4312ee90df6b8a64cd6426f4fR146.

Kristina Yasuda: let’s move to the next topic.

5. Remove proof from v2 context (pr vc-data-model#924)

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

Kristina Yasuda: manu has briefly mentioned it.
… brief overview – Orie did a PR removing ‘proof’ from the VC @context.
… there is another PR that’s a counter-proposal (to keep the proof).
… anyone who would like to speak to move this forward?.

Orie Steele: 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 Integrity to the VC context.

Orie Steele: this is a valid path forward, and I’m happy to close my PR..
… I asked for a counter-proposal, and it was given. so unless anyone objects I’ll close my PR.

Manu Sporny: does everyone understand the ask?.
… Orie, not everyone on the call may understand what’s being proposed in the PRs.
… we can ask if anyone has objections, but I’m just concerned people are unclear.

Shawn Butterfield: I’ll sheepishly admit that I don’t fully understand - I’m about 60% of the way there..

Kristina Yasuda: that’s a fair point.
… Orie would you like to comment?.

Orie Steele: I invite people to look through the comments / conversation in the issues.

Manu Sporny: ok, let me see if I can explain.
… 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)?.
… 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.
… so the whole question is – do we want to create a base format for a Data Integrity proof, that’s batteries included.
… meaning, when somebody includes the VC v2 context, for most use cases, they can just attach a DI proof.
… that’s what my PR does.
… 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.
… 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.
… this whole thing does not hurt or affect JWT VCs.
… it just makes JSON-LD dev experience easier; cuts down on too many cryptosuite contexts from being created.
… so, it offers upsides for DI users, while not dis-enfranchising JWT users.

Shawn Butterfield: just wanted to say thank you, Manu, that was helpful, and I see the connection between the PRs. I think this is great.

Phillip Long: +1 to the explanation and support closing 924, as well..

Kristina Yasuda: so, what’s on the table is closing #924.
… any objections?.

Manu Sporny: +1 to close #924.

Dmitri Zagidulin: +1 to close.

Dave Longley: +1 to close #924.

Logan Porter: +1 to close.

Shawn Butterfield: +1.

Orie Steele: I opened it, I closed it..

Orie Steele: :).

Markus Sabadello: +1.

Kristina Yasuda: 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).
… ok, the counter-PR was opened 3 days ago, let’s give people a few more days to comment on it.
… ok, let’s move to issues discussion.

6. Issues Discussion.

Kristina Yasuda: See list of relevant issues.

Kristina Yasuda: 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.
… and most of them don’t have activity after that.
… so, I picked several that have enough new comments that we haven’t discussed.

6.1. Dereferencing relative to issuer (issue vc-data-model#914)

See github issue vc-data-model#914.

Kristina Yasuda: the first one was #914 where Brent added the label ‘discuss’.
… de-referencing relative to issuer.
… . Brent was asking the question.
… Orie or Brent – any comments?.

Orie Steele: an issuer is a well-understood term at this point.
… you can use the term definition from VC spec 1.1.
… in the case of a Data Integrity proof, there’s a well-defined relationship between the issuer, the verificationMethod, and the proof.
… so in a DI proof, as a developer, I know what to do with a key and how to verify.
… in the context of JWTs, it’s completely un-defined.
… this may be shocking, you may ask – how can I use JWTs if I don’t know how to obtain the public key?.
… 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.
… 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.
… 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.
… 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.
… which was - an absolute ‘kid’ vs relative url.

Michael Prorock: +1 orie.

Orie Steele: but basically, we need a consistent definition of how to obtain a public key for a JWT.

Kristina Yasuda: thanks Orie.

Manu Sporny: +1 to providing guidance.
… we should do that, since this has come up multiple times, and we keep making different decisions.
… the thing that stands out to me that feels dangerous, is the whole ‘iss’ + ‘kid’ approach.
… which presumes that the verification method is always relative (or can be relative).
… this is dangerous because it presumes that the ‘iss’ property always exists.
… but for Data Integrity proofs, they can be applied to non-VC objects.
… in use cases where there’s no issuer.
… if ‘kid’ is always a relative URL and it’s enforced, then that might be ok…
… I’ll also note that there are valid concerns about putting absolute URLs everywhere.
… where the key that’s signed is different from the issuer’s URL.
… some people look at that as a feature, some as a bug.

Orie Steele: so, the example that I’ve shown, with ‘iss’ + proof verificationMethod was confusing.
… in a VC that uses a DI proof, you only need proof.verificationMethod to obtain the key material.

Manu Sporny: ok, thanks Orie, that’s helpful..

Gabe Cohen: +1 Orie, ran into this exact issue this week when implementing resolving keys + verifying jwt-vcs.

Orie Steele: 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.
… I’ve seen libraries that check for this, and I’ve implemented that myself.

Dave Longley: +1 to Orie, thanks for clarifying.

Orie Steele: anyways, so this issue is – how did you get to that key material in the first place.

Manu Sporny: ah, I think I see….

Orie Steele: the other point I don’t agree with that Manu made.
… is that DI proofs apply to things that aren’t VCs. I agree that that’s true, but VCs /require/ issuers.
… so one is not going to encounter a situation, in the context of this WG, where that would happen, unless we make normative changes.

Markus Sabadello: I agree, it feels like this should be defined (wrt relative IDs).
… in the JSON-LD perspective, such a relative ID would be resolved relative to the ‘id’ field, rather than the ‘issuer’ field.

Gabe Cohen: I’m curious where the normative change needs to be. Is this something that the VC JWT spec can handle?.

Orie Steele: To be clear, I am NOT suggesting proof.verificationMethod be ANYTHING other than an absolute IRI to a verificationMethod.

Orie Steele: I am pointing out that people still have questions about relationship to issuer..

Manu Sporny: ok, so what Orie just said (in chat) – great, I totally agree with that.
… so what’s our further question….

Orie Steele: manu, we are talking about this: https://github.com/digitalbazaar/vc-js/blob/main/lib/CredentialIssuancePurpose.js#L72.

Manu Sporny: how about this – let me try and state a question and provide an answer.
… 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.
… does anyone object or disagree?.
… introducing relative URLs, especially around key material in DI proofs, is asking for trouble.
… since as Markus points out, there are ways to change the base URL.
… all that to say, for DI proofs, absolute IRIs are required any time there’s key material. not sure what to do for JWTs.

Dave Longley: if we haven’t done this already (in the DI spec, we were going to specify this).
… that the base URL for a VC must be null.
… which would enforce the usage of absolute URLs.

Steve McCown: +1 for absolute URLs in proofs, etc..

Dave Longley: what I wanted to ask about – is what Orie asking specific to JWTs?.

Orie Steele: iss: did:example:123, kid: #key-1 …. is safer..

Kristina Yasuda: +1 to ack selfissued.

Michael Jones: this may be more of an analogy to think about,.
… rather than directly actionable, but - JWT key ids just tend to be locally unique IDs, not URLs.
… you get the key from a .well-known off of the issuer, or something along those lines.
… so I’m sympathetic to ‘kid’s being local to the context of key retrieval.
… I know that doesn’t answer the question of where do you get the keys..

Orie Steele: yep… the DIF vc-jwt implementation made it up… because there was no guidance..

Orie Steele: which hurt us all..

Michael Jones: but I think that should be separate from requiring kid from being absolute URLs. That would be overkill.

Orie Steele: 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.
… in the context of VCs – I’m going to focus on JWTs and JOSE for a sec.
… there are some usages, in the JOSE spec, that are more or less safe.
… and we should discuss on whether we should allow both, or ONLY require safe usages.
… 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.
… if we were to say nothing (in the VC spec), in my opinion it would be very harmful, in using JOSE with JWT.
… because ‘kid’ is something a developer expects to be helpful.

Manu Sporny: +1 to “we should explain exactly how to use iss/kid in VC-JWT”.

Orie Steele: we should explain why ‘kid’ is valuable and helpful, and how we should use it to get the key material.
… regarding the duplicate info piece, I propose that we should break the convention.
… that ‘kid’ should be an absolute URL, and I think that’s a mistake now.
… so I would propose we use ‘iss’ + ‘kid’ together, instead.
… it’s safer, and would allow us to have clearer guidance for implementers.

Michael Prorock: +1 to iss and kid.

Orie Steele: if we don’t give that guidance, they could do multiple different things.
… but devs will for sure be doing extra work.
… so we should plan to make their lives easier by dictating one consistent way of how to obtain the key materials for a JWT.
… so while it’s possible to leave optionality in, wrt key resolution, I don’t think we should.

Kristina Yasuda: thanks, Orie.

Manu Sporny: +1 to removing optionality wrt. key resolution with respect to VC-JWT..

Kristina Yasuda: so, do we want to provide guidance on what to do with ‘kid’s in a JWT VC?.

Michael Jones: again, I’ll make an analogy to other solutions.
… in OIDC4VC work, we do retrieve the keys based on the issuer.
… now, there is a case statement, which I think is ok,.
… 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.
… and I think we’d do well in the VC 2.0 spec to do something similar.
… recognizing the different affordances with DIDs and HTTP URLs.
… but it would be good to have a normative retrieval method, yes.

Orie Steele: +1 to normative guidance on retrieving public keys..

Dave Longley: +1 for normatively described ways to get the keys.

Manu Sporny: real quick, +1 to what Mike was saying, and to what Orie was saying – we should be super clear, eliminate optionality.
… and that’s what people are suggesting, let’s provide guidance for VC JWTs.
… 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?.
… that’s challenging (the ‘case’ statement grows).
… presuming we might do a relative URL thing might also be problematic.
… this may not match every type of protocol scheme.
… the only way you could be sure, is by having an absolute URL in ‘kid’.

Orie Steele: We can’t comment on identifier formats that are not standards..

Dave Longley: 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.

Manu Sporny: I think we’re presuming a security issue.
… the only thing I can think of here is – ‘iss’ is a totally different URL from the URL in ‘kid’.
… like, if the issuer is a university, then the issuer URL would be the homepage.

Orie Steele: FWIW, I could live with kid MUST be absolute or kid MUST be relative to iss… I can’t live with both..

Manu Sporny: 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.
… so that’s my concern – in the rush to provide clear guidance.
… (such as ‘one of them is relative to the other one’), we’ll eliminate valid use cases.
… to be clear, I think absolute IRIs are the thing to do, but I’m interested in people who disagree.

Markus Sabadello: +1 to absolute IRIs.

Orie Steele: 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,.
… then it will always resolve, and there’s no way to revoke it.
… so the VC will always verify.
… and to protect against that, we’d need to add additional text, such as ‘hey, make sure this key is controlled by the issuer’.

Dave Longley: there needs to be a trusted link between the issuer and the key..

Manu Sporny: ^^ yes, that..

Orie Steele: and we’d need to have a per-protocol discussion for the relationship between iss and kid.
… the comment about that we don’t know the various identifier schemes, I don’t think that matters –.
… 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.

Michael Jones: +1 to defining key retrieval methods for the URL types that we do expect to be used.

Orie Steele: we shouldn’t wait, to provide clear guidance.

David Waite: 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.
… DIDs provide a way to enforce this.
… for OIDC4VC, we provided a different mechanism.

Orie Steele: dwaite is giving a good argument for why kid and iss should be used together IMO… it would be safer to use relative..

Orie Steele: +1 dwaite.

David Waite: the issue with having absolute URIs – we still have to define how does somebody enforce / check that the issuer controls the kid?.

Dave Longley: 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..

David Waite: so, they can be relative, maybe the ‘kid’ is not a URI but a fragment, but there still has to be a way.
… of how to go from an issuer to the key, or if the key is trusted by the issuer.

Manu Sporny: here’s how this is solved Data Integrity – you HAVE to ensure there’s a bi-directional link between issuer and key.
… so, you go to the controller document (such as the DID doc), and you verify that the key is authorize3d.
… clearly we need to have further discussion, but I’m confident we can unify the guidance.

Kristina Yasuda: thank you, everyone. Orie, anything we can do in this issue, to clarify?.

Orie Steele: comment on the issue, make concrete proposals we might discuss on the follow-up call.
… we need more engagement on issues.

Kristina Yasuda: agreed.
… we encourage everyone to make proposals, add comments to the issue, so we can make progress.