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

デジタルアイデンティティ人材育成推進ワーキンググループ 翻訳サブワーキンググループ 活動報告 ...

デジタルアイデンティティ人材育成推進ワーキンググループ 翻訳サブワーキンググループ 活動報告 / 20250114-OIDF-J-EduWG-TranslationSWG

2025/01/14 開催
OpenIDファウンデーション・ジャパン デジタルアイデンティティ人材育成推進WG:活動報告会
翻訳サブワーキンググループ
発表資料

OpenID Foundation Japan

January 14, 2025
Tweet

More Decks by OpenID Foundation Japan

Other Decks in Technology

Transcript

  1. O‘Reilly Media, Inc.から出版されていた Phillip J. Windley著「Learning Digital Identity」 の翻訳を行いました 【目次】

    1章 アイデンティティの本質 2章 アイデンティティの定義 3章 デジタルアイデンティティの課題 4章 デジタルアイデンティティの原則 5章 関係性とアイデンティティ 6章 デジタル上の関係のライフサイクル 7章 信頼、信用、リスク 8章 プライバシー 9章 完全性、否認防止、機密性 10章 名前、識別子、ディスカバリ 11章 認証と関係の完全性 12章 アクセス制御と関係の有用性 13章 フェデレーション型アイデンティ ティ̶堅固な関係性の活用 14章 暗号識別子 15章 Verifiable Credentials 16章 デジタルアイデンティティアーキ テクチャ 17章 デジタル関係の真正性 18章 アイデンティティウォレットとエ ージェント 19章 スマートアイデンティティエージ ェント 20章 モノのインターネットにおけるア イデンティティ 21章 アイデンティティポリシー 22章 アイデンティティエコシステムに おけるガバナンス 23章 生成アイデンティティ 出所:https://www.oreilly.co.jp/books/9784814400980/ (O’Reilly Japan, Inc. ) 2024年12月出版
  2. 第1章 アイデンティティの本質 デカルト「我思う、ゆえに我あり」から始まり、アイデンティティをデジタルの世界に当て はめるには必要なことが多岐にわたることを紹介した始まりの章 普遍的なアイデンティティシステムなどない 誰が存在を決めているのか 自分 我思う、 ゆえに我あり 他者

    正しい表現とは 束理論 • 紫色 • 球形 • 直径5cm • ジューシーなもの 実体論 未熟 完熟 プラムとは? 戸籍 リ ア ル デ ジ タ ル 誰が存在を決めるのか。その存在はどうしたら正しく表現できるのか? 認証 出自 信頼 真正性 管理 認可 プロトコル 属性 エンテ ィティ ・・・
  3. 第2章 デジタルアイデンティティの定義 関連分野との関係、用語、階層・コントロールの視点、アーキテクチャなど多様な側面があるこ とを紹介した章 アイデ ンティ ティ セキュ リティ プライ

    バシー アイデンティティはセキュリティに使われ、セキュリティはプライバシーに使わ れる。プライバシーはアイデンティティのインプットになる アイデンティティとセキュリティとプライバシー の関係 デジタルアイデンティティの見方 第1層 自分のアイデンティティ 元来自分が持っている 第2層 共有アイデンティティ 他人が決めた 第3層 抽象化されたアイデンティティ グループ化されて割り当てられる 管理 組織等によるの管理下 ユーザー中心 割り当てられた範囲で自由 自己主権 全て自分が決める 階層の視点 コントロールの視点 デジタルアイデンティティをどうとらえるかは、階層による情報精度の視点と、 誰がそれをコントロールするのかの視点がある。 アーキテクチャ 階層型 非階層型 同居 分散型 配置 制御 トポロジー 非集中型 集中型 集中型、非集中型、分散型という整理より、配置と制御の考え方を入れて整理す べきではないか(例:DNSは、制御は非集中、配置が分散で階層型) 配置:アイデンティティシステ ムを同じ場所に配置するか、 分散させるか 制御:コンポーネントが単一の エンティティの制御下にある か、複数のエンティティの制 御下にあるか 各種用語の紹介とそれぞれの関係 識別子、PEP、PDP、認証、アクセス制御などよく使われる用語をアクセスフロー 図を用いて紹介
  4. 第3章 デジタルアイデンティティの課題 デジタルアイデンティティは物理世界でのアイデンティティと異なる点を理解する 物理世界 デジタル そのまま移行できる わけではない • プログラムされたロ ジックに従う

    • 全てを記憶できる • 説明できないロジック • 認識・記憶できないこ とが多い 物理世界 デジタル世界 距離感の問題 すぐそばでやり取りすることができる 相手と物理的に距離が離れる 自律性の問題 自ら考えて行動できる IDシステムの管理下で行動する 柔軟性の問題 属性は数多あり絶えず変化する 属性を容易に追加・変更することができない 同意の問題 明示的に同意が必要なシーンは限られる 取得できる情報が多く明示的に同意を取得する必要がある プライバシーの問題 記憶・認識できる情報に限りがある 全てのデータを記憶できる 匿名性(の欠如)の問題 個を認識せずともやり取りできることが多い トランザクションを識別するためID情報が不可欠 相互運用性の問題 複数のエンティティと自然に連携 別のIDシステムとの連携が容易ではない スケールの問題 非中央集権的な仕組む 単一中央集権的なシステム
  5. 第4章 デジタルアイデンティティの原則 • アイデンティティシステムをメタシステム(=相互運用が可能なアイデンティティシステムの集合体)として機能させる ために必要な原則を記述 →「The Laws of Identity」 「デジタルアイデンティの原則(The

    Laws of Identity)」の内容を理解する 項目 概要 ①ユーザの制御と同意 ユーザー自身が自分のデジタルアイデンティティを制御できる ②制御された利用のための最小限の開示 必要最低限の情報収集・情報開示を実施する ③正当と認められる当事者 収集・開示された必要最低限の情報が知る必要のある主体にのみ開 示される ④方向づけられたアイデンティティ:パブリック識 別子とピア識別子(プライベート識別子)を持つ パブリック識別子:不変で誰でも知ることができる(例:URL) ピア識別子:一時的に利用され非公開(例:ユーザー名) ⑤運用と技術の共存 複数のアイデンティティシステムが関連・共有して共存する ⑥ユーザーの統合 アイデンティティシステムにはユーザ―の存在が組み込まれるべき ⑦特定のコンテキストに依存しない一貫したエク スペリエンス コンテキストが異なってもUXは共通である
  6. 第5章 関係性とアイデンティティ • デジタル上の関係性が持つべき3つの特性 デジタルアイデンティティの数は関係性の数の分存在している 項目 概要 完全性 一連のやり取りで相手が同じエンティティであることを保証する 存続期間

    関係性毎の特性に合わせて存続期間を適合させる 短期的な関係性でよい場合でもデジタル上では匿名性を維持できないケースが多い →一方物理世界ではコンテキストの言うおじて変化していく複数の仮名=「流動的な仮名 性」を使い分けている 実用性 特定の目的にかなった関係性を構築する 通販サイト 関係性A 映画館 関係性B 物理世界 の人間 デジタルアイデ ンティティA デジタルアイデ ンティティB
  7. 第7章 信頼、信用、リスク 7章では信頼(trust)と信用(confidence)の関係に着目し、相互作用とトラストフレームワークがもたらす役割につい て解説されていました 信頼 (Trust) • ある関係性・文脈の中で、自 分にとって利益のある事象・ 期待する事象が起きることを

    第三者に依存(期待)すること ➢ 不確実性が高く、信頼す る側が弱い立場にある ➢ 主観的、演繹的 信用 (Confidence) • 過去の経験や知識に基づき、 得られる結果について予測 可能であること ➢ 不確実性が低く、信頼す る側が弱い立場にない ➢ 客観的、帰納的 信用レベル 要 求 さ れ る 信 頼 レ ベ ル 【信頼が強い例】 個人間の借金 【信頼と信用が複雑に関与する例】 航空会社のエコシステム 【信用が強い例】 ビットコイン トラスト フレームワーク (Trust Framework) 第三者への依存 =リスクをどれだ け取るかが信頼 と信用のバランス につながる ガバナンス (Governance) 法律やルール、 ポリシー等 出自 (Provenance) 社会的立場や評判、 2者間の関係性等 信頼 (Trust) テクノロジー (Technology) OIDC、OAuth、 FIDO、TLS等 忠実度 (Fidelity) 技術の組み合わせや 暗号・認証手段の選択等 信用 (Confidence) ◼ 2者以上が関与する信頼・信用のエコシステムを維持す るために、ガバナンスやテクノロジーを提供する取り決め 例) ➢ プラットフォーム企業 (VisaやUberなど) ➢ ドキュメント (eIDASやNIST SP800-63など)
  8. 第8章 プライバシー 8章ではプライバシーについて、デジタルアイデンティティとの関係性が解説されていました 身体的プライバシー • 人の肉体的な存在と侵襲に対する保護(遺伝子検査、薬物検査等) 地理的プライバシー • 個人の環境に立ち入る能力への権限の付与 通信のプライバシー

    • あらゆる通信手段に対する保護 情報プライバシー • 個人・グループ・組織に関する情報の扱いについて決定するための権限の付与 No. 原則 詳細 1 事後的ではなく事前的、救 済的ではなく予防的 システムや製品にプライバシーを後付けで組み込む のではなく、設計段階から検討すること 2 初期設定としてのプライバシ ー プライバシーが最も保護される状態が初期設定と して設定されること 3 プライバシーを設計に組み込 む ポリシーではなく設計によりプライバシーが保護され ること(=過度に情報を取得しない設計) 4 全機能的―ゼロサムではなく、 ポジティブサム プライバシーとセキュリティの一方を重視し、もう一 方を諦めるのではなく、両方を確保できる設計を 採用すること 5 全般にわたるセキュリティ―す べてのライフサイクルを保護 制約やニーズも考慮して、製品・システムのライフサ イクル全体でプライバシーについて考慮すること 6 可視性と透明性―公開の 維持 取得するデータの種類と目的が明文化され、常に 公開され続けていること 7 利用者のプライバシーの尊重 ―利用者中心主義を維持 する 個人に対して、「サービスの利用と天秤にかからな い同意」、「PIIを修正・削除するためのアクセス」、 「ポリシーと慣習について学び、異議申し立てを行 うためのアカウンタビリティ」 【参考】Privacy by Design (PbD)の概要 デジタルアイデンティティの要素を持つ可能性が高い 通信 情報 トランザクション プライバシー 機密性 プライバシー 真正性
  9. 9章 完全性、否認防止、機密性 9章では、完全性、否認防止、機密性が、デジタルアイデンティティの基本概念であることが紹介されており、特にアイデンティテ ィ管理におけるほとんど全てのアクティビティは、これらの概念のうち1つ以上に依存していると説明されています デジタルアイデンティティの基本概念 デジタル証明書とPKI 鍵 不可逆 鍵システ ム

    可逆 鍵システ ム 秘密鍵で暗号化できるが復号ができない 公開鍵で復号できるが暗号化ができない 秘密鍵 (公開鍵) は公開鍵 (秘密鍵) で暗号化されたメッセージを復号できる 否認防止 否認できないよう保証できること 完全性 改ざんされていないと信頼できること 機密性 内容を特定できないようにすること デジタル証明書 秘密鍵の制御や鍵のすり替え防止のため、下記の仕組みがある ◼ デジタル証明書 ➢ 識別情報を公開鍵に関連付けるデータ構造 ◼ PKI ➢ デジタル証明書が広く使用されるよう、ポリシー、ルール等を提供するサポ ート基盤 ➢ 世界中の何十もの認証局を含むように設計され、各認証局からの証明 書を活用して鍵の正しさを確立する 図9-6 PKIを構成する認証局の階層構造 証明書パス DC3の公開鍵の完全性 ←CA3のデジタル証明書で検証 CA3の公開鍵の完全性 ←CA1のデジタル証明書で検証 CA1の公開鍵の完全性 ←CA2のデジタル証明書で検証
  10. 9章 ゼロ知識証明とブロックチェーン アイデンティティシステムで採用できる最も強力な暗号処理の1つである「ゼロ知識証明」と、”非集中型”の実現方 法としてアイデンティティシステムでも利用されている「ブロックチェーン」について紹介されています 証明したいこと Peggyは、下記の数式でsha256(w)==xとなる値wを知っていることを、wの値を 明かさずVictorに証明したい C(x, ??) =

    ( sha256(??) == x ) 事前プロセス 関数Cと、秘密のパラメータlambdaより、証明鍵pkと検証鍵vkを設定 (pk, vk) = G(C, lambda) プロセス ゼロ知識証明(zkSNARKs) ブロックチェーン ◼ 過去10年間で最もエキサイティングで物議を醸した新技術の1つ ◼ 人々が非集中型のアーキテクチャを求めるのに従い、アイデンティティシ ステムでの利用も増加している ビザンチン将軍問題 悪意ある参加者との合意形成問題 シビル攻撃 多数決を制するため、新しいノードを導入して 投票を有利に進める攻撃 ◼ Succinct (実際の証明に比べてメッセージサイズが小さい) ◼ Noninteractive (双方向でのやり取りが必要ない) ◼ Arguments (数学的な証明ではなく何が正しいという議論) ◼ of Knowledge (知識に関する) Peggy (Prover) prf = P(pk, x, w) V(vk, x, prf) Victor (Verifier) 証明鍵pk、ハッシュ値x、値wを 入力とし、証明”prf”を算出 検証鍵vk、ハッシュ値x、prfを 入力とし、事実かどうかを確認する ”prf”を送信 シビル攻撃への対策 ◼ プルーフオブワーク: 検証の労力を増やすことで、不正行為の費用を高くする対策 ◼ プルーフオブステーク: 不正時の掛け金の没収により、不正行為の費用を高くする対策 ◼ プルーフオブオーソリティ: 新ノード導入時に、信頼できる機関からの参加承認を必要とする対策
  11. 認証要素の多様性 • 知識要素: パスワードやPINなど、ユーザーが知っている情報 • 所有物要素: セキュリティトークンやスマートフォン • 生体要素: 指紋や顔認証

    • 振る舞い要素: タイピングの癖やジェスチャー • 多要素認証 (MFA): 複数の要素を組み合わせることでセキュリティを 強化 第11章 認証と関係の完全性
  12. 12章 アクセス制御と関係の有用性 • 12.1 ポリシーファースト • アクセス制御の考え方は、責任をシステム上でのポリシーとして整えたもの • 最小権限の法則にしたがった権限付与が理想だが、現実には難しい •

    強制するのみのポリシー制御よりも監査で説明責任を担保するという選択肢が存在する • 12.2 認可パターン • 強制アクセス制御(MAC)/ 任意アクセス制御(DAC) • パーミッションシステム / アクセス制御リスト(ACL) • ロールベース(RBAC)/ 属性ベース(ABAC) • 12.3 抽象的な認可アーキテクチャ • 右図のようにあらわされる 認証は、リモートのエンティティが真正であり、アカウントを最初に作成したエンティティと同じエンティティであるということを証明する。 本章でのRelationshipは、ユーザーとシステムの間の関係性も、システム間の関係性も、組織間の関係性も取り扱われている。
  13. 12章 アクセス制御と関係の有用性 • 12.3 抽象的な認可アーキテクチャ • 12.4 アクセス制御ポリシーの表現と管理 • 宣言的なルール言語のXACMLを用いたポリシーの記述方法

    • 12.5 複雑なポリシーセットを扱う • 複雑になるならポリシーは実行可能なコードである必要がある • 12.6 電子証明書とアクセス制御 • 電子証明書を使うと、改ざん耐性のあるパーミッションや認可情報の管理をすることもできる • 12.7 適切な境界の維持 • 認可制御は、ゼロトラストの基礎となっていて、デジタル世界での境界制御の基礎となっている
  14. 13章 フェデレーション型アイデンティティ―堅固な関係性の活用 • 13.1 フェデレーション型アイデンティティの本質 • アカウントの数を減らし負担軽減 • 1つの認証サービスに集中させることで、セキュリティ強化を容易に •

    構築する認証システムを減らし、コスト削減 • 13.2 SSOとフェデレーションの比較 • フェデレーションはSSOより広い概念 • 13.3 クレジットカード業界におけるフェデレーション • Visa(BankAmericard)は銀行・加盟店・消費者に関するフェデレーション Federationの実例とパターンについての説明章
  15. 13章 フェデレーション型アイデンティティ―堅固な関係性の活用 • 13.4 3つのフェデレーションパターン • 13.4.1 パターン1:アドホック・フェデレーション • 個々の組織・システム間での直接のフェデレーション

    • 13.4.2 パターン2:ハブ&スポーク・フェデレーション • 中央のIdPがありそこに多数のサービスがつながるタイプ • ソーシャルログイン(Meta/Google/X/Apple/Amazonなど) • 13.4.3 パターン3:アイデンティティ連携ネットワーク • 参加者間でメタシステム(多数のIdP/RP)で構成されるネットワーク • クレジットカードの決済ネットワーク等 • 安全で保護された環境だけど、金融ネットワークよりアイデンティティネットワークは複雑 • 13.5 信頼の問題に取り組む • 三つのパターンそれぞれにおける信頼(Trust)がどう構成されるか
  16. 13章 フェデレーション型アイデンティティ―堅固な関係性の活用 • 13.6 ネットワークの効果とデジタルアイデンティティ管理 • 分散型アーキテクチャはより安全 • 分散型システムは、商業的または政治的な悪用が起こりにくい •

    分散型アーキテクチャはより優れた耐障害性を備えている • 13.7 フェデレーションの方法と標準仕様 • 13.7.1 SAML • 13.7.2 SAML認証フロー • 13.7.3 SCIM • 13.7.4 OAuth • 13.7.5 OpenID Connect(OIDC) • 13.8 フェデレーションのガバナンス • 実際の接続は何らかの契約がある、標準仕様もガバナンス • 13.9 フェデレーションネットワークの勝利
  17. { "id": "did:example:123", "verificationMethod": [ { "id": "did:example:123#key-1", "type": "Ed25519VerificationKey2018",

    "controller": "did:example:123", "publicKeyBase58": "H3C2AVvLMv6gmMNam3uVAj…PV" }, { "id": "did:example:123#key-2", "type": "JsonWebKey2020", "controller": "did:example:123", "publicKeyJwk": { "kty": "OKP","crv": "Ed25519", "x": "r7V8qmdFbwqSlj26eupPew1Lb22vVG5vnjhn3vwEA1Y" }, } ], "authentication": [{ "id": "did:example:123#z6MkpzW2izkFjNwMBwwvKqmLaQcH…1y4", "type": "Ed25519VerificationKey2018", "controller": "did:example:123", "publicKeyBase58": "BYEz8kVpPqSt5T7DeGoPVUTZcDeX5jGk…oBg" }], "service": [{ "id": "did:example:123#edv","type": "EncryptedDataVault", "serviceEndpoint": "https://edv.example.com/" }], "created": "2022-02-08T16:03:00Z", } 第14章 暗号識別子 DID(分散型識別子)は、中央機関に依存せず、安全性とプライバシーを重視した識別子。 自己証明やピア間信頼を基盤とするKERIなどの新しいモデルも取り上げている。 DID(URI) DIDドキュメント (JSON-DL形式) 分散型台帳など DID解決 DID構文: DIDメソッド例: did:ion did:ethr did:btcr did:sov did:indy did:peer パブリックDID Peer(ピア) DID 分散型台帳など 公開リポジトリに依存 プライベートにDID/DIDドキュメントを交換 X Y 公開鍵暗号 秘密鍵 公開鍵 did: メソッド: メソッド固有識別子 DIDドキュメント例: 所有者 プライバシー向上:◎ 非改ざん証明:◎ Alice Bob 署名や暗号化等に 利用する公開鍵 認証に利用する 公開鍵 DID 検証可能なデータレジストリ
  18. 資格情報 所有者 および 対象者 資格情報 発行者 資格情報 検証者 { "@context":

    [ "https://www.w3.org/2018/credentials/v1", "https://www.w3.org/2018/credentials/examples/v1" ], "type": "VerifiablePresentation", "verifiableCredential": [{ "@context": [ "https://www.w3.org/2018/credentials/v1","https://www.w3.org/2018/credentials/examples/v1"], "id": "http://example.edu/credentials/1872", "type": ["VerifiableCredential", "AlumniCredential"], "issuer": "https://example.edu/issuers/565049", "issuanceDate": "2010-01-01T19:23:24Z", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "alumniOf": { "id": "did:example:c276e12ec21ebfeb1f712ebc6f1", "name": [{ "value": "Example University", "lang": "en" }] } }, "proof": { ★発行者による署名情報 } }], "proof": { ★所有者による署名情報 } } 第15章 Verifiable Credentials 検証可能な資格情報の発行、所有、提示のプロセスを通じて信頼を転送し、ゼロ知識証明・ブラ インド識別子などの利用によりプライバシーリスクを低減。OpenID4VCについても言及。 発行者からのクレームを信頼 クレームに対する クレデンシャルを発行 クレデンシャルを共有 ➢ 完全なクレデンシャルプレゼンテーション ➢ 派生的なクレデンシャルプレゼンテーション ・最小限のクレームの開示が可能(ゼロ知識証明) ・資格情報全体が含まれる → 資格情報を分割できない 完全なクレデンシャルプレゼンテーション例: ・ユニバーサル識別子を使うと名寄せが可能 ・ブラインド識別子により名寄せを回避 →プライバシーリスクを低減 検証可能なデータレジストリ(VDR) 発行者からのクレデンシャル ↓
  19. Root of trustの考え方 Root of trustとは • アイデンティティシステム内の他のコンポーネントが依存する基礎とな るコンポーネントまたはプロセス •

    これにエラーが発生すると、バインディングの完全性が損なわれる • システムはそのアーキテクチャに応じて、複数のRoot of trustを持つこ とができ、システムの信頼基盤を形成する 16章 デジタルアイデンティティアーキテクチャ
  20. アイデンティティアーキテクチャ 管理型アーキテクチャ アルゴリズム型アーキテクチャ 自律型アーキテクチャ ・バインディングではなく管理者を信頼する必要 なアイデンティティモデル ・識別子を認証要素にバインドするRoot of trustが 管理主体

    ・コントローラはパスワードの作成、二要素認証 (2FA)の登録と設定、または鍵の生成によって、認 証要素を生成 ・検証可能なデータレジストリ(VDR)に依存するアイデ ンティティモデル ・コントローラは、DIDまたは他の暗号化識別子に関連 付けられた公開鍵と秘密鍵のペアの形で、認証要素を 生成 ・コントローラは秘密鍵を保持し、公開鍵は、識別子 を導出するために使用 ・公開鍵と秘密鍵はともにVDRに登録され、VDRによ って公開鍵と識別子のバインディングの検証が可能 ・自己主権的な権限のみに依存するアイデンティテ ィモデル ・コントローラは公開鍵と秘密鍵を生成し、識別子 と公開鍵を共有 ・秘密鍵で操作を署名し、バッキングストアに保存 する ・アルゴリズム型や管理型よりいくつかの点で優位 16章 デジタルアイデンティティアーキテクチャ
  21. アイデンティティウォレット 18章 アイデンティティウォレットとエージェント デジタルアイデンティティウォレットとは、 鍵、識別子、Verifiable Credentials(VC)を収集して保持する、安全で暗号化されたデータベース アイデンティティウォレットは、すべての重要なドキュメントと関係を1つの一貫した場所における パスワードマネージャーやAppleのキーチェーンなど のOS固有のツールに保存している 初期のウォレット

    すべてのドキュメントを1つの一貫した場所に保管可能 アイデンティティウォレット ピア関係の管理に使用するバッキングストア Aliceが保有するVC ユーザー名とPW etc. ▪問題点 ・プロプライエタリシステム(ソースコードが未公開) ・ユースケースの種類が厳密に制御されている ・保存できるデータの種類が制限されている ・特定のプラットフォームに縛り付けている ・一貫性のあるユーザ体験にかけている プラットフォームごとに異なる動作 各問題を克服可能
  22. エージェントの役割 アイデンティティエージェントは、ウォレット内のすべてのものを管理するソフトウェアサービス ウォレットが保持するすべてのアーティファクトを格納、更新、取得、削除を実施 エージェント、ウォレット、OSの関係 現在の実装 単一のエージェント、単一のウォレットがペアになっている 他 APIが存在することによって、 ・1つのエージェントが複数のウォレットを使用 ・複数のエージェントが1つのウォレットを使用

    etc. 役割 • 他のエージェントとのメッセージの送受信 • ウォレットに暗号化キーペアを生成するように要求する • ウォレットとの暗号化されたデータのやり取りを管理する • 署名や署名の検証などの暗号化機能の実行 • ウォレット内のデータのバックアップと取得 • DIDドキュメントが更新されたときに他のエージェントと通信することによる関係の維持 • 他のエージェントへのメッセージのルーティング 18章 アイデンティティウォレットとエージェント
  23. 携帯電話を紛失した場合はどうなるか? デジタルアイデンティティウォレット(=暗号鍵を使用するシステム)は、 暗号鍵を使いやすくするだけでなく、攻撃者や単純な損失からも保護することが重要 セキュリティに関する問題を引き起こすシナリオは多数存在する Aliceが携帯電話を紛失した / 電話のロックを解除できない / 暗号鍵を紛失・忘れた /

    ノートPCがハッキングされた / ランサムウェア攻撃の被害に遭った etc. これらの共通項は、Aliceが自分のアイデンティティウォレットを管理するエージェントを制御できなくなったこと 例:公園のベンチでMalfoyに携帯電話を盗まれたことに気づいたAliceを追うとき Aliceが実施すべきこと ステップ1:Aliceが紛失したエージェントの権限を取り消す 他のエージェント(PC,クラウド等)を使用して、紛失した携帯電話の権限を削除 ステップ2:Aliceがリレーションキーをローテーションする 携帯電話の権限を失っても、MalfoyはAliceのピア関係の鍵を使用し、メッセージに署名したり、暗号化したりすることは可 能なため、キーのローテーションが必要 Peer DIDやKERI識別子などの自律型識別子の利点の1つは、関係の基礎となる識別子を変更することなくキーをローテーシ ョンできる 18章 アイデンティティウォレットとエージェント
  24. 自己主権における権威 19章 スマートアイデンティティエージェント DIDComm エージェントが使用するプロトコル 自己主権型インターネットを形成する1つ エージェントはDIDCommにより、(メッセージ交換以外の)他の用途でも利用できるようになる (任意のプロトコルの対話に使用されるエージェントをスマートエージェントと呼ぶ) Oskar van

    Deventerの話:自己主権型のコミュニケーションに必要な9つのこと « 物議を醸す!? Daniel Hardman の提案 相互干渉による説明責任:以下2つを掛け合わせる 1.デジタル透かし :元のドキュメントに暗号署名された追加情報 2.匿名性 :識別情報を暗号化し、パッケージは受信者に。 複合鍵は特定の条件下でのみ受信者に開示する。
  25. スマートエージェントとインターネットの未来 スマートエージェントは、 追加のプロトコルをサポートする機能を備えている / 人々が直面するタスクを支援してくれる 提供する機能 ▪アイデンティと信頼の確立 DIDとVCを交換することで、エージェントはアイデンティ ティを確立し、VCの形で提供可能 ▪関係マネジメント

    時間と共に変化するDID関係がある中で、相互作用のパタ ーンが出現する。それらの変更を管理可能 ▪安全で機密性の高い構造化されたメッセージの共有 交換されたDIDに関連付けられたキーに基づいてメッセー ジの機密性を保証する基本的なメッセージングプロトコル を提供 試験可能な直面するタスク ▪決済と価値交換 コントローラに変わり価値交換 ▪プライベートで安全、かつ信頼できるデータ共有 構造化データをVCとして発行 ▪売買 決済と価値交換を基盤として、企業や個人との商取引のた めのアシスタントとなる ▪所有権の譲渡 財産の譲渡における様々なやりとりを簡素化 ▪モトとの対話 モノとインターネットとのやり取りを簡素化 18章 アイデンティティウォレットとエージェント
  26. 第20章 モノのインターネットにおける アイデンティティ • 現状のIoT • OAuth: 必ずしも所有者がアクセスコントロールの問題に対処できない • メーカー管理下のアカウントに接続して利用される

    →あらゆるデバイスが相互接続し、その処理をユーザーが統合可能な真のIoTに移行する必要があ る • 真のIoT実現のために • 分散化、非階層化、相互運用性をサポートするオープン型のシステム開発が必要 • SSIoT(self-sovereign Internet of Things): 自己主権型のモノのネットワークを築くことが 必要 • デバイスとそれに関するデータ管理を所有者が行える →ファームウェア更新、所有権証明、顧客サービスの改善につながる この章では現在のIoTでアイデンティティを有効にするモデルとプロトコル、真のIoTについて述べられている
  27. 第21章 アイデンティティポリシー • ポリシー:テクノロジーだけでは解消できない課題を解決するために存在 • 標準を参照し、その標準がどのように使用されるかについての詳細な定義を含む • アーキテクチャ上の意思決定を反映、参照する • 優れたポリシーの5属性:実行できる、強制力を持つ、組織の合意がある、理解できる、自発的に採用される

    • ポリシーの作成は下記を踏まえて行うべき • 実行不可能、実行されないポリシーはリリースしない • ポリシーのレビューフレームワークを構築する(ステータス、スケジュールを含むドキュメント) • 運用方法の変更ごとに更新しなくてよい程度に一般化する • 特定の標準や製品の参照は避ける • ベストプラクティスは規定しない • ポリシーは短く、モジュール化する • 人事と法務をレビューのプロセスに含める(ポリシー違反時の対処するため) • ポリシーの作成にはバージョン管理可能なシステムを用いる この章ではガバナンスの基本ツールであるアイデンティティポリシーに焦点を当てており、その作成方法について 述べている
  28. 正統性に直結 ハイブリッド型 アイデンティティ システム 第22章 アイデンティティエコシスムにおける ガバナンス • 各アイデンティティエコシステムで採用されているアーキテクチャのガバナンスがどの様に実現されるか •

    アイデンティティエコシステムの正統性に直結する要素は何か。そしてどの様に享受できるか 適切なガバナンスによって、正統性は保持される ガバナンスの実現手段と重要な要素 自律型 アイデンティティシステム アルゴリズム型 アイデンティティシステム アイデンティティ 管理システム プログラムコード 明確で包括的な 一連のポリシー 組織とシステム (IGA等) アクターの 社会的プロセス ガバナンス フレームワーク ②コンソーシアム組織型 組織運営方法 運営・運用と 検閲耐性 ①自由参加型 相互作用と 社会的プロセス テ ク ノ ロ ジ ー 様々なテクノロジーとプロセスの 組み合わせ 日常で利用するクレデンシャルエコシステムで考える(例:ポイントカード) クレデンシャルと スキーマを定義 アイデンティティの原則を知らない人でも、その正統性を享受して初めて 現実のエコシステムをデジタルに移行可能と言える 物理世界と成功しているデジタル世界のアイデンティティシステムは似た特性がある “どの様に現実世界をデジタル世界で実現するか” クレデンシャル提示 モデルを選択 相互作用のガバナンス フレームワークを提供 アイデンティティエコシステム全体でとらえると メタシステムの選択 エコシステムの明示的/ 暗黙的な技術的選択 ガバナンス 正統性の享受 により これらが
  29. 第23章 生成アイデンティティ • 現在のソーシャルログイン(SL)から、今後出現しつつある自己主権型アイデンティティ(SSI) • ジェネレイティビティとは何か、ジェネレイティビティによってもたらされる世界とは SLメタシステム SSIメタシステム ピア関係が非サポート 利用が制限

    IdPサービスに依存 監視されている脅威 素晴らしい積み重ねにより、成果を生み出した「log in with・・・」 ただし、アイデンティティの原則に照らした課題が内在 アイデンティティの原則によく適合・準拠 非集中型アクターがニーズにあったシステムを定義・構築・展開 ジェネレイティビティ 課題1 課題2 SLに存在する課題とSSIによる解決 アイデンティティシステムの未来、ジェネレイティビティ ②自己主権型アイデンティティ レイヤー2 ①セキュアオーバーレイNW (DIDComm) レイヤー3 ②クレデンシャル交換(VC) SSIスタック ジェネレイティビティは、デジタルライフを可能にし、私たち全員のデジタルのホームを見つけることができる 個人が生き生きとしたオンラインアクティビティを実現 ソーシャルインクルージョンを解決 より良い世界 統一性を持たないオーディエンスによって突然の変化を生み出す 技術の全体的な能力 • プライバシーデザイン • 相互運用性 • 代替可能であり、検閲耐性 自己主権型インターネットの特性から、 自己主権型アイデンティティもジェネレイティビティの特性を持つ ユースケース 多様性 ピアツーピア アドホック 一貫したUX デバイスで アクセス ①自己主権型インターネット • 誰も所有していない(No one owns it) • 誰でも利用できる(Everyone can use it) • 誰でも改善できる(Anyone can improve it) インターネットの特性を引き継いだ自己主権型インターネットは ジェネレイティビティの特性を持つ コスト削減 非集中化 開発容易 自由利用