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 Baseline is hoped to be almost as secure as FAPI 1.0 Advanced while significantly simpler to implement. Also, FAPI 2.0 has greater scope than FAPI 1.0. We are hoping FAPI 2.0 Suite to be simpler, more elegant, more feature-rich, and more interoperable than FAPI 1.0. The catch is that FAPI 2.0 still is not formally verified, does not have a certification test suite, and is still changing. 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 from many current best practices and existing specifications. A FAPI 1.0 Advanced deployment that uses PAR & PKCE is likely to be conformant with FAPI 2.0 baseline.
This table compares the two sets of specifications:
|FAPI 1.0||FAPI 2.0|
|Status||FINAL||Baseline: Implementer’s 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.
Baseline is an Implementer’s draft and Advanced 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.||No. However, as it is created with formal verification in mind, it probably will be easier to formally verify than FAPI 1.0 Advanced.|
|Is a certification/conformance test suite available?||Yes.||No.|
|Is it being used?||Advanced: Yes. UK, AU, BR Banking sectors, etc.
|Not yet. It is only at the first 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.
Advanced is quite well adopted but may contain more features needed for many cases.
Baseline 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.
|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.||Limited as of Dec, 2021.|
|Backward compatibility with FAPI 1.0?||–||No, although some deployments of FAPI 1.0 Advanced may be compatible with FAPI 2.0 baseline.|
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 has been formally verified. At the same time, we also encourage people interested in FAPI 2.0 development to participate in the working group.
 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. It is hoped to be significantly easier to formally verify than FAPI 1.0 due to this explicitness.
[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)
OpenID Foundation Chairman