Closed JensJelitto closed 1 year ago
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
It appears that the verifier must use
_enum
and_const
for the generation of thepresentation definition
in the description of thefields
, e.g.or
Why is this necessary, couldn't the keywords
enum
andconst
be used directly (even though we understand that these are reserved keywords in Javascript).