Verifiable Credentials WG Telco — Minutes

Date: 2022-03-23

See also the Agenda and the IRC Log

Attendees

Present: Ivan Herman, Shigeya Suzuki, Michael Jones, David Chadwick, Charles Lehner, Orie Steele, Brent Zundel, Manu Sporny, Dave Longley, Marty Reed, Sebastian Elfors, Ted Thibodeau Jr., Gregory Natran, Kristina Yasuda

Regrets:

Guests:

Chair: Brent Zundel

Scribe(s): Michael Jones, Manu Sporny

Content:

Brent Zundel: Our working mode is working through issues.
… We will determine what we want to do for each issue and who is going to do it.
… If we don’t know what to do, we will close the issue.

Manu Sporny: IETF 113 is going on.
… We are dependent on the media types work. It is going fine.

Manu Sporny: See IETF Media type document.

Sebastian Elfors: introduced himself. He used to work for Yubico.

1. Clean up capitalization. (pr vc-wg-charter#104)

See github pull request vc-wg-charter#104.

Manu Sporny: PR #104 tries to clean up capitalization.

Brent Zundel: It appears to be truly editorial.

Ivan Herman: Proposed that if the reviewers are in agreement, it should be merged.
… Let me go through it before you merge it.
… I will do it later today during my evening.

2. Issues.

Brent Zundel: https://github.com/w3c/vc-wg-charter/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc.

Brent Zundel: This is the order we’re going to follow.

2.1. Add JwtProof2020 to the charter (issue vc-wg-charter#84)

See github issue vc-wg-charter#84.

Brent Zundel: Is there anything that needs to be done to the charter to address #84?

Orie Steele: Resulting from conversation in CCG.
… People will base64url-decode the VC-JWT. You only see a decoded VC-JWT.
… Someone decoded one, added something looking like a linked data proof, and called it something else.
… We need to define the JSON representation of a credential.
… We need to define the serialized representations - either as a compact JWT or a linked data proof.
… We need to make sure we’re defining things correctly.
… We need to include examples that can be cut-and-pasted by implementers.
… If we need to add specific capabilities to the charter to enable this, we should do so.
… We need to gather more feedback. There’s been no feedback in the last 21 days.

Manu Sporny: It’s a good point that Orie raises.
… I expect the work to be done in the VC-JWT spec.
… I expect us to pull that out and make it its own specification.
… We have 1.1 VC-JWT examples.

Manu Sporny: See example for the id property in the current spec.

Orie Steele: Those examples are from v1.1 not 1.0.

Orie Steele: but +1 to what manu is saying.

Manu Sporny: We have examples of VC-JWTs through the spec - both unencoded and encoded.

Brent Zundel: I don’t think the charter needs to be changed for this to happen.

Ivan Herman: +1 to brentz.

Brent Zundel: People can raise issues to ensure this is tracked.

Manu Sporny: +1 to close issue, we can address it per the current VCWG charter.

Orie Steele: I closed the issue and left a comment on it.

2.2. Environmental, Ethical and Social Implications of the Work (issue vc-wg-charter#89)

See github issue vc-wg-charter#89.

Orie Steele: Objections to the DID spec included social and environmental issues.
… The TAG seems to be taking us in a direction to require environmental statements, etc.
… There’s a cultural shift to acknowledge the implications of the work that we do.
… I want us to explicitly decide whether to add this to the charter or not.
… ZKPs are notoriously expensive in terms of computation.
… New ZKP cryptography is expensive.
… New ZKP is subject to attacks, etc.
… I want to have the conversation at the start while chartering, rather than at the end when we can’t fix it.

Ivan Herman: We don’t know yet how this discussion will evolve at the W3C.
… I would be very concerned about putting anything specific into the charter.

Brent Zundel: +1 Ivan.

Dave Longley: +1 to ivan.

Ivan Herman: Like internationalization, we may have to deal with it in any case.
… I don’t see what might need to change.

Michael Jones: +1 to Ivan.

Manu Sporny: +1 to close and deal w/ it when something concrete happens.

Orie Steele: I have not closed the issue.
… I will leave a comment and then close the issue.
… I remain concerned about the W3C’s ability to address objections of this nature.

2.3. Some of the “other deliverables” raise patent concerns (issue vc-wg-charter#72)

See github issue vc-wg-charter#72.

Brent Zundel: This led to a good conversation about IPR for notes versus specifications.
… I do not believe this should be a blocker for the charter.
… Should any potential notes be removed?
… If so, who is going to do it?

Manu Sporny: We’ve hit a steady state and shouldn’t rock the boat.
… We have multiple mechanisms for patent protection.
… Should we ask Wendy or Rigo what mechanisms are available to us for patent protection of the note?
… For instance, could companies get together and submit the note as a member submission? (Not that I think this is a good idea.).

Orie Steele: This is related to the issues around licenses.
… I’m not sure how to safely ask this question.
… There have been concerns about what happens to the W3C if the legal entity issue is not resolved.

Ivan Herman: Let’s not go there.

Orie Steele: Does anyone with more experience think this is relevant to the topic at hand?

Ivan Herman: Wendy is the right person to ask.
… This is the first time I’ve hit this issue in any working group.
… There is a remote possibility of the W3C finding itself in a strange spot.
… If that happens, there will be a W3c-wide line of actions to take.
… We do not need to do anything special in this working group.
… We are using the most liberal license already.

Manu Sporny: Reminder that all of our specs are published under a permissive license: https://www.w3.org/Consortium/Legal/2015/copyright-software-and-document.

Manu Sporny: also, +1 to what ivan is saying and what brentz is about to say. :).

Orie Steele: good, as long as we have already picked the most permissive, thats all we can do.

Brent Zundel: The licenses we’ve already used for the VC Data Model are already the most permissive ones.
… Worst comes to worst, the documents could move to another organization.
… With nothing more to be said about this issue, I’m going to close it.

Manu Sporny: You can fork the spec today, if you wanted to – I mean, you’d be shunned, SHUNNNNNNnnnnED… but you could do it. :).

2.4. Normatively defined crypto suites MUST fully define both public and private key representations (issue vc-wg-charter#82)

See github issue vc-wg-charter#82.

Brent Zundel: Normatively defined crypto suites MUST fully define both public and private key representations.

Orie Steele: I’m just going to close it. We’ve had a great conversation. You can read the thread.

2.5. Each registry should include at least one standardized entry (issue vc-wg-charter#67)

See github issue vc-wg-charter#67.

Brent Zundel: Each registry should include at least one standardized entry.
… The WG came to consensus on language that largely addresses this issue.
… Kyle requested that the issue be left open.
… Kyle wants to expand that to “for everything else, there SHOULD be …”.

Manu Sporny: I think we’ve done what we can..

Orie Steele: I don’t think we use MUST or SHOULD on charter documents either… right?

Manu Sporny: We shouldn’t add SHOULD statements that we know that we’re not going to satisfy.
… We shouldn’t create a charter that doesn’t reflect reality.

Brent Zundel: +1 manu.

Brent Zundel: Charters don’t have RFC2119 statements.
… I’m going to close it. I hear no screams.
… We have three more issues.

2.6. Definition of all key formats are left out of scope of the VC data model and crypto suites (issue vc-wg-charter#97)

See github issue vc-wg-charter#97.

Brent Zundel: Definition of all key formats are left out of scope of the VC data model and crypto suites.

Orie Steele: Kyle and I have been chatting about this a lot.
… I’ve encountered an argument in favor of his position.
… Basically, we have envelope formats we intended to support - for embedded and external proofs.
… JOSE and COSE define key formats.
… There are non-standard key formats that aren’t defined by the IETF.
… If you’re defining a new envelope format, should you concretely bind the signature format to the key format?
… By convention, the answer to that may be yes.
… Kyle is objecting to making that a normative requirement.
… Imagine you have a CWT signed by a key represented in JWK format.
… The two can be represented in different formats.
… This could get very painful if there is an unbounded number of key formats per signature format.

Manu Sporny: There’s nothing we’re doing that prevents arbitrary key format conversion.
… We aren’t preventing this in the charter.
… Telling people that they have to do arbitrary key conversion isn’t doing people any favors.
… -1 to not strictly saying what the input key types are for crypto suites.
… We need to provide a full-blown test suite if we’re asking for arbitrary conversions.

Michael Jones: Two points.
… Remember we talked about how protocol usage affects data structure design? This is one of those places, I think, in practice.

Orie Steele: +1 to what Mike is saying.

Michael Jones: Again, modelling after OpenID Connect, there are places where JWTs are used, but there are places where keys are included and those keys are JWK format. That promotes interop. To the extent that keys will be passed as protocol elements, we are better off having a small or singleton set to promote interoperability. I’m not asking to put this into the charter, but once we’re in the WG, whether we want to make JWK support mandatory is a fair question.
… I agree with Manu that arbitrary key conversion is evil both from implementation and interop mechanism, would rather we have a small set of key formats when moving forward.

Brent Zundel: This is something the WG needs to continue talking about.
… Charter changes aren’t needed to have these conversations.
… I’m going to close this issue on that basis if there are no objections.

Dave Longley: +1 to brent, we should have the WG continue this discussion, no charter changes required.

Manu Sporny: +1 to close and take conversation up in VC2WG.

2.7. New PR needed if did:key/multibase is going to be in scope (issue vc-wg-charter#83)

See github issue vc-wg-charter#83.

Brent Zundel: New PR needed if did:key/multibase is going to be in scope.

Manu Sporny: I think this is already covered by the charter.
… The WG can decide whether multikey should go to recommendation.

Manu Sporny: In other words, this is clearly in scope and the VC2WG can discuss whether or not they want to make this a REC.

Brent Zundel: Any other comments on this before I close it on the basis that no changes are required in the charter?
… We are at our final issue.

2.8. algorithms-related input documents for all proofs of integrity types (issue vc-wg-charter#88)

See github issue vc-wg-charter#88.

Brent Zundel: algorithms-related input documents for all proofs of integrity types.

Kristina Yasuda: This data is whether we want to add additional RFC input documents for VC-JWT work.
… We don’t need to remove any CCG documents for LDP work.
… It would be good to have these RFCs referenced.

Orie Steele: PR welcome.

Manu Sporny: JWS will reference the RFCs. VC-JWT should do so as well.
… I don’t think there’s an issue adding references based on the input documents we already have?

Brent Zundel: If there was a theoretical PR, would people be opposed to merging it.

Orie Steele: I would be in favor of a PR adding the RFCs relative to VC-JWT.

Kristina Yasuda: I would be glad to do that.

Michael Jones: I had a practical question, are there RFCs not transitively referenced by JWS or some of the other JOSE related input documents that we should be adding because there isn’t a transitive reference to them?

Manu Sporny: The answer to Mike’s question is that I don’t think there are documents not transitively referenced.
… We could add input documents.
… I don’t understand what we’re trying to include. I’m against modifying the charter at this point.

Orie Steele: I queued to answer Mike’s question about transitive reference.
… VC-JWT has no input documents.
… I think it’s a bad idea to not have input documents for VC-JWT. The charter should reference them.
… Having directly links to the IETF RFCs is incredibly useful to people reading the charter.

Manu Sporny: The input document to VC-JWT is defined in the VC 1 spec.

Manu Sporny: See relevant section in the 1.0 spec.

Manu Sporny: It contains normative references to the JOSE specs. I don’t see the problem here.
… It doesn’t make sense to me.

Kristina Yasuda: Could we add a sentence that clarifies that input for VC-JWT is vc-data-model v1 and normative references there?

Michael Jones: Since there aren’t input documents other than previous version of our own specification, I would support WG considering a PR to do so, probably authored by Kristina and approved by Orie.
… Let’s try that as good due diligence.

Brent Zundel: We have an input document, which is the previous version of the specification.
… If there aren’t RFCs already referenced in that way, I support adding them.
… I would not be opposed to a PR adding them.

Orie Steele: I don’t see any problem making the link between VC-JWT in VCDM 1.1 and IETF RFCs more explicit… thats a helpful thing for folks who don’t have the background information that we all have.

Kristina Yasuda: My suggestion would be to explicitly add a sentence saying that the previous specification is an input document for the VC-JWT work.
… I can investigate whether there are additional RFCs we should be adding.

Manu Sporny: but we already do that. :(.

Manu Sporny: “Container Formats: VC-JSON Web Token (JWT)” <– right there.

Manu Sporny: It links to VC Data Model spec – VC JWT section.

Manu Sporny: (which then references the IETF specs).

Brent Zundel: There is a link in the charter.

Orie Steele: given how poorly defined VC-JWT was in the previous versions, I think its prudent to do better with IETF RFCs.

Kristina Yasuda: Can I have a few days to investigate?

Manu Sporny: I’m fine w/ checking..

Brent Zundel: I am fine with that course of action.
… We need to see that PR by the end of the week to be able to review it our next meeting.
… With that, we have closed all but one of our issues.
… I am assigning the remaining issue to Kristina.
… We’ll see what happens.

3. future steps.

Ivan Herman: There are numerous issues we have closed because no changes are needed to the charter.

Orie Steele: Luckily github tracks closed issues for us.

Ivan Herman: I don’t want to have these things lost.
… Can we label them somehow for future consideration?

Brent Zundel: I will take an action item to add such a label.

Ivan Herman: The next step is to send the charter to the W3C for review.
… We need to do this ASAP.
… The AC meeting is soon.
… We should be prepared to approve or object during our meeting in a week.

Brent Zundel: Any other comments before we close the meeting?
… I have created a label FutureVCWorkingGroupConversation.
… Thanks for coming and for your hard work.
… We have created a great charter.
… I look forward to being in the working group and doing the work.
… I’ll see you all next week.
… Thank you to Mike for scribing.