More than 5 years have passed since last update.

The Open Banking Standard, 7c. Security の解説

Last updated at 2016-07-29Posted at 2016-03-28

はじめに

英国の Open Data Institute という団体が Open Banking Standard というレポートを 2016 年 2 月 8 日に公開しました。大雑把に紹介すると「英国の金融業界 Web API 化への指針を示した文書」となりますが、より詳しい紹介はマネーフォワード社の公式ブログにある「ODIによる銀行のオープンスタンダード」というエントリーを参照していただければと思います。

このレポートは、金融業界の方々が目を通したほうがよい文書ではありますが、「7c. Security」(41 ～ 54 ページ) の内容は、技術的な背景知識を持っていないと読むのが難しいので、この記事で少し解説しようと思います。

^{(背景事情：当レポートの読み合わせを行う「銀行オープンスタンダード勉強会」へのお誘いを受けたので、資料を準備している次第です。)}

注意：この記事はまだ完成していません。 (2016/3/29)
「7c. 9.3 Requirements of the Open Banking API」～「7c. 11. Approach to Open Data」 (51 ～ 54 ページ) をまだ言及できていません。

1. 全般

OAuth 2.0 (RFC 6749) を前提に文書が書かれています。

OAuth 2.0 は、「ユーザーが、クライアントアプリケーションに、自分の ID とパスワードをクライアントアプリケーションに渡すことなく、自分のデータにアクセスする権限を与える」手順を標準化したものです。簡単に言うと、認可の手順を標準化したものです。

銀行 API の文脈でいうと、ユーザーというのは、銀行にアカウントを持っているユーザーを指します。また、クライアントアプリケーションは、銀行 API を利用するアプリケーションを指します。ユーザーがアプリケーションに自分の銀行アカウントの ID とパスワードを直接渡してしまうと、アプリケーションが自分に成り代わって何でもできてしまうので、セキュリティー的によろしくありません。そこで、クライアントアプリケーションに ID とパスワードを渡すことを避けつつ銀行 API を利用する方法として、OAuth 2.0 が推奨されています。この仕組みを実現するためには、銀行は OAuth 2.0 の仕組みを用意する必要があります。技術用語を使って表現すると、「認可サーバーを用意する必要がある」ということになります。

なお、文書中で「データ属性提供者 (data attribute provider)」や「第三者 (third-party)」という言葉が使われていますが、それぞれ、「銀行」と「クライアントアプリケーション」を指しています。また、「顧客 (customer)」という語でユーザーを指している箇所もあります。

2. 認可

「7c. 2.4 Authorisation」では、タイトルの通り認可の話をしています。余談ですが、イギリス英語なので、綴りが「authorization」ではなく「authorisation」になっています。

このセクションは次のような文で始まります。

Once a customer has authenticated with their data attribute provider tokens should be used to ensure the third party is acting within the bounds of the permissions granted.

この文を文字通り訳すと、このようになります。

データ属性提供者による顧客認証後、第三者の行動が付与された権限の範囲に限定されることを保証するため、トークンを使うべきである。

日本語訳しても、何を言いたいのかさっぱり分かりませんね。しかし、OAuth 2.0 の知識があれば、この文が次のような手順を想定していることを読み取ることができます。

	手順
1	ユーザー（顧客）がクライアントアプリケーション（第三者）に認可を与えるのに先立ち、まず、銀行（データ属性提供者）がユーザーの認証をおこなう。
2	その認証後、ユーザーは、クライアントアプリケーションが要求している権限を確認し、クライアントアプリケーションに対して認可を与える。
3	認可が与えられた証拠として、銀行の認可サーバーは、クライアントアプリケーションに対してアクセストークン（トークン）を発行する。
4	クライアントアプリケーションは、銀行 API を利用するときに、アクセストークンを提示する。
5	銀行 API 側は、アクセストークンを調べることで、当該クライアントアプリケーションにどのような権限が与えられているかを知ることができる。
6	銀行 API 側は、その権限で許されている範囲内でクライアントアプリケーションに応答する。

図にすると分かりやすくなります。

上記に示した認可手順の大枠を理解できれば、残る項目の理解は難しくありません。

2.1. 権限

「7c. 2.4 Authorisation」では、権限 (permission) について次のような点に留意することを推奨しています。

	推奨事項
1	認可を与えたユーザー本人および場合によっては銀行による認可の取り消し Granting users and, in certain instances the data attribute provider revocation rights
2	ユーザーによる権限内容の確認とキャンセルを可能とする仕組み Requiring data attribute providers to establish a mechanism through which users can review and cancel their permissions
3	権限のリスクレベルの指定 Assigning risk levels to permissions
4	権限付与自体の禁止 Allowing for prohibitions on granting permissions
5	支払上限等、文脈に基づく権限制限 Placing contextual limits on permissions where appropriate (e.g. payment limits)
6	時刻や有効期間に基づく権限制限 Subjecting permissions to time/duration limits

ここでいう権限は、OAuth 2.0 の用語では、スコープ (scope) のことを指しています。

クライアントアプリケーションは、認可を求めるとき、欲しい権限のリストを scope というパラメーターに列挙します。列挙可能な権限の名前は、あらかじめ認可サーバーが定義しておく必要があります。例えば Facebook では、「Permissions Reference - Facebook Login」に挙げられているような権限名を定義しています。

権限名は自由に決めることができますが、使用できる文字は、空白 (0x20)、ダブルクォーテーション (0x22)、バックスラッシュ (0x5C) を除く表示可能な ASCII 文字のみです (RFC 6749, 3.3. Access Token Scope)。また、OpenID Connect Core 1.0 という仕様で、address、email、offline_access、openid、phone、profile の 6 つは標準の権限名として定義済みです。

銀行毎に権限名や権限範囲が異なると、利用者側にとっては厄介なので、業界内で統一されることが望ましいと思います。

2.2. ロール

「7c. 2.4 Authorisation」では、ロール (role) についても次のように軽く言及しています。

Roles: a set of permissions and roles should be defined with a standardised nomenclature in future work.

「ロールとは権限の集合であり、体系的に定義すべきである」と述べています。

しかし、この文脈でロールの話を持ち出すと混乱を招くと思います。同じ permission という語が使われているので、素直に読むと OAuth 2.0 の文脈でいうところの permission をまとめたものをロールと呼んでいるように聞こえます。確かにそういう風に OAuth 2.0 の permission を定義することも可能ではあります。しかし、OAuth 2.0 の permission はクライアントアプリケーションに与えられる権限のことであって、ロール (役割) という語が暗示する「ユーザーの」権限とは、異なるのです。

認可という言葉が文脈によって異なる概念を表すことは、「【第二弾】OAuth 2.0 + OpenID Connect のフルスクラッチ実装者が知見を語る」の「1. もう一つの認可」に詳しく説明してあるので、そちらをご参照ください。

ただ、The Open Banking Standard のレポートも指針を示しただけの文書であり、仕様書ではないので、ロールや権限について細かい定義に拘泥してもあまり意味はないので、ここはさらっと流してよいでしょう。

ついでなので言及すると、「7c. 2.4 Authorisation」の二つ目の文「The third-party service should provide evidence that it is entitled to use the authorisation token (e.g. by way of providing a client ID and client secret) to the data attribute provider」にも、技術的には誤りがあります。「認可トークン (authorisation token) (アクセストークンのこと) を使う権利を持っている (entitled)」ことを示すためにクライアント ID とクライアントシークレットを提示するというのは、OAuth 2.0 的には妙な話です。クライアント ID とクライアントシークレットを提示することにより、どのクライアントアプリケーションなのかを特定することはできますが、だからといって、同時に提示されたアクセストークンを使う権利を、そのクライアントアプリケーションが持っているかどうかは別問題だからです。アクセストークンは発行された時点で既に特定のクライアントアプリケーションと紐付いているので、その使用に際し、再度「どのクライアントアプリケーションか」という情報を提供する必要はないのです。

2.3. 暗号化

「7c. 2.4 Authorisation」での暗号化 (encryption) に関する言及は次のとおりです。

Encryption: API connections and data in transit should be encrypted using TLS v1.2 as a minimum.

簡単に言うと「http ではなく https を使いましょう」ということなのですが、TLS について少し説明します。

TLS は Transport Layer Security の略で、安全な通信をおこなうための仕様です。SSL (Secure Sockets Layer) という仕様を元に作られたことと、SSL という名前が普及していることもあって、SSL という語で TLS のことを指すことも多いです。

上記の引用文中では、最低でも TLS バージョン 1.2 を使うことが推奨されています。SSL のバージョン番号と併せて表にまとめると、次のようになります。なお、TLS バージョン 1.3 は現在仕様策定中とのことです。

プロトコル	定義年	仕様書	廃止年	仕様書
SSL 1.0	N/A	N/A	N/A	N/A
SSL 2.0	1995	N/A	2011	RFC 6176
SSL 3.0	1996	RFC 6101^※1	2015	RFC 7568
TLS 1.0	1999	RFC 2246
TLS 1.1	2006	RFC 4346
TLS 1.2	2008	RFC 5246
TLS 1.3		draft
^{※1: 歴史的な資料として RFC 化された。}

2.4. 証明

「7c. 2.4 Authorisation」での証明 (certification) に関する言及は次のとおりです。

Certification: should be used to coordinate the management and issuing of digital certificates with a whitelist of approved companies.

クライアント証明書と、事前承認を受けた企業群のホワイトリストを組み合わせて使うことを推奨しています。

銀行のサーバーと信頼できる企業のサーバーとの間の通信は、この仕組みを適用するのが望ましいでしょう。ただし、スマートフォンアプリケーションのように、アプリ内に組み込んだ秘密の情報を秘密に保っておくことが難しい環境にあるクライアントアプリケーションの場合、クライアント証明書自体を悪意のあるクラッカーに抜き取られてしまう可能性があるので、クライアント証明書はあまり有効とは言えないでしょう。

なお、OAuth 2.0 では、秘密鍵を秘密に保っておけるクライアントアプリケーションのことを「confidential クライアント」、そうでないクライアントアプリケーションのことを「public クライアント」と呼んでいます。(RFC 6749, 2.1. Client Types)

2.5. セキュリティー標準規格

「7c. 2.4 Authorisation」でのセキュリティー標準規格 (security standards) に関する言及は次のとおりです。

Security standards: it is suggested to use the Cheque Printers Accreditation Scheme (CPAS) as a model, i.e. a security accreditation model based on ISO27001 with a specific minimum threat profile, against which independent auditors can assess the security of data attribute providers and third parties (it may be appropriate to grant a waiver to certain data attribute providers, e.g. banks).

ここでは独立監査人による適格性認定を銀行やクライアントアプリケーション開発企業に対して付与する枠組みを考える際、CPAS (Cheque Printers Accreditation Scheme) をモデルとして使用することを提案しています。

3. リスク

「7c. 4 Risks」では、銀行 API を公開することにより生ずる新たなリスクについて言及しています。以下、要約しながら紹介します。

まず、銀行 API は、サイバー犯罪者にとって格好の攻撃対象となります。API の実装自体や、それを利用するアプリケーションやサービスに脆弱性があれば、悪用される恐れがあります。また、API に関して無知なユーザーに対してソーシャル・エンジニアリング攻撃が仕掛けられる恐れもあります。

銀行 API を利用してユーザーのデータを照会したり蓄えたりするサービスも、攻撃の対象となります。特に、PFM (Personal Financial Management; 個人財務管理) 等のアカウントアグリゲーション系サービスの場合、そこを攻撃で破りさえすれば、複数の銀行に対して攻撃を仕掛ける足掛かりとすることができるので、攻撃者にとっては魅力的です。

銀行 API と最終的なクライアントアプリケーションとの間に、別の第三者が介在するような仕組みも今後生まれるでしょうが、その介在者にセキュリティー上の問題があると、そこが攻撃の対象となります。

PC やスマートフォンなど、ユーザーが使用する機器に脆弱性があれば、それも脅威となります。

4. 顧客保護

「7c. 5. Consumer Protection」では顧客保護について言及しています。

もちろんセキュリティーは重要なのですが、「7c. 5.2 Usability vs. security」で次のように述べていることは興味深いです。

It is important to ensure that security measures are put in place to mitigate risks associated with the Open Banking API. However, these should not be so restrictive and/or onerous that they unreasonably reduce the utility, usability and benefits derived from products and services reliant on APIs. The challenge is to balance customer protection with the potential benefits.

つまり、セキュリティーを金科玉条とするあまりに、利便性を不合理に損なうほどの制限をかけるべきではないと言っています。

続けて次のように述べ、

A possible benchmark to use for determining whether usability is unreasonably restricted is to compare the functionality offered by the open API with that offered by data attribute providers' existing websites and apps.

不合理かどうかを判断する一つの方法として、銀行のウェブサイトやアプリケーションにより既に提供されている機能と比較してみることを挙げています。

先日、「社内からSlideShare見るの禁止になった。セキュリティの観点らしい。」というツイートをみかけましたが、これはセキュリティーと利便性との間のバランスを欠いた例だと思います。「ファイルがアップロードできるから」禁止されたとのことなので、だとすると、GitHub、Maven、Ruby Gems、NuGet、npm 等も禁止しないと筋が通らないですから、どの業界の会社かは存じ上げませんが、その会社内でのソフトウェア開発作業は困難を極めるでしょう。

5. 不正の検出と監視

「7c. 6 Fraud Detection/Monitoring」では不正の検出と監視に関連して、次のような項目を挙げています。

API に対しても、既存の不正検出と監視の仕組みを適用する。
リスクプロファイリングに有用な情報の提供をクライアントアプリケーションに求める。 (IP アドレス、ブラウザ種別、デバイス情報等)
アクションによっては、別経路での認証を追加で要求できるようにする。 (新しく支払いが発生するときなど)
クライアントアプリケーション側からも再認証要求を出せるようにする。
API で処理要求を出せるようにするものの、最終実行許可自体は別経路でおこなう、という手段を提供する。
重要なアクションがとられた際には、ユーザーに通知をおこなう。

ここで挙げられている項目は、OAuth 2.0 の仕様に基づくものではないので、OAuth 2.0 を実装したからといって、自動的についてくる機能ではありません。それぞれの Web API 提供者が、各々深く考え、工夫して実装する必要があります。

6. 既存規格との整合

「7c. 7 Alignment with Existing Standards」では、既存のセキュリティー規格を Open Banking API でも活用すべきと述べています。技術的には、TLS、OAuth、OpenID Connect を例として挙げているほか、規格の例として次のものを挙げています。

規格	説明
ISO 27000 シリーズ	情報セキュリティー規格群
PCI DSS	Payment Card Industry Data Security Standard クレジットカードのセキュリティーに関する規格
CPAS	Cheque Printers Accreditation Scheme 小切手印刷機に関する規格
tScheme	電子商取引のセキュリティー対策に関する規格

API 提供側はもちろんのこと、API 利用側も、その処理内容に応じて適宜関連規格への準拠が求められることになるでしょう。

7. API におけるセキュリティーと認証

「7c. 8. Security and Authentication Aspects of the API Specification」では、3 ページほど使っていろいろ述べているのですが、大雑把に言うと、OAuth の概念を紹介しています。ですので、このセクションを読む代わりに OAuth の勉強をすればいいのですが、本記事の主旨は「The Open Banking Standard レポートを読む際の助けとなること」ですので、ここは面倒臭がらずにセクション内の文を逐一参照しながら解説していくことにします。

Within the context of an Open Banking API, there are four authentication scenarios:

• The customer authenticating themselves to an data attribute provider (in order to authorise a third party);
• The customer authenticating themselves to a third party;
• The third party authenticating themselves to an data attribute provider (in order to access a customer’s data);
• The third party authenticating themselves to a customer.

上記の文では、「Open Banking API の文脈では次の 4 つの認証がある」と述べています。

銀行がユーザーを認証する。(クライアントアプリケーションに認可を与えるのに先立って)
クライアントアプリケーションがユーザーを認証する。
銀行がクライアントアプリケーションを認証する。
ユーザーがクライアントアプリケーションを認証する。

図にすると次のようになります。

技術的にはそれぞれ、次のような処理になります。

	技術的な処理
1	銀行の認可画面のログインフォームに、ユーザーが自分の銀行アカウントのログイン ID とパスワードを入力することにより、ユーザーは銀行に認証してもらう。(ただし認証方法にはバリエーションがある)
2	クライアントアプリケーション (もしくはそれに紐付くサービス) に、ID とパスワードを入力することにより、ユーザーはアプリケーションに認証してもらう。ここで入力する ID とパスワードは、銀行のアカウントのものとは異なる。
3	クライアントアプリケーションが OAuth 2.0 の認可リクエストやトークンリクエストを銀行の認可サーバーに投げる際に、事前に発行されているクライアント ID (`client_id`) を提示することにより、クライアントアプリケーションは認可サーバーに認証してもらう。クライアントアプリケーションが confidential クライアントの場合 (RFC 6749, 2.1. Client Types)、クライアントシークレット (`client_secret`) の提示もおこなう。また、OAuth 2.0 の仕様外ではあるが、クライアント証明書の提示など、追加の認証方法が要求される場合もある。
4	認可画面に出てくるクライアントアプリケーションの情報を確認することにより、ユーザーはクライアントアプリケーションを認証する。

さて、4 種類の認証を紹介したあとに、次の段落が続きます。

Data attribute providers and third parties should own and control the method by which they authenticate their customers. The methods by which a third party authenticates itself to a data attribute provider, and a user may identify a third party, should form part of the Open Banking API specification.

この段落では、「1 番目と 2 番目の認証については、銀行とクライアントアプリケーションがそれぞれ適宜やりたいようにやってください」、一方、「3 番目と 4 番目の認証については、Open Banking API の仕様の一部として定義されるべき」、と言っています。3 のクライアント認証は既に OAuth 2.0 の一部ですし、4 は「OAuth 2.0 の認可リクエストの結果表示される認可画面内にクライアントアプリケーションの情報を含めましょう」という話ですから、結局、この段落は「OAuth 2.0 に関係する部分は Open Banking API の仕様内で触れる予定」と言っていることと等しいです。

なお、1 番目のユーザー認証の方法については、RFC 6749 (OAuth 2.0) の 3.1. Authorization Endpoint に「この仕様の範囲外である」と明確に書いてあります。

The authorization endpoint is used to interact with the resource owner and obtain an authorization grant. The authorization server MUST first verify the identity of the resource owner. The way in which the authorization server authenticates the resource owner (e.g., username and password login, session cookies) is beyond the scope of this specification.

というのも、OAuth 2.0 は、認可 (authorization) の仕様であってユーザー認証 (authentication) の仕様ではないからです。

認証と認可の違いがよく分からない方は、「OAuth 2.0 + OpenID Connect のフルスクラッチ実装者が知見を語る」の「認証と認可」の説明を是非読んでいただきたいのですが、下図で意味の違いがつかめれば問題ありません。

The Open Banking Standard レポートに戻ります。続く段落はこうです。

The process by which a customer authenticates themselves to a data attribute provider in order to authorise the granting of permissions to a third party will be a tripartite process, which should be designed in a way that minimises digital friction, to avoid discouraging or confusing customers. It will potentially involve a hand-off of customer interaction from the third party to the data attribute provider for the authentication to be carried out, followed by a redirect of the customer back to the third party from the data attribute provider after the authentication and authorisation interaction process has been completed.

クライアントアプリケーションに許可を与えるために、ユーザーが銀行に認証してもらうプロセスは、三者間のプロセス (tripartite process) だと言っています。ここで三者とは、ユーザー、銀行、クライアントアプリケーションをさしています。そして、認証を行うため (for the authentication to be carried out)、ユーザーとのやりとりは一時的にクライアントアプリケーションから銀行へと引き渡され (hand-off of customer interaction from the third party to the data attribute provider)、認証および認可が完了したあと (after the authentication and authorisation interaction process has been completed)、リダイレクトによって再び銀行からクライアントアプリケーションに戻ってくる (a redirect of the customer back to the third party from the data attribute provider) と言っています。

分かりにくいかもしれませんが、Facebook を例にとれば、馴染みのある処理フローだと気付かれるかもしれません。「Facebook と連携する」という設定項目を持つスマートフォンアプリケーションを使ったことはないでしょうか？そのようなアプリで実際に連携を行おうとすると、一時的に Facebook のサイトに遷移して、「○○というアプリが○○の権限を求めています。」といった文言とともに、ログイン ID とパスワードを入力するためのログインフォームが表示されると思います。このログインフォームに入力するのは、当該スマートフォンアプリ用のログイン ID とパスワードではなく、Facebook にログインするためのログイン ID とパスワードです。つまり、ユーザーの認証をおこなうのは、スマートフォンアプリではなく、Facebook なのです。ここで、Facebook が担っている役割は、Open Banking API における銀行の役割と同じです。

段落は続きます。

This approach has the benefit of allowing the data attribute provider to continue to own and control the method for authenticating its customers (thereby minimising the risk that a third party could obtain permissions without explicit approval by the customer) and avoids mandating the use of specific authentication methods. Separately, customers will also need to authenticate themselves to third parties in order to gain access to the services or functionality being provided. The method used by both data attribute providers and third parties to authenticate customers should be appropriate to adequately protect the data and functionality in question.

太字で示した箇所、すなわち、「クライアントアプリケーションがユーザーからの明示的な承認を受けることなく権限を取得できてしまうというリスクを最小化する」、というのが一番大切なところで、それこそが OAuth の目的なのです。もしも、ユーザー認証をクライアントアプリケーションが仲介するような形にしてしまった場合、つまり、ユーザーのログイン ID とパスワードをクライアントアプリケーションが直接受け取るような処理フローの場合、そのクライアントアプリケーションが悪さをしようと思えば、何でもできてしまうのです。

このあと、The Open Banking Standard レポートでは、Figure 7c.1, Figure 7c.2, Figure 7c.3 という三つの図を示して OAuth 2.0 の処理フローを説明していますが (48 ～ 49 ページ)、良く描けているとは言い難く、ほとんど理解の助けにはなりません。そこでかわりに、「【第二弾】OAuth 2.0 + OpenID Connect のフルスクラッチ実装者が知見を語る」の「2.8. 図解：認可コードフロー」の図をここに転載します。これは、OAuth 2.0 (RFC 6749) で定義されている 4 つの認可フローのうち、もっとも複雑な認可コードフローを図にしたものです。OAuth 2.0 の詳細に興味のある方は RFC 6749 を参照してください。

せっかくですので、7c.8 のセクションは全文言及しましょう。

3 つの図の後に「7c. 8.1.2 Selection of OAuth 2.0 with future consideration of OpenID Connect」というサブセクションが続きます。

The Fingleton Report recommended the use of the OAuth 2.0 protocol, which supports the tripartite approach outlined in 7c. 8.1.1. This report endorses this recommendation, although further consideration must be given to the specific implementation.

ここでは、Fingleton Report が OAuth 2.0 を推奨していることを紹介しています。この Fingleton Report というのは、イギリスの財務省と内閣府の要請に基づき Fingleton Associates が 2014 年 9 月に公開した「Data Sharing and Open Data for Banks」という題名の文書を指します。

The OAuth 2.0 protocol supports a variety of different interpretations and styles of interaction, with different security implications. The Open Banking API should prescribe how authentication and authorisation aspects of the standard are implemented, so the appropriate levels of consistency, interoperability and security are achieved. It is recommended that the OpenID Connect authentication protocol (which provides an identity layer on top of the OAuth 2.0 protocol) be considered as part of this process. Appendix 6 sets out some considerations pertaining OAuth 1.0 and 2.0 and OpenID Connect.

この段落では、「OAuth 2.0 仕様には解釈の幅があるので、一貫性・相互運用性・セキュリティーが一定のレベルを満たすよう、認証・認可の実装方法について Open Banking API で規定すべきだ」と述べています。また、OpenID Connect についても考慮することを推奨しています。

Having been granted permission to access a customer’s account information and act on the customer’s behalf, there must be a method whereby the third party can authenticate themselves to the data attribute provider during subsequent interactions. OAuth 2.0 solves this through the use of a token that is provided by the ASP to the third party at the point at which permission to access an account is granted. The third party then presents the token to the each time it wishes to access the account.

この段落では、「ユーザーから許可を得て動作をしていることをクライアントアプリケーションは銀行に対して証明しなければならないが、OAuth 2.0 では、ASP からクライアントアプリケーションに発行されたトークンを使うことでこの問題を解決している」、と述べています。ASP とは、Glossary によると Account-Servicing Provider の略で、ここでは銀行のことを指しています。また、トークンとは、OAuth 2.0 でいうところのアクセストークンのことを指しています。

セクション 7c.8 は「7c. 8.1.3 Further considerations」で締められます。

The Open Banking API should define a method by which users can identify any third party they are interacting with, particularly at the point at which they are granting authorisation, for example, using certificates. There must also be a method by which the data attribute provider may verify that a third party is authorised to receive the permissions it is requesting.

ユーザーがクライアントアプリケーションを特定する方法を、特に認可を与える際の特定方法を、Open Banking API で定義すべきだと述べています。その例として証明書の利用 (using certificates) が挙げられています。しかしながら、スマートフォンにインストールされるアプリケーションは「public クライアント」と呼ばれ (RFC 6749, 2.1. Client Types)、クライアント証明書のような秘密鍵を秘密に保っておくことはできないと考えられているので、クライアント証明書によるクライアント認証が有効なのは「confidential クライアント」に限られるでしょう。

また、この段落では、「『（ユーザーではなく銀行の視点で）当該クライアントアプリケーションが要求している権限を与えてもいいかどうか』を銀行が検証する方法も提供されるべきだ」と述べています。この文章の解釈方法は幾つか考えられますが、もしも「クライアントアプリケーション毎に要求可能な権限の種類を変化させる」という発想なのであれば、これは OAuth 2.0 の仕様範囲外の話なので、どのように実装するかには幅が出てきます。クライアントアプリケーション毎に要求可能な権限を変化させる仕組みを作るのか、それとも単純に認可サーバーを別々にするだけで済ますのか。前者の方法は柔軟ですが、そのような機能を既に持っている OAuth 2.0 サーバーの実装は少ないと思われるので^*、サーバー実装に手を加える必要が出てくると思われます。

^{* Authlete には「クライアント毎に要求可能な権限を設定する機能」が実装されています。}

8. 認可 (再び)

「7c. 2.4 Authorisation」で既に認可について触れていますが、「7c. 9 Authorisation」で再び認可の話が出てきます。セクション 7c. 2.4 を深く掘り下げた内容になっています。

8.1. 認可プロセス

「7c. 9.1 The authorisation process」では、Open Banking API に適用することになる OAuth モデルについて説明しています。ユーザー・銀行・クライアントアプリケーションによる三者間のプロセスの話です。これに関する説明はこの記事内で既に終えています。「2. 認可」や「7. API におけるセキュリティーと認証」の内容を参照してください。

8.2. 銀行側の責任

「7c. 9.2 Responsibilities of the data attribute provider」では銀行側の責任について述べています。

The data attribute provider must allow the customer to review:

• pertinent information about the third party (e.g. the company name, location, what level of authorisation it has received);
• permissions being requested by the third party; and
• duration and validity for which the permissions will be granted.

ここで挙げられている内容は、認可画面に表示する内容、もしくはそこから参照できる内容のことを指していると思われます。クライアントアプリケーションに関する情報、クライアントアプリケーションが要求している権限のリスト、付与された権限の有効期限などです。なお、認可画面とは、クライアントアプリケーションの認可リクエストにもとづいて認可サーバーが返す画面のことです。「図解：OAuth 認可コードフローと Web API コール」の図中の「サービス ABC 認可ページ」にあたります。

これに、次の段落が続きます。

After the fact, data attribute providers must provide an independent mechanism (i.e. without any third party provided software or service) for customers to review the permissions they have granted and revoke any.

ここでは、ユーザーが、自分がどのクライアントアプリケーションに何の権限を与えたのかを確認する仕組み、及びそれらの認可を取り消しする仕組みを、銀行側が用意しなければならないと述べています。さらに、次のように述べています。

Data attribute providers should also maintain the ability to limit, suspend or revoke a third party’s access if they detect suspicious activity or become aware that it is in the customer’s best interests to do so (e.g. if a third party has been removed from the whitelist for failure to maintain required security standards).

意味は、クライアントアプリケーションが何か怪しい動きをしていると思ったときには、ユーザーの指示を待たずとも銀行側の判断で、クライアントアプリケーションからのアクセスを中断したり取り消したりできるようにしておくべき、となります。

It is expected that each data attribute provider will issue its own authorisation tokens. Third parties are expected to securely manage tokens relevant to each data attribute provider. data attribute providers in turn, must ensure that the third party is in possession of legitimate authorisation tokens and that the requested data or service relates to the customer’s legitimate account (i.e. the right customer is accessing the right account via the right third party at the right time). Data attribute providers must ensure that only valid tokens are accepted and that controls are in place to prevent common attack scenarios such as replay, enumeration, denial of service attacks, etc.

この段落は、「7c. 9.2 Responsibilities of the data attribute provider」の最後の段落です。一文ずつ見ていきましょう。

「It is expected that each data attribute provider will issue its own authorisation tokens.」では、認可トークン (authorisation token) は各銀行がそれぞれ発行することを想定していると述べています。これは、各銀行が自行用の認可サーバーを持ち、自行の Web API でのみ使えるアクセストークンを発行することを想定しているという意味になります。

「Third parties are expected to securely manage tokens relevant to each data attribute provider.」では、銀行の認可サーバーから発行されたアクセストークンをクライアントアプリケーションが安全に管理することを期待すると述べています。

「data attribute providers in turn, must ensure that the third party is in possession of legitimate authorisation tokens and that the requested data or service relates to the customer’s legitimate account (i.e. the right customer is accessing the right account via the right third party at the right time).」では、クライアントアプリケーションが正規の認可トークンを所有していること、および、要求されたデータもしくはサービスがユーザーの正規アカウントに関連していることを、銀行が確認しなければならない、と述べています。これは、銀行の Web API がクライアントアプリケーションからアクセストークンを受け取ったとき、そのアクセストークンに紐づく情報 (認可を与えたユーザー、認可を受けたクライアントアプリケーション、与えられた権限のリスト) を確認することを求めるものです。

最後に、「Data attribute providers must ensure that only valid tokens are accepted and that controls are in place to prevent common attack scenarios such as replay, enumeration, denial of service attacks, etc.」では、有効なトークンのみを受け付けること、および、リプレイ攻撃・列挙攻撃・DoS 攻撃などのよくある攻撃に対する備えをすることを、銀行に求めています。