Expectations on the OP filtering response data

[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.

‌

[Roland Hedberg]

In basic OIDC the RP asks and the OP decides. There is no guarantee that the OP will honor what the RP asks for. And there is no flag set by the OP to indicate that it could/would not fulfil the request. The OP will return whatever it feels like.

[Joseph Heenan]

I think default position does exist in https://openid.net/specs/openid-connect-core-1_0.html#IndividualClaimsRequests :

Note that even if the Claims are not available because the End-User did not authorize their release or they are not present, the Authorization Server MUST NOT generate an error when Claims are not returned, whether they are Essential or Voluntary, unless otherwise specified in the description of the specific claim.

The “… or they are not present …” part can be relatively widely interpreted I think.

The spec calls out that if an non-essential claim for an acr cannot be satisfied, the acr actually used should be returned, but I think stops short of implying that behaviour should apply to anything other than acr. [Also note that essential acr claims are defined to act differently to all other essential claims. This section of the spec already causes a lot of confusion.]

That said I think the ‘unless otherwise specified’ means that different behaviour can be defined for the new claims.

[Marcos Sanz]

I am facing a similar dichotomy when trying to give a recommendation for issue 1094:

https://bitbucket.org/openid/ekyc-ida/issues/1094/#comment-55735646