Verifiable Credentials Working Group Telco — Minutes

Date: 2022-08-31

Attendees

Present: Orie Steele, Brent Zundel, Chris Abernethy, Kristina Yasuda, David Waite, Michael Jones, Kevin Dean, Dave Longley, Manu Sporny, Ted Thibodeau Jr., Kerri Lemoie, Oliver Terbu, Logan Porter, David Chadwick, Antony Nadalin, Juan Caballero, Shawn Butterfield, Dmitri Zagidulin, Samuel Smith

Regrets: Charles Lehner

Guests: Benjamin Goering

Chair: Brent Zundel, Kristina Yasuda

Scribe(s): Orie Steele, Manu Sporny

1. Agenda Review.

Brent Zundel: we will talk about TPAC, PRs and issues..
… introductions?.

David Chadwick: I’m with crossword now, formally with university of kent..

2. TPAC.

Brent Zundel: https://docs.google.com/spreadsheets/d/1Du-3G4d08OWxW1fNtn_8BLNsAIT4GETvk7F7v_Mu_dA/edit#gid=0.

Brent Zundel: tpac is 2 weeks away…. see the draft agenda above.
… if you are presenting, please be prepared..
… for those who are remote, we will be using zoom, join as you can..
… questions?.

Manu Sporny: do all the presenters know they are presenting?.

Brent Zundel: afaik, everyone knows..
… we anticipate an excellent meeting… we have a few big topics we will be covering..
… please attend if you can..
… if you have not yet indicated that you are attending, please add yourself to the attendees tab… it helps us plan..
… make sure to report any dietary concerns if you are in person.

David Chadwick: do we need to register if we are remote?.

Brent Zundel: yes, you must register as a remote participant..

3. PRs.

Brent Zundel: See Current list of Data model PR-s.

Manu Sporny: See Current list of data integrity PR-s.

Brent Zundel: see the the explicit holder binding, the vocabulary updates, and the editors list on vc data model..
… regarding vc-data-integrity, need comment from mprorock… see also the PRs related to the baseline of the cryptography suites..

Orie Steele: See Current list of JWT PR-s.

Orie Steele: These are new PRs, opened today.
… First one removes typ header requirement.
… Second one begins to attempt production rules to convert VC data model to VC-JWT verifiable credential. Second one documents “instead of” vs. “in addition to” paths..
… My hope was that we could be clear about normative requirements for VC-JWT requirements according to v1, and be more explicit about producing VC-JWT means, once we have that in writing, we could discuss changes to it. But no w/ attempts to redefine it completely..
… It’s meant to document more concretely the “instead of” and “in addition to” paths. The previous PRs changes a normative requirement by relaxing typ requirement. We welcome feedback on PRs directly..

Orie Steele: See Current list of JWS 2020 PR-s.

Orie Steele: There is one PR open for vc-jws-2020, it uses the IANA registries to describe vocabulary terms on what a JWK is, it is pointing to IANA for vocabulary for JsonWebSIgnature20202, this is specific to Data Integrity Proof format, not VC-JWT format..
… There is a Data Integrity proof suite that depends on detached JWS, it is a description of how to use detached JWS to create Data Integrity proofs for protecting VCs. It needs to be defined in same way as other Data Integrity suites define vocabularies. The VC-JWT work is a separate item, that is why these are separate repos..

Antony Nadalin: curious why…. the comment on the vocabulary?.

Orie Steele: Yes, that’s correct. We are now referring to a specific PR, I’ll point to it..

4. Issue Discussion.

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

4.1. Add IANA to context (pr vc-jws-2020#24)

See github pull request vc-jws-2020#24.

Antony Nadalin: We’re not changing the vocabulary of what JWS/JWT use today, correct?.

Orie Steele: No, we are not changing that, I don’t think. There are certain terms that need to be defined to make a Data Integrity Proof valid, I’m intending those terms to be defined by IANA. If folks don’t agree that IANA is the right one, for example citing the RFCs directly, we can have that conversation if folks want to do that..

4.2. add claims metadata (issue vc-data-model#893)

See github issue vc-data-model#893.

Brent Zundel: kristina, can you walk us through this?.

Kristina Yasuda: the question was… where to put the metadata about “claims”….
… how do we know how to use “evidence”… can we keep this issue open until we can align with identity assurance.

Manu Sporny: the confusing word is “what is meant by metadata”..
… in theory you can add any metadata that you want, at any level….
… we should probably address this in a use case specific format… like the assurance example and evidence… in person, IAL… etc… we should be more specific.
… are “evidence” and “revocationStatus” metadata?.
… can’t tell if this applies to other metadata properties not associated with assuancee.

Kristina Yasuda: was thinking mostly about trust frameworks, government and finance use cases… passport was used to verify the claims, etc….
… evidence seem like the correct place, but there is a vocabulary for assurance that the UK refers to… and the question is how to leverage / integrate the UK vocabulary with the W3C evidence vocabulary..

Oliver Terbu: I was involved in some projects related to this… european ssi framework… they have their own context and schemas, and they use evidence..
… they cover, what did the issuer verify prior to credential issuance..
… I think folks would want to define their own evidence type and register it..

Dave Longley: +1 to oliver.

Manu Sporny: Yes, exactly what Oliver just said – +1.

Oliver Terbu: people need to evidence type to understand the evidence and the vocabulary it relies on.

Kristina Yasuda: @manu will update the issue to clarify what is meant by metadata in the issue.

Logan Porter: I think we are talking about 2 different things… the current evidence property is more like where the claims came from..
… like name came from passport or drivers license..
… but we are also talking about assurance, which is about how that is checked, in person, remote, etc….
… we might want to distinguish between these uses of the evidence property..

Antony Nadalin: I think I agree with Logan… there is evidence types and method types..

Manu Sporny: the evidence property is currently any information that the issuer can include to help the verifier decide..
… I see this as 2 entries in the evidence property, one speaking to IAL, the other speaking to trust framework..
… authenticators are another type of evidence.

Oliver Terbu: I wanted to add that folks should define their own evidence types as needed by their trust framework.

Manu Sporny: yep, +1 Oliver.

Dave Longley: +1.

4.3. What is the action associated with issuing/creating a Verifiable Presentation? (issue vc-data-model#887)

See github issue vc-data-model#887.

Brent Zundel: what is the action taken to produce a verifiable presentation.

Manu Sporny: there are options….

Dave Longley: how about: you create a presentation and then you present it :).

Manu Sporny: we could use the word “create”, “issue”, “prepare”, “present”, “assemble”, “prove”.
… I don’t like issuing a presentation, or signing….

Brent Zundel: -1 to issuing a presentation.

Dave Longley: -1 to issuing a presentation.

Manu Sporny: preparing / assembling ….
… maybe.

Juan Caballero: collate.

Orie Steele: I don’t like “prepare”, because that’s the step before protecting..

Juan Caballero: “consenting a verifiable presentation”.

Orie Steele: I think what we’re trying to define here is the verb to define the act of “protecting”, not “getting ready to protect”..
… For some presentation formats, I like the word “prove”, if you’re talking about something like a Zero Knowledge Proof… so kinda like proving. also don’t like presenting… agree with -1 on issuing, also -1 to signing.
… That’s all I can say at present. :).

Oliver Terbu: i agree, but maybe also generating….

Manu Sporny: yeah, I think I’m -0.5 to “proving”.

Oliver Terbu: I disagree with proving… because a presentation does not require a proof..
… proof is not implied when presenting..

Manu Sporny: I do like “generate”.

Orie Steele: +1 oliver.

Dave Longley: -1 to proving … it’s a great word for when it happens, but it doesn’t always happen :).

Ted: compose and then optionally sign, deliver, present, submit.

Juan Caballero: I like generate because the product is unique.

Manu Sporny: generate?.

Dave Longley: create, generate, and compose seem ok to me.

Orie Steele: I would want to be able to tell if the thing produced by the verb is secured or not, I don’t think we should use the same word for both of them..
… I think the definition of a verifiable presentation is broken, it’s not clear if it’s secured or not, I could live with “prepare” or “assemble” for unsecured version, but I don’t want to use the same term for the unsecured vs. secured version..

Brent Zundel: thats 5 minutes of bikeshedding.

4.4. credentialSchema and Selective Disclosure (issue vc-data-model#890)

See github issue vc-data-model#890.

Brent Zundel: david can you walk us through this?.

David Chadwick: thanks for reminding me… there are various ways in which selective disclosure can be done….
… there are new ways being invented with for example, sd-jwt..
… dynamic credentials or atomic credentials..
… that the verifier gets, might not be a complete verifiable credential.
… you might not get the full details of the credential… and the schema may have mandatory or optional attributes.
… this creates a conflict for the RP, they can’t match to the schema… if the required properties are not disclosed..
… one solution would be to say all attributes are optional..
… I would like for us to clarify this issue with schemas and required attributes vs selective disclosure.

Ted Thibodeau Jr.: Claims (attributes, etc.) that are required by the verifier must be in the presentation. Selective disclosure that leaves out what the verifier requires will be refused or denied or whatever verb..

Logan Porter: you want to validate as much as you can… I don’t think there should be any requirement to check the schema..
… sounds like an imp guide thing..

David Chadwick: example, I want to see bank account details from a university degree credential… assuming I got an answer… what should the RP do?.

Logan Porter: seems the credential would be contradicting the schema.
… what is requested, vs what is observed….

Manu Sporny: several layers… first one is when the issuer issues the credential, are they stating mandatory and optional….
… with bbs, that can happen at 2 layers..
… the issuer can demand required revelations either at the credential schema layer… or in the lower cryptography layer..
… it is possible that this constraint might be enforced by both.
… I think we need to look at a concrete example to speak more directly on this..
… the issuer must understand requirements… and then they get to decide how they want to signal this to RPs.
… we need an example of a concrete problem..

Ted Thibodeau Jr.: I think that those mandatory fields are mandatory for issuance, not presentations..
… consider the use of a passport for proof of age.
… the holder needs to prove age over minimum, not visa stamps or country of origin..
… they only need your picture and date of birth.
… the verifier / rp may have requirements… and they may reject a presentation that does not include a mandatory field, such as picture.

Manu Sporny: Verifiers can also chose NOT to use the credentialSchema..

Samuel Smith: we solve this in ACDC with composable schema… the issuer can create a schema in such a way that the holder can present valid combinations… using anyOf and oneOf.
… this allows the issuer to lock down the schema at presentation level..
… this avoids some of the complexity, where the presentation can be anything you want..
… we use composable schemas to solve this.

David Chadwick: what I understand is that maybe we need a separate field for presentationSchema… instead of credentialSchema..
… maybe the presentation schema, is more useful than the “issuance schema”….

Samuel Smith: https://trustoverip.github.io/tswg-acdc-specification/draft-ssmith-acdc.html.

Samuel Smith: https://github.com/trustoverip/tswg-acdc-specification.

Manu Sporny: I am concerned that we know of a few selective disclosure schemes, that define that schema at the cryptographic layer… and thats were it belongs, because you want to enforce.

Kerri Lemoie: Does the verifier specify what they want to see in the presentation?.

Manu Sporny: it looks like folks are putting these in the crypto layer, and that we don’t need presentationSchema then..

David Chadwick: if we have advanced crypto, maybe that works, but it we are using vanilla crypto, it might be more valuable.
… today, we say that it can be the description of the content or it could have to do with the ZKP..
… we seem to need a way to distinguish if the schema is for the content, or the crypto used..

Juan Caballero: +1.

Brent Zundel: this seems like the verifier presentation definition… which is the schema the verifier is requring..

David Chadwick: this would be set by the issuer, not the verifier.
… this would allow the issuer to require the presentation of points, and a verifer who know the holder was attempting to hide info from the verifier..

Juan Caballero: or “constrain” the presentation.

Logan Porter: I think there is a danger of having the issuer control the presentation.

Brent Zundel: +1 to the danger in allowing the Issuer to constrain the presentation.

Logan Porter: I think its dangerous to have the issuer mandate presented fields..
… the verifier can always ignore content they are not interested in.

Ted Thibodeau Jr.: Holder: “I want in. What do you need to know about me in order to let me in?” Verifier: “Present proof of age.” or “Present proof of membership.” or “Present proof of security clearance.” Holder: composes Presentation with relevant attributes from relevant VCs; signs the composed Presentation; Submits Presentation..

Juan Caballero: devil’s advocate: verifiers opt in to listening to/carrying what the issuer wants, i suppose?.

See github issue vc-data-model#839.

Oliver Terbu: question, is this issue related?.
… can we close or label duplicates?.

David Chadwick: I don’t think they are exactly the same… The verifier is in control of verification… and then applying business rules.

Samuel Smith: @Logan This is why we use composable Schema in ACDC. The Issuer can constrain the schema used in presentation but still allowing appropriate levels of flexibility to the presenter to pick from the allowed compositions what it wants to present. Typically its the degree of disclosure that is relevant so its clear what to compose..

Samuel Smith: @DavidChadwick Composable schema precisely solve the problem you describe.

David Chadwick: the verifier can ignore the verification if it wants to..
… my proposal is for the verifier to see the rules….
… if the verifier cannot see the issuer’s rules, it can’t know how to decide to ignore things.

Ted Thibodeau Jr.: I don’t understand.
… the holder says: I want in, what do you need?… the verifier says: present proof of age / attributes or full VCs, signs them, or presents it….
… then the verifier decides if its enough or not..
… they either let you if or they don’t.
… I don’t see that this needs more schema.

Dave Longley: this sounds like a use case where the verifier also “wants to know” if the presenter is complying with some terms of use that the issuer demands.

Dave Longley: (regardless of what those terms of use are).

Juan Caballero: ^^.

Juan Caballero: well-put, dave!.

David Chadwick: we need to separate verification from validation. This conversation is about the former.