Self-Issued ID Token Validation subtleties

[Thomas Bellebaum]

Two nits concerning the validation of self-issued ID tokens:

1. Not a SIOP

According to the implementer’s draft (Self-Issued ID Token Validation)

The ID Token is self-issued if the iss claims and thd sub claim have the same value. If both values differ, the ID Token MUST be processed as defined in [@!OpenID.Core], section 3.2.2.11..

(also there is a typo in “thd”)

Some RPs have a separate endpoint for each OP. When this is the case, the RP may already know it is listening for a SIOP and may furthermore want to abort the authN process when the response is something unexpected.

OIDCC has a more gentle way of dealing with cases not covered by the spec. E.g. (from Authentication Request Validation):

Verify that a scope parameter is present and contains the openid scope value. (If no openid scope value is present, the request may still be a valid OAuth 2.0 request, but is not an OpenID Connect request.)

Maybe the SIOPv2 spec could do something similar by replacing the MUST with a MAY still.

2. Presence of verifiable presentations

According to the implementer’s draft (Cross-Device Self-Issued ID Token Validation)

Further processing steps are required if the authentication response contains verifiable presentations - see [@!OIDC4VP].

This seems to imply that OIDC4VP must be implemented by any SIOP RP, since it is up to the OP to include additional claims in the response. What this line probably wanted to say is something like

Any claims in the authentication response are considered to be self-asserted. Verifying attestation by a third party requires additional processing steps - see e.g. [@!OIDC4VP].

‌

[Kristina Yasuda]

discussed at June 23 SIOP call - to do an editorial PR

[Kristina Yasuda]

for 2, I created PR #223.

For 1, I think it needs more discussion. the fact that SIOP ID token is differentiated from usual ID Tokens based on iss==sub remains even if OP has separate endpoints for SIOP and non-SIOP ID Tokens so I do not see why we would change MUST to MAY.

[Thomas Bellebaum]

One could rephrase the quoted statement from OIDCC to something like:

If both values differ, the ID Token is not self issued, but may still be a valid ID Token according to [@!OpenID.Core] if the OP supports attester signed ID Tokens.

@Kristina Would this address your concerns?

[Kristina Yasuda]

what is an “attested signed ID Token“? how is it different from usual ID Token (iss != sub) and self-issued ID Token (iss = sub)?

[Kristina Yasuda]

2. addressed in a PR.
3. already has a language in a SIOP spec's Self-Issued ID Token Validation section: To validate the ID Token received, the RP MUST do the following:
4. The Relying Party (RP) MUST determine whether the ID Token has been issued by the Self-Issued OP. The ID Token is self-issued if the iss claims and the sub claim have the same value. If both values differ, the ID Token MUST be processed as defined in [@!OpenID.Core], section 3.2.2.11.