PresentationSchema for VPs

[David-Chadwick]

The current specification does not address the schema of verifiable presentations, but each VP will have a schema, and different organisations, or protocol specifications, may require different parameters to be inserted into VPs e.g. nonces. I therefore think it would be a good idea to define the presentationSchema property in the v2 DM, with a similar definition to credentialSchema, in order to allow holders to describe the structure and format of the VP.

[OR13]

I propose we define a schema for VPs in JSON Schema, and that v2 perfectly reflect that schema in normative language.

[dmitrizagidulin]

+1 to a json schema. but what repo should it live in?

[OR13]

IMO the schema should be in the same repo with the normative statements that it is built from.

[David-Chadwick]

There are two sets of schema that are needed for operational systems.

1. The presentationSchema definition for the VP, which should be defined in the v2 data model (in the same way that the credentialSchema definition is published in the v1 data model)
2. Instances of presentationSchemas for different use cases that wallets will conform to. These will be published in the same places that eco-systems currently use to publish their credentialSchemas.

[OR13]

Example: https://github.com/w3c-ccg/traceability-interop/blob/main/docs/openapi/schemas/SerializedVerifiablePresentation.yml

^ This covers the shape of both JWT and Data Integrity Proof VCs...

I am in favor of defining schemas... I like type safe languages.

I'm more interested in schemas for credential and presentation as opposed to their "secured formats".

folks are welcome to copy from any of these schema files, if they are helpful.

[awoie]

I believe @David-Chadwick meant that we could define a presentationSchema property similar to credentialSchema. Currently, credentialSchema is only allowed in the VC. Implementers use this property to refer to externally hosted schemas to describe the static syntactic schema for specific types of VCs using, e.g., JsonSchemaValidator2018. In comparison to JSON-LD and @context, other schemas such as JSON Schemas are better suited for making sure static/syntactic interoperability is guaranteed.

The following is an example, how JsonSchemaValidator2018 is used (spec here). It describes the JSON Schema for a specific EmailCredential type:

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  "id": "http://example.edu/credentials/1872",
  "type": ["VerifiableCredential", "EmailCredential"],
  "issuer": "https://example.com/issuers/565049",
  "issuanceDate": "2021-01-01T00:00:00Z",
  "credentialSchema": {
    "id": "did:work:MDP8AsFhHzhwUvGNuYkX7T;id=06e126d1-fa44-4882-a243-1e326fbe21db;version=1.0",
    "type": "JsonSchemaValidator2018"
  },
  "credentialSubject": {
    "id": "did:example:MDP8AsFhHzhwUvGNuYkX7T",
    "emailAddress": "[email protected]"
    }
  },
  "proof": { ... }
}

I saw similar usage of credentialSchema in other communities, e.g., EBSI/ESSIF.

So, I believe, @David-Chadwick wants to achieve the same thing for new types of Verifiable Presentations such as the following:

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  "id": "urn:uuid:3978344f-8596-4c3a-a978-8fcaba3903c5",
  "type": ["VerifiablePresentation", "CredentialManagerPresentation"],
  "newProperty": 12345,
  "anotherProperty": "asdf",
  "verifiableCredential": [{  }],
  "presentationSchema": {
    "id": "did:work:MDP8AsFhHzhwUvGNuYkX7T;id=06e126d1-fa44-4882-a243-1e326fbe21db;version=1.0",
    "type": "JsonSchemaValidator2018"
  },
  "proof": [{  }]
}

In the example above CredentialManagerPresentation is a new type of Verifiable Presentation that could add additional properties not defined in the VC core data model. The presentationSchema could describe that specific schema from a static and syntactical perspective.

@David-Chadwick Is my assumption correct?

Updated:

• updated example to show potential new properties in the VP.

[OR13]

if this is really a request for presentationSchema I suggest we update the title and description.

[iherman]

The issue was discussed in a meeting on 2022-08-17

• no resolutions were taken

View the transcript

2.2. Schema for VPs (issue vc-data-model#839)

See github issue vc-data-model#839.

David Chadwick: in OIDC, when we stick something into VP, it will have new type into type field -- it would be nice if this data model could give some guidance on how different types of VPs are formed and how recipient will know if VP is well formed..

David Chadwick: Are we going to have a presentation schema? That's the broad issue..

Kristina Yasuda: don't think we made that decision in Connect WG, David...

David Chadwick: We have schemas for VCs, so looking at schema you can see what they contain... but we don't have one for VPs. We have talked 19:22:55 <manu> q+.

Brent Zundel: is anyone opposed to having a vp schema.

Manu Sporny: not opposed, but it would be very simple for now.
… however it will be related to protocols as they determine what fields should be there e.g. audience.

Kristina Yasuda: +1 to maybe we do not need a schema.

Dmitri Zagidulin: not opposed but maybe we don't need a schema if all the fields are optional.

Michael Jones: not opposed but it is work. Takes work to keep schemas in sync.

Orie Steele: context files are not schemas..

Michael Jones: is the effort worth the benefit?.

Orie Steele: very different security considerations.

Michael Prorock: can we leave this until we have more context and examples. Feels like a lot of maintenance work to start now.

Oliver Terbu: the schema is needed for syntactic interoperability. Can we reuse credentialSchema for VPs?.
… whilst number of properties is small now, implementors may add lots of new ones.

Kevin Dean: if we are going to verify a VP then processing schema seems to be fundamental to me.

Orie Steele: See also input validation, as it related to "schemas"... https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html.

Samuel Smith: in ACDC we use compose schema and disclose schema so that once verifier signs it is committed to the rules then the ACDC can be disclosed.

David Waite: if we have normative text describing properties plus a schema then one has to trump the other if they conflict.

Orie Steele: +1 david... normative text trumps... ideally schema implements normative stuff only..

Dave Longley: +1 to David.

Manu Sporny: +1 to dwaite.

David Waite: since we dont want to mandate people to use schemas then they should be informative.

Michael Jones: JSON schema is not used in TLS. Prose are sufficient for interoperable implementations.

Michael Prorock: +1 selfissued - the normative text tells you what to do (hopefully with nice examples and test vectors and other fun bits).

Gabe Cohen: their is value in schemas.

Manu Sporny: there is spec text already so a schema would be simple and not necessary (for now).
… someone who is interested can create a PR with the schema and keep it up to date.

David Chadwick: Yes, trying to write down what Oliver said, got a bit lost when he was talking about subtypes and subschemas..
… As we have with credentials, there can be multiple types of credentials that have the same schema, there was some confusion in DIF -- 1-to-1 mapping between schemas and types. Types come into this because we should be creating different types of verifiable presentation when they have different content... but if properties remain the same, type could still change. Schema defining a particular property, but type alters value of particular property, for example..

Manu Sporny: we are still not clear if we are talking about a new VPschema or existing credentialSchema.
… we have conformance tests currently for VPs.
… if the wallet creates a VP with its own properties and adds the schema, but has a bug in this, then the wallet has not followed its own rules.

Brent Zundel: concludes that there is no opposition to this, but not necessarily anyone wanting to do all the work!.

[David-Chadwick]

Yes I was requesting that the property presentationSchema be defined in the v2 data model.

[awoie]

@David-Chadwick thanks, can you please update the title of the issue to reflect what is requested? It was not clear to everybody.

[awoie]

IMO the schema should be in the same repo with the normative statements that it is built from.

@OR13 it seems that @David-Chadwick requests to add a new property presentationSchema to the VC Data Model but you proposed defining a JSON Schema for VPs in the VC Data Model spec normatively. If you still want to add a JSON Schema for VPs in the VC Data Model spec, I suggest you create a new issue.

[iherman]

The issue was discussed in a meeting on 2022-08-31

• no resolutions were taken

View the transcript

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.

---

[iherman]

The issue was discussed in a meeting on 2022-10-19

• no resolutions were taken

View the transcript

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

See github issue vc-data-model#839.

David Chadwick: I haven't looked at this for some time..
… I think there was an agreement, that what I'm looking for is presentationSchema, which is equivalent for credentialSchema -- that will tell RP whether VP has been properly formed or not..

Orie Steele: +1 david, that is my understanding of your request..

David Chadwick: The proposal was to have a presentationSchema property..

Manu Sporny: thinks it lets an attacker choose the schema.

---

[iherman]

The issue was discussed in a meeting on 2022-11-09

• no resolutions were taken

View the transcript

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

[David-Chadwick]

I have produced the PR for this as requested, but when I tried to push it to the repo it said I did not have write access, so did I want to fork the repo instead. Please advise

[decentralgabe]

@David-Chadwick I did add a VP schema to the repo here -- https://github.com/w3c/vc-data-model/tree/main/schema

is this sufficient to close out this issue?

[David-Chadwick]

My PR is simply adding text to the VCDM to describe this new property. It does not affect your schema but actually supports it

[decentralgabe]

@David-Chadwick i was planning on another change to add text to support both the VP and VC schemas - happy to build off your work

[David-Chadwick]

My current question is, how should I submit my PR so that you can build off it. Should I create a fork in the repo as Github desktop suggests I should do, or should I be given write access to the VCDM repo (which I believe I had for DCVM v1 and v1.1)

[decentralgabe]

I'm not sure who controls write access maybe @iherman

In the meantime a fork should work - you'll be able to open up a pull request from your fork to this repo which I can build upon

[David-Chadwick]

Thanks. Manu also suggested the same approach. So you should be able to see the PR now #987

[awoie]

In general I'm supportive of that feature since I found credentialSchema in the VC useful. What I'm missing is whether the schema matches the VP with or without the embedded VCs. For VPs I expect the schema to just match VP without the embedded VCs. Matching embedded VCs might be also a bit difficult since JWTs can be included as b64-encoded strings.

[David-Chadwick]

@awoie Good question. The presentationSchema should control the properties of the VP, not the VC. That being said, any instantiation of the presentationSchema will no doubt mandate that a verifiableCredential property must be present, without diving into the details of this property, as its credentialSchema will do that

[iherman]

The issue was discussed in a meeting on 2023-06-06

• no resolutions were taken

View the transcript

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

See github issue vc-data-model#839.

Brent Zundel: presentation schema for VPs, the associated PR is closed because we couldn't come to consensus to merge it. Suggest marking this as pending close in light of that.

Joe Andrieu: +1.

Orie Steele: +1.

Manu Sporny: +1.

Brent Zundel: ok, not hearing objections, marking pending close and moving on.

[brentzundel]

No objections raised since marked pending close, closing.