Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

金融 API 時代のセキュリティ: OpenID Financial API (FAPI) WG

7,257 views

Published on

金融分野におけるAPIのセキュリティ水準を確保する観点から、詳細仕様の標準化が検討されているFinancial APIの現状について、海外の動向なども踏まえながら説明する。

Published in: Internet
  • Hey guys! Who wants to chat with me? More photos with me here 👉 http://www.bit.ly/katekoxx
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

金融 API 時代のセキュリティ: OpenID Financial API (FAPI) WG

  1. 1. Nomura Research Institute 崎村 夏彦(@_nat) 金融 API 時代のセキュリティ: OpenID Financial API (FAPI) WG • OpenID® は、 OpenID Foundation の登録商標です。 • *Unless otherwise noted, all the photos and vector images are licensed by GraphicStocks. 2017年9月11日 米国OpenID Foundation 理事長 上席研究員 #apijp API Meetup #21
  2. 2. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 2 JWT JWS OAuth PKCE OpenID Connect
  3. 3. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 3 崎村夏彦(Nat Sakimura) 著作: OpenID Connect Core 1.0 JSON Web Token [RFC7519] JSON Web Signature [7515] OAuth PKCE [RFC7636] OAuth JAR [IETF Last Call] Etc. Editor of: ISO/IEC 29184 Guidelines for online notice and consent ISO/IEC 29100 AMD: Privacy Framework – Amendment 1 ISO/IEC 27551 Requirements for attribute based unlinkable entity authentication Etc. • OpenID Foundation 理事長 • Financial API WG議長 • ISO/IEC JTC 1/SC 27/WG5国内 小委員会主査 • WG5〜OECD/SPDEリエゾン • 野村総合研究所上席研究員 • https://www.sakimura.org • https://nat.sakimura.org • @_nat_en (English) • @_nat (日本語) • https://www.linkedin.com/ in/natsakimura • https://ja.wikipedia.org/wi ki/崎村夏彦 3
  4. 4. Copyright(C) Nomura Research Institute, Ltd. All rights reserved. 4 自己紹介 OpenID Foundationとは FAPI WGとは? FAPI Part 1 & 2 FAPI Part 3 and beyond Certification もくじ
  5. 5. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 5 自己紹介 OpenID Foundationとは FAPI WGとは? FAPI Part 1 & 2 FAPI Part 3 and beyond Certification もくじ
  6. 6. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 6 OpenID Foundationとは? 米国オレゴン州非営利法人 Digital Identityに特化した国際標準化団体 (international standardization organization) 国際(international) = 参加に対する地域制限なし 標準化団体(standardization organization) = WTO TBT協定のプロセス に従って、コンセンサスベースで標準規格を作成する団体。 IPR regimeに特徴 特許相互不行使 規格サポートに関する商標(OpenID®) 不正利用取締 相互接続性強化のための規格準拠性認証(Certification) メンバー(スポンサー企業)と参加者 現在のスポンサー企業 ▪ 有料。Member Agreementが必要。理事の選任、WGの生成、規格承認が可能。 参加者(汗をかく人) ▪ 無料。IPR Agreementのみ必要。規格開発作業参加が可能。 6 Sustaining corporate members (理事企業) Corporate members Non-profit members NEC Yubico
  7. 7. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 7 「国際標準規格開発」と「普及・啓蒙・知財管理」がメインタスク 国際標準規格開発 WGで実施  WG一覧は次ページ参照 完全にオープンな開発環境 IPR Agreementに署名さえすれば、無料で 規格開発に参加可能。 Bitbucket (git) で変更管理。 課題(issue)を作成、プルリクエスト送信! 普及・啓蒙・知財管理 OpenID Workshops 各種カンファレンスでのスピーチ Certification OpenID標準の提供サイト運営(安定的 なURL) OpenID®の商標管理 各種団体とのリエゾン関係の管理 7
  8. 8. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 8 OpenID Foundation のワーキング・グループ(WG) WGは3社以上のメンバーの共同提案と Specs Council及び理事会のレビュー(2 週間)によって形成される。 Specs Council は、現在のエディタから選 任され、他のWGや規格作成団体との重 複が無いかなどをチェック。 理事会は、知財的に財団にとってリスクを もたらさないかチェックを行う。 8
  9. 9. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 9 OpenID Financial API (FAPI) WGとは? 9
  10. 10. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 10 OpenID Foundation のFinancial API WG (2016/6組成) 目的 セキュリティ+プライバシープロファイル、 JSON data schema, REST APIs, に関する勧告を提供し、 アプリケーションが金融口座に保管されているデー タを利用すること、 アプリケーションが金融口座とやりとりすること、 利用者がセキュリティとプライバシー設定をするこ と、 を可能にすることである。 銀行・証券口座のみならず、保険およびクレジットカー ド口座も考慮対象とする。 10 (Source) OpenID Foundation Financial API WG draft charterを元に、崎村試訳 JSON REST OAuth OpenID Connect (SOURCE) ODI OBWG: The Open Banking Standard (2016) FAPI WGの詳細情報 ↓ https://openid.net/wg/fapi/
  11. 11. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 11 なぜOpenID Foundationで行うのか? • OAuth, JWT, JWS, OpenID Connect の 全著者が所属 Right People • 無償、相互不主張提供とする知財ポリ シー→だれでも自由に実装可能 Right IPR • WG加盟は無料 (スポンサーは歓迎だが) • WTO TBT 協定準拠のプロセス. Right Structure 11
  12. 12. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 12 作業は、週1回の電話会議(太平洋会議、大西洋会議を隔週で実施)、 メーリング・リスト、 プロジェクト・レポジトリ (https://bitbucket.org/openid/fapi/ )を通じて実施 12 課題管理 議事録など コミット履歴 プル・リクエスト ドラフト・テキスト
  13. 13. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 13 Working Together 13 OpenID FAPI (Chair) (Co-Chair)(Co-Chair) (UK OBIE Liaison) Liaison Organizations TC 68 JTC 1/SC 27/WG 5 Nat Sakimura Tony NadalinAnoop Saxena fido 2.0 WG Chair W3C Web Authn WG Chair
  14. 14. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 14 FAPI仕様群:Financial Services – Financial API – Part 1: Read Only API Security Profile (implementer’s draft) http://openid.net/specs/openid-financial-api-part-1.html Part 2: Read and Write API Security Profile (implementer’s draft) http://openid.net/specs/openid-financial-api-part-2.html Part X: Client Initiated Backchannel Authentication Profile (WD) Part 3: Open Data API (WD) UK OBIE からの寄付待ち Part 4: Protected Data API and Schema - Read only (WD) 銀行口座 - US FS-ISAC DDA / OpenBank Project / Figo などを参考に作成 UK OBIEからの寄付待ち 証券口座 – 現在NRIで試案作成中 Part 5: Protected Data API and Schema - Read and Write (WD) 同上〜Scopeではなく、Claims Requestを使うことで、より詳細・柔軟な認可を取得 14 OpenAPI(Swagger) ファイルを提供。 レジストリ化? ISO 20022?
  15. 15. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 15 自己紹介 OpenID Foundationとは FAPI WGとは? FAPI Part 1 & 2 FAPI Part 3 and beyond Certification もくじ
  16. 16. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 16 Part 1 , 2 の特徴=セキュリティ・プロファイル 16
  17. 17. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 17 え、OAuth使えばそれで 問題解決なんじゃ?!
  18. 18. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 18 “部品を正しく組み合わせることが重 要だ。#oauth を使えば良いと言うだ けでは解決策になっていない。” 18 -- Mark O’Neill, Gartner (SOURCE) Photo taken by Nat Sakimura @APIDays on 13th Dec. 2016 @APIDays Paris 2016 モバイルファーストの時代には, API保護にOAuth 2.0 を使うのは当然だが、 OAuthを使えというだけでは問題解決になっていない。 なぜならば…
  19. 19. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 19 OAuth 2.0 はフレームワーク: 19
  20. 20. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 20 OAuthは「フレームワーク」であることより、様々なサービス環境に 適切に対応できるようになっている。 20 様々なサービス環境に 対応するための 柔軟なオプションを提供 対象の価値 環境制御レベル高 低 高 低
  21. 21. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 21 しかしそれは、個別の状況に応じてプロファイルを用意する必要が あることを意味している。 21 対象の価値 環境制御レベル高 低 高 低 Social sharing Closed circuit Factory application Financial API – Read & Write たとえば: 基本的実装でも OK Bearer token Not OK 基本的実装では ダメ すべてのセキュリティ要件をOAuth 層で満たす必要はない インターネットのように制 御されていない環境下で は、十分注意する必要が ある。 Financial API – Read only
  22. 22. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 22 金融APIのためのプロファイルを作る上では、 複数の要因を考慮する必要がある。 22 これらの多くはしばしば無視され、結果として非常 に危ないOAuth 2.0実装を産んでいる。
  23. 23. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 23 要因の例: 23 1クライアント1サーバの前提 メッセージ認証(要求・応答) 送信者認証 受信者認証 利用者認証 メッセージ秘匿性 トークンフィッシング/リプレイ 金融機関向けのプロファイルは これら全てを解決する必要がある。
  24. 24. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 24 Paraphrased BCM*1 Principles 24 4 Criteria (a)Unique Source Identifier (b)Protocol + version + msg identifier (c)Full list of actor/roles (d)Messages are not tampered Basin, D., Cremers, C., Meier, S.: Provably Repairing the ISO/IEC 9798 Standard for Entity Authentication. Journal of Computer Security - Security and Trust Principles archive Volume 21 Issue 6, 817-846 (2013) *1
  25. 25. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 25 RFC6749 OAuth – code grant protocol メッセージs Authorization Request Authorization Response Token Request Token Response Assume:  a network attacker (e.g. Browser malware) the crypto & TLS are not broken pure RFC6749 – Three parties static OAuth 2.0 25 UA Client AS
  26. 26. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 26 So, how is RFC6749 (Naïve implementation) doing? Message Parameters (a) Unique Source Identifier (b) Protocol + version identifier (c) Full list of actor/roles (d) Message Authentication Authorization Request response type client id redirect uri scope state Authorization Response code state other extension parameters Token Request grant type code redirect uri client credential/client id . Token Response access token token_type expires_in refresh_token others 26 メッセージ種別毎にパラメータ の組み合わせは異なるので、 (b)= Good! Legend Required Parameter Optional Parameter Recommended Parameter でも、喜ぶのはそこまでだ!
  27. 27. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 27 So, how is RFC6749 (Naïve implementation) doing? Message Parameters (a) Unique Source Identifier (b) Protocol + version identifier (c) Full list of actor/roles (d) Message Authentication Authorization Request response type client id redirect uri scope state Client ID is not globally unique. Tampering possible OK, but it is not integrity protected No. No. Authorization Response code state other extension parameters No source identifier OK, but it is not integrity protected No No Token Request grant type code redirect uri client credential/client id Client ID is not globally unique. OK (as long as there is no OAuth 3.0) No. OK Token Response access token token_type expires_in refresh_token others No source identifier As above No. OK 27
  28. 28. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 28 RFC6749における、発信者(sender)・受信者(receiver)・ メッセージ(message)認証(authentication)の状況 28 送信者認証 受信者認証 メッセージ認証 認可要求 Indirect None None 認可応答 None None None トークン要求 Weak Good Good トークン応答 Good Good Good
  29. 29. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 2929 泣けてくる
  30. 30. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 30 OAuth 2.0 関連のオプション機能とセキュリティレベル セキュリ ティ・レベ ル 機能セット 適用 JWS Authz Req w/Hybrid Flow 認可要求の保護 Hybrid Flow*1 (confidential client) 認可応答の保護 Code Flow (confidential client) + PKCE + MTLS code injectionへの対応 長期Bearer Tokenの排除 Code Flow (confidential client) クライアント認証 Implicit Flow クライアント認証無し Plain OAuth Anonymous *1) stateインジェクションの回避のために、‘s_hash’ を含む。 認証要求・応答の種類とセキュリティ・レベル トークンの種類とセキュリティ・レベル セキュリ ティ・レ ベル トークンの種類 適用 記名式トークン (Sender Constrained Token) 発行をうけた者しかトー クン利用不能 持参人トークン (Bearer Token) 盗難されたトークンも 利用可能 30 Part 1 Part 2
  31. 31. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 31 Could be tightened up Message Parameters (a) Unique Source Identifier (b) Protocol + version identifier (c) Full list of actor/roles (d) Message Authentication Authorization Request response type client id redirect uri scope state Unique redirect URI + Client ID OK (Unique Parameter List) (a) + state as the UA identifier / TBID as UA identifier Request signing by JAR Authorization Response code state other extension parameters Unique redirect URI OK (Unique Parameter List) (a) + client_id + state as the UA identifier / TBID as UA identifier Response signing by ID Token + s_hash Token Request grant type code redirect uri client credential/client id Unique redirect URI + Client ID OK (Unique Parameter List) (a) + state as the UA identifier / TBID as UA identifier TLS Protected Token Response access token token_type expires_in refresh_token others Unique redirect URI OK (Unique Parameter List) (a) + client_id + state as the UA identifier / TBID as UA identifier TLS Protected 31
  32. 32. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 32 FAPI RWセキュリティプロファイルでは、送信者・受信者・ メッセージ認証を強化 32 送信者認証 受信者認証 メッセージ認証 認可要求 Request Object Request Object Request object 認可応答 Hybrid Flow Hybrid Flow Hybrid Flow トークン要求 Good Good Good トークン応答 Good Good Good
  33. 33. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 33 実際のFAPI Profileは、 チェックリストになっています。 33
  34. 34. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 34 たとえば、ほんの一部を Part 1: Read Only API Security Profile から抜き出してみると、 注意) keywords が、IETF的なのと違います。(ISOのKeywords, “shall”, “should”, “may”, “can” を使っているため)。 34 (出所)Financial Services – Financial API -- Part 1: Read Only API Security Profile Implementer’s Draft
  35. 35. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 35 これ以外にも、いっぱい “shall” があります。 全部やらないとセキュリティ・レベル、保てません。 35
  36. 36. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 36 Part 1, 2の採用状況は良好 36
  37. 37. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 37 Open Banking Implementation Entity Announcement (17 May 2017)
  38. 38. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 38 欧州 • UK Open Banking は Part 2 (=Part 1を含む)を採用。 現在、CMA9が実装中、来年1月13日にカットオーバー予定。 • ちなみに、Open Banking Profile は、FAPI WG下で現在リファクタリング中。 (https://bitbucket.org/openid/obuk/) • デンマークは、UK Open Bankingを横展開すると見られている。 • ドイツのBerlin Group も採用の方向? 米国 • FS-ISACは、Part 1を採用の見込み。 日本 • 全銀協の「オープンAPIのあり方に関する検討会」における検討結果で言及。 • 金融ISACが設置した「FinTechセキュリティWG」ではどうなるか??? 38
  39. 39. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 39 自己紹介 OpenID Foundationとは FAPI WGとは? FAPI Part 1 & 2 FAPI Part 3 and beyond Certification もくじ
  40. 40. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 40 Part 3, 4, 5 and beyond 40
  41. 41. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 41 Part 3~はWorking Draft == work in progress 1. US FS-ISAC DDAのcontributionを受けてスタート(Part 4)。ただし、UK OBに合わせる かも。 2. Part 3, 5には、UK OBのOpen Data APIs と Read Write APIs の寄付を受けてアップ デートする予定。UK OBのAPIと日本の現状のFit&GapはNRI内部で検討中。ある程度 まとまり次第、WGにSubmit予定。 3. 証券APIは弱いので、現在まずはNRI内部で、どのようなデータモデルなら行けそうか検 討中。ある程度まとまり次第、WGにSubmit予定。 41
  42. 42. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 42 ちなみに、UK Open Bankingをベースにすると、 Part 3, 4, 5はこんな感じに。 42
  43. 43. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 43 Part 3: Open Data API ATM API Specification – v2.0.0 (location, service, and accessibility information about ATMs) Branch API Specification – v2.0.0 (location, service, accessibility, and opening time information about branches) PCA API Specification – v2.0.0 (product information about retail personal current accounts) BCA API Specification – v2.0.0 (product information about retail business current accounts) SME API Specification – v2.0.0 (product information about business unsecured loans) CCC API Specification – v2.0.0 (product information about commercial credit cards) 43
  44. 44. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 44 Part 4 - Account and Transaction API Resource Endpoint Mandatory? Parameters 1 account-requests POST /account-requests Mandatory Pagination 2 account-requests GET /account-requests/{AccountRequestId} Optional Pagination 3 account-requests DELETE /account-requests/{AccountRequestId} Mandatory Pagination 4 accounts GET /accounts Mandatory Pagination 5 accounts GET /accounts/{AccountId} Mandatory Pagination 6 balances GET /accounts/{AccountId}/balances Mandatory Pagination 7 beneficiaries GET /accounts/{AccountId}/beneficiaries Mandatory Pagination 8 direct-debits GET /accounts/{AccountId}/direct-debits Mandatory Pagination 9 products GET /accounts/{AccountId}/product Mandatory Pagination 10 standing-orders GET /accounts/{AccountId}/standing-orders Mandatory Pagination 11 transactions GET /accounts/{AccountId}/transactions Mandatory PaginationFiltering 12 balances GET /balances Optional Pagination 13 beneficiaries GET /beneficiaries Optional Pagination 14 direct-debits GET /direct-debits Optional Pagination 15 products GET /products Optional Pagination 16 standing-orders GET /standing-orders Optional Pagination 17 transactions GET /transactions Optional PaginationFiltering 44
  45. 45. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 45 Part 5 - Resource HTTP Operation End-point Mandatory? Scope Idempotent Request Object Response Object payments POST POST /payments Mandatory payments Yes OBPaymentSetu p1 OBPaymentSetu pResponse1 payments GET GET /payments/{Pay mentId} Optional payments NA NA OBPaymentSetu pResponse1 payment- submissions POST POST /payment- submissions Mandatory payments Yes OBPaymentSub mission1 OBPaymentSub missionResponse 1 payment- submissions GET GET /payment- submissions/{Pay mentSubmissionI d} Optional payments NA NA OBPaymentSub missionResponse 1 45 Payment Initiation API この他にも、Account Creationやら、証券取引やら…。ひょっとしたら、Part 5ではなく、Part 6 … にするのかも。
  46. 46. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 46 User not-in-presence authorizationは どうするのか? 46
  47. 47. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 47 Client Initiated Backchannel Authentication Profile 47
  48. 48. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 48 これらを正しく実装できているか、 どうやったらわかるか? 48
  49. 49. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 49 自己紹介 OpenID Foundationとは FAPI WGとは? FAPI Part 1 & 2 FAPI Part 3 and beyond Certification もくじ
  50. 50. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 50 仕様が正しく実装されているかどうかは、Certification によって 確認できるようにしていく。 オンライン提供されているテスト・スイートを使って、正しく 実装されていることを確認。 結果をSelf Certify して登録・公開 → FTC法5条の配下に入る。これによって信頼性を担保。 また、ログも公開されるので、虚偽の申告は、他者が指摘可能。 現在はOP Certification, RP Certificationが正式提供中。 FAPIにおいても、同様のスキームでテスト可能にする予定。 Certificationの詳細については、 http://openid.net/certification/ 参照 50
  51. 51. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 51 uestions? 51

×