Suggestion - Consider renaming schema -> type

[tplooker]

Currently the term schema in the input descriptors data model creates the in-correct association that it is attempting to convey not only a logical grouping of claims/credentials being requested but also instead the shape of the data those claims or credentials are expressed within (i.e how they concretely manifest within say a JSON structure). In order to clear up this confusion I would suggest renaming this field to type which better conveys what this request element is attempting to communicate.

[tlodderstedt]

I suggest to also consider to use a simple type element instead of an array. I'm not sure what the use case of the array is. If a verifier is ready to accept alternative credentials, it can use multiple ' input_descriptors' along with 'submission_requirements'.

[David-Chadwick]

@tlodderstedt An array is needed because the type of a VC is an array. It is not hierarchical, so you cannot simply present the most refined subtype. If you present a single value then several different VCs might match (and if you present the VerifiableCredential type then all VCs will match). Having an array provides the maximum flexibility for the verifier to chose which VCs are required

[tplooker]

To make things more concrete here is a proposed syntax change

Below is a relevant extract from an input descriptor object as it stands within the spec today

{ // Example Input Descriptor
    .....
    "schema": [
        {
            "uri": "https://bank-schemas.org/1.0.0/accounts.json#primary-account"
        },
        {
            "uri": "https://employment-schemas.org/2.0.0/employee.json#current-job"
        }
    ]
    ....
}

I proposed we both rename schema to type but also change the JSON value type of this element to an array (or string as per @tlodderstedt suggestion). This would result in the following:

{ // Example Input Descriptor
    .....
    "type": ["https://bank-schemas.org/1.0.0/accounts.json",
             "https://bank-schemas.org/2.0.0/accounts.json" ]
    .....
}

Where the logic of this array within the context of an input descriptor object would be OR (e.g I want your bank account credential of type v1 OR v2)

OR instead type as a string would result in the following

{ // Example Input Descriptor
    .....
    "type": "https://bank-schemas.org/2.0.0/accounts.json"
    .....
}

Why? Currently the syntax declares an array of objects which allows data model extension on a per array element basis with the fields uri and required already defined. Personally I think extensibility at this layer is only going to created complexity and P.E would benefit from being stricter here.

Determining whether type should be a string OR an array of strings is an interesting question. The only use-case I can see for allowing it to be an array is if we believe patterns will emerge where the same credential is referred to by multiple distinct types (e.g versioning might be a valid case here as shown above, however it may also be an anti-pattern for types to be versioned). A counter argument to this point is that allowing type to be an array may create a developer anti-pattern and hence cause un-wieldy requests that abuse this syntax.

[tplooker]

@David-Chadwick it sounds like your use-case would have the type value in the input descriptor be an array where the logic of the array is AND? For example the following:

{ // Example Input Descriptor
   .....
    "type": [ "X", "Y" ]
    .....
}

Is interpreted as asking for a credential of type X AND Y? If this is correct can you give some use-cases for this syntax?

[David-Chadwick]

We currently do not have enough experience of VC types to know if each VC will have just two types (the generic VerifiableCredential type and its specific type), or whether people will try to subtype, supertype or have multiple inheritance types. I know that in some current implementations, because there is a lack of official VC issuers (e.g. for driving licences, employment, utility bills etc) then the implementors are issuing one megaVC that contains all the properties the subject needs for the use case. What the type is I dont know. But they might say its a set of DrivingLicense, CouncilBill and Employment etc.). Depending on the choice they have made for the VC type, they might need the input descriptor to match their set, because they are selecting multiple sets of subject properties from the megaVC.

[Sakurann]

I think there are no objections to renaming the property name itself to type.

[Sakurann]

(separating out another issues discussed here)
+1 to using array instead of array of objects.

whether it should be a string is an interesting question, but given that input_descriptors can grow bigger in size, using multiple ' input_descriptors' along with 'submission_requirements' might result in bigger requests than having an array of types.

I also think

{ // Example Input Descriptor
   .....
    "type": [ "X", "Y" ]
    .....
}

should be interpreted as requesting a credential of type X OR Y.
It is usually a good practice not to keep something that is not currently used, but MAY be used.

X AND Y seems to be a not-yet established use-case right now and if it becomes more used in the future, using multiple ' input_descriptors' along with 'submission_requirements' is an option too (wallet will send back a same credential that satisfies two input_descriptors)

[OR13]

https://w3c.github.io/vc-data-model/#types

It is RECOMMENDED that each URI in the type be one which, if dereferenced, results in a document containing machine-readable information about the type.

Setting aside the JSON-LD aspect of credential types, the examples in PE are clearly targeted at JSON Schema... This is probably a mistake, I would rely on this property from the W3C Standard for JSON Schema instead:

https://w3c.github.io/vc-data-model/#data-schemas

The value of the credentialSchema property MUST be one or more data schemas that provide verifiers with enough information to determine if the provided data conforms to the provided schema.

I strongly suggest not conflating JSON-LD types and JSON Schema $ref / oneOne, etc...

TLDR: type != credentialSchema

[OR13]

I keep forgetting this spec isn't about W3C VC Data Model...

[David-Chadwick]

Filtering on the JSON schema rather than the credential type is semantically wrong in my opinion. For example, the address schema element occurs in many different types of VCs. But the RP will most likely want to specify the type of credential that they want to be presented that contains an address, rather than any type of credential that contains an address schema element in it. Different types of credentials have more trust associated with them e.g. a driving license with an address compared to a club membership card with an address.

[OR13]

The spec does not care about what you move around.... channeling @csuwildcat does bananaOctopus have an @type ? or a schema?

better to use the constraint language on type in you want to assert that bananaOctopus is really a VC Data Model of a specific type.

[csuwildcat]

PROPOSAL from OIDC/PE call:

1. Simplify current schema/type interrogation property to an OR array of URIs.
2. Add spec text/note to inform issuers that you may submit one cred that fulfills multiple descriptors.

Please provide feedback, and we can do a PR to add these modifications.

[csuwildcat]

ACTION ITEM: Daniel will do PR based on the agreed upon simplified array value, with bikeshed-forcing-prop name, for funzies.

[csuwildcat]

Handing off to @JaceHensley, who is doing this within his PR for the move to adopting the same normalized functionality of Fields to evaluate the type/schema.