教育機関におけるBYOIDとKYC
•
1 j'aime•1,237 vues
ID&IT for Education 2018用資料 （speakers deckにアップロードしたものと同一）
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à 教育機関におけるBYOIDとKYC
Similaire à 教育機関におけるBYOIDとKYC (20)
Plus de Naohiro Fujie
Plus de Naohiro Fujie (19)
教育機関におけるBYOIDとKYC
- 2. 自己紹介 • 役割 • 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 -）
- 3. 教育機関の経営とアイデンティティの役割 • 外部から人を呼び込む • 新入生、留学生 • 外部機関からの受け入れ（産学連携など） • 在籍者の管理と保護 • リソース（情報、アプリケーション）の提供と保護 • 在籍している（していた）人への価値提供 • 身元保証機関としての役割
- 4. 教育機関に関係するアイデンティティ 種別 時系列 前 中 後 学生 国内 入学希望者・候補生 在校生 卒業生 留学生 保護者 入学希望者の保護者 在校生の保護者 卒業生の保護者 教員 常勤 希望者・候補者 教員 OB/OG 非常勤 職員 希望者・候補者 職員 OB/OG 業者 常駐 取引希望者・候補者 常駐業者 過去の取引業者 非常駐 非常駐業者 他の機関 他の教育機関 在学生、卒業生 卒業生、共同研究者 卒業生 研究機関 在学生、卒業生 卒業生、共同研究者 卒業生 一般企業（就職先など） 在学生、卒業生 卒業生 卒業生
- 6. 観点によりニーズが異なる • 情報センター • セキュリティ：学内の情報を保護したい • 運用：楽に運用管理を行いたい • 学生課、就職支援課 • 学生とのコミュニケーションを密にしたい • 卒業生の行く先をトラッキングしたい（OB・OG訪問） • IR/広報 • 学生を集めたい • 保護者、卒業生へアピールしたい 2B,2Eの観点 ⇒守り 2Cの観点 ⇒攻め
- 7. 攻めのアイデンティティ（価値を生む領域） 種別 時系列 前 中 後 学生 国内 入学希望者・候補生 在校生 卒業生 留学生 保護者 入学希望者の保護者 在校生の保護者 卒業生の保護者 教員 常勤 希望者・候補者 教員 OB/OG 非常勤 職員 希望者・候補者 職員 OB/OG 業者 常駐 取引希望者・候補者 常駐業者 過去の取引業者 非常駐 非常駐業者 他の機関 他の教育機関 在学生、卒業生 卒業生、共同研究者 卒業生 研究機関 在学生、卒業生 卒業生、共同研究者 卒業生 一般企業（就職先など） 在学生、卒業生 卒業生 卒業生 人を呼び込みたい領域 ⇒教育機関 as RP 在籍している（いた）ことが価値となる領域 ⇒教育機関 as IdP
- 8. 攻めるためのアイデンティティ管理 種別 時系列 前 中 後 学生 国内 入学希望者・候補生 在校生 卒業生 留学生 保護者 入学希望者の保護者 在校生の保護者 卒業生の保護者 教員 常勤 希望者・候補者 教員 OB/OG 非常勤 職員 希望者・候補者 職員 OB/OG 業者 常駐 取引希望者・候補者 常駐業者 過去の取引業者 非常駐 非常駐業者 他の機関 他の教育機関 在学生、卒業生 卒業生、共同研究者 卒業生 研究機関 在学生、卒業生 卒業生、共同研究者 卒業生 一般企業（就職先など） 在学生、卒業生 卒業生 卒業生 人を呼び込みたい領域 ⇒教育機関 as RP 在籍している（いた）ことが価値となる領域 ⇒教育機関 as IdP B2C ID管理の領域 KYCの領域
- 9. B2C ID管理の例：デジタル・マーケティング 顧客の 段階 認知 維持 支持 必要な 機能 匿名での操作 属性鮮度維持 他サービス連携 ユーザ同意の取得・管理 プロファイル管理 実装例 他サービスへの ID連携 コミュニケーション 顧客化 全属性の登録 認証・認可 顧客DB連携（CRM連携） 身元確認プロセスの統合 個別認証、多要素認証、リスク判定
- 10. B2C ID管理の例：デジタル・マーケティング 顧客の 段階 認知 検討 顧客化 維持 支持 必要な 機能 匿名での操作 簡易なID登録 全属性の登録 属性鮮度維持 他サービス連携 ユーザ同意の取得・管理 プロファイル管理 認証・認可 実装例 SNSでの ID登録 追加属性登録 顧客DB連携（CRM連携） 身元確認プロセスの統合 他サービスへの ID連携 コミュニケーション 個別認証、SNS認証連携、多要素認証、リスク判定 離脱防止に SNSでコンテ ンツ提供 顧客化のための 初期登録の簡素化
- 11. 教育機関への応用 学生の 段階 認知 検討 受験 入学 学生 必要な 機能 匿名での操作 簡易なID登録 全属性の登録 学内ID登録 各種ｼｽﾃﾑ連携 ユーザ同意の取得・管理 プロファイル管理 認証・認可 実装例 SNSでの ID登録 学生DB登録 各種システム へのID連携 コミュニケーション 個別認証、SNS認証連携、多要素認証、リスク判定 受験を検討しても らうための 「ゆるい」繋がり 密なコミュニ ケーション 全属性登録 身元確認
- 12. オープンキャンパスのコンバージョン率の向上 • 本登録が不要な部分はSNSで簡素化 • SNSでの簡易サインアップ • イベント情報の配信 • 各種サービス提供 • Wifiログイン • 説明会予約 • 興味を持ってもらったら本登録へ誘導
- 14. コミュニケーション強化によるエンゲージメント • メールや手紙からSNSへ • 休講通知 • 保護者への連絡 • 安否確認
- 15. 慶應義塾様における取り組み • 学内IDとSNS ID（LINE、Facebook）の紐づけ • 一部アプリへのSNS IDでのログイン • SNSへのメッセージ配信 2018/11/19 プレス発表 http://www.ctc-g.co.jp/news/press/20181119a.html
- 16. 2つの話をつなげるとパスワード問題が解ける？ • 入学前は色々とサービス • SNSのフル活用 • 入学後はやっぱりIDとパスワードとメール • 後からSNSを紐づけるにしても一旦はIDとパスワードとメール • 入学前に使っていたSNS IDをそのまま持ち込むことは出来ないか？ • SNSへのメッセージ通知 • SNSログインによりパスワードのいらない世界 • 入学前後の連続性の担保もできるのでPR効果の測定も可能
- 20. KYC：身元保証元としての教育機関の価値 • 教育機関 as Identity Provider • 価値の提供 • 身元の保証 • 在籍している／していたことが価値となる KYC：Know Your Customer。身元確認
- 21. BlockchainはKYC電子化の銀の弾となるのか？ • 各所で絶賛実証実験 • USのケース（EIC） • UKのケース（EIC） • 経産省の取り組み
- 22. US事例）学位の電子化と採用時身元確認の簡素化 European Identity & Cloud Conference 2018より
- 23. UK事例）研修医の身元確認の簡素化 European Identity & Cloud Conference 2018より 控えめに見積もってもドク ターは年間25,000人日かけて 55,000人の研修医の身元確認 を行っている。
- 25. 本当にBlockchainはKYCに向いているのか？ • Blockchainの特徴 • インフラは分散 • No interconnect • Shared nothing • No trust（でも良い） • データは集中 • 系の中に閉じている • Immutabilityが高い • 管理者や少数のノードが悪意を持って値の改竄をしにくい • 系の中でデータが生成され、系から出ない限りは割と安全
- 26. そもそもBlockchainが向いている用途は？ • 集中的にインフラを管理する主体がいない • 信じられるオーソリティがいない • 各ノードの管理をしている主体がお互いを信頼できない • エンドポイントに高い可用性が求められる • 分散ノードで運営される • ノード間での同期が不要（aBFT/Asynchronous Byzantine Fault Tolerance) • 系からデータが出ない（出ると意味がない）
- 28. 考えるべき課題：Blockchain上に何を乗せる？ • プライバシーの観点：参加ノードからデータ可視性 • 利用用途・利用箇所の観点：系の外で生成・利用されるか アイデンティティ情報は載せるデータとして適切なのか？ • プライバシーの観点では向かない • 系の外で生成される、系の外に出てから使われる 系のスコープで解決できるか？ パブリック 公的証明という意味ではアリ、プライバシーの観点で難あり コンソーシアム 参加主体でしか運用出来ない プライベート もはやブロックチェーンの意味はない？
- 29. アイデンティティの前提 • 系の外で生成される • 自分で生成する属性 • 他の主体で生成・付与される属性 • 他者との関係性で生成される属性 • 系の外で利用される • アプリケーション（利用主体）がないと意味がない • 認証 • 認可 • プロファイル表示 • 全てのアプリケーションが系に直接参加するのは非現実的
- 30. Identity on Blockchainは何に使えるのか？ 用途 Immutabilityの 要求 全員から見えて問題 ないか 系内でクローズして 問題ないか Blockchainに向い ているか アイデンティティ情報 なし 問題あり 問題あり （広く使いたい） × 身元確認情報 （証明記録） あり 問題なし？ （プライバシー？） 問題あり （広く使いたい） △ 番外編）セッション管理 （SSO、SLO） * Hashgraphの事例あり あり 問題なし 問題ない（SSO,SLO 範囲） ○ （Private or コン ソーシアム） アイデンティティそのものを載せるのは疑問 Immutabilityを担保したいのはトランザクション記録のみ
- 32. 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.
- 33. 系を跨ぐ：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的な存在）
- 35. 非Blockchainでの取り組み：LIGHTest • DNSベースで信頼を表現 • ドメイン名：エンティティ • PTRレコード：トラスト・リスト • SMIMEAレコード：Verify条件 • ドキュメントのトランザクションが信 頼できるかどうかの検証 • ドキュメント自体の真正性はデジタル 署名
- 36. UNHCR DAPIプログラムでのPoC • 難民支援プログラム。大学に行きたい難民の申請プロセスにおける文 書の確認と承認にLIGHTestのトラスト基盤の利用 • 文書のデジタル化と不正や喪失を防止しアクセス性を向上、UNHCR、 大学、難民の間での転送を簡素化する • https://www.unhcr.org/blogs/new-digital-solutions-refugees- education/
- 39. そもそも何を担保したかったのか 担保対象 Blockchainベース DNSベース（LIGHTest） 文書の真正性 デジタル署名 デジタル署名 トランザクションの 真正性 コンセンサスアルゴリズム 透明性の担保による検証 DNS上に構築された信頼ポリ シー 事前定義された信頼リスト DNSクエリで検証 発行主体の喪失/ねつ 造への対策 チェーンによるImmutability の担保 Delegationの仕組み
- 41. まとめ • 教育機関におけるアイデンティティ管理も攻めの方向へ • 呼び込み：教育機関 as RP • 在籍による価値の付与（身元保証）：教育機関 as IdP • 呼び込みにはB2C IDの手法が活用できる • オープンキャンパスへのSNSの活用 • コミュニケーション改善へのSNSの活用 • KYCの電子化の様々な検討やPoCが行われている • Blockchainベース、DNSベース • 経済的合理性は微妙？