Messages 2.1.2.1 - Clarify that "none" is not an acceptable signature algorithm
Issue #851
resolved
http://openid.net/specs/openid-connect-messages-1_0.html#id_token says:
ID Tokens MUST be signed using JWS [JWS] and OPTIONALLY both signed and then encrypted using JWS [JWS] and JWE [JWE] respectively, thereby providing authentication, integrity, non-repudiation, and optionally, confidentiality, per Section 9.13 (Signing and Encryption Order).
I was recently asked whether "none" was an acceptable algorithm to use for this signature. While obvious, I believe that we should explicitly rule it out in the final versions of the specifications.
Comments (5)
-
-
reporter
Messages currently requires Clients to validate the ID Token - saying "Clients MUST validate the ID Token per Section 4.2". John points out that we could relax this to allow clients to not check the signature in the same cases when Basic doesn't.
We would still need to require OPs to sign the ID token to allow Clients to check the signature that want to. Not doing so would currently be a breaking change to some clients.
-
I disagree.
How would that be a breaking change? If a client is currently configured/registered for RS/EC/HS signature, how would allowing none as a different option be a breaking change?
Our implementation currently does allow none as an option (it will only send such an ID Token via the back-channel). Which is, I'll argue, a perfectly reasonable interpretation of what's been written. So explicitly disallowing it is a breaking change for us.
-
reporter
-
assigned issue to
Michael Jones
To be consistent with Registration, and JWS/JWT, we will apply this correction.
If Brian wants to propose allowing non-integrity-protected ID Tokens, this could be filed as a separate issue for Final.
-
assigned issue to
-
reporter
- changed status to resolved
Fixed
#851- Clarified that "none" is not an acceptable ID Token signature algorithm.→ <<cset fa6d2e9a79b6>>
- Log in to comment
"none" seems like a perfectly reasonable option when the ID Token is received over TLS directly from the Token Endpoint at the AS.