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

[Mike Jones]

Oh, wait.  Joseph is right that an error must be returned for Q2 when the “claims” parameter is supported because of this language that special-cases the “value” behavior for “sub” in the ID Token https://openid.net/specs/openid-connect-core-1_0.html#AuthRequestValidation:


  1.  If the sub (subject) Claim is requested with a specific value for the ID Token, the Authorization Server MUST only send a positive response if the End-User identified by that sub value has an active session with the Authorization Server or has been Authenticated as a result of the request. The Authorization Server MUST NOT reply with an ID Token or Access Token for a different user, even if they have an active session with the Authorization Server. Such a request can be made either using an id_token_hint parameter or by requesting a specific Claim Value as described in Section 5.5.1<https://openid.net/specs/openid-connect-core-1_0.html#IndividualClaimsRequests>, if the claims parameter is supported by the implementation.

                                                       -- Mike

P.S.  I should have read Joseph’s response before sending mine!

From: Mike Jones
Sent: Wednesday, April 27, 2022 10:02 AM
To: Artifact Binding/Connect Working Group <openid-specs-ab at lists.openid.net>
Cc: Daniel Fett <fett at danielfett.de>
Subject: RE: [Openid-specs-ab] A "simple" question regarding value/values constraints in OpenID Connect Core

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<mailto: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<mailto:openid-specs-ab at lists.openid.net>
Cc: Daniel Fett <fett at danielfett.de<mailto: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/fec7a372/attachment.html>