TMD45'β'LOG!!!

Life is Beta-ful.

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

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

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

blog.tmd45.jp

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

前提

  • EU の PSD2(決済サービス司令2)*1
  • 日本
    • 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
  • pages.nist.gov/800-63-3
  • 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
      • メッセージ送信者認証
      • メッセージ受信者認証
  • 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 の有名人(?) アツミ氏
    • AmazonAWS エヴァンジェリスト*8
      • 日本も国家レベル(金融庁)でやっていくための行動プラン決めている
      • 金融機関を守るための庁から、消費者を守る庁へ方向転換
      • 消費者の利便性向上に Fintech も進めていく
      • 肝心の金融機関、チャレンジャーバンクの取り組みを理解しない状況がある
  • 金融 API IaaS の動きは?
    • IaaS 単体では難しいのでは
    • Microsoft とか
    • 銀行はオンプレでやるかもだけど、IaaS のようなものは出るのでは

合わせて読んでみた

▲ ページトップへ移動