[Openid-specs-ab] A "simple" question regarding value/values constraints in OpenID Connect Core

[Joseph Heenan]

Hi Daniel

For info, there are (to the best of my knowledge) no certification tests that cover value/values (aside from one of two FAPI tests that request values for acr or ecosystem specific claims).

My belief is:

Q1 : “B”. Although I think you meant to write “family_name”: “Doe” for “B”.

Reasoning is that I don’t see any language that requires a non-match for one value to affect other returned values. (Except in the special cases of sub and acr where behaviour is explicitly defined.)


Q2: “C” an error as per specific behaviour for ’sub’ defined in bullet 4 of https://openid.net/specs/openid-connect-core-1_0.html#AuthRequestValidation

Cheers

Joseph


> On 13 Apr 2022, at 17:14, Daniel Fett via Openid-specs-ab <openid-specs-ab at lists.openid.net> wrote:
> 
> Hi all,
> 
> during the work on the Advanced Syntax for Claims spec, a question came up in the eKYC working group. It seems that some details of the constraints one can express using value/values in OpenID Connect Core are not as clear as we thought.
> 
> The relevant bits of the spec: https://openid.net/specs/openid-connect-core-1_0.html#IndividualClaimsRequests <https://openid.net/specs/openid-connect-core-1_0.html#IndividualClaimsRequests>
> Let's suppose that the OP has the following data about the authenticated user:
> 
> sub: 1337
> given name: John
> family name: Doe
> For clarity, I'll try to capture the bone of contention in two questions. There is a potential for follow-ups, with other claim names, essential, max_age etc., but let's focus on these examples first:
> 
> ------------------------------
> 
> Q1: For this request, what should be the user claims in the ID token?:
> 
> claims={
>     "id_token": {
>         "given_name": {
>             "value": "Albert"
>         },
>         "family_name": null
>     }
> }
> 
> (A)
> 
> { "sub": "1337" }
> 
> (All claims are omitted since the given name does not match. sub must always be present in the ID Token, so it is not omitted.)
> 
> (B)
> 
> {
>     "sub": "1337",
>     "family_name": null
> }
> 
> (given_name is omitted as it does not match the value constraint. The other claims are not affected by the value constraint.)
> 
> (C)
> 
> An error is sent back to the RP. While this is explictly forbidden in case of unavailable "essential" claims, it is not excluded for mismatches in value/value constraints.
> 
> (D)
> something else?
> 
> ------------------------------
> 
> Q2: What about this request?
> 
> claims={
>     "id_token": {
>         "sub": {
>             "value": "4224"
>         },
>         "given_name": null,
>         "family_name": null
>     }
> }
> 
> 
> (A)
> 
> { "sub": "1337" }
> 
> (Again, all claims are omitted since the sub does not match, but in order to send back a valid response, sub must be present.)
> 
> (B)
> 
> ??? Not sure what other non-error solutions there could be.
> 
> (C)
> 
> An error is sent back to the RP. 
> 
> (D)
> 
> something else?
> 
> ------------------------------
> 
> -Daniel
> 
> _______________________________________________
> Openid-specs-ab mailing list
> 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/20220413/7c35f127/attachment.html>