JARM+FAPI-RW+openid client session binding

[Joseph Heenan]

I think there’s an odd interaction with JARM and the FAPI-R spec which doesn’t entirely make sense to me. When you’re using FAPI-R+openid+jarm, FAPI-R requires that clients send nonce. However nonce isn’t part of the JARM response, so there’s actually nothing binding the JARM response to the client session .

FAPI-RW also specifically excludes this situation from requiring support/use of PKCE. https://openid.net/specs/openid-financial-api-part-2-wd-05.html#authorization-server :

shall require [RFC7636] with S256 as the code challenge method for public clients only, if it supports public clients;

(that clause is somewhat odd anyway as FAPI-RW no longer allows public clients)

[Filip Skokan]

I agree that this doesn’t make sense with JARM in the picture. I think the language should be made more generic. Something along the lines of the following:

nonce is REQUIRED and state OPTIONAL if the authorization request results in an ID Token being issued by the authorization endpoint, otherwise state is REQUIRED and nonce OPTIONAL.

In the JARM FAPI Test suite variant this would mean that fapi-rw-id2-ensure-authorization-request-without-state-success needs to be skipped.

[Joseph Heenan]

Discussed on today’s FAPI WG call. Requiring state would work, but it requires the client to make the check, and poor client implementations often don’t make such checks. There seemed to be a consensus on the FAPI WG call that it would be better to require PKCE instead, which aligns with the OAuth security BCP.

[Filip Skokan]

Does this mean an update to part 1 and part 2 will be made?

[Joseph Heenan]

Yes, I’ll be preparing a pull request to modify the specs.

[Torsten Lodderstedt]

nonce, in the same way as state, relies on enforcement by the client.

If the group is in favour of AS/OP enforced methods (which I 100% agree with), then we should consider to make PKCE the default in FAPI. It works fine for R (OAuth & OIDC) and R+W (OAuth & OIDC with response type “code” & JARM). OIDC RPs could still use nonce if they want as an alternative.

The only use case where the OIDC RPs MUST use nonce is FAPI R+W (w/ ID Token as detached signature) since detecting id token injection in the response type “code id_token” relies on the RP to check the nonce. One could get rid of this by first checking the code using PKCE at the token endpoint and then checking the corresponding c_hash in the ID Token but I assume that a too disruptive change .

[Dave Tonge]

Agreed that this would be solved by requiring PKCE - but this is for v2