{{item.title}}
{{item.text}}
{{item.text}}
以前、「デジタルアイデンティティ・ウォレットの技術解説:その仕組み、主要要件」という記事でデジタルアイデンティティ・ウォレット(以下、DIW)の技術について紹介しました。この記事で紹介したDIWをやりとりする代表的なプロトコルであるOpenID for Verifiable Credentials(以下、OpenID4VC)仕様群が、2025年7月より順次承認されています。
本稿ではこのOpenID4VCの全体像とセキュリティメカニズム、OpenID4VCを支えるトラストフレームワークの必要性について解説します。
「デジタルアイデンティティ・ウォレットの技術解説:その仕組み、主要要件」でも述べた通り、「提示された内容が改ざんされていないことをデジタル的に検証できる、電子的な資格情報」であるVerifiable Digital Credential1(VC)をやりとするDIWの技術が発展しています。
DIWを使用すると、運転免許証、卒業証明書、資格証明など、これまで紙だった証明書がデジタル化され、スマートフォンなどの「デジタルウォレット」で管理できるようになります。
しかし、ただデジタル化すれば良い、というわけではありません。この新しいデジタルな仕組みを安全に、そして誰にとっても便利に利用するためには、いくつかの重要な課題があります。OpenID4VCは、まさにこれらの課題を解決するために開発された、標準仕様群です。
OpenID4VCは現在、大きく以下の3つの仕様群が標準仕様として認められています(図表1)。
図表1:OpenID for Verifiable Credentials関連仕様リスト
名称 |
概要 |
OpenID for Verifiable Credential Issuance |
発行者が保持者にVCを発行する際の、通信手順を定めたプロトコル |
OpenID for Verifiable Presentations |
保持者が検証者にVCを提示する際の、通信手順を定めたプロトコル |
OpenID4VC High Assurance Interoperability Profile(HAIP) |
OpenID4VCI/VPの実装のばらつきを防ぎ、高いセキュリティと信頼性が求められるユースケースにおいて相互運用性を確保するための詳細なルール定義 |
この3つの仕様群の関係は、下の図のようになっています(図表2)。
図表2:VCのやり取りで使用されるOpenID for Verifiable Credentials関連仕様の関係
Issuer(発行者)はOpenID4VCIを使用してユーザー(保持者)にVCを渡し、ユーザーがそれを一度ウォレットに格納した後は、OpenID4VPを使用してVerifier(検証者)に提示します。また、HAIPは高いレベルのセキュリティとプライバシーが要求されるVCの発行者、ウォレット、および検証者間で相互運用性を確保するため、既存のさまざまな仕様から特定の機能を選択し、その利用に関する一連の要件を定義した文書です。
OpenID4VCIは、発行者がVCをウォレットに配布するためのプロトコル仕様です。
VC発行を始めるフローには、ユーザーがウォレットを起動するWallet-Initiated(ウォレット開始型)という方法と、発行者がQRコードやディープリンクを介してウォレットを起動するIssuer-Initiated(発行者起動型)という方式が定められています。また、VCの発行処理に柔軟性を持たせており、たとえば、ユーザーが操作するデバイス内のブラウザからアプリケーションを連携させてVC発行を完結させたり、PCとスマートフォンといった異なるデバイス間で連携して手続きを進めたりできます。
また、VCの発行は、一度に一つだけでなく、複数発行する「バッチ発行」という方式も定められています。また、対応するVC形式として、仕様書にはInternet Engineering Task Force(IETF)が定めるSD-JWT VC、ISO/IECで定められたmdoc(ISO/IEC 18013-5)、World Wide Web Consortium(W3C)のVerifiable Credentialsが記載されています。ただし、これら特定のVC形式に限定されさない、多様なVC形式に対応が可能な設計(「クレデンシャルフォーマットアグノスティック」と呼ばれる)が採用されており、独自のクレデンシャルフォーマットプロファイルを定義することも可能です。
OpenID4VCIは、これらの柔軟なフローと幅広いVC形式への対応により、さまざまなVC発行のユースケースをカバーできるよう考慮されています。
OpenID4VPは、ウォレットからVCを検証者に提示するためのプロトコル仕様です。
OpenID4VPでは、VCを検証者に提示する際、一部または全部を、プレゼンテーションという「提示用データのかたまり」にして送ります。プレゼンテーションは、検証者が必要としている情報だけを「あなたが正当な持ち主である」というデジタル署名(なりすまし防止の証明)を添え、さらに、その情報が「いつ、誰に、何のために提示されたか」という情報も一緒にまとめたものです。
まず、ユーザーが検証者へVCを提示する方法は、大きく二つの方式で行われます。
これらの提示方式を支えるチャネルとして、以下の方法に対応しています。
さらに、提示内容のコントロールにおいては、ユーザーのプライバシー保護が重視されます。これには、Digital Credentials Query Language(DCQL)と呼ばれるクエリ言語を使用し、検証者が求めるVCの種類や具体的な情報のリストに対し、選択的開示(Selective Disclosure)という、ユーザーが実際にどの情報(属性)を開示するかを細かく選択できる仕組みが提供されています。
OpenID4VCIについても、さまざまなユースケースを想定しつつ、ユーザーが検証者に対して必要な情報だけを安全に提示できる仕組みとなっています。
HAIPは、高いセキュリティとプライバシーが求められるVCのやり取りにおいて、発行者、ウォレット、検証者間の確実な相互運用性を実現するプロファイルです。
HAIPが必要とされるのは、OpenID4VCIやOpenID4VPに多くのオプション(VC形式、提示チャネル、セキュリティ機能など)が提供されている一方、発行者や検証者など実装者の間で選択が異なると相互運用性が損なわれる恐れがあるためです。そこでHAIPはこれらの選択肢を整理し、特に高い信頼性が求められるユースケースで「必須」となる機能を明確化します。
HAIPでは、セキュリティ強化のためにPKCEやPAR、DPoPといったセキュリティ技術を使用し、アクセス権を示すトークンが盗まれても悪用されにくい仕組みを必ず使い、さらに通信相手が正しいことを確認するための情報の利用も要求します。さらに、ウォレットが信頼できることを証明するWallet Attestationや、鍵がセキュアなモジュールで保護されていることを証明するKey Attestationを導入し、発行前のウォレットの信頼性検証を強化することも要求しています。
また、相互運用性保証のため、SD-JWT VCやISO mdocといった対象VC形式のサポートを要求します。また、DCQL(Digital Credentials Query Language)の使用を必須にすることで、提示内容の記述方法を統一しています。
これらセキュリティ技術は、次章にてご紹介します。
OpenID4VCは、通信の安全性を確保する為に多層的なセキュリティメカニズムを規定しています。ここでは、セキュリティスタックを「基盤技術」、参加者の「信頼の確立と認証」、データの「バインディング」、そして「プライバシーと開示制御」に分割し、一表にまとめます(図表3)。
図表3:OpenID4VCのセキュリティスタック
例えば、OpenID4VPでは、最終的に検証者に渡るVCのデータの内容が正確で改ざんされていないことを検証するため、以下のようなステップでVCを検証します。
①VPトークンのフォーマット検証
検証者は、まずVPトークンと呼ばれる一つまたは複数のプレゼンテーションがパッケージ化されたものが正しく構成されていることを検証します。
②個々のプレゼンテーションの検証
③発行者の署名の検証
高い保証レベルが求められるプロファイルでは、検証者はVCの発行者の署名を検証するためにX.509証明書ベースの鍵解決をサポートすることが義務付けられています。
④DCQLクエリの全体的な要件の充足
返されたプレゼンテーションのセット全体が、検証者の要求(DCQLクエリ)で定義された要件を満たしていることを確認します。
これらの検証ステップのいずれかが個々のプレゼンテーションに対して失敗した場合、そのプレゼンテーションは破棄されなければなりません。VPトークンまたは応答全体に関するチェックが失敗した場合、VPトークン全体が拒否されます。
技術仕様への準拠と発行者の信頼性は別の問題です。OpenID4VCの技術仕様が正しく実装されていても、発行者による虚偽の情報を含むVCを発行する可能性は排除できません。属性の確からしさの検証は、技術的な署名検証とは独立した、社会的・制度的な信頼メカニズムに依存します。
たとえば、技術的にはOpenID4VC仕様に準拠し渡された資格証明書であっても、発行した機関が正当な認可を受けていない場合、その資格証明書は法的に無効です。このように、技術的信頼は「どのように」の問題を解決しますが、「誰が」「何を」「何に基づいて」「どのように」発行されているかという根本的な信頼は別の仕組みが必要です。
VCを発行する場合、資格情報の確認、管理、そして発行の仕組みが極めて重要です。特に、法的効力を伴う高い真正性が要求される資格情報の場合、発行者には発行資格が必要となるでしょう。この発行資格は、政府機関であれば法的権限に基づいて、民間企業であれば業界団体や規制当局からの認定に基づいて与えられるべきです。また、発行資格の付与にあたっては、発行プロセスの適格性、定期的な監査の実施、継続的なモニタリング体制、そして適切な苦情処理システムの存在などを厳格に確認する必要があるでしょう。
一方、資格情報を検証する側(検証者)は、目的外利用やプライバシー侵害を防ぐための適切な規制を講じる必要があります。検証者が要求できる情報は、サービス提供に必要最小限のものに限定され、それ以上の過度な情報収集は厳しく制限されるべきです。
ウォレットの認証制度では、セキュリティ要件の定義、認証プロセスの確立、継続的な品質管理が重要な要素となります。ガバナンス体制により、技術的な実装だけでなく、運用面での信頼性も確保されます。
ルート証明書の管理は、信頼の連鎖を確立する基盤となります。認証局の役割と責任は、証明書ポリシーと証明書実施規程(CP/CPS)により明確に定義され、定期的な監査により品質が保たれます。
OpenID4VCにおいても、X.509 PKIが広範囲に活用されており、発行者の鍵解決、検証者の認証、ステータスリストの署名検証などで重要な役割を果たしています。ただし、ルート証明書の取得方法や信頼の確立方法は仕様の範囲外とされており、実装者が適切に設計する必要があります。
OpenID4VCは、デジタルアイデンティティの革新を推進する重要な技術です。高い相互運用性とセキュリティを両立させ、国境を越えたデジタルサービスの利用を促進し、個人のプライバシーと利便性のバランスを実現できるよう配慮されています。
この技術の真価を発揮するには、技術標準の実装だけでなく、法制度やトラストフレームワークとの統合が不可欠です。発行者・検証者の適切な管理やプライバシー保護の制度的裏付けなど、技術を超えた社会システムの整備が成功の鍵となります。
国内では、2025年6月に「マイナンバーカードのiPhone対応」2を開始しましたが、mdocを用いた選択的開示機能が可能になっています。さらに、Android向けのGoogleウォレットとの連携は2026年秋頃に予定されています。
さらに、OpenID4VCは教育や医療など多様な分野での応用が期待されます。グローバルでの採用には各国の法制度や文化への適応が必要ですが、欧州eIDAS2.0のような大規模実装の事例3もあり、デジタル社会の信頼基盤として普及していくことが見込まれます。
OpenID4VCは、デジタル社会の信頼基盤として、今後も重要な役割を果たし続けることでしょう。
事業者には、単なる仕様の実装にとどまらず、社会的価値の創造を意識した取り組みが期待されます。
【公式仕様書】
1 発行プロセスやフォーマットについての情報とデータモデルに基づいてやり取りされる、暗号学的に検証可能な資格情報
{{item.text}}
{{item.text}}
{{item.text}}
{{item.text}}
{{item.text}}
{{item.text}}