(cache)OpenID BizDay で金融 API の動向について聞いてきた

BizDay は開発者向けではないと分かった上で、普段利用しているソーシャル API とどのくらい違うのか、というのを知りたくて参加した。分からない単語が多かったので、いろいろ引用とか補足多めの自分用メモ。まとまらない。

OpenID BizDay #10 - 金融 API 時代の OAuth 2.0 & OpenID Connect (と、CIS 2017報告会) | Peatix
OpenID BizDay #10 - 金融 API 時代の OAuth 2.0 & OpenID Connect (と、CIS 2017報告会) | お知らせ | OpenID ファウンデーション・ジャパン

前回の参加（Tech Night）は、もう 2 年も前なのか…時間の流れが早い…

blog.tmd45.jp

OpenID Certification については、どこで聞いたんだったか…？

前提

EU の PSD2（決済サービス司令2）*1
- UK → Open Banking Standard
- ドイツ → Open Bank Project
日本
- 2017年5月銀行法等一部改正国内銀行は API 公開の努力義務
米 OpenID Foundation
- Financial API（FAPI*2）Working Group 立ち上げ
  - OAuth 2.0 は "Framework"
  - 利用ケースに即した適切なプロファイルが必要
    - 例: FAPI におけるセキュリティプロファイル
  - これらのプロファイルを策定する WG
お知らせ
- Japan Identity & Cloud Summit (JICS) 2017
  - 2017/9/15 (金) 9:30-18:00 ＠溜池山王
  - 金融 API、IoT、AI とセキュリティ、政府・大学の API 化

CIS 2017 参加報告 @nov 氏

スライド: CIS 2017 参加報告 @ OpenID BizDay 10

CIS → Identiverse (名称変更)
Fintech の注目話題
- GDPR（EU一般データ保護規則）*3
- PSD2 → Financial API
- FHIR（医療 IT 標準仕様フレームワーク）*4
  - Blockchain に関する話題は以前より減った
IDPRO.org
- Kantara Initiative*5 の IDPRO 部会が独立
  - 参加企業(一部): Salesforce, Kantara, GIGYA, etc.
pages.nist.gov/800-63-3
- NIST SP 800-63 Digital Identity Guidelines
FIDO, Federation
- Google の FIDO に関する統計データ
  - Google 社内は U2F 導入済み
  - Security Key（認証ハードウェア）に比べて OTP は操作に約 2 倍の時間がかかる（ユーザビリティ）
  - Security Key を導入したほうがサポートインシデント（OTP 設定したスマフォを無くしたとかの問い合わせ）が減るらしい
    - Security Key を失くすってことはないんだろうか…
Salesforce, 攻撃の種類と対策レベル
- Bulk Attackers（全データ引っこ抜こうとするヤツ）
- Single Row Attackers（特定個人のデータを抜こうとするヤツ）
- Successor Attackers（権限を持った人間の犯行）
  - 下にいくにつれ対策は難しい
- Level.1 〜 Level.5 の対策
Open Banking
- openbanking.org.uk/developers
Google
- YouTube 買収と Gmail ユーザ
  - SignUp と SignIn が別々に存在する
  - SignUp で新規ユーザ作ってしまう
    - YouTube 専用に作ったアカウントは、その後使われなくなってしまう
    - 登録は増えたがエンゲージメントが下がった
- 電話番号ログインオプション導入　
  - 同じことがおきた（普段使っている Email アカウントと別に電話番号でアカウントを作ってしまう）
- Google がやったこと
  - 既存アカウントに電話番号を登録するよう誘導
  - SignUp と SignIn の入り口を分けず共通化
  - まず ID（Email や電話番号）を入力させ、登録済みの ID であれば次に Password を求める
    - 新規率は落ちたがエンゲージメントは維持できた
Token Binding
- Secure OAuth, セキュリティプロファイル技術
- ブラウザ証明書で署名
  - あとで調べる 📝
Microsoft 3rd Party App and Azure AD (Active Directory)
- 利用されている App 統計
- No.1 は Google
  - ランキングのなかに Workspace for facebook があった…使われてるのか…
- IE → カメラで FIDO
- Cognitive (AI) でリスク情報
OpenID Certificate
- Test tool Open Source (github)
- RP general 仕様準拠ツールももうすぐ出る
- RP test server
  - 気にはなっているが…
App Auth (Best Practice, Google)
Mobile Connect
- 世界の携帯キャリアが集まって IdP を作ろうとしている
  - 電話番号からキャリアを特定する中央システム
  - MNP したら電話番号変わらず IdP が移管される
  - などなど
生体認証のディスカッション
- 生体って、歳取るとかでデータが劣化変化するから、情報の更新が必要だよね
- とか

まとめ

UK FAPI は素の OAuth 2.0 は使わない
OTP より FIDO, U2F
Mobile Connect のような IdP の枠組みが金融業界でも起こるか

金融 API 時代の OAuth 2.0 と OpenID Connect 崎村氏(NRI)

スライド: Financial APIセキュリティの現状について @ OpenID BizDay 10

Fintech
- API
- AI
- Blockchain
Fintech API
- REGO モデル, B2D という顧客セグメント
- Our Expertise as a Service (OEaaS)
Future of European Fintech
- 「パスワード保存による Direct Access こそがセキュア」と主張
- 無いわー
- Credential 保護は token で行うのは必須
API Days (イベント)
API 保護に OAuth 2.0 は必須
しかし OAuth を使えば全て解決というわけではない
- OAuth はフレームワークである
- 適切な部品を組み立てねばならない
- 個別の状況に応じたプロファイルが必要
RFC 6749 - The OAuth 2.0 Authorization Framework
- 発信者 (sender) 認証
- 受信者 (receiver) 認証
- メッセージ (message) 認証
  - OAuth 2.0 関連のオプション機能とそれぞれのセキュリティレベル（表）
  - 認証要求・応答の種類とセキュリティレベル（表）
    - レベル低; Bearer Token (持参人トークン) → 電車の切符*6
    - レベル高; Sender Constrained Token (記名式トークン) → 飛行機のチケットとパスポート*7
  - 1 クライアント 1 認可サーバ
    - 認可サーバ毎に redirection url を用意する（Mix-in 攻撃を防ぐ）
  - メッセージ認証
    - response_type, xxx
    - code, state
  - メッセージ送信者認証
  - メッセージ受信者認証
    - カスタムスキームでのハイジャック etc.
    - RFC 7636 - Proof Key for Code Exchange by OAuth Public Clients
OAuth と Identifier は別モノ
メッセージ秘匿性
トークン・フィッシング／トークン・リプレイ
BCM Principles
- (a) Unique Source Identifier
- (b) Protocol + version + message Identifier
- (c) Full list of actors/roles
  - 例: Client ID は global に unique ではない
    - redirect url と組み合わせて unique にする for (a)
    - recommend の state を require にする for (c)
- AuthZ Request/Response
  - state の hash s_hash
- これらは未検証（Art）
- Darmstadt University Team が検証中（Science）
  - 仕様が、文章の読み方で意味が変わってしまわないようにする、とか
  - スポンサーに OAuth0 ...!
  - openid / fapi — Bitbucket
これからの話
- ネットにつないでいないユーザの認可
  - サーバからユーザのスマフォに push 通知で認可を求める
- 全国銀行協会
- 米銀行の取り組み
OpenID Certified
- これらを正しく実装されたか
- FTC法5条が適用される
  - FTC = 米の公正取引委員会。公取よりよっぽど厳しいらしい
  - 虚偽の申告は他者が指摘可能
  - 正しく取り組んでいる場合は強い保証になる
- Self Certify のための Docker Image も公開
- Self Certify を公開しなくても、チェックのために使える
- スポンサー募集してる
OAuth 2.0 for Native Apps
- IETF 最終提出済み
- webview は使ってはならない、という記述気になる…

パネルディスカッション

司会林タツヤ氏

金融 API はいつごろ触ろう？
- 完全にオリジナルの API をローンチする前に入れた方がいいんじゃないか
ためしに動く FAPI 触りたい開発者はどうしたらいい？サンドボックスとかない？
- openbanking.org のリポジトリにそんなようなものがあったような
- EU の各銀行は期限を決められて（FAPI を）作っているところ。やらないといけない状況なので sandbox も出るだろう
いつからやるか難しくないですか？
- クライアントは JWT が使えればなんとかなるだろうからいつでも
- サーバは、セキュリティやスキーマの FAPI プロファイルが出たら
  - セキュリティとスキーマは別もの
    - すでに取り組んでいる金融システムはある
    - マネフォは FAPI v1 の第一弾
    - Paypal はレガシーメンテ大変らしい(；´∀｀)
  - それに対応しないといけない
  - EU FAPI 登録時には Certificate 通らないと NG
  - ping (?) と forgelock はもう出来てるはず
AISP(readonly), PISP(read/write)
- EU は 1/13 までにやらないといけない。FAPI v2 要求
- FAPI 化されたらスクレイピングするなという空気になるんだろうな
日本 IBM BIAN と FAPI の関係は？
- BIAN 情報ないのでよくわからない
- 世界の認知度は無いが、国内では IBM 強い
- （IBM に頼らないような）チャレンジャーバンクが出てこないとつらいのでは？
  - いるんじゃないかな
EU FAPI
- 銀行 API を、契約によって限定提供してはならない（と決まっている）
- それぞれに考えるのではなく、あくまでも Foundation が定めた仕様にそっている、という状態でないといけない
  - 日本って契約（で限定）ですよね
  - trust api 難しいのでは
日本の金融 API の有名人(?) アツミ氏
- 元 Amazon の AWS エヴァンジェリスト*8
  - 日本も国家レベル（金融庁）でやっていくための行動プラン決めている
  - 金融機関を守るための庁から、消費者を守る庁へ方向転換
  - 消費者の利便性向上に Fintech も進めていく
  - 肝心の金融機関、チャレンジャーバンクの取り組みを理解しない状況がある
金融 API IaaS の動きは？
- IaaS 単体では難しいのでは
- Microsoft とか
- 銀行はオンプレでやるかもだけど、IaaS のようなものは出るのでは