[Openid-specs-ab] Issue #1536: Self-Issued ID Token Validation subtleties (openid/connect)

[Thomas Bellebaum]

New issue 1536: Self-Issued ID Token Validation subtleties
https://bitbucket.org/openid/connect/issues/1536/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\].

‌