[OpenID-Specs-eKYC-IDA] Issue #1152: Expectations on the OP filtering response data (openid/ekyc-ida)

[Daniel Fett]

New issue 1152: Expectations on the OP filtering response data
https://bitbucket.org/openid/ekyc-ida/issues/1152/expectations-on-the-op-filtering-response

Daniel Fett:

Working on a prototype for OIDC4IA, I found that a number of details on the request semantics are not clear yet.

The main question is: **What if a certain attribute is requested** \(e.g., using value/values/max\_age\) **but cannot be satisfied?**

This question is not answered conclusively by the OIDC Core Spec:

Section 5.5.1, JSON Object with “value”: _Requests that the Claim be returned with a particular value. \(…\) Definitions of individual Claims can include requirements on how and whether the value qualifier is to be used when requesting that Claim._

For “values”: _Requests that the Claim be returned with one of a set of values, with the values appearing in order of preference._

**What happens if the request cannot be satisfied?** 

1. Whatever data is available is sent anyway.

    1. Variant: There is a flag sent by the OP to indicate that the request was not fulfilled.
    
2. The claim in question is skipped \(omitted from the results\). If this is applied to OIDC4IA, a number of questions come up: Is a document that is not of the requested type skipped entirely? Skip the whole evidence part if no matching document is available?
3. There is an error or empty response.

The advantage of Option 3 could be that the RP can rely on the data being properly filtered by the OP. This is also a disadvantage: RPs might be vulnerable to OPs sending data that does not match their criteria.

‌