Are unsigned id_tokens permitted in FAPI2 baseline?

[Joseph Heenan]

The table at the end of FAPI2 seems to imply that servers may issue unsigned id_tokens:

I’m not sure if this was intentional or not. (OpenID Connect Core does permit the issuing of unsigned id tokens from the token endpoint, i.e. relying on TLS for integrity protection of the id_token.)

The FAPI1-Adv certification tests require id_tokens to be signed in all cases. The FAPI1-Adv spec seems to require signed id_tokens (including from the token endpoint), possibly with the exception of response_type=code & scope containing openid.

If servers are permitted to issue unsigned id tokens, then we should probably add a test that clients can cope with unsigned id tokens.

However the certification programme has generally moved away from requiring an implementation to support unsigned JWTs (e.g. https://bitbucket.org/openid/connect/issues/1214/certification-remove-requirement-for-rp-to ) for the reasons given in https://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20200810/007880.html

I am not sure there’s really any benefit in allowing servers to issue unsigned id tokens, so in the spirit of FAPI reducing implementation choices I think it can be argued that requiring signed id tokens in all cases makes sense. (I can’t see a reason to require the RP to verify the signature, although FAPI1 does appear to require it in https://openid.net/specs/openid-financial-api-part-2-1_0.html#id-token-as-detached-signature-2 but I believe the RP tests don’t try issuing a badly signed id token from the token endpoint.)

‌

[Brian Campbell]

The section right before that differences table says “and the none algorithm shall not be used or accepted” which would imply that unsigned id_tokens are not permitted.

But FAPI 2.0 isn’t reliant on OIDC the way that FAPI 1.0 was. And testing OIDC stuff as part of FAPI 2.0 certification is a whole bigger can of worms. For FAPI2 baseline there shouldn’t be any.

That row in the table should probably be fixed up.

‌

‌

‌

[Joseph Heenan]

Thanks Brian. I had missed that clause. Phew.

But FAPI 2.0 isn’t reliant on OIDC the way that FAPI 1.0 was. And testing OIDC stuff as part of FAPI 2.0 certification is a whole bigger can of worms. For FAPI2 baseline there shouldn’t be any. 

I’m not sure I quite understand the final sentence there?

What we do re: testing OIDCC in FAPI2 certification I guess may need a working group discussion. Due to the way the tests/spec evolved support for OIDCC was considered mandatory for certification in FAPI1, even after the later spec versions made it optional at some point around when JARM was added as an option. (No tester has ever mentioned trying to certify a system that doesn’t support OIDCC.)

I think for FAPI2 the intent would be to allow the tests to run with or without OIDCC. This might then lead to separate certification columns for with/without OIDCC. It’s possibly not the preferable outcome, but unfortunately a FAPI2 compliant server can’t run the OIDCC tests and definitely can’t certify for OIDCC for multiple reasons (like the requirement in OIDCC certification to support client secrets, to allow non-PAR requests, etc).

That row in the table should probably be fixed up. 

Agreed.

‌

[Brian Campbell]

| For FAPI2 baseline there shouldn’t be any. 

I’m not sure I quite understand the final sentence there?

Sorry… What I think I was trying to say is that FAPI 2.0 Baseline Profile doesn’t rely on OIDC (other than the optional ‘if desired’ “Returning Authenticated User's Identifier” section and private_key_jwt client auth) so there needn’t/shouldn’t be OIDC stuff (openid scope / ID tokens) in the certification tests for the Baseline Profile.

But maybe you did understand and that was the point…

‌

[Joseph Heenan]

Thanks Brian! I wasn’t sure exactly what direction you were going so the clarification does help. I think it’s an important discussion, I’ve raised https://bitbucket.org/openid/fapi/issues/475/certification-fapi2-baseline-is-openid to make sure we get the working group’s feedback.

[Nat Sakimura]

Editorial.

[Joseph Heenan]

Remove mention of signing id_tokens in comparison table

As per earlier clauses, unsigned id tokens are not permitted (the 'none' alg is not allowed).

Note that the situation is that the id_token returned in the backchannel must be signed by the server, but as it is TLS protected the client is not required to verify the signature as per OpenID Connect core.

closes #470

→ <<cset 777a4063ad7a>>

[Dave Tonge]

Remove mention of signing id_tokens in comparison table

As per earlier clauses, unsigned id tokens are not permitted (the 'none' alg is not allowed).

Note that the situation is that the id_token returned in the backchannel must be signed by the server, but as it is TLS protected the client is not required to verify the signature as per OpenID Connect core.

closes #470

→ <<cset 625de048d92a>>