schema uri in example using a string

[nklomp]

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:

 "schema": [
              {
                "uri": "InteropExampleVC"
              }
            ]

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

[nklomp]

It seems that the orig spec lists the uri property as a string. The question still remains though

[dtmcg]

call to work item to provide info on how each implementer uses schema vs @context & type

[Sakurann]

Microsoft uses types in presentation definition for the verifier to request certain credentials and the wallet to filter a requested credential. The rationale was

• we do not use JSON-LD, hence all of the Credentials in the ecosystem have a same @context value, so cannot use @context value.
• credentialSchema is an optional property and our credentials do not have this property, so cannot use it either.

So type property was a way to differentiate credentials with different claim sets about the user.

[sudeshrshetty]

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

[nklomp]

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