tomoima525's blog

Androidとか技術とかその他気になったことを書いているブログ。世界の秘密はカレーの中にある！サンフランシスコから発信中。

Self-Sovereign Identity の概要と考察


Self-Sovereign Identity を読了したので、自分の頭の整理も兼ねて、本書籍の概要と考察をまとめます。

概要

本書は近年アイデンティティの新たな管理技術として注目されている Self-Sovereign Identity について、その発展や技術要素、現実世界におけるユースケースなどについて網羅的に解説しています。なお、Self-Sovereign Identity は日本語だと”自己主権型アイデンティティ”と訳されるようですが、以降は書籍にならって SSI と書きます。

特に前半の章では SSI の基幹技術である Decentralized Identifier(DID)や Verifiable Credential(VC)、Blockchain、Cryptography について詳しく説明されており、ブロックチェーン技術や dApps のようなブロックチェーンアプリケーションを扱う人であれば、目を通すだけで技術の理解や応用の幅が広がります。

各パートの要点

全部で 24 章、４つのパートに分かれています。ここではパートごとに重要なポイントなどをまとめていきます。

Part1 SSI の紹介

なぜ今 SSI が注目を浴びているのか

  • もともとのインターネットは研究者が使う前提で、規模も小さく、誰が誰であるかが明らかであった
  • 商業利用としてインターネットが拡大してから、アイデンティティにまつわる課題が表出するようになり、Identity 管理の解決策が模索されている。ソーシャルログインなどはその解決策の一つとして生まれた
  • 現状の中央集権的アイデンティティモデルの課題
    • ソーシャルログインのポータビリティ(サービスがなくなることによる ID の喪失)
    • サードパーティへの個人情報の提供によるプライバシーやセキュリティリスク

  • SSI とは?

    • 他に依存しない個人のアイデンティティ。第三者ではなく、個人が管理する。
    • Issuer:発行者(政府、機関、雇用者)がクレデンシャルを個人に提供し、個人はそのクレデンシャルを digital wallet で管理する
    • Verifier:検証者は個人に必要なクレデンシャルを要求し、検証する。検証はクレデンシャルに紐付く検証可能なデータを確認したり(Verifiable Data Registry)、ブロックチェーンを利用して暗号学的に行う(Zero-Knowledge proof)
      SSIのデザイン(書籍より)

  • SSI 普及への課題

    • wallet の鍵管理
    • オフラインでの利用
  • 現実世界でのシナリオ
    • 例:銀行口座の開設 — 政府や雇用者が VC を発行し、銀行は個人から提供された VC を確認して口座開設を承認する。すべては digital wallet に紐ついた端末を経由して行われる

Part2 SSI の技術要素

SSI の 4 階層モデル

4階層モデル(書籍より)

  • Layer 1: Utilities — DID の管理を定義する層。分散化されたアイデンティティの管理の要件を検討した結果、現在はブロックチェーンが主流となっているが、別にブロックチェーンに限らなくとも良い
  • Layer 2: Providers — DID 間や検証者との通信やプロトコルを定義する層。アプリケーションによって幾つかの手法がある(API-oriented, Data-oriented, Message-oriented)
  • Layer 3: Credentials — クレデンシャルを信頼する仕組みを定義する層。SSI の core とも言える。いわゆる Holder - Issuer - Verifier の三角関係と VC の仕様はこの層で設計されている
  • Layer 4: Governance — クレデンシャルの正当性を定義する層。クレデンシャル信頼性に関するポリシーを定義する(後述)
  • Layer 1 と Layer 2 は技術的信頼性に関する層、Layer 3 と Layer 4 はアプリケーションレベルの人と人の信頼性に関する層

Verifiable Credentials

  • 検証可能なデジタル証明
  • 複製や盗難が非常に難しく、選択的に公開情報を個人が選べることで、プライバシーにも配慮
  • 発行者あるいは個人によって容易に期限を設定したり、破棄できる
  • Verifiable Data Registry(VDR)
    • VC の検証プロセスに必要なメタデータなどが保持されている、インターネット上のストレージシステム。発行者の公開鍵情報、権限をもつドキュメントなど
    • VDR は VC の検証システムを成立させるために必要な技術であり、そのデータがどのように、例えば中央集権的に管理されていても問題はない
    • VDR を通じて VC の改ざんを検知する方法を提供する(tamper-evidence)どのようなシステムにおいても改ざんを防ぐことはできないが、改ざんされたとわかった場合は VC を無効にできるようにする
  • VC のデータ規格
    • w3 org では JSON-Linked Data をベースに規格が定義されている
    • issuer, proof, credentialSubject などの情報が含まれる
  // JSON-LDの例
{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://schema.org"
  ],
  "id": "http://example.edu/credentials/58473",
  "type": ["VerifiableCredential", "Person"],
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "alumniOf": "Example University"
  },
  "proof": { ... }
}

Decentralized Identifier(DID)

  • リソースをユニークに特定する文字列(識別子)。”リソース”とは人に限らず、個別に特定できるあらゆるもの。W3C の定義(https://www.w3.org/TR/did-core/)では did: で始まる文字列とされている
  • W3C によって提案された DID の 4 要素
    • 永続化された識別子
    • 名前解決ができる。ID から情報をひっぱってこれる
    • 暗号学的に所有していることを示すことができる。公開鍵/秘密鍵と紐付く。
    • 中央集権的な登録システムが存在しない、いわゆるパーミッションレス

didの規格(書籍より)

  • DID が解決していること
    • 既存の公開鍵構造(PKI: Public Key Infrastructure)では、公開鍵が誰に制御されている(誰が生成したか)が定かではない
    • DID では公開鍵を元に DID を生成し、DID を含む データ(DID Document)に秘密鍵でサインをすることで、公開鍵の生成者と DID の紐付けを行う。これにより誰が所有者かを明示できる

did document(書籍より)

Digital Wallet

  • Holder が鍵、VC や個人情報などを管理するためのソフトウェアないしはハードウェア
  • 厳密には Wallet と Agent と区別される
  • Wallet — 暗号化されたストレージや鍵管理の仕組みを持つ
  • Agent — メッセージやバックアップ、他の DID とのコミュニケーションを管理する
  • Wallet における VC の管理
    • Wallet は独立しているため一度発行された VC を無効化する方法は主に 2 つしかない
    • VC に expiration date を設定する
    • Issuer が VDR に VC のステータスを確認するためのデータを設置し、Verification process においてその VC が提示されたときに VDR から無効化されていないかを確認する

Decentralized Key management(DKMS)

  • 一般的に、デジタル鍵の管理は難しい
    • 物理鍵と違い、遠隔で盗まれる可能性があったり、盗まれた場合の損失が大きい
  • この領域のアイデアとして提案されているのが DKMS。基本的なアイデアとしては peer-based な鍵管理のシステム

Governance Frameworks

  • コミュニティや業界、国などが構築した SSI のシステムにおけるガバナンス、すなわちポリシーを定義する層。ポリシーはシステムごとに異なる
  • Governance Frameworks で定義することの例
    • 権限の移譲 — すべての人が自らの個人情報を管理したいと考えてはいない。現実世界では代わりに管理する人がいる(例. 銀行員、弁護士、会計士…)同様に SSI においても権限を移譲できるルール作りが必要
    • 信頼の透過的な適用 — SSI では、ブロックチェーンのインターオペラビリティを利用して、他のコンテキストで構築された信頼を別のコンテキストで利用するルールが設定できる。例えば学校のシステムで利用された VC を旅行のネットワークで適用できるようなルールを構築できる
    • 信頼の構築方法 — 評価や信頼を SSI に蓄積できる仕組み
  • 誰が Governance Frameworks を作り、管理するか
    • そのコミュニティでうまく機能する立場の組織
  • Governance Frameworks の定義に必要な要素
  • Governance Frameworks における法的処置
    • システム内における違法行為にどう対応するか。また GDPR などの政府機関による法令を遵守していくか
    • コミュニティによる監視や他のリソースからの評価システム
    • 法務を担当するメンバーとの協力

Part3 分散化と人生

SSI がどのような思想に根ざしているかの話。

Part4 SSI が事業をどう変えるか

SSI をビジネスとして扱う上でどう実践していくべきかの話。

SSI の価値を伝える

  • 過去さまざまな方法で SSI の説明がなされており、失敗も重ねてきた
  • 技術や哲学の観点から説明するアプローチは失敗してきた
    • オーバーエンジニアリングである、組織に対してのメリットが見いだされない etc
  • ストーリーテリングが重要
    • 現状の認証システムと比較してどういう変化があり、どのようなメリットがあるのかを現実の出来事に照らし合わせて説明する

現実世界での SSI のユースケース

要点まとめ

個人的には Part 1, 2, 4 は読むべきパートです。Part 3 は思想が強めにでているので、話としては興味深いですが、読む必要はないと思います。

考察

ここでは本書を読んで気づいたことについて考察します。

Web3 と Self-Sovereign Identity の違い

Web3 も SSI もブロックチェーンを基盤としたアイデアであるものの、その思想は大きく異なることは目からウロコでした。

Web3 ではシステムはトラストレスであることが基本原理(https://ethereum.org/en/web3/#what-is-web3)として掲げられています。一方 SSI においては、いかに既存のトラスト(信用)を活用してシステム自体の信用を高めるかということが重要視されています。例えば VC は政府など発行者の信用を担保に検証しますし、SSI の最上位層である Governance Framework ではシステムとして信用を保つためのポリシーを定義します。

Web3 はネットワーク上の個人の所有権から端を発している一方で、SSI はネットワーク上のどうアイデンティティを管理するかが起点となっています。お互いにブロックチェーンがたまたま実現方法としてフィットしているだけで、目的や用途は全く異なるものなのだなと理解しました。

難しいのは、現状 Web3 の視点のほうが広く認知されているので、その文脈で SSI を捉えると、トラストフルで不完全であると認識されてしまう点です。今後の SSI の取り組むべきこととして、理念から人々に伝えていく必要性があると感じました。

SSI と Abstraction Account

本書は 2021 年に出版されたこともあり、SSI の課題である鍵管理に関して、Decentralized Key management system と multi-sig が提案されているにとどまっています。しかし最近にわかに注目を浴びている Abstraction Account によって、wallet 管理が劇的に変化することが予想されます。DKMS はその複雑性から実装は現実的ではなく、AA に取って代わられる可能性は高いと感じます。

SSI の実世界での運用

現状 SSI は安全な鍵管理など、まだ解決しなくてはいけない課題がありますが、既存の社会システムを活かして分散化したアイデンティティ管理ができる点や複数の信用を紐付けられる点において今後さらに発展することを予想しています。すでに EU での ID 管理システムでも一部利用されているように、個人データを安全に管理したい政府が活用するメリットは非常に大きく、またそれによって SSI の信用も高まり普及につながりそうです。

最後になりますが、偽名で働く人のHRサービスであるわれわれの Noxx でも VC をベースとするシステムを構築しています。詳しくはこのブログをご覧ください。

https://mirror.xyz/tomo.eth/UtI783tK2pcXBVzXkpMj1WAKK19UQf_iOntcU1ZVDIE