デジタルクレデンシャルの利用用途に応じた管理要件に関する考察

Discussion Paper: Management Requirements for Different Uses of Digital Credentials

エグゼクティブ・サマリー

スマホに搭載される運転免許証をはじめ、学生証や学修歴、スキル証明、国民IDなど公的機関や民間組織が発行する各種証明書類（クレデンシャル）のデジタル化に向けた検討が活発に進められている。クレデンシャルのデジタル化は、我が国のみならず、世界で同様に各種ベンダによるソリューションの開発〜提供が始まっており、今後拡大していく市場としての期待を集めている。 そのような状況において特定のベンダやプラットフォーム提供者に依存するのではなく、かつ、クレデンシャルの用途に応じたセキュリティやプライバシーを含む管理要件や相互運用性に関して検討し、その結果を相互運用可能な標準活動をへて世界で利用されることこそがクレデンシャルのデジタル化の持続可能性のための重要な戦略となる。 そのために、本書においてはクレデンシャル（身分証明書）をデジタル化する上で必要となる管理要件を整理した。具体的には、1)正しい主体に対して発行されているクレデンシャルであるかどうかを当人認証の強度を判断可能な状態であること、2)利用するウォレットの特定と発行済みのクレデンシャルの管理（取り消しなど）を発行機関側で可能な状態であること、3)検証者が本人確認書類として当該クレデンシャルを利用できること、のための論点を整理する。今後、この論点をもとに政府や学術機関において具体的なアーキテクチャを定義し、各構成要素に求められる実装・管理要件およびガバナンスルールを定義し、より良い社会実装に向けて検討が進むことを期待するものである。

導入

国民IDや運転免許証のスマホ搭載やデジタルアイデンティティウォレットの大規模展開など、デジタルクレデンシャルの発行と利活用に関する検討がグローバルで進んでいる。しかしながらデジタルクレデンシャルの用途によっては発行先や状態を厳格に管理することが必要となるケースも想定される。特に本人確認書類としての利用が想定されるケースにおいては物理的な書類における「原本」と「コピー」に相当する考え方をどのようにデジタルに持ち込むことが妥当なのか、真正性検証が可能でありデジタルクレデンシャルの主体とクレデンシャルのホルダーが一致していることが一定程度確認されれば問題ないのかについては十分に検討を行う必要がある。本ディスカッションペーパーではデジタルクレデンシャルの種別・利用用途に応じた管理の必要性と考えられる手法について論点を整理する。また、先行して実証・実装が進む欧州の事例を踏まえて概説する。なお、本書の想定読者は所謂IHV（Issuer-Holder-Verifier）モデルに関する基本的な点について理解していることを前提としており、モデルそのものや基本的なアクターに関する解説は省略する。必要に応じて「Decentralized Identifiers (DID) とVerifiable Credentials (VC) の現況 ¹ 」などの先行論文を参照されたい。

原本と複製に関する課題

• 現実世界におけるクレデンシャルの原本と複製の扱いについて
  例えばパスポートの利用について挙げると、旅行保険を申請する場合は複製の提出で問題ないが出入国審査の際は原本が必要となる。また、大前提としてこれらの書類が提示された際、受け取り側が書類に記載された顔写真と提示者の同一性の確認を行うことが可能であることが暗黙の了解として存在する。

• 電子ファイルにおける原本と複製
  電子ファイルにおける「原本（Original）」の定義とその扱いについては現状明確ではない。例えば電子契約において電子契約書の原本は電子署名とタイムスタンプを付与した電磁的記録を指すのが一般的だが、民法 ² および電子帳簿保存法 ³ においても「原本」と「複製」に関する区分は明示されていない。また一般財団法人日本情報経済社会推進協会(JIPDEC) ⁴ の用語解説（「原本性保証」 ⁵ ）によると「複製ではなく本人が作成し以後改ざんされていない原本であることを保証すること。電子文書においては電子署名とタイムスタンプ ⁶ を組み合わせることにより、本人が作成し以後改ざんされていないことを証明できる。」となっている。一方、本定義では複製の定義がされておらず、デジタル署名済みであれば複数の電子ファイルが同ビット列で構成される場合は作成の前後関係に関わらずいずれも原本としての特性を満たせる。従って、電子ファイルにおける原本と複製に明確な差異は存在しないと考えられる。

• 複製と派生の違い
  一方で電子ファイルにおいても複製と派生（原本を元に別のファイルを作成したもの）は明確に異なる。なお、本書において電子ファイルにおいて「複製」は同一性が確保されたもの（Duplicate）、「派生」は同一性が必ずしも確保されていないもの（Copy）として分類することとする。例えば、マイナンバーカードを利用して本人確認を行なった状態を表す民間の身分証明書アプリなどはマイナンバーカードの複製ではなく、派生クレデンシャルとして捉えることができる。物理世界における複製は複写機の性能にも依存するが原本とは明らかに状態が異なることから、電子ファイルにおける派生と同等のものとして扱うことが妥当である。

  表. 原本・複製・派生の違い

  区分	現実世界	デジタル
  原本	発行者が直接発行したもの（例：パスポート）	電子署名とタイプスタンプを組み合わせて作成以後改ざんされていないことが証明できるもの
  複製	コピー機等で複写されたもの（例：パスポートのコピー）	原本を電子的に複製したもの（原本と明確な差異はない）
  派生	原本の発行者以外の第三者が原本を元に別途発行したもの（例：「本人確認済み」のスタンプが押された書類）	原本の発行者以外の第三者が原本を元に別途発行したもの

• 派生クレデンシャルを身分証明書として利用することによる課題の例
  

  • 原本側の取り消し等のライフサイクル上の状態の変更に派生クレデンシャルのライフサイクルが追従しない
  • クレデンシャル発行者が原本発行者ではなく派生クレデンシャルの発行者となることから、検証者にとっては原本発行者ではなく派生クレデンシャルの発行者が信頼の基点となる。そのことにより原本と派生クレデンシャルが必ずしも同一の内容を保証するとはみなせない
  • 同一の原本に基づき複数の派生クレデンシャルを生成した場合、一方の派生クレデンシャルを使って識別された個人は別の派生クレデンシャルを使って識別された個人とは異なるエンティティとして識別されてしまう（ポータビリティがなく、時として利用者の混乱を招く）

• デジタルクレデンシャルを利用した本人確認における課題
  上記の電子ファイルにおける原本、複製、派生の考え方を加味した上でデジタルクレデンシャルを本人確認書類として利用するケースを考えると、派生物として作製されたデジタルクレデンシャルは物理世界における複製と同等とみなし、本人確認書類として利用できないと考えるのが妥当である。しかし、原本・複製に関しては差がないことから原本に相当するデジタルクレデンシャルが複数存在することとなる。このことが身元確認に大きな影響を及ぼす。例えば複製されたデジタル本人確認書類を複数の人物が保有し行使することが可能な状態がありえることを想定して本人確認を行う必要性がある。

本人確認プロセスの分解とデジタルクレデンシャル利用時の要件

本人確認へデジタルクレデンシャルの活用を考慮する上で、本人確認をプロセスに分解し、各プロセスにおける要件を整理することが重要である。一般社団法人OpenIDファウンデーションジャパンが公開している「民間事業者向けの業界横断的なデジタル本人確認のガイドライン ⁷ 」によると、本人確認は「身元確認」と「当人認証」のに分解される。デジタルクレデンシャルを身分証明書として利用することを考える上では本人確認の中でも「身元確認」のプロセスについて詳細に分解・整理することが重要である。米国立標準技術研究所（NIST ⁸ ）が発行するデジタルアイデンティティに関するガイドラインである「NIST SP800-63 ⁹ 」では「身元確認」について「NIST SP800-63A ¹⁰ 」でさらにそのプロセスをResolution、Validation、Verificationの3つの段階に分離し整理しているため、本書ではNISTのプロセスにおいてデジタルクレデンシャルを適用した場合の要件を整理する。なお、NIST SP800-63におけるValidation（エビデンスの確認。主に提示されたエビデンスの真正性の確認）とVerification（エビデンスの検証。提示者とエビデンスの主体の同一性の確認）の用法については他の文書（例：ISO 9000ファミリー）との差異がしばしば指摘されている。本節においてはVerification/Validationの定義を明確化することを目的としておらず、NIST SP800-63の定義する本人確認プロセスへのデジタルクレデンシャルの適用した整理を行うものとする。

出典）NIST SP800-63A/The Identity Proofing User Journey

• Resolution（コア属性の収集とエビデンスの収集）
  本プロセスではCredential Service Provider（CSP。属性等のアイデンティティ情報を登録し、他サービスへ提供する役割を持つ）が属性情報とエビデンスを収集する。本人確認書類への記載事項や本人申告事項が主な登録対象となる。この際、CSPはエビデンスとして本人確認書類の提示を求める。本書においては本人確認書類としてデジタルクレデンシャルを提示するケース、およびその他属性情報の申告としてデジタルクレデンシャルを提示するケースを想定するため、当該クレデンシャルが収集対象となる属性情報を包含している必要がある。
• Validation（エビデンスの確認）
  本プロセスではCSPが申告された属性情報の信頼できる情報ソースへの確認、およびエビデンスとして提示された本人確認書類の真正性検証を行う。デジタルクレデンシャルを利用するケースにおいては提示されたクレデンシャルのデジタル署名の検証を行うことにより真正性の検証を行うことが可能であるが、情報ソースとなる発行者側でクレデンシャルが有効な状態であること（取り消し確認など）について確認を行う必要がある。なお、前述の通り派生クレデンシャルを利用する場合、信頼の起点が原本とは異なるためクレデンシャルに包含される情報が原本と同一であることは保証されない。そのため属性情報の確認を行う際は原本発行元へ問い合わせを行い有効性確認を行う必要がある。
• Verification（エビデンスの検証）
  エビデンスと提示者の同一性確認を行う。デジタルクレデンシャルをエビデンスとして利用する場合、提示者との同一性を確認するための手段となりうる情報（例えば対面の場合は顔写真の情報）をクレデンシャル自体に含めることが重要である。なお、属性そのものを確認して提示者との同一性を確認する方法以外に、クレデンシャル提示のアクションを行うために必要な措置として当人認証をウォレット側で実施、その信頼性（ウォレットにおける当人認証の強度）および実施結果をクレデンシャルと共に検証する方法をとる場合もある。その場合はクレデンシャル発行時に適切に当人認証が行なわれたことを示す情報（Key Attestationなど）がクレデンシャルに含まれる必要がある。

クレデンシャル管理とウォレットの信頼性に関する要件

前述の通り、本人確認プロセスにおいてデジタルクレデンシャルを本人確認書類として利用するケースにおいてはクレデンシャルの状態管理を行うことが非常に重要となる。

• クレデンシャルが有効であること
  • クレデンシャル自体が有効であること（リテンション期間の設計を含むライフサイクルが管理されていること）
  • クレデンシャルに含まれる属性の値が有効（変更・取り消しがされていない）であること
  • クレデンシャル自体が改ざんされていないこと
• クレデンシャルと提示者がバインドされていること
  • クレデンシャルに提示者と同一性を確認するための属性を含むこと
  • クレデンシャル発行時に発行対象主体に関する当人認証が行なわれたことを示す情報がクレデンシャルに含まれること

また、上記に加えてクレデンシャルが格納されるウォレットに対する信頼性についての考慮が必要となる。

• ウォレット側でHolder鍵が正しく管理されていること（署名アルゴリズムの危殆化対策を含む）
• ウォレット側でクレデンシャルの情報が正しく管理されていること（プライバシーへの配慮など）
• ウォレット側で正しく当人認証が行われていること（認証結果をクレデンシャルと共に提供されること）

これらの管理がクレデンシャルとウォレットのライフサイクル全般に渡って担保されていることが重要である。例えば、スマートフォンの機種変更や紛失・盗難、ウォレットの鍵の危殆化や漏洩などのインシデントが発生した際に適切な対応を行うことが必要である。当該プロセスの設計にあたっては、OSベンダやバックエンドの同期ファブリックを含むクレデンシャルエコシステムに関連するプラットフォーム事業者への信頼度・依存度の評価を行いアプリケーションレベルで実施する対策を決定することが必要である。

一方で先に挙げたパスポートの例における旅行保険契約の際の加入資格確認では資格確認を行うことが目的となり、本人確認に比較して厳密な管理を必要としない可能性がある。実際、パスポートの複製を利用して資格確認を行うことが可能なのと同様に、派生クレデンシャルの利用を許容しうるユースケースも存在する。このようにユースケースならびにリスクを分析・区分することでデジタルクレデンシャルの管理要件を決定していくことが肝要である。

クレデンシャル管理に関して考慮すべきシナリオ

クレデンシャル管理を考える上で考慮すべきシナリオとして、前述のクレデンシャルとウォレットのライフサイクルに加えて以下のシナリオについて考慮が必要となる。

• 単一の利用者が複数のデバイスを保持しているケース
  • 例えばスマートフォンとスマートウォッチを利用するケースなど、利便性を向上するためには複数のデバイスへ同一のクレデンシャルを発行するケースが存在する。その場合、Issuer側で発行済みクレデンシャルの状態管理（発行先デバイス情報を含む発行履歴の管理など）が必要となる。
  • 単一のデバイスに入った複数のウォレットが入っている状態、もしくは単一の利用者が複数デバイス上のウォレットに入っているクレデンシャルを同時にVerifierへ提示するケース。
• 複数の利用者がクレデンシャルを共有利用するケース
  • 未成年と保護者、秘書への権限委譲のケースなど、他者の制御するデバイスへクレデンシャルを発行するケースが存在する。この場合、Verifier側へ権限委譲が行われていることを判別できる状態でPresentationを行うことが必要となる。Verifierの利用シナリオによっても権限委譲されたクレデンシャルを受け入れるかどうかを利用者（提示者/Holder）に対して明示することが重要である。
• Issuer/Verifier、Verifier/Verifierの結託による名寄せと意図しない属性の提供
  • 従来のフェデレーションモデルにおいても対策を行なってきたとおり識別子の再利用によるリンク可能性については考慮が必要となる。従来のフェデレーションモデルにおいてはPairwise識別子を利用することでRelying Party単位で送出するアサーションを仮名化することにより、複数のRelying Partyが結託することによる意図しない属性開示へ対策を行なってきた。一方でIHVモデルにおいてはウォレット内に保持されるクレデンシャルを再利用するモデルとなること、かつクレデンシャルに含まれる識別子をウォレット側で改変することで方式によってはクレデンシャルへの署名が無効となること、識別子以外にウォレットのフットプリントなど管理性と名寄せのリスクの天秤となる傾向があること、など課題は大きい。今後、ゼロ知識証明などの技術を適用するなど対策が講じられることになる可能性が高いが、現時点で標準的な対策が固まっているわけではなく、今後の潮流を注意深く観測しつつ対策を吟味していく必要がある。

実装方式に関する議論

ここまでの要件を踏まえ、現状のIHVモデルの実装について議論する。前提として特定の技術要素(例：クレデンシャルフォーマットだとmdocやVerifiable Credentials）に依存しない抽象度で議論する）

• 全体構成 以下に全体構成を示す。以降、構成要素単位に求められる実装要件について記載する。

• 構成要素と求められる要件
  • Issuer
    デジタルクレデンシャルの発行を行う機能を担うのがIssuerである。本人確認書類として利用するデジタルクレデンシャルの発行を行う際は、主体に関する当人認証、クレデンシャルに含める当人に関するアイデンティティ情報の収集、複数デバイスへの同一クレデンシャル発行のケースに対応するための発行状態の管理を行う必要がある。
    • 当人認証
      クレデンシャル発行要求の際に主体に関する当人認証を行う。その際、認証強度（Authentication Assurance Level）や認証手法（Authentication Method）に関する情報をクレデンシャルに含めることによりVerifierは適切な当人認証に基づき発行されたクレデンシャルであることを確認できる。
    • アイデンティティ情報の収集と管理
      クレデンシャルに含める当人等に関する属性情報の収集を行う。典型的にはIssuerへの利用者登録を行う際の自己登録情報や本人確認の結果取得した属性情報などをIssuerが保持・管理を行う。なお、登録された属性情報が継続的に有効であることについては確認を行い、必要に応じて発行済みのクレデンシャルの取り消しや更新を促す等についても検討を行う必要がある。
    • ウォレット（インスタンス）の情報
      当人認証と合わせてHolderが利用するウォレット・インスタンスの情報をIssuerが保持・管理する。このことで複数デバイスへのクレデンシャルの発行を制御する、もしくは特定のデバイス紛失時における対象クレデンシャルの取り消しの制御等を行うことが可能となる。場合によってIssuerからウォレットインスタンスに対してPush通知などを行い能動的にクレデンシャルの取り消しを行うケースも存在する。
  • Wallet Provider
    ウォレット（ソフトウェアやハードウェア）を開発・提供する機能を担うのがWallet Providerである。ウォレットを利用者であるHolderへ配布（Provision）する際の配布管理、暗号化アルゴリズムの危殆化のウォッチを含むウォレットの品質管理を行う必要がある。
    • ウォレットインスタンスの配布管理
      利用者（Holder）がウォレットのインストールまたはセットアップを行うことでウォレットインスタンスが生成される。この際、どのHolderがどの実装のどのバージョンのウォレットがインスタンス化されているかについて管理を行う。このことで、仮に特定のバージョンのウォレットにバグや脆弱性が発覚した場合や、スマートフォンの盗難や紛失、利用者によるウォレットのアンインストールなどのケースにおいてIssuerへクレデンシャルの無効化に関する通知を行う等の制御性を向上することが可能となる。
  • Holder(ウォレットインスタンス)
    利用者であるHolderがスマートフォン等にウォレットソフトウェアをインストールしたものをウォレットインスタンスとして表現する。ウォレットインスタンスにはIssuerによって発行されたデジタルクレデンシャルが保管され、必要に応じてVerifierへ提示（Presentation）を行うためのPresentationを生成する。
    • デジタルクレデンシャルの管理
      Issuerから発行されたデジタルクレデンシャルについて署名検証等により真正性の確認を行う。典型的にはIssuerがVerifiable Data Registry（VDR）へ公開している公開鍵等の情報を利用して検証を行う。また、あらかじめ定められたクレデンシャルの保持期間を超えたらクレデンシャルの削除やリフレッシュを行う、もしくは定期的にStatus Listを参照してクレデンシャルの有効性確認を行う場合もある。
    • デジタルクレデンシャルの提示（Presentation）
      Verifierに対してデジタルクレデンシャルを提示する。その際にHolderの意志の元でPressentationが行われていることを確認するため、ウォレットインスタンスにおいてHolderの当人認証等による秘密鍵へのアクセスを行いPresentationに対してデジタル署名を付与するのが一般的である。また、場合によってはウォレットインスタンスがどの程度の強度や手法で当人認証を行っているかについてPresentationに含めてVerifierへ提示することもありえる。これはクレデンシャルの発行時にIssuerにおいて厳密な当人認証と、当人が制御する特定のウォレットインスタンスへの発行が行われていることをクレデンシャル自体に含めることでウォレットとクレデンシャルのバインド強度が一定レベルに保たれていることを仮定するセキュリティモデルに加えて、Verifierが能動的にウォレットインスタンス側での当人認証の強度・方法やHolderによる意志表明の有無を確認する要件への対応が必要になるケースへ対応することができる。
  • Verifier
    Holderからデジタルクレデンシャルの提示（Presentation）を受け、クレデンシャルの検証および利用を行う。なお、本人確認書類として利用されるデジタルクレデンシャルを検証する際はデジタル署名の検証のみならず当該のクレデンシャルがIssuerによって管理されていること、Holderとのバインド強度が高いことの検証を行う必要がある。
    • Presentationの検証
      ウォレットインスタンスから提示されるPresentationの署名検証による真正性検証を行う。
    • クレデンシャルの検証
      以下の検証を行う。
      • クレデンシャルが真正であり有効であること
        クレデンシャルに付与されたデジタル署名をIssuerの検証鍵により検証することでIssuerが発行・署名したクレデンシャルであることを検証する。また、Status List Providerが提供するリストを元に当該のクレデンシャルがIssuerによって取り消し済みでないことを検証する。
      • クレデンシャルが示す主体から提示されていること
        Presentationを発行したウォレットインスタンスを制御するHolder主体とクレデンシャルが指し示す主体が同一であることを検証する。
      • クレデンシャルが別のウォレット等に不正にコピーや移動されていないこと
        Issuerがクレデンシャルを発行した対象となるウォレットインスタンス（クレデンシャルに包含）とPresentation元となるウォレットインスタンスが同一であることを検証する。
      • Holderがクレデンシャルに対してバインドされていること
        Issuerがクレデンシャルを発行する際にHolderの当人認証を実施していることを確認することで当該クレデンシャルがHolderとバインドされている可能性が高いことを確認する。また、必要に応じてPresentationを行う際にHolderがウォレットインスタンスにおいて当人認証を行った結果を確認することでHolderの意志および当該クレデンシャルへ継続的に制御可能性を保持していることを確認する。
  • Status List Provideer
    Issuerによりクレデンシャルの状態を管理する。Issuerの制御下で運営されるケースとIssuerと独立して運営されるケースが存在する。後者はVerifier等からのStatus問い合わせによりIssuerがPresentation等のイベントを検知することによるプライバシー上の課題へ対応することを目的とすることが多い。
  • Verifiable Data Registry
    クレデンシャルやPresentationの検証を行うための検証鍵や各主体に関する付加的なサービスに関する情報を保持・管理する。Status List Providerと同様にプライバシー保護上の観点によりIssuer等の制御下で運営されるケースと独立して運営されるケースが存在する。

現在の標準技術仕様で解決できない残存課題

• 複数ウォレットに入ったクレデンシャルのバインディング
  複数のウォレットが同一または複数のデバイスに導入されているケースにおいて、VerifierからのクレデンシャルのPresnetaion要求に応答するケースのユーザ体験の向上については今後議論が必要となる。例えば、VerifierからクレデンシャルA、クレデンシャルBのPresentation要求があった場合、HolderはウォレットインスタンスAに格納されているクレデンシャルAを提示した後にウォレットインスタンスBに格納されているクレデンシャルBを単一トランザクションで提示することは現在のPresentationプロトコル（例：OpenID for Verifiable Presentation）においても想定されておらず適切なユーザ体験についても議論が不足している。
• ウォレットでの当人認証結果の表現
  先述のとおり、クレデンシャルの発行時にIssuerにおいて厳密な当人認証と、当人が制御する特定のウォレットインスタンスへの発行が行われていることをクレデンシャル自体に含めることでウォレットとクレデンシャルのバインド強度が一定レベルに保たれていることを仮定するセキュリティモデルに加えて、Verifierが能動的にウォレットインスタンス側での当人認証の強度・方法やHolderによる意志表明の有無を確認する要件への対応が必要になるケースへ対応する必要があるケースも存在する。このようなケースに対応するためにPresentationにウォレットインスタンスにおける当人認証の強度や方法を含める等の検討が必要となる。
• 鍵管理の話（バックアップ・リカバリ、同期など）
  特にウォレットインスタンスが利用する鍵の管理方式については議論が収束していない。欧州におけるガイドラインにおいては鍵の保管場所としてセキュアエレメント、国民IDカード、クラウド型HSMのオプションを提示しているが、機種変更を円滑に行うための鍵のバックアップ・リカバリやクラウドベースの同期ファブリックを利用した複数デバイス間での同期についてはウォレット実装者に任されている状態である。
• 各主体の信頼性（トラストフレームワーク、Trust Listなど）
  IssuerやVerifier、そしてウォレットプロバイダが提供するウォレットの信頼性を一定のスケールを持って担保する仕組みの検討が必要である。従来のトラストフレームワークによるアプローチでは一定のサイズのコミュニティにおける信頼性担保については効果を発揮するものの異なる業界や国を跨ぐクレデンシャルのやり取りを前提とすると従来のトラストフレームワークの適用範囲を超えた信頼性担保の仕組みが必要となる。例えば、認定機関を信頼する第三者認定モデルの表現をどのように行うか（X.509の様に証明書のチェインの考え方のみならず）、そして各構成要素を運営する機関が実態としてどの様な機関であり信頼できるのかについて透明性を持って確認する方法の検討が必要となる。
• クレデンシャルの利用用途を確認する方法
  本書の主題でもあるが、当該のクレデンシャルが本人確認書類として利用されるのか、単なる資格確認のために利用されるのかによってクレデンシャル管理にかかる厳密性等の要件は異なる。しかしながら発行主体が発行したクレデンシャルが発行者の意図とは異なる用途で利用されることは現実社会でもしばしば発生しているため、HolderやVerifierがIssuerのクレデンシャル発行の意図や想定された用途について理解できるようにすることが必要である。現状はDescriptionなどで定性的な情報として提供することは可能だが、機械可読で自動判別が可能な情報のあり方について整理・標準化を行う必要がある。

プライバシーに関する考慮事項

先述の通り、フェデレーションモデルと異なりIHVモデルにおいてはあらかじめIssuerにより発行された同一のクレデンシャルをHolderが複数のVerifierで再利用することが前提となっている。また、Verifierへの提示をHolderが実施するため、クレデンシャルへの署名者（Issuer）と提示者（Holder）が異なり、提示の都度クレデンシャルに包含される識別子等の情報を修正し再署名を行うことが困難である。そのため、従来のようにVerifier単位で識別子を仮名化することでリンク可能性を低減することが難しい。また、特に本人確認書類としてクレデンシャルを利用する際、クレデンシャル発行先となるウォレットインスタンスの特定を行う必要があり、そのためにクレデンシャル内にウォレットインスタンスに関する情報を包含することがある。ウォレットインスタンスの情報を利用した名寄せを防ぐためには、Holderのアイデンティティの仮名化に加えウォレットインスタンスの情報が仮名化されていることも必要となる。選択的開示やゼロ知識証明のテクノロジーを活用することでこれらの課題を満足するための設計を行うことが必要となる。

他国の動向

デジタルクレデンシャルの社会実装を先行して進めている欧州および米国においては技術仕様のみならず実装や運用に関するガイドラインの策定が進められている。ここでは欧州におけるEU Digital Identity Walletおよび米国のモバイル運転免許証について検討状況の概要を示す。

• 欧州連合/EU Digital Identity Wallet
  欧州連合においては、Digital Identity Wallet（EUDIW）への各種クレデンシャルを発行するモデルを採用することとなっており、2026年には各加盟国単位で社会実装〜展開が予定されている。展開に向けて欧州連合が発行しているEuropean Digital Identity Wallet Architecture and Reference Framework v1.4.0（ARF） ¹¹ ではウォレット実装に関する各種仕様について下記の通り定義（抜粋）されており、議論が続けられている。
  • デジタルクレデンシャルフォーマットとしてInternet Engineering Task Force（IETF） ¹² で標準化が進むSelective Disclosure for JWTs（SD-JWT） ¹³ を採用している
  • トランスポートプロトコルやクレデンシャルフォーマットを組み合わせたプロファイルとしてOpenID Foundation ¹⁴ で策定が進められているOpenID4VC High Assurance Interoperability Profile（HAIP） ¹⁵ を採用することで一部のベンダやプラットフォーマーへの依存度を下げつつ相互運用性を担保している。ARF 4.2 Reference Architectureや5.2 Available standardised formatsにおいて、モジュール化された複数の候補があり得る技術や標準化されたフォーマットやプロトコルが指定されいる。
  • ウォレットは加盟国、もしくは加盟国が認定した組織が開発したものを採用するモデルとなっている。ARF 3.2 EUDI Wallet Providersにウォレットプロバイダーに求められる要件が定義されている。
  • 利用者（Holder）と発行されるクレデンシャルのバインディングを担保するための仕様が策定されている。ARF 6.5.3 Wallet Instance activationや6.6.2 PID or attestation issuance、6.6.2.3 PID Provider or Attestation Provider validates the EUDI Wallet Instance, Annex 2 - High Level Requirements　topic 9　において、以下を元にしたホルダーとクレデンシャルのバインディングの担保をする想定で仕様検討が進んでいる。
    • 発行時にIssuerがHolderを認証
    • 発行されたクレデンシャルとそれを格納するウォレットのバインディングを担保
    • 提示時にウォレットインスタンスがHolderを認証
  • 発行されるクレデンシャルと利用者（Holder）が利用するウォレットのバインディングを担保するための仕様検討が継続的に検討されている。毎年2回マウンテンビューで開催されるInternet Identity Workshop（IIW） ¹⁶ においてここ数年ドイツ政府メンバーを中心にWallet Attestationを利用した仕様の提案が行われている。
  • クレデンシャル発行時のIssuerによるHolder認証の強度や手法については、ARF 6.6.3.8 Relying Party verifies or trusts User binding, Annex 2 - High Level Requirements　topic 9においてウォレットにおけるクレデンシャル発行や利用時に高レベル信頼で認証されることを前提としているのと同時に、IIWでKey Attestationを利用した仕様の提案が行われている。
  • なお、SD-JWTのリンカビリティについては、IETF OAuth WGのメーリングリスト ¹⁷ において継続的に議論が行われている。
• 米国/AAMVA Mobile Driver's License Implementation Guidelines
  米国においては運転免許証のモバイル搭載に関して、American Association of Motor Vehicle Administrators（AAMVA。米国自動車管理者協会） ¹⁸ が実装者向けのガイドラインであるMobile Driver's License Implementation Guidelines v1.4（以下、AAMVA実装ガイド） ¹⁹ を発行しており、各州で実装が進められている。同ガイドラインでは欧州におけるARFと同様にデジタルクレデンシャルであるモバイル運転免許証と関連するアクターに求める各種ガイドラインが下記の通り定義（抜粋）されている。
  • デジタルクレデンシャルフォーマットとしてISO ²⁰ が標準化しているmdocを採用している。AAMVA実装ガイド 3.1 INTRODUCTIONにおいて、mDLはISO/IEC 18013-5 ²¹ に沿う旨定義されている。
  • 発行者の責任が非常に重く、ウォレットに保存されているクレデンシャルの状態についても発行者が責任を持つモデルとなっている。AAMVA実装ガイド 4.3 PROTECTING DATAにおいて、発行局は、mDL保持者のデバイスに保存されたすべてのmDLデータが適切に保護されていることを確認する必要性について言及されている。また同ガイドの6 MDL DATA REFRESH において、発行されたクレデンシャルを更新や無効化しなくてはならない場合についても発行者の責任が重くなっている。具体的には発行されたクレデンシャルの状態についてVerifier側からの問い合わせに対応する、あるいは、mDLアプリケーションから取得あるいは利用者への通知の上でmDLアプリケーションへプッシュ出来るようにする、と言った手法への対応が定義されている。
  • 上記の発行者の責任に対応するためにウォレットに求める機能についても細かく定義されている。例えば、発行済みのクレデンシャルのリフレッシュに関して、Device RetrievalのケースではIssuerがmDL App（ウォレット）に対してリフレッシュするメカニズムを実装することを推奨している。同様にmDL Appの自動アップデートの機能を実装しても良いが、その場合は透明性の観点から利用者の同意に基づきONにすることが求められる、など詳細なガイドラインが定義されている。AAMVA実装ガイド 6.2.2 Device retrieval method　において、発行されたクレデンシャルについて更新されたことを把握できないまま利用し続けられるリスクに対応するため、発行されたクレデンシャルを利用可能な期間を30日とすることが推奨されている。
  • 欧州で採用されているSD-JWTと同様に、リンカビリティの問題については他の技術の採用について検討が必要とされている。AAMVA実装ガイド 4.6 NO TRACKING において、Verifier側での紐付けをできるだけ難しくすることで匿名性を確保するため、発行機関は、静的または長期間のメタデータの共有を最小限に抑えるべきである。さらに、発行したクレデンシャルの状態についてVerifier側からの問い合わせに対応する方式は、発行機関がリアルタイムで関与するため、追跡防止に課題があり、mDLホルダーの使用状況や物理的な位置を追跡できる可能性がある。これらの対応には発行機関に対する規制による保護が必要とされている。
  • mDLデータを利用する際のHolder認証を必須とする一方で認証レベルについては特に規定はされていない。AAMVA実装ガイド 4.3 PROTECTING DATA　にはmDLデータを利用するときにはHolderの認証を必須とする旨の定義はあるが、具体的な認証レベルについては定義が存在していない。
  • 利用者が複数端末を利用するケースを想定したクレデンシャルの発行に関するガイドが定義されている。AAMVA実装ガイド 7 MULTIPLE CREDENTIALS AND SHARED DEVICES　において、複数のデバイスでの同一クレデンシャルの利用、同一デバイスでの複数クレデンシャルの利用について、次のような事項が検討されている。
    • 同一Holderに対するクレデンシャルを複数デバイスで利用することは、デバイスに対してバインドされていれば無制限のコピーを作ることにはならないので安全である。
    • また利点もあり、例えばスマートウォッチとスマートフォンそれぞれにクレデンシャルを格納することで利便性を向上させたり、家庭人としての利用と友人関係での利用といった利用コンテキストを分離することでプライバシー保護に貢献する。
    • 一方で、攻撃面を増やすことになるので、利用者からのリクエストにもとづいてのみ発行されるべきで、上限数も設けることが推奨される。

デジタルクレデンシャル導入時に検討すべきこと

政府、学術機関、企業などおいて本人確認書類や資格証明のデジタル化やDigital Identity Walletの導入検討が進んでいる。一方で、多くのソリューションベンダがこの新たな市場と捉えシェア獲得とロックインに向けた活動が活発化するなど、デジタルクレデンシャルを導入すること自体が目的となってしまっている事例も散見される。 デジタルトランスフォーメーションを正しく推進するためには、この機会を正しく捉え、グローバルで持続可能な形な社会実装に向けて取り組むことが肝要である。そのためには標準技術の採用や、国や業界におけるルールメイキングをグローバルで推進するなど相互運用性を強く意識した活動が非常に重要である。すでに欧州をはじめとする他国では国際（International）的な優位性確保に向けた活動が活発化しており、我が国においても国内・国際・グローバルの各段階を見据えた戦略の立案と実行が重要である。目先の国内市場の獲得とロックインにとらわれやすいソリューションベンダを牽制しつつ国際・グローバルでのポジションを確立するために政府や学術機関が果たす役割は非常に大きいと言える。 そのためにはデジタルクレデンシャルを漠としたキーワードとして捉えるのではなく、本人確認書類なのか単なる資格証明なのか、など利用用途に応じてきめ細かいアーキテクチャと構成要素毎の要件を既存トラストフレームワークや各種ガイドラインと照らし合わせた上で整理を行い、必要となる技術の標準化やポリシーの策定と相互運用性の確保に向けた活動を今行うことが必要である。また、同時に技術仕様の標準化動向（例：mdoc、Verifiable Credentialsといった複数クレデンシャルフォーマットの乱立）を見据えつつ持続可能で相互運用可能な状態を実現するために必要なプロファイルの策定を慎重に進めることが重要である。

お問い合わせ等

本件についてのコメント及びご質問などを含むお問い合わせについては、慶應義塾大学SFC研究所 データ・アーキテクチャ・ラボ、および伊藤忠テクノソリューションズ株式会社 みらい研究所まで、下記emailアドレス宛で、ご連絡頂きたい。

慶應義塾大学SFC研究所 データ・アーキテクチャ・ラボ dal-info/at/sfc.wide.ad.jp ( /at/ は @ に置き換え )

伊藤忠テクノソリューションズ株式会社 みらい研究所 mirai-contact/at/ctc-g.co.jp ( /at/ は @ に置き換え )

なお、この文書は、随時更新し、以下のURL にて公開する予定である。

最新版のURL: https://dal.sfc.keio.ac.jp/ja/TR/management-requirements-for-digital-credentials/
本バージョンのURL: https://dal.sfc.keio.ac.jp/ja/TR/management-requirements-for-digital-credentials-20250124/