By Tatsuo Kudo (Authlete)

1. Financial APIs Workshop - Japan/UK Open Banking and APIs Summit 2018
銀行APIのトレンド
工藤達雄

2. 本プレゼンテーションの内容
• 近年欧州を中心に「銀行API」の共通仕様を策定する動きが
進んでいます。本プレゼンテーションでは各仕様のAPIアク
セス認可に注目し、今後の方向性を考察します。
2

3. 自己紹介
• 工藤達雄 https://www.linkedin.com/in/tatsuokudo
– サン・マイクロシステムズ(1998-2008)
– 野村総合研究所 (2008-2018)
– OpenIDファウンデーション・ジャパン (2013-2014)
– NRIセキュアテクノロジーズ (2014-2018)
– Authlete(2018-)
• VP of Solution Strategy
3

4. 「銀行API」とは
• 「銀行API」と言ってもいろいろある
– 「オープンデータ」の提供（e.g.支店
の住所情報）
– コア機能のホワイトレーベル提供
（“Bank as a Service”）
– お客さまに関わるデータ・機能の口
座情報・契約情報・取引履歴の提供、
取引の実行機能など 約2万API中、Bankingカテゴリに登録されているのは371種類
Source: https://www.programmablew eb.com/category/banking
4

5. 銀行APIにおける“OAuth 2.0”の活用
• お客さまの同意に基づく
APIアクセス認可のフ
レームワークとして用い
られることが多い
5
“OAuth 2.0” の登場人物と処理の流れ
Source: https://www.slideshare.net/tkudo/api-meetup-oauth

6. 銀行APIの策定者
• 銀行各行が策定
• 業界団体やコンソーシアムが
共通仕様を策定
• （ベンダーが策定）
6
• Open Banking UK
• Berlin Group
NextGenPSD2
• Polish Bank Association
• Slovak Banking
Association
• (France Stet)

7. Open Banking UK
• FAPI Part 2
• Client Credentials Grant Type (OAuth 2.0) / OIDC Hybrid
Flow
• Request Object
• Mutual TLS
7
Source: Open Banking Security Profile - Implementer's Draft v1.1.2
https://openbanking.atlassian.net/w iki/spaces/DZ/pages/83919096/Open+Banking+Security+Profile+-+Implementer+s+Draft+v1.1.2

8. Open Banking UK
口座情報等取得のフロー
1. PSU (Payment Service User) がAISP (Account
Information Service Provider) に情報取得開始を許可
2. AISPがASPSP (Account Servicing Payment Service
Provider) にPOST /account-resource
(Mutual TLS, Client Credentials Grant Type)
3. ASPSPがPISPに “AccountRequestId” を返却
4. AISPがAccountRequestIdを含む Request Objectを生成し
ASPSPに認可リクエスト
（OIDC Hybrid Flow）
5. ASPSPがPSUを認証
6. ASPSPがAISPに認可コードを返却
7. AISPがASPSPに認可コードを送信しアクセストークンを取得
（Mutual TLS）
8. AISPがアクセストークンを使ってGET /accounts
（Mutual TLS）
8
Source: Account and Transaction API - v2.0.0
https://openbanking.atlassian.net/w iki/spaces/DZ/pages/127009546/Account+and+
Transaction+API+Specification+-+v2.0.0

9. Open Banking UK
決済指示のフロー
1. PSUがPISP (Payment Initiation Service Provider) に決済指示
開始を許可
2. PISPがASPSPにPOST /payments
(Mutual TLS, Client Credentials Grant Type)
3. ASPSPがPISPに ”PaymentId” を返却
4. PISPが PaymentId を含む Request Objectを生成し、ASPSPに
認可リクエスト
（OIDC Hybrid Flow）
5. ASPSPがPSUを認証
6. ASPSPがPISPに認可コードを返却
7. PISPがASPSPに認可コードを送信しアクセストークンを取得
（Mutual TLS）
8. PISPがアクセストークンを使ってPOST /payment-submissions
（Mutual TLS）
9. Optionally retrieve the status of a payment setup or
submission
9
Source: Payment Initiation API - v1.1.0
https://openbanking.atlassian.net/w iki/spaces/DZ/pages/5786479/Payment+Initiation+API+Specification+-+v1.1.0

10. OIDC Hybrid Flowによる決済指示フローの例 (1)
• Slovak Banking API Standard
– OB UKと同様、PISPは決済のID (orderId) をASPSPから取得後、それをRequest Objectに格納し、認可
リクエストを開始する
10
Source: Slovak Banking API Standard Version 1.1 http://w ww.sbaonline.sk/files/subory/projekty/sbas/sbas_ver1.1-final.pdf

11. OIDC Hybrid Flowによる決済指示フローの例 (2)
• ハンガリー MKB銀行
– Open Banking UKのSecurity
Profileを活用
– OB UKと同様、PISPは決済の
ID (openbanking_intent_id)を
ASPSPから取得後、それを
RequestObjectに格納し、認可
リクエストを開始する
11
Source: Account and Transaction API Specification
https://portal.sandbox.mkb.hu/api-documentation/account-info

12. Berlin Group “NextGenPSD2”
• 認証・認可フローが大別して4種類ある
– Redirect SCAApproach
– OAuth2 SCAApproach
– Decoupled SCAApproach
– Embedded SCAApproach
12

13. Berlin Group “NextGenPSD2”
Redirect / OAuth2 SCA Approach
• PSUをASPSPにリダイレ
クトしてPSUの同意を確
認
• “OAuth2” はRedirectの
一種
– Authorization Server
Metadataを用いてリダイ
レクト先を動的に決定
13
Source: NextGenPSD2 XS2A Framew orkImplementation Guidelines Version 1.1
https://docs.wixstatic.com/ugd/c2914b_5351b289bf844c6881e46ee3561d95bb.pdf

14. Berlin Group “NextGenPSD2”
Decoupled SCA Approach
• ASPSPがPISP/AISPと
は別の経路を介して
PSUの同意を確認
14
Source: NextGenPSD2 XS2A Framew orkImplementation Guidelines Version 1.1
https://docs.wixstatic.com/ugd/c2914b_5351b289bf844c6881e46ee3561d95bb.pdf

15. Berlin Group “NextGenPSD2”
Embedded SCA Approach
• ASPSPがPISP/AISPを介して
PSUの同意を確認
15
Source: NextGenPSD2 XS2A Framew orkImplementation Guidelines Version 1.1
https://docs.wixstatic.com/ugd/c2914b_5351b289bf844c6881e46ee3561d95bb.pdf

16. Berlin Group “NextGenPSD2”
OAuth 2.0との関係
• “Optional Usage” という位置付け
• PISP/AISPは、“pre-step” の結果として、もしくはOAuth
SCA Approachを実行した結果として、ASPSPからアクセス
トークンを取得し、API (XS2A interface) を呼び出し
16

17. 他のDecoupledな認証の例
• ポーランド “PolishAPI”
• NextGenPSD2とは別の方
法による decoupled な認証
– OAuth 2.0の認可コードグラ
ントを応用
– TPP (Third-Party Provider)
がEAT (External
Authorization Tool) の出力
値をASPSPに送信
17
Source: PolishAPI Verison 2.0
https://docs.polishapi.org/files/ver2.0/PolishAPI-spec-v2.0-EN.pdf

18. 他のEmbeddedアプローチの例
• フランス “STET”
• Resource Owner
Password Grant
– ASPSPがPSUを
Strong Customer
Authenticationによって
認証した結果を「パス
ワード」として送信する
18
Source: PolishAPI Verison 2.0
https://www.stet.eu/assets/files/PSD2/1_3/API_DSP2_STET_V1_3.pdf

19. まとめ
• TPPからASPSPに “intent” をPOST → 取得した intent idを
Request Objectに入れて認可リクエスト、というフローが
Open Banking UKを中心に広まりつつある
• TPPとASPSPとの間は原則的に相互TLS認証を行っている
• “Embedded” vs “Decoupled”
19

20. Thanks!