id_token signature validation
https://openid.net/specs/openid-connect-federation-1_0-23.html#section-10.4 is potentially ambiguous as to whether the id token signature must be validated or not:
The RP MUST validate any ID token as defined in Section 3.1.3.7. of OpenID Connect Core 1.0 [OpenID.Core]. If the trust relationship between RP and OP was established using OpenID Connect Federation, the key material used for ID Token signature validation MUST be obtained from the OP's metadata the RP obtained as a result of Trust Chain validation as defined in Section 8 and combining the metadata policies from the Entity Statements of the Trust Chain as described in Section 5.1.
It kind of seems to say you must validate the signature, whereas 3.1.3.7 of OIDC makes validation optional for the client (“If the ID Token is received via direct communication between the Client and the Token Endpoint (which it is in this flow), the TLS server validation MAY be used to validate the issuer in place of checking the token signature.”).
It should be made clear which is intended. If intended to align with OIDC, I suggest changing “If the trust relationship…” to “If the ID token signature is to be validated and the trust relationship…”.
Comments (8)
-
reporter -
We need to discuss whether it was an intentional change from Connect to always validate the ID Token.
We also need to be clear that flows other than the Code flow can be used.
-
- changed status to open
@Roland Hedberg - was it intentional that we always require ID Token validation when Connect Core does not when the ID Token is delivered to the Token Endpoint using TLS?
-
If it’s an intentional requirement then the none value in id_token_signing_alg_values_supported must be never allowed.
-
I’d be for the removal of this section related to ID Token, it would be simpler if Federation 1.0 would be avulse to this kind of operations related to OIDC Core, OAuth2 and so on
-
This PR closes this issue
https://bitbucket.org/openid/connect/pull-requests/322/fix-federation-id-token-section-removedthank you
-
-
assigned issue to
-
assigned issue to
-
- changed status to resolved
- Log in to comment
Referencing 3.1.3.7 explicitly is perhaps wrong too, it implies only response_type=code is in use and I can’t obviously see anything in federation that says you must use that response_type.