Verifiable Credentials Working Group Telco — Minutes

Date: 2023-08-30

See also the Agenda and the IRC Log

Attendees

Present: Brent Zundel, Michael Prorock, Ted Thibodeau Jr., Kristina Yasuda, Gabe Cohen, Sebastian Crane, Manu Sporny, David Chadwick, Joe Andrieu, Benjamin Young, Dave Longley, Andres Uribe, Michael Jones, Orie Steele, Dmitri Zagidulin, David Lehn, David Waite, Justin Richer

Regrets:

Guests: Calvin Cheng

Chair: Brent Zundel

Scribe(s): Joe Andrieu, Manu Sporny

Content:

* present:* present+.

Brent Zundel: processing issues and discussions as usual.

Rachel: self-introduction (hard to hear).

CalvinCheng: self-introduction. here to learn.

1. Work Item status updates/PRs.

Brent Zundel: starting with updates and PRs.

1.1. Changes to normative statements (pr vc-jose-cose#143)

See github pull request vc-jose-cose#143.

Brent Zundel: looking to transition to CR no later than end of September.

Michael Prorock: one PR ready to merge (vc-jose-cose).
… clean things up. better to test.
… should help with test suites.

1.2. Add support for DIDs (pr vc-jose-cose#144)

See github pull request vc-jose-cose#144.

Michael Prorock: Also PR #144 could use eyes.
… pulling over items from data integrity.
… some won’t apply to jose-cose, so help with that would be appreciated.

1.3. Schema test suite.

Gabe Cohen: https://github.com/TBD54566975/vc-json-schema-test-suite.

Gabe Cohen: the VC-json-schema test suite is up. testing our implementation at Block.
… reach out to me if you’re interested in integrating it.

Brent Zundel: Ivan is out, but I’ll follow up with him about moving the repo.

1.4. DI, VCDM, and Crypto Suite specs.

Manu Sporny: update on data-integrity and crypto suite specs.
… we have PRs for all before-CR issues. In DI and the cryptosuites.
… for VC Data Model, by the end of september, I don’t see that happening. Its close but we need more issue processing and PRs.
… maybe October?
… StatusList continues to drag. It shouldn’t have much work, but should be doable.

Brent Zundel: StatusList, just needs rebasing on the one open PR.

Manu Sporny: yes, some merge conflicts, Mike?

Michael Prorock: I’ll look after the call.

Manu Sporny: we should discuss if we are going to have multiple status list types or not.

Michael Prorock: +1 manu.

Brent Zundel: for the group, the chairs perspective: meetings up to and including TPAC will be processing issues and PRs for all issues marked before CR.
… whatever we don’t get to before TPAC, we’ll deal with that at TPAC.
… Editors, can you reach out to us to tell us how much time you need during TPAC.

Manu Sporny: I’m wondering what you mean by time.
… if we have no pre-cr issues what are you expecting?

Brent Zundel: if no pre-cr issues open and all PRs are merged, then we can talk proposal to move to CR.
… which probably won’t need much time.
… other work items might need more time.

2. Add Verification Method types to v2 context (pr vc-data-model#1260)

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

Orie Steele: this PR was raised after a thread in DI repo about how many contexts are needed.

Joe Andrieu: .,, vc-di has the vc-di context, but only with limited terms.

Orie Steele: [more details].
… in DI, we have three contexts. one for proof and DI proof. one for multi-key and one for webkey.
… for StatusList2021 you can use without one of the contexts, but that context is bundled into v2 context.
… you can use multikey and json multikey but these are not bundled.
… so this adds those terms to that bundle, so you can get the same URI in all situations.
… the contentious part is the private key representations.
… manu said he doesn’t know a good use case for private keys.
… my preference is that the term definitions be consistent, as its harder to prevent them from …
… people can do whatever they want. my preference would be to make sure the graph looks right.
… also, the keys part of a JSON web key set.
… similiar to JWK in v2.

Manu Sporny: I think that’s a fair introduction to the issue.
… to hone in on the parts that are contentious.
… One is, do we have a use case where people are going to express private key material in a VC and signing it?
… If so, they can always do that.
… but its a corner case, so it’s not clear we want to promote that by default.
… I don’t think that as a working group we should be promoting that.
… Signing over private key material doesn’t seem like something we should support.
… We don’t currently have an example of representing this.
… if we had confidenceMethod is included, that might make sense.
… but that doesn’t look to be on a trajectory to make it into the spec, so I think we should hold off.
… If we get a super valid use case, we can always put that into the context later.
… We have text in the spec that the context file might change during CR and we can deal with it then.

Phillip Long: +1 to NOT supporting signing over private credentials - not something we should encourage. As we’re in an open world model we can’t prevent this.

Manu Sporny: I don’t think its a good idea to merge this PR at this time. We need a good use case.

Phillip Long: private credentials should have read private keys.

Sebastian Crane: Orie, I know where you’re coming from. I asked Manu something similar last week.
… given the VC flexibility, you can use them to cross-sign keys.
… any one of those use cases could be addressed with cross-signing.

Orie Steele: You can sign whatever you want… this working group does not control what issuers sign… and using RDF to try and enforce that is… not a good idea.

Manu Sporny: To be clear - we’re not blocking any of the use cases Orie is talking about… we’re just saying: “That’s not a mainstream use case, but if you want to do it, there is a mechanism there to do it (include the other context).”.

Sebastian Crane: at no point do you actually need a private key to move.

Orie Steele: The confidenceMethod is reserved. Not clear if we settled domain & range.
… There is a question if we should define those for reserved properties.
… You could say the range is “verification methods”.
… then you could expect to see those defined.
… For those who want confidence method, one of the use cases is to bind to a DID.
… the other is to bind to some key material.
… the only contentious issue I see here is the secret key material in them.
… if its better to do that not in the V2 context, but can be in a different one.
… I was surprised to see secret keys in the context definition.
… I want to move away from the multi-base approach but support issuer-provided means.

Brent Zundel: this is good, about ready to move on.

Manu Sporny: two contentious part here. one confidenceMethod doesn’t exist (because of no implementations).
… we’ve agreed that if you don’t have an implementation, don’t add it to the context.
… I agree. In theory you could use confidence method, but that will need another context (because it isn’t in V2).
… So we shouldn’t put that into the spec.

Orie Steele: confidenceMethod the “predicate” is reserved, and exists.

Orie Steele: ConfidenceMethod the RDF class does not exist, but “VerificationMethod” does… afaik.

Orie Steele: disagree with basically everything Manu is saying… but happy to keep talking about it on issues.

Manu Sporny: Two, yes. We’ve been arguing for a long time. Orie, you said you would object if it isn’t in there. So that was a compromise made.
… That is shifting into core context where it doesn’t look like it belongs.
… There is no use case that’s broad enough for secret keys to be in the base context.

Orie Steele: I will object if core context defines confidenceMethod, but not JsonWebKey and Multikey.

Manu Sporny: if its not there, it can be an issuer-specific context.

3. Issue Triage.

See github issue vc-data-model#1263.

Brent Zundel: sounds like Orie is happy to drop it from the main context if we can get it in other contexts.
… now moving to issue triage.

3.1. are domain and range correct for all properties in data model? (issue vc-data-model#1263)

See github issue vc-data-model#1263.

Brent Zundel: only one issue so far.
… looking for before-cr or post-cr comments.

Manu Sporny: discussed this yesterday. Ted mentioned he would think about it.

Brent Zundel: ok, that’s ok with me. Ted did you want to share anything now?

Ted Thibodeau Jr.: not yet. This is probably post-cr.

Orie Steele: there are reserved terms that also point to reserved RDF classes.
… we currently have confidenceMethod as a reserved RDF class.
… which maybe implies some future inheritance. but what is the relationship between the reserved predicate and the reserved RDF class.
… what’s the thought process around confidenceMethod being reserved in this way, instead of having confidencemethod refer to verification method.
… are these normative.

Manu Sporny: ivan did a lot of this work. we’d need to ask him.

Orie Steele: Does this work reflect working group consensus?

Orie Steele: Is the vocabulary normative?

4. Issue Discussion.

Brent Zundel: https://github.com/w3c/vc-data-model/issues?q=is%3Aopen+is%3Aissue+label%3Abefore-CR+sort%3Aupdated-asc.

Brent Zundel: moving to final topic.
… These are all labeled before CR, some are ready for PR we’ll ask when we might see that. Some are not. We’ll ask what the plan is.

4.1. need resourceIntegrity in vocab and under w3c (issue vc-data-model#1152)

See github issue vc-data-model#1152.

Brent Zundel: Raised by Mike Prorock. Ready for PR.

Michael Prorock: I thought we were going to get some guidance from Ivan, but maybe I’m misremembering.
… it’s ready for PR. I’ll try to get to it.

Sebastian Crane: is this the same a #1261.

Manu Sporny: no.

Brent Zundel: no.

Michael Prorock: no. different.

Manu Sporny: This should be an easy one – fairly straight-forward PR.

Brent Zundel: the resource integrity is literally adding that term to the vocabulary (rather than integrity of the vocabulary).

4.2. Internationalization Review for VCDM 2.0 (issue vc-data-model#1155)

See github issue vc-data-model#1155.

Brent Zundel: any actions to take here?

Manu Sporny: it’s not clear. Addison continues to review. So I think we are getting active i18n reviews.
… we should probably ask outright if we’ve addressed his concerns in his review.

Brent Zundel: we do have on i18n pre-cr issue.

Orie Steele: +1 to an example.

Dmitri Zagidulin: I wanted to ask if there would be any objections or push back to adding a PR with an example of i18n.

Manu Sporny: we have stuff in the internationalization section.

Dmitri Zagidulin: it doesn’t have value-level language selection.

Manu Sporny: yes, we had that and people complained, so we removed it.
… so maybe we could add one that has the bare @language or @value in there.

Orie Steele: maybe file an issue capturing the example you want to see, and cross link for discussion.

Dmitri Zagidulin: I just mean, for example, if the value is a string, then an object with the properties for lang.

Brent Zundel: hold on. remember the queue.
… an issue to track this concern with an example example, would be an appropriate way to advance this.

4.3. Clarification needed on the ease of deducing that a subject is the holder. (issue vc-data-model#959)

See github issue vc-data-model#959.

Brent Zundel: issue 959. says PR exists.
… If we merge that PR we can close this?

Orie Steele: that was the intent.

4.4. NIST defines “credential” differently (issue vc-data-model#1047)

See github issue vc-data-model#1047.

Brent Zundel: NIST defines credential differently.

Orie Steele: I definitely need to get to it.
… it might be that credential has more alignment.
… it’s related to previous topic about the abstract class confidentMethod.
… I do plan to do this at some point.

Brent Zundel: is the some point anticipated before TPAC.

Orie Steele: possibly, but this should probably be post-CR.
… assuming the other PR is merged this gets to post-cr.

Brent Zundel: comments to that effect with link to PR would be helpful.

Justin Richer: the TLDR version is that 800-63 definition of credential is authenticator plus attributes.
… fundamentally this is how credentials are used in VCs.
… but that’s largely based on the definition of authenticator, which is fundamental to the NIST definition of credential.
… so the W3C can align or redefine or reference.
… this term has changed about 6 times since I started working with NIST.

Orie Steele: the group has been discussing how to express “confidenceMethod” in VCs, which would express the public key that would be used for an authenticator.
… we are using similar but not the same.

Manu Sporny: Nope – that’s not the only use case for confidenceMethod – it’s not only bound to authenticators.

Brent Zundel: moving to next issue.

Orie Steele: ConfidenceMethod is a “super set” that includes authenticators?

Brent Zundel: we added context resource integrity. how do we test it?

Orie Steele: or we just need it to not be the same thing in order to justify defining it?

Dave Longley: Orie: ^not that later question, which is presuming bad faith, please don’t do that.

Michael Prorock: I will be adding code for testing the jose-cose side of this.

Manu Sporny: +1 should be straightforward to add.

Justin Richer: “authenticator” per 800-63 is fundamentally about proving access to a secret, it’s an intentionally wide definition that spans many technologies. It might or might not make sense for it to be used exactly the same way here. NIST is not likely to change how it’s used.

Brent Zundel: should we move this to the test suite repo?

Manu Sporny: or we just test in the core data model.

Orie Steele: so its a superset, where we are not defining the behavior beyond authenticators?… I am not going to assume thats being done maliciously, but I will assert its a bad idea to do this way.

Brent Zundel: If I here no issues, I’ll move to vc test suite repo.

Dave Longley: justin_r, yeah, that makes sense – and people here have said they want some concept that also includes other “authentication mechanisms” that are not strictly related to secrets or proof of possession / use of keys.

Justin Richer: @orie I think it’s more a matter of the venn diagram having some overlap that’s fuzzy around the edges - not a super or subset from what I can tell.

Justin Richer: dlongley, right, which in the NIST framework would include things that aren’t authenticators, which is fine.

Dave Longley: +1.

4.5. Document the value of processing as JSON-LD (issue vc-data-model#1227)

See github issue vc-data-model#1227.

Brent Zundel: value of processing JSON-LD.

Manu Sporny: you can mark it ready for PR. we are working on text for it activly.

4.6. Revisit validation vs verification (issue vc-data-model#1232)

See github issue vc-data-model#1232.

Brent Zundel: revisit verification and validation.

Joe Andrieu: I don’t think there’s been any forward movement.
… I do think it’s on me to do a review on validation/verification… could come back and add them as comments. I think that’s where we’re at.

4.7. termsOfUse is insufficiently specified (issue vc-data-model#1010)

See github issue vc-data-model#1010.

Brent Zundel: termsOfUse insufficiently specified.
… can anyone give us an update.

David Chadwick: I think we got to the text in the space should be generic enough to allow anyone to specify their own terms of use with their own URI.
… and for testing we want something more than generic URI.
… we want specific URI for the type, which we can actually test for.
… I think we’re at this state now.
… I think we can now write specific tests with specific URIs and we could have different implementations that understand that type and can process it.

Joe Andrieu: pl-asu: I think David said it well.

David Chadwick: the issue was that we needed something machine processable and not just a reference to a description.
… now we have a way to test out David’s idea.

Manu Sporny: I’m confused about where we are on this topic.

Brent Zundel: +1 to being confused.

Manu Sporny: we made … we had a consensus that the reserve term is going to be removed if we don’t have a spec with two implementations by end of CR.
… the other way to do it is that we have multiple implementations and there is functional interoperability.
… where are we as a group. have we decided on one way or another.

Orie Steele: +1 manu.

Sebastian Crane: I was going to propose something complicated, but in the interest of time, I’ll yield to David.

Manu Sporny: to be clear, I’m fine w/ either way forward… we just need to pick a direction. :) – the first one is more stringent than the second.

David Chadwick: manu didn’t quite catch what I said. There will be two implementations that are interoperable.

Manu Sporny: great, thanks DavidC – that makes things easy.