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

[Mike Jones]

The “value” constraint only affects the claim in which it occurs.  Therefore, the claims returned in the first example (Q1) would be:

{
  “sub”: “1337”,
  “family_name”: “Doe”,
  (plus all the other required ID Token Claims, such as “iss”, “aud”, “exp”, etc.)
}

It is never an error condition for requested claims to not be available.  They just aren’t returned.

In the second example (Q2), the set returned would be:

{
  “sub”: “1337”,
  “given_name”: “John”,
  “family_name”: “Doe”,
  (plus all the other required ID Token Claims, such as “iss”, “aud”, “exp”, etc.)
}

While the “sub” value doesn’t match the requested value, a “sub” value is required in the ID Token, therefore, “sub” is returned anyway.

From: Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net> On Behalf Of Daniel Fett via Openid-specs-ab
Sent: Wednesday, April 13, 2022 9:14 AM
To: openid-specs-ab at lists.openid.net
Cc: Daniel Fett <fett at danielfett.de>
Subject: [Openid-specs-ab] A "simple" question regarding value/values constraints in OpenID Connect Core

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/20220427/53b8fcc6/attachment.html>