Skip to content

Improved presentation flexibility

Kreiner, Stefan requested to merge feature/2024-04-03-improved-presentation-flexibility into develop

Created by: acrusage-iaik

This pull requests adds logic to handle a presentations more diligently, but this unfortunately leads to some changes in semantics expected from the "createPresentation" function before that. I hope the changes are reasonable, I tried following the guide from PresentationExchange at: https://identity.foundation/presentation-exchange/spec/v2.0.0/#input-evaluation

I tried to stay conform with openId4vp, but I hope that we don't need to support other presentation specifications?

Semantic changes to be approved:

Presentation Submissions now only contain matches from input descriptors.

Previously a verifiable presentation contained all the verifiable credentials with the required credential scheme, but not anymore. Each input descriptor matches to exactly one verifiable credential, and that verifiable credential must satisfy all constraint fields. This may actually break some things, as it was previously possible to present multiple AtomicCredentials at once, but after this change each AtomicCredential attribute needs to be requested separately (in separate input descriptors). -> result.vp.verifiableCredentials now always has size 1! Impacted Tests (among others):

  • AgentTest."valid presentation is valid": change last "shouldHaveSize" to "1"
  • ValidatorVpTest."valid parsed presentation should separate revoked and valid credentials": Change last "shouldHaveSize" to "issuedCredential.successful.size"

Presentation Submissions where no fields are requested don't return any fields

Previously it seems like not requesting any claims should return all available claims, but not anymore. Impacted Tests (among others):

  • OidcSiopIsoProtocolTest."test with Fragment for mDL": request an attribute to satisfy the "document.validItems.shouldNotBeEmpty()" assertion
  • OidcSiopIsoProtocolTest."test with Fragment for custom attributes": request an attribute to satisfy the "document.validItems.shouldNotBeEmpty()" assertion

Scope value semantics have somewhat changed

Previously the scope values were used to deduce the requested credential schemes, but not anymore. As per openid4vp the scope values have the following semantics:

Such a scope value MUST be an alias for a well-defined Presentation Definition that will be referred to in the presentation_submission response parameter.
https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#section-5.3-2

scope values are therefore only taken into consideration now in case neither presentationDefinition nor presentationDefinitionUri return a presentation definition.

Users can now define a path authorization validator

This can mainly be done by providing a default authorizer in the constructor of HolderAgent.

Merge request reports