本記事は生成AIと共同で執筆しています。事実関係は可能な範囲で公式ドキュメント・一次情報と照合していますが、誤りが含まれている可能性があります。重要な判断を行う前にご自身でも一次情報をご確認ください。

データスペースの検証をしていると「デジタルアイデンティティ」という語が頻繁に出てきます。ただ、話している相手によって指しているものが違うことが多く、識別子を発行する話なのか、所属を証明する話なのか、本人確認の話なのかで、必要な作業がまったく変わります。手元での実装を通じて整理がついた範囲を書き出しておきます。

この記事は続きものの 1 本目で、概念の整理にあたります。

  1. デジタルアイデンティティとは何か（この記事）
  2. W3C は Verifiable Credentials の何を決めていて、何を決めていないか ── 規格の側から
  3. アイデンティティ・ウォレットの 4 つの機能と、学認のトラストアンカー ── 保持者の側から
  4. Gaia-X Registry には何が入っているのか ── 実際の名簿を開く
  5. 学認のメタデータを開いて読む ── 既存の仕組みを実データで確かめる

3 つの要素に分けて考える

デジタルアイデンティティは単一の技術ではなく、ある主体（人・組織・機器）について「相手が確認できる形で表現された情報と、それを確認する仕組み」の総称です。3 つに分解すると、議論がどこの話なのか判別しやすくなります。

デジタルアイデンティティを 3 つの要素に分解した図。見出しは「デジタルアイデンティティは 3 つの要素の組」、副題は「1 つの技術の名前ではなく、識別子・属性・認証がそろって初めて可否の判断に使える」。上段に 3 つの箱が並ぶ。① 識別子 (Identifier)「その主体を一意に指す名前」で、例として did:web:example、eduPersonPrincipalName、ウォレットのアドレス。② 属性・資格 (Attributes / Credentials)「その主体について主張されること」で、例として所属機関・職位、学位・資格、倫理審査を通過している。③ 認証 (Authentication)「いま操作しているのが本人か」で、例として鍵による署名、パスワード・生体、本人確認済みのカード。各箱の下に「欠けると」どうなるかが赤い箱で示されている。①が欠けると同じ相手を指し続けられず過去の判断と結びつかない、②が欠けると相手が誰かは分かっても可否を判断する材料がない、③が欠けると資格情報を拾った第三者がそのまま名乗れてしまう。最下部に「『デジタル ID を作る』と言うとき、①を発行する話か、②を出す話か、③を確かめる話かで作業が違う」と記されている。

要素中身具体例
識別子 (Identifier)その主体を一意に指す名前did:web:example（DID = Decentralized Identifier、分散識別子）、学認の eduPersonPrincipalName、ウォレットのアドレス
属性・資格 (Attributes / Credentials)その主体について主張されること所属機関、学位、倫理審査を通過している
認証 (Authentication)いま操作しているのが本人かどうか鍵による署名、パスワードや生体認証、本人確認済みのカード

具体的な場面に当てはめると分かりやすくなります。ある研究者が制限のかかった資料にアクセスする場面では、①「この人を指す名前は何か」、②「その人が申請区分に該当する所属や資格を持っているか」、③「いま画面の向こうにいるのがその人本人か」の 3 つが別々に確認されています。紙の運用では、②が身分証明書、③が対面での顔照合にあたり、①は台帳の申請者番号にあたります。デジタルでも確認すべきことは変わりません。

3 つ目が抜けると、アクセス制御は「誰であるか」ではなく「その資格情報という文字列を持っているか」の判定になります。身分証明書のコピーだけで通してしまう状態に近く、コピーが出回れば誰でも通ります。手元の実装でここが埋まっていないことに気づいたのが、この整理を始めたきっかけでした（3 本目の記事で扱います）。

属性が誰を経由して届くか

もう 1 つの軸が、属性の発行元から検証者までの経路です。ここが変わると、発行元が「いつ・どこに提示されたか」を把握するかどうかが変わります。

次の図に略語が出てくるので先に開いておきます。IdP は Identity Provider（属性の発行元）、SP は Service Provider（サービス提供者）、SAML は Security Assertion Markup Language（大学間の認証連携などで使われている規格）です。VC は Verifiable Credentials（検証可能な資格情報）、VP は Verifiable Presentation（その提示物）、SSI は Self-Sovereign Identity（自己主権型アイデンティティ）を指します。それぞれ本文で改めて説明します。

二者モデルと三者モデルを上下に並べた比較図。上段は二者モデル (SAML / OpenID Connect などのフェデレーション)。IdP (属性の発行元、大学の認証基盤など) から SP (サービス提供者、電子ジャーナルなど) へ「属性を直接送る」矢印が引かれ、利用者はブラウザで経由するだけと注記されている。その下に赤い帯で「IdP は、どの利用者がいつどの SP にアクセスしたかを毎回把握する」とある。下段は三者モデル (Verifiable Credentials / SSI)。Issuer (発行者、所属・資格を証明する主体) から Holder (保持者、本人＝ウォレット) へ「VC を発行」、Holder から Verifier (検証者、アクセスを判断する側) へ「VP を提示」の矢印が引かれる。Issuer と Verifier の間は破線で結ばれ、✗ 印つきで「発行者と検証者は直接やりとりしない」と記されている。最下部に「発行者は提示先を知らない。検証者は Issuer の署名を検証するだけで、発行元に問い合わせない。VC は事前に発行されているので、提示の時点で Issuer が稼働していなくても成立する」とある。

学認 (GakuNin) や一般的な OpenID Connect のように、IdP (Identity Provider、属性の発行元) が SP (Service Provider、サービス提供者) へ直接属性を送る形が二者モデルです。この形では IdP が利用者のアクセス先を毎回把握します。図書館や出版社の文脈で長く議論されてきた「認証基盤が閲覧履歴を把握する」という論点は、この構造から来ています。

三者モデルでは、発行者 (Issuer) が資格情報 (VC、Verifiable Credential、検証可能な資格情報) を本人 (Holder) に渡し、本人がそれを検証者 (Verifier) に提示 (VP、Verifiable Presentation) します。検証者は署名を検証するだけなので、提示のたびに発行元へ問い合わせる必要がありません。結果として、発行元は提示先を知らないままになります（失効を確認する仕組みを入れる場合は、発行者側が配る一覧を取りに行くことになるので、この性質は設計次第で変わります。2 本目で扱います）。

VC の実体は、発行者が署名した 1 通のデータです。「誰について」「何を主張し」「いつからいつまで有効か」が書かれていて、末尾に発行者の署名が付いています。紙の証明書と違うのは、署名を機械が検証できることと、複製がいくらでも作れることです。この 2 点目のために、後述する「いま提示しているのが本人か」の確認が別途要ります。VP は、その VC を 1 通以上まとめて提示するときの包みで、本人の署名を足す場所でもあります。

SSI (自己主権型アイデンティティ)

この三者モデルを、原則の側から言語化したのが SSI (Self-Sovereign Identity、自己主権型アイデンティティ) です。Christopher Allen が 2016 年 4 月 26 日の "The Path to Self-Sovereign Identity" で 10 の原則としてまとめたものが、以後よく参照されています。

同記事は、SSI に至るまでを 4 つの段階として整理しています。SSI 自体が第 4 段階にあたります。

  1. 中央集権型 — 単一の権威（認証局やドメイン管理機関など）が識別子の正しさを握る段階
  2. フェデレーション型 — 複数の組織が権限を分け合う段階。利用しやすくはなるが、権限は組織側の集まりに残る
  3. ユーザー中心型 — 同意と相互運用性が重視されるようになった段階。ただし識別子の最終的な保有は登録した事業者側に残る
  4. 自己主権型 — 権威の数によらず、本人が制御する段階

そのうえで挙げられている 10 の原則が次のものです。

原則趣旨
Existence（存在）デジタル上の身元は、独立した実在の主体を土台にする
Control（制御）本人が自分の身元情報の最終的な決定権を持つ
Access（アクセス）本人は自分に関するデータと主張をすべて取り出せる
Transparency（透明性）仕組みとアルゴリズムが公開され、検証できる
Persistence（永続性）身元が長期にわたって存続する
Portability（可搬性）身元情報を別の場所へ持ち出せる
Interoperability（相互運用性）文脈をまたいで使える
Consent（同意）利用には本人の同意が要る
Minimalization（最小開示）必要な範囲だけを開示する
Protection（保護）個人の権利がネットワーク側の都合に優先する

上の三者モデルを、原則の側から言語化したものだと捉えると分かりやすくなります。手元で動かした範囲では、この形にすることで解けるのは次の 2 点でした。

  • 発行元が提示先を把握しない。所属機関が「その研究者がどの資料を見たか」を知らないまま所属を証明できる
  • 判断の根拠が検証可能な形で残る。「誰が許可したか」ではなく「どの発行者が署名したどの主張に基づいて通したか」が、後から第三者に再検証できる形で残る

一方、この形にしても解けないのが「誰を発行者として信じるか」です。署名が正しいことは検証できても、その署名者に証明を出す資格があるかどうかは、署名からは出てきません。ここは別に合意を作る必要があります。この点は 2 本目・3 本目で具体的に見ます。

なお、「自己主権」という語は理念としての側面が強く、実装を見ると本人の手元に残るのは鍵と資格情報の管理までで、発行者やウォレットの提供者への依存は残ります。用語としては強い一方、設計上の含意は上の三者モデルに集約されると捉えておくと、資料を読むときに混乱が少なくなります。

IIIF のような相互運用規格との対比

構造としては、IIIF (International Image Interoperability Framework) のような規格と似た考え方だと捉えると分かりやすい部分があります。IIIF が画像とマニフェストの形を決めることで、配信サーバとビューアが別々の組織の実装でも噛み合うように、Verifiable Credentials は資格情報の形を決めることで、発行側と検証側が別組織でも噛み合うようにしています。スキーマが共通なので第三者が参入しやすい、という効果も同じです。

違いが出るのはその先です。IIIF が主に扱ってきた公開画像では、「そのマニフェストを出した機関を信じてよいか」を判断する場面がそれほど多くありません。一方、資格情報はアクセス可否の判断そのものに使うので、「この署名者を発行者として認めるか」を必ず決める必要があります。IIIF でも Authorization Flow API のようにアクセス制御を扱う部分では同じ論点が現れますが、そこでも「誰が認証を行うか」は各機関の運用に委ねられています。

つまり、規格が揃うと相互運用は進む一方、「誰を信じるか」は規格の外に残る、という構図は共通しています。

用語の対応

最後に、同じものを指す語がいくつもあるので対応をまとめておきます。

この記事の語仕様上の語現れる場所
発行者IssuerVC の issuer フィールド
保持者（本人）Holderウォレット、または鍵を持つプロセス
検証者Verifierアクセスを判断するサーバ
資格情報Verifiable Credential (VC)発行者が署名した 1 通
提示物Verifiable Presentation (VP)保持者が検証者に出す束

次は、このうち「形」の部分をどこまで W3C が決めているのかを見ます。

出典