[Openid-specs-ab] Handling of invalid claim values within claims request parameter

[Joseph Heenan]

Hi Kai

I’m not sure any of these cases are really strictly defined. Certainly we don’t test any behaviours like this in any of the OpenID Foundation conformance tests, although the testing of the claims perhaps is certainly not comprehensive.

Rejecting the request seems fine.

Accepting the request but ignoring parts of it is probably acceptable as I can’t see anything that really defines the behaviour in this case. You should probably NOT return any claims where the request for that claim is invalid. The caveat would be that by ignoring that part of the request you’re also losing your ability to tell the developer why their request is not working as they expected, which makes it harder for them to figure out what they’ve done wrong and hence harder for them to fix their request to be valid.

In reality we really shouldn’t be expecting a situation like this to occur except when a developer has badly misread the specification, and hence my instinct is we should err towards returning an error that tells the developer what they’ve done wrong.

(For clarity the above is not an official position of the OpenID Foundation.)

Thanks

Joseph


> On 28 Sep 2023, at 14:06, Kai Lehmann via Openid-specs-ab <openid-specs-ab at lists.openid.net> wrote:
> 
> Hi,
>  
> The OIDCC spec allows RPs to request individual claims with the claims parameter:
>  
> https://openid.net/specs/openid-connect-core-1_0.html#IndividualClaimsRequests
>  
> I was wondering how strict the OP should be in handling invalid claim values within this request. For example:
>  
> {
>   “first_name”: “INVALID”,
>   “last_name”: 5,
>   “email”: {
>     “essential”: “INVALID”
>   }
> }
>  
> My interpretation of “The member values MUST be one of the following …” would be that the claims request parameter would be invalid if it contained invalid member values and thus the server should reject the request with a redirect back to the RP’s provided redirect_uri with invalid_request error. Would a more relaxed parsing (ignoring invalid claim parameters) also be an option and still in accordance with the specification?
>  
> Best regards,
> Kai
>  
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net <mailto:Openid-specs-ab at lists.openid.net>
> https://lists.openid.net/mailman/listinfo/openid-specs-ab

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20230929/87f5398a/attachment.html>