Upgrade to Pro — share decks privately, control downloads, hide ads and more …

教育機関におけるBYOIDとKYC

Naohiro Fujie
December 03, 2018

 教育機関におけるBYOIDとKYC

2018/12/3 ID&IT for Education 2018向けスライド
・教育機関におけるSNS IDの利活用の事例
・身元保証、本人確認とBlockchainの利活用に関する考察

Naohiro Fujie

December 03, 2018
Tweet

More Decks by Naohiro Fujie

Other Decks in Technology

Transcript

  1. 自己紹介 • 役割 • B2C IDをコアとしたビジネス開発担当。大阪から全国をカバー • 書き物など • Blog(IdM実験室):https://idmlab.eidentity.jp

    • 監訳 : クラウド時代の認証基盤 Azure Active Directory 完全解説 • 共著 : クラウド環境におけるアイデンティティ管理ガイドライン • その他活動 • OpenIDファウンデーション・ジャパン理事、KYC WG Chair • 日本ネットワークセキュリティ協会アイデンティティ管理WG • Microsoft MVP for Enterprise Mobility(Jan 2010 -) • LINE API Expert (Feb 2018 -) • Auth0 Ambassador(Sep 2018 -)
  2. 教育機関の経営とアイデンティティの役割 • 外部から人を呼び込む • 新入生、留学生 • 外部機関からの受け入れ(産学連携など) • 在籍者の管理と保護 •

    リソース(情報、アプリケーション)の提供と保護 • 在籍している(していた)人への価値提供 • 身元保証機関としての役割
  3. 教育機関に関係するアイデンティティ 種別 時系列 前 中 後 学生 国内 入学希望者・候補生 在校生

    卒業生 留学生 保護者 入学希望者の保護者 在校生の保護者 卒業生の保護者 教員 常勤 希望者・候補者 教員 OB/OG 非常勤 職員 希望者・候補者 職員 OB/OG 業者 常駐 取引希望者・候補者 常駐業者 過去の取引業者 非常駐 非常駐業者 他の機関 他の教育機関 在学生、卒業生 卒業生、共同研究者 卒業生 研究機関 在学生、卒業生 卒業生、共同研究者 卒業生 一般企業(就職先など) 在学生、卒業生 卒業生 卒業生
  4. 観点によりニーズが異なる • 情報センター • セキュリティ:学内の情報を保護したい • 運用:楽に運用管理を行いたい • 学生課、就職支援課 •

    学生とのコミュニケーションを密にしたい • 卒業生の行く先をトラッキングしたい(OB・OG訪問) • IR/広報 • 学生を集めたい • 保護者、卒業生へアピールしたい 2B,2Eの観点 ⇒守り 2Cの観点 ⇒攻め
  5. 攻めのアイデンティティ(価値を生む領域) 種別 時系列 前 中 後 学生 国内 入学希望者・候補生 在校生

    卒業生 留学生 保護者 入学希望者の保護者 在校生の保護者 卒業生の保護者 教員 常勤 希望者・候補者 教員 OB/OG 非常勤 職員 希望者・候補者 職員 OB/OG 業者 常駐 取引希望者・候補者 常駐業者 過去の取引業者 非常駐 非常駐業者 他の機関 他の教育機関 在学生、卒業生 卒業生、共同研究者 卒業生 研究機関 在学生、卒業生 卒業生、共同研究者 卒業生 一般企業(就職先など) 在学生、卒業生 卒業生 卒業生 人を呼び込みたい領域 ⇒教育機関 as RP 在籍している(いた)ことが価値となる領域 ⇒教育機関 as IdP
  6. 攻めるためのアイデンティティ管理 種別 時系列 前 中 後 学生 国内 入学希望者・候補生 在校生

    卒業生 留学生 保護者 入学希望者の保護者 在校生の保護者 卒業生の保護者 教員 常勤 希望者・候補者 教員 OB/OG 非常勤 職員 希望者・候補者 職員 OB/OG 業者 常駐 取引希望者・候補者 常駐業者 過去の取引業者 非常駐 非常駐業者 他の機関 他の教育機関 在学生、卒業生 卒業生、共同研究者 卒業生 研究機関 在学生、卒業生 卒業生、共同研究者 卒業生 一般企業(就職先など) 在学生、卒業生 卒業生 卒業生 人を呼び込みたい領域 ⇒教育機関 as RP 在籍している(いた)ことが価値となる領域 ⇒教育機関 as IdP B2C ID管理の領域 KYCの領域
  7. B2C ID管理の例:デジタル・マーケティング 顧客の 段階 認知 維持 支持 必要な 機能 匿名での操作

    属性鮮度維持 他サービス連携 ユーザ同意の取得・管理 プロファイル管理 実装例 他サービスへの ID連携 コミュニケーション 顧客化 全属性の登録 認証・認可 顧客DB連携(CRM連携) 身元確認プロセスの統合 個別認証、多要素認証、リスク判定
  8. B2C ID管理の例:デジタル・マーケティング 顧客の 段階 認知 検討 顧客化 維持 支持 必要な

    機能 匿名での操作 簡易なID登録 全属性の登録 属性鮮度維持 他サービス連携 ユーザ同意の取得・管理 プロファイル管理 認証・認可 実装例 SNSでの ID登録 追加属性登録 顧客DB連携(CRM連携) 身元確認プロセスの統合 他サービスへの ID連携 コミュニケーション 個別認証、SNS認証連携、多要素認証、リスク判定 離脱防止に SNSでコンテ ンツ提供 顧客化のための 初期登録の簡素化
  9. 教育機関への応用 学生の 段階 認知 検討 受験 入学 学生 必要な 機能

    匿名での操作 簡易なID登録 全属性の登録 学内ID登録 各種システム連携 ユーザ同意の取得・管理 プロファイル管理 認証・認可 実装例 SNSでの ID登録 学生DB登録 各種システム へのID連携 コミュニケーション 個別認証、SNS認証連携、多要素認証、リスク判定 受験を検討しても らうための 「ゆるい」繋がり 密なコミュニ ケーション 全属性登録 身元確認
  10. 2つの話をつなげるとパスワード問題が解ける? • 入学前は色々とサービス • SNSのフル活用 • 入学後はやっぱりIDとパスワードとメール • 後からSNSを紐づけるにしても一旦はIDとパスワードとメール •

    入学前に使っていたSNS IDをそのまま持ち込むことは出来ないか? • SNSへのメッセージ通知 • SNSログインによりパスワードのいらない世界 • 入学前後の連続性の担保もできるのでPR効果の測定も可能
  11. 典型的な新入生登録プロセス 新入生 入試・学生課 入学書類の提出 書類の確認と 学生IDの登録 ディレクトリへの ID登録、初期パス ワード生成 学務システム

    情報センター ディレクトリ 学生課 ID、初期パスワード 一覧の共有 オリエンテーションで ID、初期パスワードの 通知 初回ログインと パスワード変更
  12. 初期パスワード問題 新入生 入試・学生課 入学書類の提出 書類の確認と 学生IDの登録 ディレクトリへの ID登録、初期パス ワード生成 学務システム

    情報センター ディレクトリ 学生課 ID、初期パスワード 一覧の共有 オリエンテーションで ID、初期パスワードの 通知 初回ログインと パスワード変更 物理(オフライン) の世界 デジタル(オンライン) の世界 物理とデジタルの橋渡しをするのに パスワードは都合が良い
  13. KYC:身元保証元としての教育機関の価値 • 教育機関 as Identity Provider • 価値の提供 • 身元の保証

    • 在籍している/していたことが価値となる KYC:Know Your Customer。身元確認
  14. 本当にBlockchainはKYCに向いているのか? • Blockchainの特徴 • インフラは分散 • No interconnect • Shared

    nothing • No trust(でも良い) • データは集中 • 系の中に閉じている • Immutabilityが高い • 管理者や少数のノードが悪意を持って値の改竄をしにくい • 系の中でデータが生成され、系から出ない限りは割と安全
  15. 考えるべき課題:Blockchain上に何を乗せる? • プライバシーの観点:参加ノードからデータ可視性 • 利用用途・利用箇所の観点:系の外で生成・利用されるか アイデンティティ情報は載せるデータとして適切なのか? • プライバシーの観点では向かない • 系の外で生成される、系の外に出てから使われる

    系のスコープで解決できるか? パブリック 公的証明という意味ではアリ、プライバシーの観点で難あり コンソーシアム 参加主体でしか運用出来ない プライベート もはやブロックチェーンの意味はない?
  16. アイデンティティの前提 • 系の外で生成される • 自分で生成する属性 • 他の主体で生成・付与される属性 • 他者との関係性で生成される属性 •

    系の外で利用される • アプリケーション(利用主体)がないと意味がない • 認証 • 認可 • プロファイル表示 • 全てのアプリケーションが系に直接参加するのは非現実的
  17. Identity on Blockchainは何に使えるのか? 用途 Immutabilityの 要求 全員から見えて問題 ないか 系内でクローズして 問題ないか

    Blockchainに向い ているか アイデンティティ情報 なし 問題あり 問題あり (広く使いたい) × 身元確認情報 (証明記録) あり 問題なし? (プライバシー?) 問題あり (広く使いたい) △ 番外編)セッション管理 (SSO、SLO) * Hashgraphの事例あり あり 問題なし 問題ない(SSO,SLO 範囲) ◦ (Private or コン ソーシアム) アイデンティティそのものを載せるのは疑問 Immutabilityを担保したいのはトランザクション記録のみ
  18. MITのケースも結局はトランザクション記録? Anatomy of a digital diploma: The presentation layer has

    a customized image of a traditional MIT diploma; the content layer contains code with the student’s public key and generates the image; and the receipt layer proves the transaction has been recorded on the blockchain.
  19. 系を跨ぐ:DIDとUniversal Resolver • DID(Decentralized Identifier):W3Cが標準化を推進 • DID • did:{method}:{method-specific identifier}

    ⇒Sovrinの場合の例:did:sov:12345679 • DID Document(メタデータ) • 公開鍵、エンドポイント、Proof、timespamp等 • Universal Resolver • DIDからDID Documentの解決を行う (DNS的な存在)
  20. 非Blockchainでの取り組み:LIGHTest • DNSベースで信頼を表現 • ドメイン名:エンティティ • PTRレコード:トラスト・リスト • SMIMEAレコード:Verify条件 •

    ドキュメントのトランザクションが信 頼できるかどうかの検証 • ドキュメント自体の真正性はデジタル 署名
  21. そもそも何を担保したかったのか 担保対象 Blockchainベース DNSベース(LIGHTest) 文書の真正性 デジタル署名 デジタル署名 トランザクションの 真正性 コンセンサスアルゴリズム

    透明性の担保による検証 DNS上に構築された信頼ポリ シー 事前定義された信頼リスト DNSクエリで検証 発行主体の喪失/ねつ 造への対策 チェーンによるImmutability の担保 Delegationの仕組み
  22. まとめ • 教育機関におけるアイデンティティ管理も攻めの方向へ • 呼び込み:教育機関 as RP • 在籍による価値の付与(身元保証):教育機関 as

    IdP • 呼び込みにはB2C IDの手法が活用できる • オープンキャンパスへのSNSの活用 • コミュニケーション改善へのSNSの活用 • KYCの電子化の様々な検討やPoCが行われている • Blockchainベース、DNSベース • 経済的合理性は微妙?