FAPI工作组是OpenID基金会的一个工作组。FAPI以前被称为金融级API，但工作组一致同意将其名称更新为FAPI，以反映该规范适用于许多需要更安全的模型而不仅仅是金融服务的高价值用途。

该小组有来自身份和访问管理部门的专家成员。该工作组最初成立的目的是帮助开发金融API的安全配置文件和API标准。随着时间的推移，该集团将重点放在安全配置文件上，这些安全配置文件虽然适用于金融API，但也可以用于其他行业和生态系统。

工作组开发的安全配置文件基于OAuth 2.0和OpenID Connect标准套件。OAuth 2.0是一个授权框架，可用于低值和高值操作。FAPI工作组制定的标准比一般OAuth 2.0框架包含的可选性少得多，并且要求实现者使用现代安全最佳实践。

FAPI规范的主要优点是：

1. 清晰的逐点规范，实现者可以将其用作“检查列表”
2. 详尽的一致性测试，允许实现者确保其软件的安全性和互操作性
3. 基于标准的方法来保护复杂交互（例如，通过CIBA解耦的authZ流、授权管理、推送请求对象）。

FAPI工作组不负责财务或其他API的数据模型或标准。这些是特定于生态系统的。

请参考规范性变更文件：https://bitbucket.org/openid/fapi/src/master/fapi_1.0/changes-between-id2-and-final.md 

FAPI 2.0的范围比FAPI 1.0更广。它旨在实现客户端和授权服务器之间接口的完全互操作，以及客户端和资源服务器之间接口上的互操作安全机制。

因此，除了FAPI 1.0中已经定义的机制外，FAPI 2.0还提供了获得API访问细粒度和事务授权的机制，以及在两个接口上进行重放检测和不可否认的安全机制，这些机制侧重于授权流的安全性。

工作组还根据对各种开放银行实现的分析结果、最新的OAuth安全BCP的建议以及全面的安全威胁模型，开发人员更容易使用该配置文件。

FAPI 1.0和FAPI 2.0都定义了两个符合性级别，但FAPI 2.0级别与不同的保护级别（基线与高级）相一致，而不是与FAPI 1.0中的API访问模式（读与读写）相一致。基线级别旨在针对安全威胁模型中捕获的所有威胁提供安全保护，高级级别添加了不可抵赖性。

FAPI 2.0提供了更高程度的互操作性，更易于使用，同时保持了可比较的安全级别。FAPI 2.0旨在兼容实现之间的在线兼容性，并为此删除了可选和替代功能。

规范正在制定中，目前处于“草案”状态。

OpenID Foundation规范开发过程涉及发布一个（或多个）具有公共审查期并经成员批准的实施者草稿，然后发布另一个审查期/投票“最终”状态。

对于FAPI 1.0，日期为：

第一实施者草案：2017年7月
第二份实施者草案：2018年10月
启动一致性测试：2019年4月
最终日期：2021年3月

工作组打算以更快的速度推进FAPI 2.0。

非常欢迎您加入工作组并提出更改建议。

提交知识产权协议后，任何人都可以加入工作组并对规范作出贡献。

FAPI 2.0一致性测试于2023年3月启动。第一套FAPI 2.0自我认证已经发布，现在可以在认证列表.

我们祝贺Authlete、Cloudentity、ConnectID、Ping Identity和Raidiam遵守了当前的FAPI 2.0认证，并成为这项重要工作的思想领袖。我们感谢澳大利亚的ConnectID，他们在生态系统中采用了FAPI 2.0，并为FAPI 2.0一致性测试套件开发提供了资金。

以下是一些实施FAPI 1.0的生态系统示例：

这个财务数据交换还与FAPI工作组密切合作，在北美实施规范。

以下是FAPI 1.0认证实施的列表：https://openid.net/认证

FAPI 2.0作为OAuth概要文件，利用了现有实现中可用的或可以在现有实现之上实现的OAuth特性和扩展。

具体如下：

• PKCE–https://tools.ietf.org/html/rfc7636
  • 供应商已经广泛支持这种安全机制。
• mTLS–https://datatracker.ietf.org/doc/rfc8705/
  • OAuth Security BCP也推荐了一种用于客户端身份验证和访问令牌发送方约束的标准。
• DPoP–https://tools.ietf.org/html/draft-ietf-oauth-dpop-02
  • 应用层的发送方约束访问令牌标准
• 推送授权请求–https://tools.ietf.org/html/draft-ietf-oauth-par
  • IETF规范等待发布
  • 开源项目和商业供应商广泛采用
• 丰富授权请求（RAR）–https://tools.ietf.org/html/draft-ietf-oauth-rar
  • RAR可以作为扩展参数在OAuth 2.0实现之上实现。现有实施证明了其可行性。
• 授权响应中的授权服务器颁发者标识符
  • https://tools.ietf.org/html/draft-ietf-oauth-iss-auth-resp
  • 可以在现有OAuth 2.0实现之上实现。

工作组获悉，以下组织已实施FAPI 2：

• 是的QES方案签名API（由三个不同的授权服务器实现），使用PKCE、mTLS、PAR、RAR、iss授权响应参数
• Authlete：支持PKCE、mTLS、PAR、RAR和iss响应参数。

工作组并不认可这些组织或其产品，我们只是报告我们收到的信息。

FAPI 1.0和FAPI 2.0之间有相似之处（例如，FAPI 1.0/read和FAPI 2.0/baseline中的响应类型代码+PKCE），但范围不同，因此没有完全的向后兼容性。

制定2.0草案的原因不是因为规范比1.0更安全，而是FAPI 2.0的目标是：

• 实现更简单（在不降低安全性的情况下对消息签名的要求更少），
• 更具互操作性（通过减少可选性），
• 更接近OAuth安全BCP，
• 范围更广–涵盖细粒度和事务授权，这超出了FAPI 1.0的范围。

关于安全性，已经使用深入的形式分析对FAPI 1.0进行了分析。FAPI 2.0提供了一个定义更明确的攻击者模型，目的是使标准更容易接受这种分析，并使规范中与安全相关的决策更加透明。

值得注意的是，FAPI 2.0 Baseline旨在防范与FAPI 1.0 Advanced类似的攻击者模型。FAPI 2.0 Advanced通过将“不可否认性”引入所有交易所，进一步扩展了FAPI 1.0的范围。此表给出了一个粗略的比较：

1.0规范的最终版本于2021年3月发布。

最终规范是一个经过多轮审查的规范，由许多行业专家进行审查，并有多个实时实现。

采用1.0或2.0是有正当理由的。

• 如果生态系统中的供应商已经支持FAPI 1.0，这可能是使用它的一个有效理由。
• 如果生态系统已经在使用OpenID Connect进行身份声明，那么使用FAPI 1.0可能会更加困难。
• FAPI 1.0是一个成熟且广受支持的安全配置文件。
• FAPI 2.0要求较少使用消息签名，这可能会使其更容易实现（尤其是对于客户端）。
• FAPI 1.0不涵盖复杂的授权请求和授予生命周期管理，因此您可能需要实现自定义解决方案。FAPI 2.0涵盖了这些方面。尽管规范仍在开发中，但它们已经代表了工作组和其他实施此类解决方案的人员收集的经验。

出于与上述答案相同的原因，这是一个特定于生态系统的决定。

是的，如果FAPI 1.0存在任何安全问题或主要互操作性问题，工作组可能会更新FAPI 1.0规范。然而，这些规范已经在多个生态系统的生产中使用了一段时间，因此工作组预计FAPI 1.0不会有太多（如果有的话）更改。

没有计划向FAPI 1.0添加新功能。

这可能是可行的。FAPI 1.0 Advanced允许使用PAR和PKCE。这些都是FAPI 2.0所要求的。

FAPI和OpenID Connect认证是正交的。为了通过OpenID Connect认证，服务器必须支持各种较低安全性的方法（如客户端身份验证的client_secret_basic），这些方法通常在符合FAPI的服务器中不启用。

对。丹尼尔·费特领导的FAPI 1.0分析发现https://arxiv.org/pdf/190.11520.pdf