2024年11月11日

eIDAS2発効後の動向と欧州デジタルIDウォレットのリファレンス・アーキテクチャ

SBI金融経済研究所主任研究員

中山靖司

はじめに

　本レポートは、当研究所所報第6号「『欧州デジタル ID枠組み規則』制定の経緯と欧州デジタル IDウォレットの共通仕様」[1]のフォローアップである。同論文では、本年5月に発効された同規則（以下「eIDAS2[2]」と呼ぶ）に基づいてEU市民に提供することが義務付けられたEuropean Digital Identity Wallet（以下「EUDIW」と呼ぶ）の技術仕様等について、「EUDIW Architecture Reference Framework」（以下「EUDIW ARF」）をもとに読み解いた。その際、EUDIWエコシステムのコアとなるコンポーネント等を概説した「リファレンス・アーキテクチャ」や、それらのコンポーネント間で安全なやり取りを可能とするための信頼関係を確立する「トラストモデル」については、紙面の都合により紹介できなかった。

　最近になって、EUDIW関連の実施法案の一部がパブリックコンサルテーションに付され始めているが、実装に関わる内容も多く、改めて「リファレンス・アーキテクチャ」についても言及し、コア・コンポーネント等についても解説しておくことが実施法案の理解を進めるうえで有用であると考えられるため、今回紹介することとした。

eIDAS2発効後の動向

　eIDAS2では、規則承認後、6～12カ月で定められた期限までにEUDIWの技術仕様と認証の概要を定めた複数の実施法を整備することが求められている。2024年11月21日を期限とする実施法案については、本年8月から9月にかけて、図表1に示す5本のパブリックコンサルテーションが行われた。

EUDIW – integrity and core functionalities（整合性とコア機能）[3]	相互運用可能で意図するすべての目的に使用できるウォレットを加盟国が確実に提供するためのルールを定めるための施行規則。例えば、ウォレットは、①広範な公共・民間サービスにおける国境を越えた安全なオンライン本人確認、②EA（電子証明書）の共有、③電子署名の発行、を可能にするものでなければならない。
EUDIW – protocols and interfaces to be supported（サポートされるプロトコルとインターフェース）[4]	ウォレットの効果的な運用に不可欠なプロトコルとインターフェースについて、これらの適切な実装を確保するための施行規則。共通のプロトコルとインターフェースをサポートすることで、ウォレットは、①PID（個人識別データ）およびEA（電子証明書）の発行および提示、②ウォレットユニット間のデータ共有、③関係者との効率的なコミュニケーションを保証できる。
EUDIW – person identification data and electronic attestations of attributes（個人識別データおよび電子属性証明書）[5]	発行、検証、失効、および停止を網羅するPID（個人識別データ）とEAA（電子属性証明書）の円滑なライフサイクル管理を保証するための施行規則。
EUDIW – trust framework（信頼フレームワーク）[6]	欧州委員会が設置した電子通知システムが、欧州委員会と加盟国間の情報交換のための安全で透明性の高い通信手段として機能するための施行規則。
EUDIW – certification（認証）[7]	EUDIWの適合性認証の要件を定めるための施行規則。

（図表1）2024年第4Q成立に向けてパブリックコンサルテーションを行った実施法案

　さらに2025年5月21日を期限とする実施法案についても、欧州委員会の公開情報によれば、図表2に示す少なくとも5本のパブリックコンサルテーションが準備中である。

EUDIW – registration of relying parties（依拠当事者の登録）[8]	EU 諸国におけるrelying parties（依拠当事者）の登録プロセスに関するルールを定める施行規則。EUDIWにアクセスするための認証に必要な情報、relying partiesの連絡先詳細およびウォレットの使用目的 (relying partiesがユーザーに要求できるデータを含む) に関連するものであり、ウォレットのrelying partyの登録後に発行されるアクセス証明書の仕様と要件が含まれている。
EUDI Framework – cross-border identity matching（国境を越えたID照合）[9]	電子識別手段またはEUDIWを使用する際の明確な ID 照合に関するルールを定める施行規則。利用者が国境を越えたオンライン公共サービスにアクセスしようとする場合に、明確なID照合を確保するために加盟国が講じるべき措置を定めている。
EUDIW – security breaches（セキュリティ侵害）[10]	ウォレットの信頼性に影響を与えるセキュリティ侵害や一部の情報が漏洩した場合に、EUDIWの一時停止や、場合によっては認証ウォレットリストからの削除を確実に行うためのルールを定める施行規則。
EUDI framework – verification of electronic attestation of attributes（電子属性証明書の検証）[11]	EAA（電子属性証明書）の発行および検証の要件を定めるための実施規則。また、authentic sources（真正情報源）と照合して検証可能でなければならない個人属性のカタログ（個人のアイデンティティを構成する情報）を示しているほか、PuB-EAA（公的電子属性証明）を発行する公的機関が情報を通知・公開する際のルールを定めている。
EUDIW – list of certified wallets（認証ウォレットリスト）[12]	認証済ウォレットのリストとそれに関連する電子的な本人確認スキームに関する情報の届出制度に関する施行規則。EU諸国が欧州委員会に提出する義務があり、提出書類の授受には欧州委員会が設置する安全な電子システムを使用することになっている。

（図表2）2025年第1Q成立に向けて準備中の実施法案

　こうした実施法は、技術的な共通仕様や要件を定める「EUデジタルIDツールボックス」および同ツールボックスの一部を構成するEUDIW ARFと整合することが求められている。今回パブリックコンサルテーションにかけられた実施法案の具体的な文書を見ると、EUDIWを構成するものとして定義されるコア・コンポーネント（後述）や、暗号機能等の高い安全設計にかかわる主要なエンティティを前提に、それらが主要なインターフェースを介してどのように通信するかなど、かなり細かい技術レベルまで含めて規定する内容となっており、EUDIW ARFの記述内容に沿ったものとなっていることがわかる。そこで、所報6号では紹介しきれなかったEUDIW ARFの「リファレンス・アーキテクチャ」部分について、本レポートで追加的に解説することとした。

　なお、EUDIW ARFは、eIDAS専門家グループにより適宜更新・作業等が進められているが、その開発作業において筆者が特徴的だと感じた点は、ソフトウェア開発のプラットフォームであるGitHubを作成途上文書のバージョン管理や作業コラボレーション支援にも使っているところである。このため、世界中の人々がEUDIW ARFの更新・作業状況およびそれに基づくコンポーネントの開発状況を、同時進行で確認することができるようになっている。ソフトウェア開発などにおいてこうした共有・管理サービスを活用することは既に一般化しているが、日本で規制や行政文書をGitHubで管理運営している先はないのではなかろうか[13]。本稿執筆時の最新版は、EUDIW ARF1.4.1版であるが、以下では、所報6号執筆の際に使用したものと同じEUDIW ARF1.4版をもとに、「リファレンス・アーキテクチャ」について解説する。

EUDIWのリファレンス・アーキテクチャについて

　図表３は、EUDIWのエコシステムとそのコンポーネントのアーキテクチャの概要を示したものである。なお、技術的内容になるため、正確性を期すため、以下ではコンポーネント名等に関しては英語表記を中心に用いている。

（図表３）EUDIWソリューションのリファレンス・アーキテクチャ

【コア・コンポーネント】
　EUDIWソリューションのコアとなるコンポーネントとしては、以下のものがある。

User device（UD）：User deviceはWallet Instanceをホストするためのデバイス。自然人（個人）は通常モバイルデバイスを使うことになるが、法人の場合はクラウドサーバーを使うことも想定される。

Wallet Instance（WI）：User device上にインストールされたアプリまたはアプリケーション。コアビジネスロジックとインターフェースを実装しており、WSCA/WSCDと直接対話することで、認証の高い保証レベルを確保している。

Wallet Secure Cryptographic Device（WSCD）：WSCDは、暗号鍵等を管理するためのセキュアな環境とストレージを提供するデバイス。改ざん防止および複製防止が対策済みの信頼できるハードウェア。

Wallet Secure Cryptographic Application（WSCA）：WSCAは、WSCD上で実行されるセキュリティ関連のアプリケーション。一つの WSCA は一つのWallet Instanceに限定して関連付けられ、特定のWallet Instanceのアセット（暗号鍵など）を管理する。

Wallet Provider backend（WP）：WPは、ユーザーにWallet Instanceのサポートを提供し、必要なメンテナンスを行い、Wallet Provider Interface（WPI、後述）を通じてWallet Trust EvidencesとWallet Instance Attestationsを発行する処理システム。

【インターフェースとプロトコル】
　図表3に示されるインターフェースとそれぞれのプロトコルは、欧州デジタルID枠組み規則の第5条a項第5号で定められた仕様に準拠している。主なものとしては下記の仕様がある。

Wallet Provider Interface（WPI）：Wallet InstanceがWPと通信するために使用される。Wallet Trust EvidencesとWallet Instance Attestationsの発行に用いられる。

The User Interface（UI）：ユーザーとWallet Instance間のやり取りが行われる接点である。

Presentation Interface（PI）：Relying Party（依拠当事者）がEUDIWからPID（個人識別データ）や様々な証明書（QEAA、PuB-EAA、EAAなど）を安全に要求して受信できるようにするインターフェース。リモートと近接通信の両方に対応する。リモートプレゼンテーションフローのために、Wallet InstanceはOpenID for Verifiable Presentationプロトコル（OpenId4VP）を実装する。一方、近接プレゼンテーションフローでは、ISO/IEC 18013-5標準に準拠する。なお、リモートフローでは、Relying Partyがサービスを提供するためにユーザー認証とデータアクセスを必要とする場合、ウェブブラウザまたはモバイルアプリのいずれかを介してプロセスが開始される。

Secure Cryptographic Interface（SCI）：Wallet Instance が WSCA と安全に通信するためのインターフェース。暗号資産の管理と暗号機能の実行のために特別に設計されている。

PID Issuance Interface（PPI）: Wallet InstanceがPID Providerと通信するためのインターフェース。OpenID4VCIプロトコルに基づいており、Wallet Instance内に格納される PID を要求したり受け取ったりするときに使用される。

Attestation Issuance Interfaces (AII)： Wallet Instanceが様々なEAA（電子属性証明）を要求する際に使用されるインターフェース。OpenID4VCIプロトコルに基づいている。

Remote Signing Interface (RSI)：Wallet InstanceがQES（適格電子署名）リモートサービスプロバイダと通信するためのインターフェース。QESリモート署名の実行に使用される。

【EUDIWとRelying Partyの間の通信方法】
　EUDIW（Wallet Instance）をRelying Party（依拠当事者）に提示するプレゼンテーションインターフェースの実装では、4つの異なる通信フローが定義され、用途によって使い分けられる。

近接監視フロー（Proximity Supervised Flow）：EUDIWユーザーが物理的にRelying Partyの近くにいる対面の場合の通信フローであり、Wallet InstanceとRelying Party Instanceの間で近距離無線通信技術（NFC、Bluetooth等）を使用して、EAA（電子属性証明）が交換される。この間、Relying Party側の代表者（人間）がプロセスを監視する。

近接非監視フロー（Proximity Unsupervised Flow）：近接監視フローと似ているが、Relying Partyが機械である点が異なる。EUDIWは人間による監視がない中で、Relying Partyとして機能する機械に対してEAAを提示する。

遠隔デバイス横断フロー（Remote Cross-Device Flow）：このケースでは、EUDIWユーザーは、EUDIWとは分離されている別のデバイスを使ってサービス情報を閲覧する。EUDIWは安全なセッションを結ぶためにのみ使用される（例：オンラインサービスにアクセスする際に、EUDIWでログインページのQRコードをスキャンする等）。

遠隔同一デバイスフロー（Remote Same-Device Flow）： このケースでは、EUDIWユーザーは、オンライン接続におけるセッションのセキュリティ保護と、情報交換を含むデジタルサービスの利用の両方で、EUDIWデバイスを使用する。

　Relying Partyがサービスを提供するためにユーザー認証といくつかのデータを必要とする場合、サービスのプロセスはウェブブラウザまたはモバイルアプリのいずれかで開始される。特に遠隔同一デバイスフローでは、サービスプロバイダがEAA（電子属性証明）やデータを必要とする時はいつでも、ユーザーのブラウザやアプリはEUDIWにリクエストをリダイレクトする。

　これとは対照的に、遠隔デバイス横断フローと近接監視フローおよび近接非監視フローでは、ウェブブラウザとのやり取りを必要としないNFCタップまたはQRコードのスキャンによってWallet Instanceをアクティブ化することからサービスプロセスが始まる。

【WSCDの実装方法別アーキテクチャ】
　暗号機能等の高い安全設計に基づくEUDIWソリューションは、WSCD（Wallet Secure Cryptographic Device）の実装方法によって、少なくとも4つの異なるタイプのアーキテクチャに分けられる。

リモートWSCD： HSM (Hardware security module)を使用してWallet Providerによって実装された機能を使用するアーキテクチャで利用されるデバイス。WSCDはユーザーのデバイスとは別の遠隔地に設置されている。

ローカル外部WSCD：デバイスにセキュアエレメントのような十分安全なハードウェアがない場合、セキュリティを強化するための外部機器が必要になる。例えば、ユーザーのデバイスに接続して暗号化機能を提供する外部WSCD（ハードウェアトークンやスマートカードなど）が使われる。

ローカルWSCD：ユーザーのデバイス内にWSCDが直接統合されているアーキテクチャで利用されるデバイス。これには、eSIM/eUICC や eSE （内蔵セキュリティエレメント）などのソリューションが使われる。WSCA（例えば Java カードアプレット）はWallet Providerによって配置される。

ハイブリッド・アーキテクチャ：前の3つのアプローチのうち2つ以上を組み合わせたもの。

最後に

　本レポートでは、EUDIWのeIDAS2発効後の動向を紹介するとともに、EUDIWのリファレンス・アーキテクチャの概要について解説した。EUDIWでは、「ウォレットは多種多様であっても、仕様はヨーロッパ共通（One European set of specifications. Many different wallets.）」と謳われている。EU全域で国境を越えてシームレスに機能するウォレット構築に向け、共通の標準仕様を定めるとともに、これを実施法で参照することで実効性を確保しており、すべての EU 加盟国のすべてのウォレットの仕様に反映される仕組みとなっている。各加盟国は、eIDAS2発効に基づき、2026年までに、国民、居住者、企業に向けて少なくとも1つの EUDIWを提供[i]することが義務付けられている。今のところ、スケジュールは守られており、EUDIWはリリースに向けて着実に進捗しているように見受けられる。

レポート一覧