Open nklomp opened 1 year ago
It seems that the orig spec lists the uri property as a string. The question still remains though
call to work item to provide info on how each implementer uses schema vs @context
& type
Microsoft uses types in presentation definition for the verifier to request certain credentials and the wallet to filter a requested credential. The rationale was
@context
value, so cannot use @context
value. So type property was a way to differentiate credentials with different claim sets about the user.
We can still use presentation exchange to query by credential type by following below pattern,
{
"id": "69ddc987-55c2-4f1f-acea-f2838be10605",
"input_descriptors": [
{
"id": "23b00531-caa1-49f3-a5a1-4a0eae8c0921",
"constraints": {
"fields": [
{
"path": [
"$.type",
"$.vc.type"
],
"filter": {
"type": "array",
"contains": {
"type": "string",
"const": "VerifiedEmployee"
}
}
}
]
}
}
]
}
Note: CredentialType are not collision-resistant
Yes of course, just like you could for @context
or credentialSchema, except that is not what this issue is about.
Since then we have updated our library to also accept strings for v1 PE schema's as that is what we encounter in the wild
Our Presentation Exchange library conforms to PE v1. In our library we are enforcing that a schema URI is a valid URI according to https://identity.foundation/presentation-exchange/spec/v1.0.0/#input-descriptor-object
In this profile an example is however given where the URI is the string at https://identity.foundation/jwt-vc-presentation-profile/#requesting-verifiable-credentials
The example:
Is this on purpose or is this an error in the example? If a simple string is allowed in the profile, it for sure needs to be mentioned. I do not see how a string would work for a location where an actual schema is supposed to be found though