读/写API旨在提供对PSU（最终用户）帐户的非常特定的粒度控制访问，对于任何级别的访问，TPP都需要创建一个“同意”，并要求最终用户直接通过其银行进行批准。
请注意，同意是由TPP定义的，因此，在授权TPP查询数据之前，aspsp必须向用户提供有关访问请求的简明信息。Open Banking规范为用户界面提供了指导方针，以使每个银行的用户体验尽可能简洁明了。
下图显示了帐户和事务API (AISP)的用户旅程，同样的用户流也应用于PISP和CBPII。
AISP用户流程
1. 终端用户希望在资金管理应用程序中显示其帐户余额；
2. TPP应用程序将用户重定向到其银行以授权特定的访问请求，用户登录到其在线银行帐户并确认TPP应用程序可以访问帐户余额，授权视图包含确切的访问请求以及TPP将有权访问数据的时间；
3. 用户被重定向回具有TPP查询数据授权的TPP应用程序；
然后，TPP应用程序可以连接到帐户余额的各个Open Banking AISP终端，并在TPP应用程序中显示信息，直到访问请求到期。
上图显示了用户流程的简化视图，下一节将详细介绍有关用户流程和测试读/写API的挑战的技术细节。此外，研究人员将讨论研究人员的Open Banking测试工具。
测试读/写API
当查看上面的用户流程图时，用户流程的复杂性不是立即显而易见的。Open Banking涉及三个参与者,而不是通常的客户机/服务器模型，并利用各种技术，如用户重定向，交互TLS，消息签名以及PSU的手动身份验证和授权，所有这些使自动化测试比常规的Web服务评估更加复杂。
接下来，研究人员将首先描述技术工作流，然后提供有关所涉及技术的更多信息。本文介绍的知识可用于测试TPP和ASPSP。然而，当测试一个ASPSP的读/写API实现时，就需要覆盖更多的用户工作流。
技术工作流程
在测试ASPSP的读/写API时，需要同时考虑PSU和TPP的角色。因此，测试人员需要：
· 配置和测试交互TLS；
· 向ASPSP的OAuth端点进行身份验证；
· 调用相应的读/写API以创建同意并执行授权的操作；
· 生成从TPP到ASPSP的重定向；
· 向ASPSP认证为PSU，以授权访问请求（同意）；
· 处理来自ASPSP的重定向（回调）；
· 根据Open Banking规范实现和配置消息签名。
下图显示了终端用户通过Open Banking进行国内支付的一个示例序列。灰色区域突出了TPP和ASPSP之间的交互TLS联系，蓝色区域标记了TPP需要消息签名的请求。
PISP国内支付顺序
可以在Open Banking规范中找到每个版本和组件的更详细的序列图，例如，读/写版本3.1.2 – PISP。
交互TLS
Open Banking生态系统中的注册机构有两套证书，用于传输和消息签名。Open Banking安全配置文件定义到读/写API的连接需要使用交互身份验证的TLS (MTLS)进行保护，MTLS连接使用传输证书处理。
OAUTH
在一个TPP可以向ASPSP的读/写API发出请求之前，它们需要使用OAuth终端进行身份验证。这在图2中被注释为“pre-auth OAuth token”，用于创建不需要用户授权的同意和其他请求。
对于其他终端，不同的OAuth令牌需要与授权代码一起生成，授权代码包含在从ASPSP重定向到TPP同意授权后。这将在“重定向”部分中进一步解释。
有关Open Banking的OAuth的更多信息，请参考。每个ASPSP的具体信息可以在Open Banking规范的实现指南中找到，或者通过ASPSP的开发人员门户找到。
消息签名
除了交互TLS之外，Open Banking规范还将消息签名定义为一种附加措施，以确保不可拒绝来自TPP和ASPSP的特定敏感API终端。
Open Banking签名算法规定了一个符合RFC 7515（关键标头）和RFC 7797（未编码/分离的有效负载）的库。在撰写本文时，Brian Campbell的Jose4J Java库是同时符合上述两个RFC的少数几个库之一，这可能会将消息签名算法的实现限制为具有兼容库的编程语言。下面的代码片段是使用Jose4J进行Open Banking消息签名的示例：
重要功能以黄色突出显示：
· 禁用Base64编码(第25行)；
· 设置关键标头(第16、17和29行)；
· 生成一个分离的JWS和所需的声明(第31行)。