Accepance of `const` and `enum` keys
JensJelitto opened this issue · 4 comments
It appears that the verifier must use _enum
and _const
for the generation of the presentation definition
in the description of the fields
, e.g.
constraints: {
fields: [
{
path: ['$.credentialSubject.role'],
filter: {
type: 'string',
_const: 'admin',
},
},
]
}
or
constraints: {
fields: [
{
path: ['$.vc.credentialSubject.degree.name', '$.credentialSubject.degree.name'],
filter: {
type: 'string',
_enum: ['Bachelor of Science and Arts'],
},
},
],
},
Why is this necessary, couldn't the keywords enum
and const
be used directly (even though we understand that these are reserved keywords in Javascript).
Would also like to point out that in the spec it says ->
The Exchange 1.0 https://identity.foundation/presentation-exchange/spec/v1.0.0/
in-set - Use the enum descriptor.
For example, to request proof that an attribute is contained in the set of rainbow colors,
use the following as the value of the filter object:
{ "type": "string", "enum": ["red", "yellow", "blue"] }
Hi @marek5050 @JensJelitto Yes, you both are correct. The reason is that the PEX library uses autogenerated models from an OpenAPI specification in https://github.com/Sphereon-Opensource/pex-openapi The different language generators typically do not support these keywords. The PEX library does internally replace these values with the correct ones.
I will do some investigation, whether we can create a custom template for Typescript in the generator code, or whether we can re-export a version that removes the underscore version and replaces it with a string based property key.
It for sure is in the generator, as our OpenAPI spec is explicitly using strings as keys:
properties:
"const":
$ref: './polymorphic_entity.yaml#/one_of_number_string'
description: A fixed value that is acceptable in this variable
"enum":
type: array
description: Fixed listed values which are acceptable in this variable.
items:
$ref: './polymorphic_entity.yaml#/one_of_number_string'
This is fixed in V2.0.0 of @sphereon/pex-models and @sphereon/pex and as a consequence in @sphereon/did-auth-siop