- changed status to open
consent and error handling contradiction
Section 6.5.1 and 6.5.4 contradict each other in some circumstances
Comments (7)
-
reporter -
reporter -
reporter 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…
-
reporter 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”
-
reporter Just noting down the discrete cases we should describe:
- Unavailable Data
- Non-consent for subset of data requestsed
- No consent to whole transaction
- 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
-
reporter addressed by PR#179
-
reporter - changed status to resolved
resolved by PR#179
- Log in to comment