Open OIDF-automation opened 2 years ago
@Jeremie commented “I have immediate concerns about the security implications of adding any schema definition to the metadata. Is the client/consumer of this metadata now required to use and validate the schema, and fail as part of the validation? What if it contains a schema type it doesn’t understand? If it’s not required to verify, then what behavior is expected if the schema doesn’t match on clients that do support it?”
The W3C VC DM regards the verifier as the root of trust, meaning that it makes up its own rules about which VCs to trust. It might decide to accept revoked or expired credentials e.g. a nightclub owner allows a person to enter with an expired identity card. In this vein, the client can decide to ignore schema types it doesn’t understand or to reject credentials with schemas it does not understand and credentials that do not conform to schemas it does understand. We could add some notes to the Implementation section to advise clients on this issue.
@Kristina Yasuda asked for descriptive text to be added to PR#241. The following is a strawman proposal
“Credential types
and schemas
are not synonymous nor interchangeable terms. The schema
enumerates what the contents of a credential should be, including its mandatory and optional properties. Thetype
identifies the type of a credential. Multiple different types
can use the same schema
. A simple example is address. The schema
might list street number, street, town, area, country. An issuer might issue HomeAddress
and BusinessAddress
credential type
s using the same schema. Whilst the credential type
s are different the schema
s are the same.”
Comments and/or edits gratefully accepted
I don’t believe there’s a standard schema for JSON that’s widely deployed. That argues against doing this.
It’s also not clear that run-time schema would be generally valuable.
discussed in SIOP Jan-12-2023 call. Direction was that it makes sense to add schema parameter to the credential issuer metadata. A separate topic how does the verifier discover issuer schema was raised - asked to continue that discussion in issue #1551 or raise a new issue.
Verifier discovering the issuer’s schema is unrelated to #1551 (as this discusses how the wallet can trust the verifier).
The answer to the verifier is as follows
Either the issued VC already contains the credentialSchema property (which is already in the VCDM) so problem solved or
the verifier reads the metadata of the issuer (which this issue is suggesting), so again problem solved.
Closed PR #241
I think this one can be closed when we resolve #266.
Imported from AB/Connect bitbucket: https://bitbucket.org/openid/connect/issues/1578
Original Reporter: dwc8
There is not a one to one mapping between credential types and schemas. The same schema may be shared by different credential types e.g. Visa and Mastercard credentials could have the same “credit card” schema. Therefore the OP should publish in its metadata the schemas that control the contents of the different types of credentials that it issues. In this way the RP will be able to determine if a credential is well formed or not.