optional ID Token signature validation for code flow
This issue calls for clarification on inheriting optional response_type=code
OIDC behaviour which allows the client to omit verifying the ID Token signature.
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.
Both FAPI 2.0 and FAPI 1.0 (only when using response_type=code and JARM) are in question here.
Having checked FAPI 2.0, 1.0 Baseline and 1.0 Advanced I have not found a statement which would further profile client behaviour to require verifying these signatures.
Comments (12)
-
-
Ah, it was very briefly discussed in https://bitbucket.org/openid/fapi/issues/490/request-for-suggestions-for-tests-for without reaching a conclusion/consensus.
-
reporter - changed component to FAPI2: Baseline
-
reporter - edited description
-
reporter On last week’s call we’ve explored this and in order to decide we need the information (@Daniel Fett offered to collect it) about whether the signature validation step is part of the security analysis mathematical model and whether it in any way shape or form affects the outcome.
-
Thanks for the reminder! The signature validation will be considered optional in the analysis.
-
reporter - edited description
-
reporter - edited description
-
Thanks all.
So given the various confirmations, I’ve raised https://gitlab.com/openid/conformance-suite/-/issues/1114 so we make sure the conformance tests are correct in this regard.
I think we can close this ticket.
-
- changed status to open
We will wait for the analysis result to come out. If it is found that verification is needed, then we will add text.
-
- changed status to resolved
Security analysis concluded that ID Token signature verification is not required if it is received within a correct TLS session.
-
- changed component to FAPI2: Security Profile
- Log in to comment
My notes for FAPI2 RP certification tests says “Remove various tests that return invalid frontchannel id_tokens, as there isn't one in FAPI2 (under discussion with FAPI WG; we may want to have these checks used for backchannel id token instead)”.
Unfortunately I don’t appear to have made any note of where/how it was under discussion, and I can’t find anything relevant in the issue tracker. I know I made that note on 10th April this year.