[Openid-specs-fapi] Issue #470: Are unsigned id_tokens permitted in FAPI2 baseline? (openid/fapi)

[josephheenan]

New issue 470: Are unsigned id_tokens permitted in FAPI2 baseline?
https://bitbucket.org/openid/fapi/issues/470/are-unsigned-id_tokens-permitted-in-fapi2

Joseph Heenan:

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

![](https://bitbucket.org/repo/K7gLBb/images/2268237440-Screenshot%202022-02-04%20at%2017.27.07.png)
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](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](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 though.\)

‌