Last updated: February 2023.
In one paragraph, FAPI 1.0 Advanced is secure, stable, and complete Final Specification with a certification test suite while FAPI 2.0 is still in development so new features can be incorporated. FAPI 2.0 Security Profile has been through a formal security analysis in the same way as FAPI 1.0 Advanced, but is significantly simpler to implement. Also, FAPI 2.0 has greater scope than FAPI 1.0. We are hoping the FAPI 2.0 Suite will be simpler, more elegant, more feature-rich, and more interoperable than FAPI 1.0. The catch is that FAPI 2.0 does not have a certification test suite, and may still change. The last point can be a blessing as well – if you have a new feature request that FAPI 1.0 cannot fulfill, you should come to the FAPI working group to participate in FAPI 2.0 development.
While FAPI 2.0 is not a final specification, it is built upon many current best practices and existing specifications. A FAPI 1.0 Advanced deployment that uses PAR & JARM is likely to be conformant with FAPI 2.0 Security Profile when used with signed requests as per FAPI 2.0 Message Signing.
This table compares the two sets of specifications:
|FAPI 1.0||FAPI 2.0|
|Status||FINAL||Security Profile: Second Implementer’s draft|
Message Signing: Draft
|Development Period||2016 – 2021||2020 –|
|Design principles.||Based on BCM principles.|
All messages are integrity protected (message authentication) and all senders are strongly authenticated (client authentication) etc.
|Based on the explicit attacker model .|
Message authentication requirements are relaxed so to make it simpler to implement while hopefully not exposing it to threats.
|Will it change?||No.|
It is FINAL and set in stone.
Security Profile is an Implementer’s draft and Message Signing is still a working draft.
|Are new features possible?||Only in extensions. FAPI 1.0 Baseline and Advanced are FINAL and cannot be changed.||Yes.|
It is still in development.
|Formally Verified for security?||Yes for FAPI 1.0 Advanced.||Yes for FAPI 2.0 Security Profile.|
|Is a certification/conformance test suite available?||Yes.||Yes (in beta)|
|Is it being used?||Advanced: Yes. UK, AU, BR, KSA Banking sectors, etc.|
|There is at least one ecosystem live using an implementer’s draft of FAPI2, and several ecosystems have indicated they intend to adopt it. It is at the Second Implementer’s Draft and people are implementing it to test it out right now.|
Baseline is probably undersized and is mostly not being used, while it is quite simple to implement. A formal security analysis has not been performed for baseline and there are no certification/conformance tests.
Advanced is quite well adopted but may contain more features needed for many cases.
Security Profile is incorporating some of the essential features from FAPI 1.0 Advanced. While it is enjoying the good part of the most wanted features of FAPI 1.0 Advanced, it is significantly simpler to implement.
|Is PAR (RFC9126) Required||No.|
It is optional.
It is better for interoperability and security/privacy.
|Can it be used with the Grant Management spec?||Yes.||Yes and will be optimized since it is being developed together with it.|
|Can it be used with CIBA?||Yes.||Yes and will be optimized since it is being developed together with it.|
|“Non-repudiation” of the resource response.||Limited.||Comprehensive.|
|Vendor support.||Quite well supported.||Several vendors have full FAPI2 support as of Feb, 2023.|
|Backward compatibility with FAPI 1.0?||–||No, although some deployments of FAPI 1.0 Advanced may be compatible with FAPI 2.0 Message Signing.|
The ‘Main Differences to FAPI 1.0’ section of FAPI2 Security Profile contains further technical details.
Recommendation for Deployers
In short, the FAPI working group recommends that deployments being specified at present use FAPI 1.0 Advanced, since it is Final and well supported. At the same time, we also encourage people interested in FAPI 2.0 development to participate in the working group and to consider it for ecosystems launching in the future.
Ecosystems should consider mandating the use of the PAR (Pushed Authorization Requests) option when using FAPI 1.0 Advanced, as this will enable an easier transition to FAPI 2.0.
 BCM principles is a summary version of the recommendation by the seminal paper by Basin, Cramers, and Meier: Provably Repairing the ISO/IEC 9798 Standard for Entity Authentication [BCM2013].
P1 Positional tagging. Cryptographic message components should contain information that uniquely identities their origin. In particular, the information should identify the protocol, the protocol variant, the message number, and the particular position within the message, from which the component was sent.
P2 Inclusion of identities and their roles. Each cryptographic message component should include information about the identities of all the agents involved in the protocol run and their roles unless there is a compelling reason to do otherwise.
 FAPI 2.0 Attacker Model is available from https://bitbucket.org/openid/fapi/src/master/FAPI_2_0_Attacker_Model.md.
[BCM2013] Basin, D., Cremers, C., Meier, S.: Provably Repairing the ISO/IEC 9798
Standard for Entity Authentication. Journal of Computer Security – Security and Trust Principles Archive Volume 21 Issue 6, 817-846 (2013)