is response_type=code id_token permitted in FAPI2 Baseline?

[Joseph Heenan]

Are servers allowed to support response_type=code id_token when FAPI2 Baseline is in use?

My initial thought is that they probably shouldn’t, as it would result in an id_token being leaked in the front channel, and I can’t think of any reason it should be permitted.

However I’m not sure if there’s a spec clause that disallows it. Possibly this one might:

shall reject requests using the resource owner password credentials grant or the implicit grant described in [RFC6749]

as the hybrid flow is a form of implicit grant (according to https://openid.net/specs/openid-connect-registration-1_0.html#ClientMetadata ). But if so perhaps it could be a bit clearer.

‌

[Nat Sakimura]

Daniel pointed out that nonce in the ID Token may leak so that it may not be a good idea to return ID Token in the front channel and do ID Token injection.

Brian pointed out that there could be some ramification to the Advance profile although nonce check is not mandated at AS.

Ralph pointed out that because we are using PAR, it should not be a problem while disallowing it may impact the migration strategy from FAPI 1.0 to FAPI 2.0.

[Joseph Heenan]

This was discussed on today’s call.

The position isn’t clear.

We may need the formal security analysis before knowing if this is okay or not. Daniel was potentially concerned with it meaning nonce is leaked in the front channel (although comparing to FAPI1Adv, nonce is always leaked there).

FAPI2Adv ( https://bitbucket.org/openid/fapi/src/master/FAPI_2_0_Advanced_Profile.md ) explicitly says:

may support OpenID Connect [@!OIDC] ID Tokens as detached signatures for backward compatibility with existing implementations

so disallowing this in FAPI1Baseline is potentially problematic.

‌

[Joseph Heenan]

Suggest approach for FAPI2Baseline:

At least for next implementer’s draft, only allow response_type=code

‌

And for FAPI2Adv, remove text about backwards compatibility, as existing FAPI1Adv implementors can switch to JARM before moving to FAPI2Adv.

[Dave Tonge]

https://bitbucket.org/openid/fapi/pull-requests/311/remove-support-for-hybrid-flow

[Dave Tonge]

PR merged