Meeting minutes
Kristina: 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.
<Zakim> manu, you wanted to note credentialStatus next steps?
manu: CredentialStatus2021 exists in CCG. its implementable, don't know what is right time to move to this group. is group interested in moving now or hold off?
manu: 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: in support of moving it as a work item. some privacy concerns, but makes sense to have official recommendation.
Kristina: 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: I think you should not restrict to one credentialstatus type, i think we should follow a registry model.
<Zakim> manu, you wanted to note that we can have multiple things for each extension point.
kristina: We should be on the same page about positioning, advocating for discussion first.
manu: 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.
<Zakim> decentralgabe, you wanted to ask how we specify existing options for known fields (status, schema, evidence...)
<decentralgabe> https://
Kristina: can you open an issue, this is not a "change existing status property" but rather a "example status list"
decentralgabe: what is difference between vc-extension-registry and this proposed work, why not just use that registry?
Kristina: the registry points to multiple extensibility values, points to spec and allows people to know what their specific value means.
oliver: is there any work needed on defining a more concrete interface similar to did resolution?
<manu> Define CredentialStatusList2021 in a specification in the group: https://
kristina: 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
<Zakim> manu, you wanted to elaborate on difference between "registering a mechanism in the registry" vs. "CredentialStatus2021 as a deliverable".
manu: 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 itll 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: no wg call or special topic next week. we will have both in 2 weeks. The special topic is on '@context' is 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.
manu: 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 ahve any response?
Oliver: 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.
TallTed: 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: will reply on PR, we can delay to next week to merge it in.
kristina: will we incorporate ted's concern?
oliver: will clarify his concerns first.
manu: 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 includign 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: vcjwt, I believe we're waiting on mikejones chages. for VCJWS2020, two open PRs one for FPWD I think specs are same status
Credential Schema
https://github.com/w3c/vc-data-model/issues?q=is%3Aopen+is%3Aissue+label%3Aschema+sort%3Acreated-desc
kristina: : any preference on which issue to start with?
Gabe: 934, but they will be closely related.
https://github.com/w3c/vc-data-model/issues/934
Gabe: : 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 readign from '@context' thread it seems there is no normative way to refer to it.
<Zakim> manu, you wanted to note a way to refer to JSON Schema and make it useful
Gabe: : happy to start working on it, but want to make sure there is consensus
manu: +1 to specifying json shemas 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: 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: happy to take this on as a work item will need some assistance on language but ready to work on first draft.
https://github.com/w3c/vc-data-model/issues/933
<decentralgabe> https://
Gabe: 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.
<Zakim> manu, you wanted to support "a concrete mechanism for credentialSchema" use -- one of many possible options. Concern over what the spec says right now
manu: +1 to use concrete mechanism for credentialSchema use, Gabe I noted theres some langauge that is concerning. This is not only talking about how to apply credentialSchema, there is notes about makign '@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 beign additive, +1 to beign one of many schemas, just do not eat at the core datamodel
kristina: I don't think this is mature enough, should be worked on at CCG while we acknowledge its value.
<manu> +1 to "how they can be used together"
Gabe: 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.
https://github.com/w3c/vc-data-model/issues/839
Kristina: lets tackle #839. We agreed with Gabe to begin working on it, this is for credentialSchema for VPs?
DavidChadwick: will produce a PR, it is ready but haven't had the time just yet.
https://github.com/w3c/vc-data-model/issues/890
Kristina: #890 credential Schema selective disclosure. we discussed if this can be incorporated in the VP. is that a fair statement?
David: 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: 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: 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.
<Zakim> manu, you wanted to wonder if presentationSchema is highly specific to the selective-disclosure mechanism?
logan: 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: +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: 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: 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, havign a second schema talking about how it is disclosed/used is extra complexity.
<manu> 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.
TallTed: 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 dont disclsoe that field
mkhraisha: 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.
<DavidC> +1 mkhraisha
<oliver> +1 mkhraisha
Kristina: 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: 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?
mkhraisha: +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: i think this shouldn't be on the schema level, I find it a strange place to draw a line.
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: IF issuer issues ABCD then schema can say SD has to have ABC or ABD to be valid credential.
Shawn: 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: 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.