Uploaded byFinTechLabs.io
Trends in Banking APIs #fapisum - Japan/UK Open Banking and APIs Summit 2018 - July 24, 2018
By Tatsuo Kudo (Authlete)
More Related Content
Similar to Trends in Banking APIs #fapisum - Japan/UK Open Banking and APIs Summit 2018 - July 24, 2018
Trends in Banking APIs #fapisum - Japan/UK Open Banking and APIs Summit 2018 - July 24, 2018
- 1. Financial APIs Workshop- Japan/UK Open Banking and APIs Summit 2018 銀行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 “OAuth2.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” DecoupledSCA 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” EmbeddedSCA 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” OAuth2.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.