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

Daniel Fett fett at danielfett.de
Wed Apr 13 16:14:03 UTC 2022


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

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20220413/28824158/attachment.html>


More information about the Openid-specs-ab mailing list