The EC conformance team has raised the following clarification issue.
According to OID4VP, trusted_authorities queries do not have to be followed strictly, which is why the following requirement uses SHOULD instead of MUST:
Every Credential returned by the Wallet SHOULD match at least one of the conditions present in the corresponding trusted_authorities array if present.
In my view, this flexibility was primarily introduced for trusted_authorities query types that require dereferencing external resources (e.g., fetching data from a URL), either to mitigate privacy concerns for wallet providers or to reduce implementation burden by not requiring support for all possible trusted_authorities types, e.g., openid-federation.
However, this leads to ambiguity in the following scenario, which can result in three different VALID outcomes:
Scenario: The Verifier sends a trusted_authorities query with a known type defined in OID4VP, e.g., AKI.
Possible VALID outcomes:
- The Wallet returns a credential with a non-matching AKI (e.g., because AKI is not implemented for some reasons).
- The Wallet returns a credential with a matching AKI (successful AKI match).
- The Wallet returns no credential (because it performs AKI matching and finds no match).
From an OID4VP perspective, all three outcomes seem to be valid because of the SHOULD. Note that in this context the Verifier cannot determine which trusted_authorities types the Wallet supports.
However, when considered in combination with HAIP:
The Authority Key Identifier (AKI)-based Trusted Authority Query (trusted_authorities) for DCQL, as defined in Section 6.1.1.1 of [OIDF.OID4VP], MUST be supported.
In this case, the Verifier can expect the Wallet to support AKI.
This raises the question of whether the original SHOULD (in OID4VP) is effectively elevated to a MUST in practice for AKI queries.
The key question is whether:
- a conformance testing suite should fail / or a verifier can expect that only credentials matching an AKI are returned,
- or whether such behavior would still pass because it is permitted under:
- OID4VP (due to the use of SHOULD), and
- HAIP (because requiring support for AKI-based queries does not explicitly require enforcing the matching result in the response).
In my view, the original privacy considerations do not apply to AKI. Furthermore, limiting trusted_authorities to AKI does not impose a significant implementation burden on Wallets.
For this reason, I believe the expected behavior should be that no credential is returned if the AKI does not match (option 1 below).
However, I do not recall the original intention behind HAIP in this regard. We should clarify this requirement in HAIP 1.1, for example by stating explicitly that:
trusted_authorities queries of trusted_authorities types defined in HAIP were intended to be effectively a MUST constraint, or- a note that explains when to deviate from AKI matching because the original privacy considerations don't apply to AKI.
Additionally, we should add a privacy consideration to OID4VP 1.1 that explains the privacy risks of ignoring trusted_authorities queries by disclosing credentials that won't be accepted by a verifier.
What do you think @c2bo @jogu @paulbastian @leecam (cc @brentzundel, potentially for 1.1) ?
The EC conformance team has raised the following clarification issue.
According to OID4VP,
trusted_authoritiesqueries do not have to be followed strictly, which is why the following requirement uses SHOULD instead of MUST:In my view, this flexibility was primarily introduced for
trusted_authoritiesquery types that require dereferencing external resources (e.g., fetching data from a URL), either to mitigate privacy concerns for wallet providers or to reduce implementation burden by not requiring support for all possibletrusted_authoritiestypes, e.g., openid-federation.However, this leads to ambiguity in the following scenario, which can result in three different VALID outcomes:
Scenario: The Verifier sends a
trusted_authoritiesquery with a known type defined in OID4VP, e.g., AKI.Possible VALID outcomes:
From an OID4VP perspective, all three outcomes seem to be valid because of the SHOULD. Note that in this context the Verifier cannot determine which
trusted_authoritiestypes the Wallet supports.However, when considered in combination with HAIP:
In this case, the Verifier can expect the Wallet to support AKI.
This raises the question of whether the original SHOULD (in OID4VP) is effectively elevated to a MUST in practice for AKI queries.
The key question is whether:
In my view, the original privacy considerations do not apply to AKI. Furthermore, limiting
trusted_authoritiesto AKI does not impose a significant implementation burden on Wallets.For this reason, I believe the expected behavior should be that no credential is returned if the AKI does not match (option 1 below).
However, I do not recall the original intention behind HAIP in this regard. We should clarify this requirement in HAIP 1.1, for example by stating explicitly that:
trusted_authoritiesqueries oftrusted_authoritiestypes defined in HAIP were intended to be effectively a MUST constraint, orAdditionally, we should add a privacy consideration to OID4VP 1.1 that explains the privacy risks of ignoring
trusted_authoritiesqueries by disclosing credentials that won't be accepted by a verifier.What do you think @c2bo @jogu @paulbastian @leecam (cc @brentzundel, potentially for 1.1) ?