Verifiable Credentials Working Group Telco — Minutes

Date: 2022-11-09

Attendees

Present: Gabe Cohen, Manu Sporny, Oliver Terbu, Mahmoud Alkhraishi, Kristina Yasuda, David Chadwick, Steve McCown, Logan Porter, Ted Thibodeau Jr., Charles Lehner, Shawn Butterfield, Phillip Long

Regrets:

Guests:

Chair:

Scribe(s): Mahmoud Alkhraishi, Manu Sporny

Kristina Yasuda: Editors’ call, if you’re an editor encouraged to ready-for-pr on issues. Three big topics are: credentialSchema, EvidenceClaim, Credential Status.
… Starting with credential Schema, added a new tag schema, with a url that is shared. if we have time will go to issues. Evidence probably next week, could already be ready-for-pr..
… CredentialStatus doesn’t seem to have an issue but it is mentioned in different places. There is also a fourth bucket for holder binding..

Manu Sporny: CredentialStatus2021 exists in CCG. It’s implementable, don’t know what is right time to move to this group. is group interested in moving now or hold off?.
… i think it is ready, it is useful and I believe there is an appetite, not sure about charter support. In theory it is included as no normative reference to CredentialStatus.

Gabe Cohen: in support of moving it as a work item. some privacy concerns, but makes sense to have official recommendation..

Kristina Yasuda: before we go there, chairs are weary of adding new docs. Before we make that decision, can we have a general conversation about credentialStatus and the vc-data-model.
… we should do it based on requirements and see if we should only allow one credentialStatus.

Oliver Terbu: I think you should not restrict to one CredentialStatus type, i think we should follow a registry model..

Kristina Yasuda: We should be on the same page about positioning, advocating for discussion first..

Manu Sporny: we have extensibility model in spec, anyone can define any credential status type. What we can do is publish a new spec of a normative type, we would no way imply it is only way, no “special standing”..
… it should not get any special treatment outside of it has been vetted by group. Bringing it in and referring as an example and put it in as one of many possible things. We can have multiple types. Lets just start with one..
… DB has a test suite, and implementation..

Gabe Cohen: https://w3c-ccg.github.io/vc-extension-registry/.

Kristina Yasuda: can you open an issue, this is not a “change existing status property” but rather a “example status list”.

Gabe Cohen: what is difference between vc-extension-registry and this proposed work, why not just use that registry?.

Kristina Yasuda: the registry points to multiple extensibility values, points to spec and allows people to know what their specific value means..

Oliver Terbu: is there any work needed on defining a more concrete interface similar to did resolution?.

Manu Sporny: Define CredentialStatusList2021 in a specification in the group: https://github.com/w3c/vc-data-model/issues/974 <— I’ll fill in language in a bit..

Kristina Yasuda: this is why I want an issue, to validate whether we need a credential status property change or if just incorporating an example is good enough.

Manu Sporny: two options: Light touch, add something to registry and point to statuslist2021 as being maintained by ccg. option 2: same thing, but take the spec into our group to maintain and modify. Benefit of option 2 is we control it and it’ll get more scrutiny than in CCG, and we can choose to take to standards track..
… still need to discuss how far we would take it..
… I don’t think we should modify credentialStatus property in data model, we’re just defining one of many extensions..
… raised an issue, will fill in details after the call..

Kristina Yasuda: no wg call or special topic next week. we will have both in 2 weeks. The special topic is on @context being optional..
… we currently do not see consensus either way, we believe conversation is still useful so not closing issue. Encouraging wg to come with concrete solutions/proposals to move us forward..
… don’t be too married to @context, think one layer more abstract, how do we do interop, do we want to express it in jsonld..
… focus on bigger picture..

1. Document status.

Manu Sporny: for vcdm, there are two PRs. Mahmoud withdrew his PR last week to unblock Ivan. We have two new PRs, one is adding non-transferable property to credential vocab. This needs more discussion PR #969..
… #970 ted/Ivan do you have any concerns? Oliver do you have any response?.

Oliver Terbu: would be good to get feedback from ted. I believe the PR does what the title says. it does it by adding MUST. Ted raised a concern would love feedback from him..

Ted Thibodeau Jr.: as i said, I don’t see an implication that it cannot be a string. I don’t understand shift from we want this to be URI, to anything but string which is implied here. I don’t understand how this written change does it..

Oliver Terbu: will reply on PR, we can delay to next week to merge it in..

Kristina Yasuda: will we incorporate ted’s concern?.

Oliver Terbu: will clarify his concerns first..

Manu Sporny: vc-data-integrity has no new PRs waiting on FPWD which will be published tomorrow..
… once vc-data-integrity is published it will pave way for a number of other suites including JWS eddsa cryptosuite.
… once the changes to eddsa is ready, we should pull it into group, at which point it should be ready for FPWD. it also adds framework for other suites to follow some adjustments will need to be made..
… probably ready to be pulled by end of November.

Kristina Yasuda: vcjwt, I believe we’re waiting on mike jones’ changes. For VCJWS2020, two open PRs one for FPWD I think specs are same status.

2. Issues.

Kristina Yasuda: See https://github.com/w3c/vc-data-model/issues?q=is%3Aopen+is%3Aissue+label%3Aschema+sort%3Acreated-desc.

Kristina Yasuda: any preference on which issue to start with?.

Gabe Cohen: 934, but they will be closely related..

2.1. Define JSON Schemas for all objects in the VCDM (issue vc-data-model#934)

See github issue vc-data-model#934.

Gabe Cohen: 934 says it must define it for all terms. Seems there is back and forth discussion on interested and on how to do this. Seems like there is general consensus, but reading from @context thread it seems there is no normative way to refer to it..
… happy to start working on it, but want to make sure there is consensus.

Manu Sporny: +1 to specifying json schemas for core datamodel, unfortunately there is no standard we can normatively point to but it is being worked out. But this doesn’t stop us from defining useful stuff for developers..
… We can say here is OpenAPI 3.0 or 3.1 and we can point to it and make it non-normative and devs have options to use it, making it helpful for them. We just cannot normatively say you must use OAS 3.1 to work with the property. Also need to be careful that we don’t close door to other schema formats..
… this issue is about JSON schema for core data model, which will always be limited, which doesn’t cover extension points. In general +1..

Kristina Yasuda: we’ve had this at TPAC and in other times, We can’t normatively mandate, but direction wise we’re good to start assuming that limitation..

Gabe Cohen: happy to take this on as a work item will need some assistance on language but ready to work on first draft..

2.2. Define a standard way to use Credential Schemas for Credential Subjects (issue vc-data-model#933)

See github issue vc-data-model#933.

Gabe Cohen: https://w3c-ccg.github.io/vc-json-schemas/.

Gabe Cohen: 933 makes use of credential schema property, we should have at least one official implementation of how to reference the JsonSchemaValidator2018 property. Need some help mostly been myself working on it. Also need to know if we should bring it into wg..
… how does the credentialSchema property apply to the rest of the credential, initially wanted it to apply to credentialSubject, but see value in applying to rest of credential. curios on thoughts and people willing to work on it..

Manu Sporny: +1 to use concrete mechanism for credentialSchema use, Gabe I noted theres some language that is concerning. This is not only talking about how to apply credentialSchema, there is notes about making @context optional as you can imagine there is pushback there, but there is a narrower scope that can be supported..
… if the issuer specifies something in the field, does this influence the credential in any way? It helps with specifying trusted issuer/verifier lists, with a schema that these credentials should conform to, so the issuer is not on the hook for specifying it. +1 for specifying it, +1 to being additive, +1 to being one of many schemas, just do not eat at the core datamodel.

Kristina Yasuda: I don’t think this is mature enough, should be worked on at CCG while we acknowledge its value..

Manu Sporny: +1 to “how they can be used together”.

Gabe Cohen: I agree its not quite ready, the intention is not to be at odds with JSON-LD, would love input into how to be used together..

2.3. PresentationSchema for VPs (issue vc-data-model#839)

See github issue vc-data-model#839.

Kristina Yasuda: lets tackle #839. We agreed with Gabe to begin working on it, this is for credentialSchema for VPs?.

David Chadwick: will produce a PR, it is ready but haven’t had the time just yet..

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

See github issue vc-data-model#890.

Kristina Yasuda: #890 credential Schema selective disclosure. We discussed if this can be incorporated in the VP. Is that a fair statement?.

David Chadwick: my thoughts were if the credential schema property are in the credential that is in the VC then it will say what the mandatory/optional properties are. Depending on the disclosure model, for example in a merging multiple atomic credential or like JWTSD or the credential only contains properties verifier wants, my feeling is if the schema is copied into each of these, the verifier would not be able to match the schema, as the schema say[CUT].
… credential doesn’t have them as they were not requested to be disclosed. All the verifier can do with a credential schema can say these are attributes that MAY be present, but if a property is not defined then it should be present. i.e. Credential Schema can be used to show what MUST NOT be present rather than what MUST be present.

Kristina Yasuda: we should tackle selective disclosure first, my suggestion is adding sentence to spec saying “depending on the selective disclosure mechanism used, a schema may or may not be valid”.

Gabe Cohen: there is also utility in knowing what a set of credentials may or may not contain, including authorship information, like state or DMV etc. will make sure that there is language in schema to avoid issues you described..

Logan Porter: I think putting it in the wrong layer to talk about selective disclosure here, in the case of selective disclosure, what isn’t issued shouldn’t matter..

Manu Sporny: +1 i think this is at the wrong layer, we have multiple different schemes that are being disclosed, typically they have “must” “can” disclose terms, which is usually at the cryptographic level..
… lots of this does fall into the crypto layer. -1 until we get more feedback on how the Selective Disclosure mechanisms work..

David: The Credential Schema gives the full set of all the properties that should be present, so all the verifier can do is, regardless of the disclosure mechanism. tell if there are additional properties that are not in the schema..
… this should be in verification process, if properties are there, that are in the implied must not be present, the credential is faulty..

Kristina Yasuda: we have Gabe defining schema into Data Model, and you are doing it for the presentation, what actionable item are you requesting?.

David: Between us we have enough to move forward..

Logan Porter: Disagree with complexity credential schema brings, this feels like a business logic decision, if you think it is well formed is a function of trusting the issuer, having a second schema talking about how it is disclosed/used is extra complexity..

Manu Sporny: Agree with Logan – this feels like a business logic decision, not something that’s asserted by the issuer or the holder while presenting. Don’t understand the need for the complexity..

Ted Thibodeau Jr.: I’m finding it difficult to frame an argument against it because it makes no sense to me. Suggestion that I’ll take a VC issued to me, and selectively disclose attributes, and schema attributes to a verifier, if I don’t want to I don’t disclose that field.

Mahmoud Alkhraishi: What David might be saying - you can’t add a field when you’re doing a selective disclosure – original credential had AB and C, if verifier receives A B and D - that was not in original schema..

David Chadwick: +1 mkhraisha.

Oliver Terbu: +1 mkhraisha.

Kristina Yasuda: anyone opposed to david giving concrete proposals while noting there may be confusion and if concerns are not incorporated PR will not be merged?.

Manu Sporny: I’m with ted, the logic doesn’t line up, if you have a credential that has AB and C and you can selectively disclose AB and C combination how can you disclose D?.

Mahmoud Alkhraishi: +1 I have similar issue.

David: Lets say we have a schema that has A B and C, and issuer issues A B C and D, then if verified the signature will pass, but the schema itself will fail the verification logic:.

Logan Porter: i think this shouldn’t be on the schema level, I find it a strange place to draw a line..

Manu Sporny: Agree with Logan, again :).

David: this is only to do with VC credential schema, we have to address what is the point of the property. is it to check if it is well-formed or not, it should be a conformance property not an advisory property..

Oliver Terbu: IF issuer issues ABCD then schema can say SD has to have ABC or ABD to be valid credential..

Shawn Butterfield: trying to think through this from real world point of view, what you talked about is about composition constraints, if you just have a schema with no required properties, once processed with a json schema processor it will ignore the things that are there that are not in your schema. If we have regex patterns or composition operators, then json schema validator will spit useful info about properties that shouldn’t be there, there is mo[CUT] making it valuable..

Kristina Yasuda: nothing in the data model mandates usage of the schema. When you suggest schema make sure your feedback is incorporated, please make concrete suggestion on advanced schema part..