この記事の内容
自己主権型アイデンティティ（Self-Sovereign Identity）に関する動向やその実装技術についてお勉強した内容を整理していきます。
目次
- はじめに
- SSIについて
- SSIのキーファクター
- まとめ
はじめに
最近デジタルアイデンティティの世界で「自己主権型アイデンティティ（Self-Sovereign Identity）」という考え方が注目され始めています。EUや北米では以前からその実用化に向けた取り組みや議論がされており、国内でもブロックチェーン界隈を中心に徐々に話題に上がるようになってきています。なぜブロックチェーン界隈なのかというと、ブロックチェーン技術と相性の良いユースケースだからです。なぜ相性が良いのかという話は後述するとして、今回はSelf-Sovereign Identity（長いので以後"SSI"に省略）の概要と基本的なアーキテクチャについて学んだ内容を整理してみました。
SSIについて
自己主権型アイデンティティとは何か？については、最近インターネット上にわかりやすい記事が増えてきていますので、ここではさらっとだけ触れようと思います。
デジタル技術が進歩しビジネス環境が複雑化していく一方で、アイデンティティ情報は依然として様々な企業のデータベースに分断して保管され、それぞれ異なる方法で管理されています。その為、高度化していくデジタル環境に対応する為のシームレスな認証が出来なかったり、情報漏洩やプライバシーの問題が発生したりと、従来のアイデンティティ管理の仕組みでは限界が見え始めています。それらを解決する新しいアイデンティティ管理の在り方として、SSIが注目されているという訳です。
SSIの考え方においては、個人（あるいは組織、モノ）が自分にまつわるアイデンティティ情報を自分の元に集約し、かつそのコントロール権を有し、従来型のような自分以外の管理主体を介在させないことが特徴です。
SSIの実装を推進するSovrin Foundationの説明では以下のような表現がされています。
"Lifetime portable identity for any person, organization, or thing that does not depend on any centralized authority and can never be taken away."
図解して従来型のデジタルアイデンティティ管理モデルと比較してみます。
例えば何かのサービスを提供するWebサイトでアカウント登録をして、ID/PWで認証するようなイメージが該当します。現時点においては最も普及している認証方法です。
我々のアイデンティティ情報を企業の要求に応じまるっと提供し、企業側がそれを管理している状態であり、個人のアイデンティティ情報が多くの企業にそれぞれサイロ化して管理されています。情報をどう取り扱うかの裁量は企業側にあり、個人情報保護規制等に則る同意確認などはあるものの、アイデンティティの所有者たるユーザーに完全なコントロール権はありません。また、以下のような多くの問題があります。
・ 情報管理サーバーをハッキングされたら大量の個人情報が漏洩するリスクがある
・ サービスが終了してしまったら、紐づいている様々なアイデンティティ情報が失われる可能性がある
・ 同じアカウント名を使い回している場合、悪意ある企業の結託・名寄せにより行動把握をされる可能性がある
・ 一方通行型の認証であり組織側の信用は担保されない為、フィッシングにより個人情報を奪われるリスクがある
・ 大量のID/PWを覚えなければならないといった利便性の問題
上記の利便性の問題を解消する仕組みがこのサードパーティ型です。よくある「Googleアカウントでログイン」「Facebookアカウントでログイン」のような、フェデレーションの仕組みです。シングルサインオンを実現し複数のID/Passwordを管理する必要がなくなる為、認証が簡単になりとても便利ではあります。ただしアイデンティティ情報が組織側（GAFAのようなアイデンティティプロバイダ）で管理されている点は変わりません。上記の中央集権型と同様に情報漏洩、プライバシー侵害、フィッシングなどの問題は解消されていません。
SSIモデルでは従来型のように組織を介在させず、アカウントベースでアイデンティティ情報を管理されることはありません。アイデンティティ情報は個人が所有しており、必要に応じて直接相手に提示するP2P型の管理モデルです。相手というのは、上の図でいう「Peer」が該当します。
イメージとしては、パスポートや免許証、学位証明書といったアイデンティティ情報をスマートフォン上のデジタルウォレットアプリに保管して利用します。現実世界でお財布に身分証を入れているのと同じイメージです。紙の身分証をそれに関する信頼された機関から発行してもらうのと同様に、デジタルアイデンティティ情報も提供元である機関（Peer）からデータとして発行してもらい、デジタルウォレットに保管します。そして何かのサービスを利用する際に、サービス提供者（peer）に対して自分のデジタルウォレットにある情報を必要最小限データとして連携します。そのサービスを利用する資格があると証明するアイデンティティデータそのものを連携する為、ID/Passwordという従来の認証の概念は使いません。そういった意味では、現実世界の対面における本人確認に近い認証モデルと言えます。
上の図で「Connection」という部分がありますが、大事なアイデンティティ情報をデータとして相手とやり取りする以上、通信はセキュアかつプライベートである必要があり、Peerとの間で直接暗号化されたコネクションを確立します。このコネクションは相手のPeer毎に確立し、使い回しません。またセッションベースではなく、永続的に保持しておくことができます。
Connectionの矢印が双方向になっているのは文字通り双方向での認証が可能な仕組みという事であり、自分の認証だけではなくて相手が誰であるかについても認証できます。例えば銀行のサービスをオンラインで使う場合、相手が間違いなく銀行であるということを確認できるということであり、フィッシングの問題を解決します。
概要はこれぐらいにして、次に技術的にどのような仕組みになっているのかをもう少し詳しく見ていきます。
SSIのキーファクター
SSIのアーキテクチャを理解するために重要な要素として、以下の4つを挙げたいと思います。
・Verifiable Credentials
・DID（Decentralized Identifiers）
・Agent
・Blockchain
上記の要素の関係性を絵で表現してみます。
W3CというSSIの標準化を推し進めるコンソーシアムの図をベースに描いており、適当にイメージしたものではないので安心してください。
例として、就活中の学生が身分を証明するために大学にデジタルな学生証（アイデンティティ情報）を発行してもらい企業に提示するケースをイメージします。
まず大学が学生に発行している学生証データが、Verifiable Credentialsに相当します。厳密にはデータを指すのではなく、データをやり取りするためにJSONフォーマットで表現されるデータモデルであり、入れ物です。次に大学・学生・企業がP2P通信でお互いを認識するために、アドレス情報となるエンドポイントが必要です。これがDIDです。そして大学・学生・企業の箱の部分で、それぞれの役割（発行、所有、提示、検証）をシステム上で実行するプロセスがエージェントです。最後に、これらのプロセスでやり取りされるデータの信頼性を担保する仕組みがVerifiable Data Registoryであり、その実装基盤として主流なのがBlockchainです。
一言で言うと、各エージェントがDIDでお互いを識別し、Blockchainでデータの信頼性を担保しつつVerifiable Credentialsのやり取りおよび必要なプロセスを実行するイメージです。
ここで Issuer・Holder・Verifierというキーワードが登場していますが、SSIのアイデンティティ管理モデルでは基本的にこの３つの役割でステークホルダの関係性を表現しています。
Issuer： アイデンティティ情報を発行する組織（今回の例では大学）
Holder： アイデンティティ情報の所有者（今回の例では学生）
Verifier： アイデンティティ情報を受領・検証するサービサーなど（今回の例では企業）
文脈によってはHolderを「Prover」「Subject」と呼んだり、Verifierを「Relying Party」と呼んだり、総称して「エンティティ」と呼んだりしますが、基本はIssuer/Holder/Verifierの３つの役割を理解しておけば大丈夫だと思います。
ちなみに「Verifiable Credentials」と「DID」については、Web技術の標準化を行っているW3C（World Wide Web Consortium）がSSIの普及に向けて技術的な標準仕様を定めており、SSI基盤を提供するプラットフォーマーやソフトウェアベンダはその標準に則った実装をすることが業界の流れになっています。
各要素についてもう少し詳しく説明します。
Verifiable Credentials
まずCredentialとは何かですが、「個人や組織が資格・能力・権利などを保有することを、第三者機関（その事柄に関連する信頼された組織や機関）が証明すること、またはその証明媒体」のように理解しています。平たく言うと証明書です。例えば個人においては運転免許証やパスポートや学位証明書、法人においては登記情報や各種営業許可証などが該当すると思います。このCredentialは現状においてはほぼ紙ベースですが、デジタルの世界でデータとして表現するための手段としてVerifiable Credentialsが提唱されています。身分証明書のような重要なものをデジタルデータとして安全にWeb上でやり取りする事は簡単ではなく、その内容の真正性が保証されなければなりません。そのためのVerifiable（検証可能）な仕組みとしてVerifiable Credentialsがあり、以下の４つを証明することができます。
①誰が発行したか
②誰に発行したものか
③発行後に変更されていないか
④その時点で失効されておらず有効か
①~③については、現実世界の対面のやり取りでも確認は出来ます。ただし目視が基本であり、偽装・改竄されていたらその場では見抜けないかもしれません。発行元に問い合わせて照合まですれば（いわゆるKYC）①~④の確認は出来ますが、手間とコストがかかります。Verifiable Credentialsは①～④を瞬時に、かつ暗号技術ベースで確実に検証することが出来ます。
もう１つ特筆すべき点としては、複数のCredentialをまとめたり、Credentialの一部の項目（Claim）だけ提示したりといった、カスタマイザブルかつ柔軟な証明情報の作成が出来るという事です。よく言われる例だと、バーで20歳以上だということを証明する為には運転免許証を丸ごと提示するのではなく、生年月日の項目だけ相手に伝われば本来OKな訳で、Verifiable Credentialsによるデジタルな認証ではそれが可能になります。名前や住所や持っている運転免許の車種まで相手に知られたくは無い訳で、こういったプライバシーの問題も解決します。
Verifiable Credentialsのデータ構造について少し触れます。
Verifiable Credentialsの実体は下図のような要素で定義されたJSONドキュメントです。
出所：W3C Verifiable Credentials Data Model 1.0
Credential Metadataは文字通りメタデータで、Credentialの名前、種類、発行のタイムスタンプ、発行者、発行先Subjectなどの情報が定義されます。ClaimはCredentialを構成する項目のセットで、例えば運転免許証を構成する氏名、住所などの個々の項目が該当します。Proofは発行者が署名する電子署名に関する情報で、電子署名の規格、作成タイムスタンプ、電子署名のデータ自体やナンス値、公開鍵などの情報が定義されます。
ちなみにVerifiable Credentialsは基本的にIssuerが発行するものですが、Holder本人が発行する事も出来ます。その場合は発行者に関する情報や発行者の電子署名が入らず、裏付けのない自己主張みたいな情報になります。ちょっと用途が思いつきませんが。
出所：W3C Verifiable Credentials Data Model 1.0
W3CのVerifiable Credentials Data Model 1.0ではもう１つ、Verifiable Presentationというものを定義しています。IssuerがHolderに発行する証明書を定義するものがVerifiable Credentialsですが、これをそのまま丸ごとVerifierに提示するのは前述の通りプライバシーの問題がある為、複数のCredentialをまとめたり、Credentialの一部の項目（Claim）だけ提示したりといった事を可能にするための形式がVerifiable Presentationです。
上の図のPresentation Metadataには、Presentationとしてのメタデータが入ります。Presentationの名前や内包するVerifiable Credentialsの名前、使用条件などです。Verifiable Credentialsの部分には、複数のVerifiable Credentialのサブセットが入ります。Proofの部分は上述のVerifiable Credentialsの説明同様に電子署名に関する情報が入りますが、ここでの主体はIssuerではなくHolderの電子署名情報です。
Verifiable CredentialsとVerifialbe Presentationの利用サイクルをまとめると、以下のような流れになります。
・IssuerはVerifiable Credentialを電子署名を付与した形で作成し、Holderに発行する。
・Holderは１つ以上のVerifiable Credentialを使い自分の電子署名を付与した形でVerifiable Presentationを構成する。
・HolderはVerifiable PresentationをVerifierに提示する。
・Verifierは受け取ったVerifiable CredentialsとVerifiable Presentationの信憑性を検証する。
ちなみにVerifiable Credentialsの有効性（その時点で失効していないか）の確認方法についてはW3Cでは定義しておらず、個々のSSIソリューションによって異なる実装をしていると思われます。
DID（Decentralized Identifiers）
DIDはブラウザで表示されるWebサイトの世界におけるURL同様に、SSIの世界において対象を識別するためのURI識別子です。Verifiable Credentialsと同様にW3Cで標準仕様が定められています。時々、Digital IdentityやDecentralized Identityの略称だと勘違いする話を聞きますが、「識別子」としての意味が一般的には正しいです。
DIDはグローバルでユニークとなる識別子であり、DIDの文字列から対応するDID Documentに名前解決されます。URLと異なり特定の管理者やプロバイダを必要とせずに利用者自身で作成可能で、ブロックチェーン等の分散システム上で管理され高可用性を持ち、公開鍵／秘密鍵と組み合わせて利用する事でやりとりの相手が正しい事を検証することが出来ます。
DIDの特徴を3点ほど挙げてみます。
・複数所有する
私は最初この点を誤解していたのですが、自分に紐づくIDをウォレットに１つだけ所有し、それを様々な認証で使うというイメージでした。しかしこれは従来の認証においてでダメな点でもあり、同じメールアドレスをアカウント代わりに使い回すと簡単に複数のアカウントを乗っ取られたり、サービス提供者側で名寄せによる本人推測が出来たりするのと同じ事です。DIDでは相手に応じて都度自分のエンドポイントを意味するDID識別子とそれに対応する秘密鍵を生成し、それぞれの相手との認証だけに利用します。つまりHolderは相手の数に応じて多数のDIDを持つことになりますが、これにより従来型におけるリスクを回避しています。
・自己管理する
DIDの生成も、削除も自分で行います。従来型のIDはIDプロバイダの裁量で削除されてしまいますが、DIDでは秘密鍵を持つ自分だけが削除をすることができます。削除といってもBlockchain上のデータにおいては物理削除は出来ませんので、実際はBlockchain上に公開されている公開鍵を無効化し、参照できなくします。
・Issuerの検証が可能
Verifiable Credentialsには発行元のIssuerのPublic DIDが記載されています。これによりVerifierは、Issuerが誰でCredentialを発行する権限を持っているかを検証することが出来ます。
DID識別子
DIDのフォーマットは以下のようになっています。
出所：W3C A Primer for Decentralized Identifiers
「Scheme」はurnなどと同様にこれが何の識別子を意味するのかを定義するもので、SSIの世界はここは"did"で固定です。「DID method」はどの分散台帳技術に依存した識別子かを定義するもので、例えばBitcoinベースなら"btcr"、Sovrinベースなら"sov"といった感じになります。「DID Method Specific String」はDID Methodで発行されるユニークな文字列です。複数の分散台帳技術のID体系に対応するインターオペラビリティを考慮した構成になっています。
DID Document
次にDID Documentについてですが、DIDはリゾルバを介してDID DocumentというJSONベースの情報を返します。DIDインフラである分散台帳ベースのネットワークを巨大なデータベースと捉えると、DIDがKeyであり、DID DocumentがValueであるというイメージです。DID Documentには以下のような情報が定義されています。
・DID （DID Documentに対応するDIDそのもの）
・公開鍵 （電子署名の検証の為）
・認証方式 （DID主体がどのような認証方式を取るか）
・サービスエンドポイント （相手と情報をやり取りする為に公開するURIなど）
・タイムスタンプ （変更履歴）
・電子署名 （DID主体の電子署名）
JSONのサンプルは以下のような感じです。
出所：Imaginea Labs
DIDとDID DocumentはBlockchainなどの分散台帳に記録されます。Verifiable PresentationとDID Documentの情報を突き合わせる事で、Verifierは証明情報を参照することができ、それが間違いなくIssuerから発行されたものか、発行時点から改竄されていないかなどを検証する事が出来ます。
Public DID / Private DID
最後に、Public DIDとPrivate DIDについて触れておきます。（これはW3Cの標準仕様外の話で、私が現在勉強しているHyperledger Indyの実装に限った考え方かもしれません）
DIDにはPublic DIDとPrivate DID（Pairwise DIDとも言う）があります。Public DIDはBlockchain上で公開されているDIDであり、誰でもアクセス可能でオーナーが誰であるかを知ることが出来ます。そのため、公的機関などのIssuerで利用する事が想定されています。対してPrivate DIDは、当事者がウォレットにのみ保有する非公開のDIDであり、当事者以外知ることが出来ずアクセス出来ません。二者間のダイレクトなやりとりで利用される事が想定されています。このPrivate DIDはBlockchain上には書き込まれない為、管理ノードによる書き込みコストが発生しない事も特徴です。
Agent
AgentとはDIDを介してエンティティ間でコミュニケーションをする為のソフトウェア、もしくはプロセスの事を言います。Holderである個人目線で言うと、スマートフォン上のデジタルウォレットアプリや、ブラウザのExtensionをイメージしてください。IssuerやVerifierとなる組織・企業においてはサーバーアプリケーションの形態を指すことが多いと思います。
特徴としては秘密鍵／公開鍵ペアの生成機能、生成した秘密鍵やCredentialを格納するセキュアなストレージを持ち、テキストや画像情報の送受信や、Credentialsの交換・提示などのトランザクションに利用します。Credentialのストレージと言った部分は、Agent内に持つのではなくクラウドストレージなどを利用する場合もあります。SSIのデジタルウォレットは、パスワードマネージャや仮想通貨ウォレットのイメージに近いですが、SSIの基盤アプリケーションとしての目的がある為、それらとは根本的に異なります。
Blockchain
最後にBlockchainについてです。SSIのアーキテクチャにおいてなぜBlockchainが必要なのか（Why Blockchain?）ですが、一言で言うと「分散型のPKI」を実現する為と個人的には理解しています。現在、Web上でセキュアに情報を授受する技術としてはPKI（公開鍵基盤）とそれを用いた電子署名による認証が主流です。PKIでは初めに公開鍵を双方で授受する必要があり、ここで公開鍵がすり替えられたりなりすましされたりしない為に、公開鍵が本人のものであると証明する電子証明書が必要です。電子証明書はその信頼性を保証するために第三者機関が管理する必要があり、その第三者機関がいわゆる認証局（CA）です。
SSIの思想においては、この認証局に課題があるとされています。中央集権型管理の仕組みの為、認証局側で証明書の改ざんや否認、剥奪を意図的に行う事が出来てしまうリスクがあるという点です。信頼の高い日本の認証局はそんな事しないかもしれませんが、海外ではそうはいかないかもしれません。認証局が組織側の都合で突然クローズしたら、アイデンティティ情報の証明が機能しなくなります。また、SPOFになり得ますので、外部からの攻撃により大量の証明書情報が流出したり、改竄されてしまうかもしれません。
このような課題を解消するために、第三者組織に依存せず、自律分散で恒久的に動きかつ改ざんを防ぐ事の出来る仕組みとして、分散台帳技術（Blockchain等）が要件にマッチします。分散型のPKIでは、やり取りするAgentはそれぞれ自分のDIDとDID Document（公開鍵が含まれる）をBlockchainに記録した上でDIDをpeer間のメッセージングで交換します。そしてDIDからBlockchain上の公開鍵を確認する事が出来ます。また公開鍵はBlockchain上にあり、Verifiable Credentials情報も個人のスマホやクラウドストレージ等にありますので、IDPや認証局がクローズしたとしても、証明情報として利用し続ける事が出来ます。
また別のメリットとしては、Blockchainに記録されるのはDIDとDID Documentのみでアイデンティティ情報自体は記録されない為、DID Documentを再作成すれば異なるBlockchain基盤でもアイデンティティ情報を利用する事が出来るポータビリティ性があったり、DID Documentへのアクセスについて高い可用性を保つ事が出来る点などがあります。
IBM社のウェブサイトにわかりやすい図があったので転載します。
出所：IBM Blockchain Blog
まとめ
SSIの概念や基本的なアーキテクチャについて整理しました。
アーキテクチャの構成要素としては、Verifiable Credentials、DID、Agent、Blockchainの4つを挙げました。これらの要素ですが、以下の図のTechnologyスタックとして各レイヤーで表現されています。
この図は「Trust Over IP Foundation」というデジタルアイデンティティの標準化を推進する団体で定義する、インターネット上のデジタルトラストを実現するための枠組みです。右側のTechnologyスタックを見てみると、Layer1はブロックチェーンなど分散台帳、Layer2はAgentとDIDによるp2p通信、Layer3はVerifiable Credentialsのデータ交換、Layer4がアプリケーションという階層になっており、今回言及した要素がすべて登場します。
これを見てみると、SSIというのは全く新しい技術というわけではなく、既存技術の組み合わせで実現されている仕組みであることがイメージできます。既存技術の組み合わせということは、既存のレガシーシステムからのリプレースや連携におけるハードルが実はそこまで高くないのかもしれません。
以上、SSI技術に関する投稿でした。今後もしばらくSSIに関連する内容を中心に投稿していこうと思います。
[参考]
W3C / A Primer for Decentralized Identifiers
W3C / Verifiable Credentials Data Model 1.0
SSI MeetUp / The Story of Open SSI Standards
Evernym / The Three Models of Digital Identity Relationships
Imaginea Labs / n depth introduction to Self Sovereign Identity