query over updating certification tests to allow unsigned id_tokens

[Joseph Heenan]

The certification team would appreciate guidance over a recent issue that was opened: https://gitlab.com/openid/conformance-suite/-/issues/1054

Essentially this is an OP that uses response_type=code and returns an unsigned (alg none) id_token from the token endpoint.

This is permitted by the OpenID Connect standard, but the java certification suite has never allowed it (not entirely as a conscious decision, nimbus-jose-jwt requires extra code to be written to opt into supporting alg none and that code had never been written). I’m not sure if the python suite had previously allowed this or not.

Given the various changes to the OIDCC certification tests that the WG has previously asked to be made around making supporting alg: none optional for RPs&OPs (various tickets linked from https://gitlab.com/openid/conformance-suite/-/issues/878 ) it seemed best for us to check with the WG before allowing alg: none in this case.

If we were to allow alg: none here, I’d imagine we should make the test go to ‘WARNING’ status (which still permits certification) with a message saying something like that any use of alg:none is considered to be a well known cause of security vulnerabilities and is known to not be interoperable.

(As per the gitlab issue, we’d also need to support OPs that don’t have a jwks_uri, but that seems less controversial than the above.)

‌

[Takahiko Kawasaki]

FYI: It was on May 28, 2015 that a PR to add support of the none alg to the Nimbus JOSE+JWT library was declined. → nimbus-jose-jwt PR 19

[Takahiko Kawasaki]

There are two facts that conflict with each other. One is that we cannot update the OIDC Core specification even if we find critical security issues in it because the specification has been finalized. The other is that implementations that issue ID tokens with "alg":"none" should not get certified for security reasons.

Solutions that come up quickly are as follows:

1. Create OIDC Core 1.1 or a supplementary specification.
2. Define a special rule that allows the conformance suite to add extra requirements for security and/or implementation reasons.

‌

[Filip Skokan]

The certification profiles already promote optional core features to required for the sake of interoperability of the profile. Not allowing such certification would just be doing the same in the opposite direction.

If the OP only issues none signed tokens I’d say it’s not interoperable with the RPs certified for the same Basic profile.

[Filip Skokan]

on the note of certification profiles, https://openid.net/wordpress-content/uploads/2018/06/OpenID-Connect-Conformance-Profiles.pdf requires an update, it still refers to the python certification suite test names and the matrix is really confusing, e.g. what does y if uses none on OP-IDToken-none mean?

[Joseph Heenan]

Filip drew my attention to another clause in https://openid.net/specs/openid-connect-core-1_0.html#IDToken :

ID Tokens MUST NOT use none as the alg value unless the Response Type used returns no ID Token from the Authorization Endpoint (such as when using the Authorization Code Flow) and the Client explicitly requested the use of none at Registration time.

This makes me think the certification tests are correct to insist that an alg other than none is supported by the OP.

[Joseph Heenan]

Actually that text is probably overridden by https://openid.net/specs/openid-connect-core-1_0.html#ServerMTI :

OPs MUST support signing ID Tokens with the RSA SHA-256 algorithm (an alg value of RS256), unless the OP only supports returning ID Tokens from the Token Endpoint (as is the case for the Authorization Code Flow) and only allows Clients to register specifyingnone as the requested ID Token signing algorithm.

‌

[Michael Jones]

https://openid.net/specs/openid-connect-basic-1_0.html explicitly says for basic clients to use alg:none for ID Tokens. The certification suite should support this.

[John Bradley]

We discussed it on the call.

The reality is that clients conforming to the basic profile are not required to support none in the certification tests.

Changing the server side to allow a server to only support none would not help interoperability, and in fact hurt it.

A server can still support only none under the constraints in the spec and be conformant, but we should not create a new certification profile to support that as it will lead to non interoperable servers in the market marked as OpenID Certified.

‌

‌

[Michael Jones]

Joseph, please close this once you’ve communicated the working group’s decision to the requesting party and closed https://gitlab.com/openid/conformance-suite/-/issues/1054.

[Joseph Heenan]

Thanks Mike - I’ve done both and hence am closing this.