consent and error handling contradiction

[Mark Haine]

Section 6.5.1 and 6.5.4 contradict each other in some circumstances

[Mark Haine]

6.5.1. Unavailable or Non-consented Data

If the OP does not have data about a certain Claim, does not understand/support the respective Claim, or the End-User does not consent to the release of the specific data, the respective Claim MUST be omitted from the response. The OP MUST NOT return an error to the RP.

-vs-

6.5.4. Error Handling

If the OP encounters an error, or the End-User does not consent to the whole transaction, standard OpenID Connect authentication error response logic applies, as defined in Section 3.1.2.6 of [OpenID].

‌

What is the resolution?

To begin with split out the cases of “unavailable” and “non-consented”

‌

With regard to consent/authorization to share with the RP, I’m pretty sure we should not mandate consent as a normative requirement for releasing claims.

perhaps a section saying something like when consent is requested interactively any subset of claims not consented should be omitted from the response and if no sub-elements of the request are authorized then the entire response shopuld be aborted with error…

‌

[Mark Haine]

Also spotted a typo in line 413 “to enable a finer-grained control of the RP over the behavior of the OP when data is unavailable or does not match the criteria“ - the first “of” should be a “by”

[Mark Haine]

Just noting down the discrete cases we should describe:

1. Unavailable Data
2. Non-consent for subset of data requestsed
3. No consent to whole transaction
4. Data doesn't match value, values, max_age

then there is the case of some other error

also need to leave the possibility of further extensions in this space open

[Mark Haine]

addressed by PR#179

‌

[Mark Haine]

resolved by PR#179