Should JARM be mandated for code flow with PAR and PKCE?

[Dima Postnikov]

FAPI 1 Advanced currently:

• allows PAR (MAY),
• use of PAR mandates PKCE (SHALL)
• allows to use code flow

shall require

the response_type value code id_token, or

the response_type value code in conjunction with the response_mode value jwt;

• use of code flow mandates JARM

In addition, if the response_type value code is used in conjunction with the response_mode value jwt, the authorization server

shall create JWT-secured authorization responses as specified in JARM, Section 4.3.

Is there a need to mandate JARM if code flow is used with PAR and PKCE? This requirement didn’t seem to come from the attacker model.

May be JARM requirement can be relaxed?

Thoughts?

‌

[Joseph Heenan]

In FAPI2, the iss draft is required:

https://bitbucket.org/openid/fapi/annotate/master/FAPI_2_0_Baseline_Profile.md?at=master#FAPI_2_0_Baseline_Profile.md-161

Removing JARM (without replacing it with something) would I believe open FAPI1 to the mixup attack described in the iss draft.

[Dima Postnikov]

The justification for not using JARM was that authorization response doesn’t require additional protection if authorisation response only contains ‘code' and it’s protected by PKCE already.

Now, to protect against AS mixup attack we would use iss draft instead of JARM.

And this would introduce another parameter to the authorization response and the need to protected with JARM?!

Right? @Daniel Fett @Joseph Heenan

[Daniel Fett]

The ‘iss’ parameter is an exception: ‘iss’ provides its security in any case only when the response comes directly from an uncompromised AS and was not modified in between (i.e., attacker cannot modify authorization response). If the attacker can read/modify the authz response, ‘iss’ is not needed, as an attacker does not need to execute a mix-up attack in that case (just reading the code from the authz response is easier).

Therefore, I think leaving code+iss without JARM protection should be fine.

[Dima Postnikov]

We’ve discussed it on a call today:

• The spec is final and it is not going to change: JARM has to be supported for code flow.
• In order to facilitate broader vendor support FAPI WG will progress JARM specification to FINAL as soon as practical.
• FAPI WG will make a decision wether JARM is required for FAPI 2.
• Potentially, FAPI WG will produce advice on migration from FAPI 1 to FAPI 2.

‌

[Brian Campbell]

For better or worse, FAPI 1.0 baseline and advanced have been finalized https://openid.net/2021/03/16/standards-adoption-and-the-adoption-of-standards-financial-grade-api-fapi-1-0-final-specifications-published/ and making a change to a finalized standard is not something that should be undertaken lightly.

‌

[Daniel Fett]

Can this be closed then?

[Dima Postnikov]

the spec is final. change is harder.

[Dima Postnikov]

@Nat Sakimura @Anoop Saxena @Edmund Jay JARM is a part of AU transition to FAPI 1 and use of code flow.