Verifiable Credentials Working Group Telco — Minutes

Date: 2023-08-02

Attendees

Present: Brent Zundel, Michael Prorock, Andres Uribe, Greg Bernstein, Kristina Yasuda, Gabe Cohen, Manu Sporny, Sebastian Crane, David Chadwick, Dmitri Zagidulin, Orie Steele, Kevin Griffin, Chris Abernethy

Regrets:

Guests:

Chair: Kristina Yasuda

Scribe(s): Manu Sporny, Sebastian Crane

Kristina Yasuda: Welcome everyone, agenda is PRs and issues, we did good job on PRs yesterday, so we are skipping PRs today.
… I did merge ecosystem PR, 13-16 approvals, which was good, merged, other PRs could get merged as a result of discussion yesterday.
… Any PRs we should discuss?

1. PRs.

Manu Sporny: Not really, just look at PRs out there… ecdsa-sd is going to be merged this week… MikeP has other PRs he might want to cover.

Michael Prorock: PR69 – did get some text pushed today that adjusted top-level typing to BitStringStatusList, please put eyes on that…

Michael Prorock: https://github.com/w3c/vc-jose-cose/pull/88/files#diff-0eb547304658805aad788d320f10bf1f292797b5e6d745a3bf617584da017051L403-L426.

Michael Prorock: The other one is PR88, in VC-JOSE-COSE, blocker at this point – fixing one last thing – that will have approval from Orie/myself as Editors – that is blocking on additional work.
… This removes stuff in v1.1, not addressed by this specification.

Kristina Yasuda: Do we need special topic call on status list PR?

Michael Prorock: only mikej is blocking that one.
… We’d like chairs to identify consensus on this to be unblocked on PR 88…
… VC-COSE-JOSE is blocked.
… Status List is just going through normal review/ bikeshedding.

Kristina Yasuda: do we need special topic call for either one of these?

Michael Prorock: No, I don’t think so.

Sebastian Crane: Why are CBOR / JSON parts part of same specification instead of being a part of different specifications?

Orie Steele: The core data model provides content types for conforming documents, for JOSE/COSE, there is a way to secure content types as per in core data model… why would you want to use COSE instead of JOSE? You might want to use COSE QR Codes, other aspects of CBOR system, because core data model is JSON-LD, you have to embed content type that you’re securing.
… Because you secure stuff in the same way in JOSE / COSE, and you do key discovery the same way – that’s why we put them together, to make sure same approach is used for both JOSE and COSE.

2. issues.

Kristina Yasuda: Brent, should we do any label for issues today?

Brent Zundel: Let’s try in least-recently-updated order.

Kristina Yasuda: https://github.com/w3c/vc-data-model/issues?q=is%3Aopen+is%3Aissue+-label%3Abefore-CR+-label%3A%22pending+close%22+sort%3Aupdated-asc+.

Kristina Yasuda: There’s the link, we’re going through “before CR” issues.

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

2.1. 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.

Orie Steele: several PRs are open regarding “holder”.

Orie Steele: people asked in its related to https://github.com/w3c/vc-data-model/pull/1199 … it is.

Kristina Yasuda: where are we on this issue?
… Does 1199 directly address this issue?

Orie Steele: Brent clarified some of this in another PR, PR1199 also clarifies parts of this, I don’t know if it’s sufficient to close the issue… let’s try to close this issue if PR 1199 does address this issue.

Kristina Yasuda: Ok, makes sense, marked as pr exists.
… direction is to close issue when PR 1199 is merged.

2.2. Provide guidance for when hash values do not match specification text (issue vc-data-model#1177)

See github issue vc-data-model#1177.

Kristina Yasuda: manu, status?

Manu Sporny: I will do this PR, straighforward PR.

2.3. Clarify credentialStatus (issue vc-data-model#991)

See github issue vc-data-model#991.

Brent Zundel: if we want for ready for PR, ask assigned person what their timeline could be – that might be valuable question to ask.

Kristina Yasuda: for clarify credentialStatus — DavidC go ahead.

Dmitri Zagidulin: does that object /need/ a name?

David Chadwick: This is partly tied into the difference between credential and verifiable credential… manu tried to clarify that text… the definition of verifiable credential is that it’s secured… what is the object called that is unsecured? That hasn’t been answered satisfactorily… the text for this one, underlying object or credential could be revoked, vc could be revoked…. we haven’t fully nailed down what we call the unsecured verifiable credential.
… I don’t believe it can be called credential… VC and C seemed to be same object before.

Orie Steele: I agree with some of what David Chadwick said, we’re still struggling Credential vs. VC language – manu has PR w/ language speaking to it… the way I’m making sense of this is specification registers two media types, subtypes of JSON, and they might be secured or they might not be and up to verifier to check… media types are hints, not assurance that something has security.

Michael Prorock: +1 orie.

Orie Steele: vc+ld+json is JSON media type of something that might not be secured… just be careful about how interpret this.

Sebastian Crane: Three different scenarios, VC (valid in terms of structure and secure in it has a cryptographic proof), but receiver has not yet done either verification of structure nor have they done cryptography to ensure signature is correct. That is a “pending VC”.
… Another is that you have a VC that was once valid, but has been revoked, and one could call that “revoked VC”.
… Final scenario is where everything is fine, “verified VC” – if we can find a new name for that, confusion might remain.

Orie Steele: proof is optional… so that seems to conflict with the RDF type definition.

David Chadwick: +1 to manu that a VC is always secured.

Manu Sporny: There is a PR out to fix the issue. It says that a Verifiable Credential credential is secured. PR means that it has to be secured for you to call it a VC. That does not preclude it from having errors.

Orie Steele: its a mistake to use english language that contradicts the RDF data model.

Kristina Yasuda: to reconcile with orie’s interpretation of vc+ld+json, vcdm does not say where to use that media type so it can be cty in vc-jose-cose, so should be no conflict..?

Manu Sporny: One school of thought is that it doesn’t matter, another school of thought is that invalid or erroneous data can not be called a Verifiable Credential.

David Chadwick: +1 to manu that vc and c are not the same thing.

Manu Sporny: The current PR tries to say that it conforms to our document, and it is secure. A ‘credential document’ is the term for things that aren’t secure or aren’t conforment.

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

Joe Andrieu: I preferred the other language, felt like there were two dimensions, other dimensionality – difference between VC and credential in real world… having a bachelors degree, have that whether or not I have a VC… but that’s not what this is about.
… When we sign a credential, not sure how to coherently describe position, will try again later.

Kristina Yasuda: PR1211 might address this, anything else that needs to be done.

David Chadwick: Yes, this is good, glad you changed position manu, that aligns w/ what I was concerned w/ all along… you and I agree now.
… The PR that we are discussing now, what is underlying document/credential/certificate – we start w/ paper document, that is turned into some JSON (credential), which is then turned into (verifiable credential) w/ proof on it.
… This PR was talking about first and 3rd object… how do we signal that… agreeing that we are not going to say anything about underlying paper document.
… That is what this PR was about… your degree is removed, but VC is still around saying you had a degree. That’s what we’re trying to address in terms of revocation.

Kristina Yasuda: can you add language to clarify this, Manu?

Manu Sporny: I will try my best.

Sebastian Crane: Respoding to DavidC – if there is consensus one way or another, we should have resolution that we are are/not addressing first layer in VCs.
… Looking for input on that.

Michael Prorock: no.

Sebastian Crane: before something becomes JSON – paper credential – are we talking about that? if physical degree is revoked, is VC-native way that addresses that situation?

David Chadwick: Yes, that’s what this issue was about.

Sebastian Crane: Yes, would like to see resolution.

Joe Andrieu: With a slight refactoring, we already do that – we don’t have mechanism to separate revocation of real world paper credential from digital version… we do have a mechanism to state that VC is revoked.

Brent Zundel: The revocation check of the real world credential sounds entirely out of scope for our group.

Joe Andrieu: You said “Credential Object”, made sense to me DavidC, JSON that’s not signed yet.

Kristina Yasuda: there are two things: validity of the signature and validity of the data about the subject. we have status list for the latter and individual mechanism per securing mechanism.

Kristina Yasuda: I am pretty confused what we need beyond that.

Sebastian Crane: For status list, which allows revocation for VC… difference between that and real world credential… if you revoke VC, because you gave no reason for that, cryptography for revoking, don’t know if that credential was ever valid… maintaining list of changes, knowledge graph, can you say “I once believed that the person had a degree” – important aspect.

Joe Andrieu: status list isn’t for cryptographic revocation.

Manu Sporny: I really like David Chadwick’s model of three parts. I see that Orie’s concern that the language and the RDF definitions don’t match, for which I have some PRs to resolve the difference.
… The thing we care most about in this specification is the third and final part, which has to be secured.
… We can add a new RDF term to align with this new three-part model.

Kristina Yasuda: I think manu has enough data to update the PR.

Orie Steele: We did start w/ abstract credential class – that VC inherited from – all of this happened before, it’ll all happen again.

Kristina Yasuda: ETA for hashes PR, manu?

Manu Sporny: Within two weeks.

2.4. test approach for resource integrity (issue vc-data-model#1153)

See github issue vc-data-model#1153.

Michael Prorock: How do we test this? We could check if hash matches, build into VCDM tests – fairly straight forward.

Kristina Yasuda: Are you volunteering to do the PR?

Michael Prorock: I can provide sample code for this, could go into PR, or whatever.

Michael Prorock: we did.

Orie Steele: I might be misremembering, thought we added property for protecting context integrity, if securing specification wanted to demonstrate conformance, it would have to write tests around it.
… Manu sent email about data integrity suites – would expect to see some test case there for this, would also expect to see stuff for VC-COSE-JOSE test suite and would love to see that adopted.

Michael Prorock: +1 orie - and I am happy to add to vc-jose tests.

Orie Steele: We dont’ have adopted work items for test suites in group.

Kristina Yasuda: Moving issue to VC-JOSE-COSE repo?

Orie Steele: This particular core data model issue is fine to stay on core data model – it will need to be tested concretely in test suites for securing core data model, those tests suites will use different approaches, I’d leave it where it is.
… I’d file issues in test suites repos, if we had those.

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

See github issue vc-data-model#1047.

Orie Steele: +1 to talking about test suites.

Kristina Yasuda: Manu sent out of an email about test suite adoption, we’ll discuss that in an upcoming call.

Orie Steele: I think the core data model has terminology, and sometimes it aligns strongly w/ existing definition, and sometimes it doesn’t… Data Integrity specs had NIST relationships with them, we should be cautious to refer to NIST w/o referring to their terminology… NIST has conflicting definitions for these things… looking at you “attestation” – highly problematic.

Michael Prorock: also https://www.rfc-editor.org/rfc/rfc4949.html.

Orie Steele: To resolve this, we either go through our terms and add references to other sources so you can navigate them, or to create informative part wrt. disambiguation and do that outside of term list so our term list can stay clean, small, instead of us trying to rationalize how others have defined their terminology.

kgriffin-again: kgriffin-again has joined #vcwg.

Kristina Yasuda: other ways to do this?

Michael Prorock: RFC4949 defines some of this stuff – they cite a bunch of other definitions because there are multiple definitions… would like to point to work/reviewed published – or creating definition of term that is confusing to those trrying to integrate w/ our stuff…
… seen a lot of cases of this, NIST draft going out – spent hours w/ NIST as did others trying to cross-reference others – really problematic.

Kristina Yasuda: We have Charles assigned… should we add Orie?

Orie Steele: you can assign me.

Kristina Yasuda: done :).

Sebastian Crane: I don’t want to negate effort of those compiling glossaries in the past, don’t think average is going to look at our use of “credential” and say “my implementation isn’t accurate”… it might be useful from a marketing perspective, but probably won’t affect implementability of VCs.

Brent Zundel: +1.

Manu Sporny: +1 to seabass.

2.6. Conformance requirements for normative context (issue vc-data-model#1185)

See github issue vc-data-model#1185.

Kristina Yasuda: what should conformance processor expect regarding normative requirements for context.

Manu Sporny: What would Orie like the specification to say?
… We have this JSON-processing part of the specification, whereas this is specifically about JSON-LD features of JSON.

Michael Prorock: +1 orie.

Orie Steele: We should describe that, when processing VCs as JSON-LD rather than plain JSON, you must use the context in a particular way.
… Yes, that’s basically it. We have this section now that says you can process core data model as JSON – with context being normative, we should also describe “if you process as JSON-LD, this is why we made context normative, so you get other values expected” – any application that uses @context would prove value of making @context normative.
… Issuers/verifiers/holders why do they need same underlying value? It’s what enables these other capabilities… if you go beyond traditional JSON, what should you get, we should make that clear to readers.

Orie Steele: don’t make json processing PR bigger.

Orie Steele: please :).

Michael Prorock: https://github.com/w3c/vc-data-model/pull/1202#discussion_r1273762313.

Michael Prorock: Comment made on JSON Processing PR – maybe we should add corresponding section on JSON-LD… I think we should, I think that’s what manu is saying, that’s what Orie is saying… we’re beating the “JSON Processing PR” to death… let’s get a corresponding PR for JSON-LD Processing as well.

Kristina Yasuda: Yes, separate PRs are fine, but it would be great if – would like to see second PR in parallel to JSON Processing PR – my concern was … what’s value of @context if pure JSON processing is possible, if that goes in, that addresses part of my concern… understand they don’t have to go in same PR.

Orie Steele: I agree with point on confusion, it is confusing to just have JSON Processing, but also have acknowledgement of @context values are normative… I understand why it is that way, I think that language is correct, but I think other people will be confused until they see these things side-by-side, and that’s caused JSON Processing to take longer. I would prefer JSON Processing to go in, keeping both of them open, will make review really hard – I.

Manu Sporny: would recommend merging JSON Processing PR – then filing bunch of issues to come up /align from review process – easier to reduce parallel places we’re having conversations.

Manu Sporny: +1 to what Orie and mikeP just said.

Brent Zundel: +1 to Orie.

Kristina Yasuda: Ok, marking this as ready for PR.
… agree that both have to happen.
… next week is going to be discussion on test suite special topic call… main call will be issue processing.
… Thanks all, see you next week.