EUDI Wallet のホルダーバインディング：提示が実際に証明するもの
所持の問題を一次資料から解説します。ウォレットの提示が証明する内容、ARF v3.0.0 がユーザーバインディングと顔写真について述べていること、脅威の一覧表、規制対象のチーム向けのリスクベースのステップアップ設計を取り上げます。
要点
EUDI Wallet のホルダーバインディングとは、ウォレットを提示する人と、本人確認データの発行対象となった人とを結び付けるものです。Architecture and Reference Framework (ARF) ではこれを User binding と呼んでいます。ほとんどの提示において、依拠当事者はこれを検証するのではなく、信頼しています。[2]
- 検証済みでデバイスに紐付いた提示により、データが真正で改ざんされていないこと、そしてウォレットが紐付けられた鍵を保持していることが証明されます。[2]
- 次回のログイン、払出しやパスワードリセットの際に、誰がその端末を持っているかは証明しません。
- 保証レベル「高」は実質的な保証です。ウォレットを標準の手段とし、リスクに見合う場面に限って顔認証を追加してください。
これが所持の問題です。ウォレットの署名は、ある鍵が使われたことを示します。その鍵から一人の人間にたどり着くには信頼の連鎖が必要で、その最後の環は貴社が管理していない端末上にあります。
だからといって、ウォレットが弱いわけではありません。ウォレットは保証レベル「高」のスキームのもとで発行されており、これを疑わしいものとして扱うチームはその価値を無駄にします。本ガイドでは、ウォレットが何に答えるのか、何を未解決のまま残すのか、そしてそのギャップをどう埋めるのかを解説します。
登録と証明書については、依拠当事者ガイドをご覧ください。連携方法の選択については、EUDI Wallet 統合プラットフォームの選び方をご覧ください。
ウォレットの提示が実際に証明するもの
リモート提示では、複数のチェックが順に行われます。貴社が行うものもあれば、ウォレット内部で行われ貴社からは見えないものもあります。
ステップ3は貴社からは見えません
署名とステータスを確認
デバイスバインディングを確認
ARF v3.0.0 第6.6.3節に基づく、簡略化したリモート提示。ステップ1、2、4は貴社または本人から見えます。ステップ3は見えません。[2]
| レイヤー | 確立されること | 確認者 | 貴社にとっての位置付け | 限界 |
|---|---|---|---|---|
| 発行者の署名 | データが真正な提供者から発行され、改ざんされていないこと[2] | 自社 | 第5b条(9)により、PID と属性証明について依拠当事者の義務とされています[1] | 誰が提示しているかについては何も示しません |
| 失効ステータス | データが提供者によって失効されていないこと[2] | 自社 | 推奨であり、義務ではない[3] | 鮮度はステータス情報源に依存する |
| デバイスバインディング | データが発行先のウォレットユニット内にあり、コピーではないこと[2] | 自社 | 推奨。ただし、ウォレット自体の認証に依拠する場合は必須[2] | 証明するのは鍵であり、人ではない |
| ウォレットの完全性 | 発行時点でウォレットユニットとそのセキュアハードウェアが有効であったこと[2] | 発行時のデータ提供者[2] | 間接的に信頼することになる[2] | 直接検証する手段はない[2] |
| 利用者認証 | ウォレットがデータを開示する前に利用者を認証したこと[2][6] | ウォレット | 間接的に信頼することになる[2] | 結果は貴社に届かない |
ARF v3.0.0は、規則上のウォレットユニット証明を2つに分けています。アプリの完全性と失効ステータスに関するWallet Instance Attestationと、鍵を保持するセキュアストレージに関するKey Attestationです。[2] 貴社の立場については、次のように述べています。「The Relying Party Instance does not have a way to directly verify the authenticity of the Wallet Unit and the Wallet Provider.」(依拠当事者インスタンスには、ウォレットユニットとウォレットプロバイダーの真正性を直接検証する手段がない。)[2]
ARFの図12:利用者は、依拠当事者からは見えない認証リンクを通じてウォレットユニットにアクセスします。出典:EUDI Wallet Architecture and Reference Framework、European Commission、CC BY 4.0。改変なし。
デバイスバインディング、ホルダーバインディング、そしてその先のギャップ
「ホルダーバインディング」という言葉には、3つの異なるリンクがまとめて含まれています。最初の2つはARFの概念です。3つ目は当社独自の呼び方です。
鍵とウォレットの紐付け
デバイスバインディング
- データがセキュアハードウェア内の鍵に紐付けられている[2]
- proof of possession（所持証明）とも呼ばれる[2]
- コピーとリプレイを防ぐ[2]
貴社で確認
ウォレットから本人へ
User binding
- 提示者がデータの発行を受けた本人であること[2]
- デバイスバインディングに依存する[2]
- 通常は信頼されるが、検証はされない[2]
ウォレットが実施する
本人から行為へ
Action binding
- この本人が後のこの行為を行ったこと
- 提示の外側にある
- 貴社のセッションと管理策の中にある
貴社のみ（当社の用語）
デバイスバインディングとUser bindingはARFの用語です。Action bindingはDiditによる呼称であり、いずれの標準の用語でもありません。
デバイスに紐付いたアテステーションに関するARFのディスカッションペーパーは、この違いを1行で述べています。「An attestation may be bound to a device but not to a User.」[11] 重要な定義は次のものです。
Section 6.6.3.9ARF v3.0.0
「User binding（「holder binding」と呼ばれることもある）とは、PIDまたはアテステーションを依拠当事者に提示する者が、実際にそのPIDまたはアテステーションの発行を受けたユーザーであるという特性である。」
出典：ARF v3.0.0、第6章[2]
通信上、貴社が制御する特性はOpenID4VPのrequire_cryptographic_holder_bindingです。既定値はtrueで、falseに設定すると、その証明のないクレデンシャルを受け入れることをウォレットに伝えることになります。[12] ARFがデバイスバインディング（device binding）と呼ぶものを、このプロトコルはホルダーバインディング（holder binding）と呼んでいます。[12][2] 有効のままにしてください。確認項目は当社のOpenID4VP検証者ガイドで解説しています。
法令とARFが定める内容（原文の表現）
これらの規定はウォレットの発行と提示を規律するものであり、アカウント上でのその後の行為を規律するものではありません。
| 規定 | 条文 | 貴社にとっての意味 |
|---|---|---|
| 規則910/2014 第5a条(4)(a) | ウォレットは、ユーザーが「under the sole control of the user」でデータを提示できるようにしなければならない[1] | 当社の解釈：ウォレットの構築方法に関する要件であり、個々のセッションについての認定ではない |
| 第5a条(5)(d)および第5a条(11) | ウォレットは保証レベル「高」の要件を満たし、保証レベル「高」のスキームの下で提供される[1] | 強固な基準であり、その主張に追加の証明は不要 |
| 第5b条(9) | 依拠当事者は、データの「認証および検証」について責任を負う[1] | 署名と有効性の確認は貴社が行う |
| 規則2024/2977 第3(5)条 | PID提供者は、発行するPIDが「発行先のウォレットユニットに暗号的に紐付けられていることを確保しなければならない」[4] | PID提供者はPIDをウォレットユニットに紐付けなければならない。貴社はその結果を検証する |
| 規則2024/2979 第3(1)条 | 「ウォレットユニットがウォレット利用者の認証に成功するまで」中核機能は提供されない[6] | ウォレットは動作の前に認証を行う |
| 実施規則2015/1502 附属書 第2.2.1項 | 保証レベル「高」について：「電子識別手段は、その所有者が他者による使用から確実に保護できるように設計されている。」[7] | 他者に対する保護であり、所有者が利用できるもの |
| WIAM_14、ARF附属書2 | PID用のセキュアハードウェアは、重要資産に対する暗号処理の前に、保証レベル「高」で利用者を認証する[3] | ウォレット内の第2の認証層 |
ARFの第6.5.3.3.1節は次のとおり定める。「ウォレットユニットの有効化時に、ウォレットユニットは利用者が2つの利用者認証メカニズムを設定することを確保する。」1つはOSレベルにあり、もう1つはPIDの発行、提示または削除の際に使われるセキュアな暗号ハードウェアにある。[2] 利用者がPIDを提示するには、両方を通過しなければならない。[2]
第6.6.3.9節は、この認証を信頼する根拠について述べる。「この信頼は、依拠当事者自身による検証の結果に基づくものではない」とし、「認証取得済みのウォレットユニットおよび(セキュリティレベル「高」のPIDおよび属性証明については)認証取得済みのWSCA/WSCDに対する事前の信頼」に基づくとする。[2](WSCAとWSCD:ウォレットのセキュアな暗号アプリケーションおよびデバイス。)ARFはさらに、この方法に依拠することは「依拠当事者がデバイスバインディングを検証しなければならないことを意味する」と付け加えている。[2]
このように、ARFは利用者バインディングについて3つの方法を示している。常に実行されるウォレットの認証を信頼する。PIDに含まれる顔写真とライブの顔を照合する。または、実際に本人のものであると検証できる本人確認書類とPID属性を照合する。[2]
保証レベル「高」が実質的な保証である理由
保証レベル「高」は「高い攻撃能力を持つ攻撃者に対する」保護を求める。[7] 認証審査はその耐性を試験する。[8] 偽造されたPID、複製されたウォレット、リプレイされた応答は失敗するはずである。当社の解釈では、保証レベル「高」は手段を記述するものであり、正当な保有者が自らその利用を貸与または売却することについては何も述べていない。
2025年10月14日付のARFのTopic Rワーキングペーパーには、「現時点では、モバイルデバイスには利用者認証が実施されたことをウォレット依拠当事者に証明する手段も根拠もない」こと、また一部の専門家の意見ではデバイスの生体認証は「完全には信頼できない」ことが記録されている。[10] これは議論の記録であり、要件ではない。
- 2026年8月11日顔写真の確認ルール規則2026/1731が発効。警告と明示的な確認。
- 2026年12月24日ウォレットの提供期限算出値:各実施法令から24か月。
- 2027年7月10日AMLR適用開始第22(6)条が義務主体を拘束する。
- 2027年12月24日受入れ義務算出値:第5f(2)条。法令または契約により強力な利用者認証の使用を義務付けられる民間事業者が、利用者の要請に応じて対象となる。零細企業および小規模企業は除外。
- 2028年8月11日PIDへの顔写真この日からPIDの必須属性となる。ただしオプトアウトあり。
12月の日付は、第5a(23)条および第5c(6)条に定める実施法令(規則2024/2977から2024/2982、2024年12月24日発効)の発効日から起算し、第5a(1)条および第5f(2)条に基づき当社が算出したものである。[1][4][5][13] 詳細は当社のEUDI Wallet期限ガイドを参照。
顔写真:有用、任意、かつ厳格に規制
顔写真は本人を確認する最もわかりやすい手段である。2026年7月15日に採択され、2026年7月22日に官報に掲載された実施規則(EU) 2026/1731により、そのルールが変更された。
- 時期。「ウォレット利用者の顔写真は、2028年8月11日以降に限り、自然人の必須の本人識別データ（PID）の一部とすることができる」。[5] 現行のPIDの表では、顔写真は「該当する場合、利用者が明示的にオプトアウトした場合を除き」含まれる。[5]
- オプトアウトは残る。 加盟国は「利用者が顔写真の格納を拒否できる選択肢を設けることができる」。その場合、値は空に設定される。[5]
- ウォレットによる警告。 ウォレットは、要求に生体データが含まれることを警告する。利用者は「顔写真の提示を明示的かつ個別に確認」しなければならない。[4] ARF RPA_07cは次のように付け加える。「沈黙又は事前にチェックされたボックスでは足りないものとする（SHALL NOT suffice）。」[3]
- 法的根拠ではない。 規則2026/1731の前文第2項は次のように述べる。「ウォレット利用者の明示的な確認は技術的な保護措置であるべきであり、それ自体が処理の法的根拠となるものではない。」[5] 同前文は、法的根拠についてGDPRの第6条及び第9条を参照している。[5]
- 保存。 顔写真は、データ保護法の下で「その処理が識別及び認証の目的のために必要である場合を除き、ウォレット依拠当事者が保存してはならない」。EU法又は加盟国の国内法が保存を定める場合も同様に例外となる。[4][5]
- 登録。 第5b条(3)により、登録した範囲を超えるデータは要求できない。したがって、顔写真は登録済みの利用目的に含めておく必要がある。[1]
遠隔での照合について、ARFは良好な照明、分かりやすい指示、そして「プレゼンテーション攻撃検知（PAD）に対応した承認済みの生体検知（ライブネス検知）の仕組み」と「インジェクション攻撃検知、特にディープフェイク検知の仕組み」を求めている。[2] ENISAは顔のプレゼンテーション攻撃について詳しく解説している。[21] ETSI TS 119 461は、インジェクション攻撃を「攻撃者が制御するコンテンツをデータ取得プロセスに注入する攻撃」と定義している。[23]
スマートフォンでの顔照合。攻撃対象となるのは撮影の工程である。画像：mikemacmarketing, Wikimedia Commons、CC BY 2.0。改変なし。
主張された本人であることの確認のみを目的とする1対1の照合は、AI Actの附属書IIIにある遠隔生体識別の項目から除外されています。[16] 個人を一意に識別するために用いる生体データは、引き続きGDPR第9条の特別な種類の個人データに該当します。そのため、法的根拠と影響評価を準備しておく必要があります。[15]
脅威ごとの整理：ウォレットが防ぐものと、貴社に残るもの
認証に関する規則には、ウォレットのリスク登録簿が含まれている。以下の脅威識別子は公式のものである。最後の2列は当社の評価である。[8]
| 脅威 | 登録簿 | ウォレットの効果 | 残るリスク | 貴社の管理策 |
|---|---|---|---|---|
| ウォレットデータの複製・コピー | TR60 | 強い：デバイスバインディング[2] | 検証すればほとんどない | バインディング証明を有効にしておく |
| 提示のリプレイ | Type 5.3 | 強い：貴社のデータに対する新たな署名[2] | ほとんどない | 要求ごとに一意のnonce |
| 盗難されたロック状態のスマートフォン | TR98 | 強い：2層の認証[2] | 知識要素の窃取（TR35） | 失効状況を確認する |
| 家族共用の端末 | TR35、TR98 | 一部 | PINまたはコードを知っている者[22] | 高リスク操作時のステップアップ |
| 強要または操作された利用者 | TR28、TR99 | 弱い：本人が承認してしまう | ほぼすべて | 取引モニタリング、クーリングオフ期間、状況に応じたステップアップ |
| クロスデバイスのリレー | TR103 | 一部：近接性チェック[24] | ブラウザセッションのフィッシング | 可能な場合は同一端末で行い、操作内容を明示する |
| 端末のローカル認証の突破 | TR113 | 認証取得状況による[8] | 端末侵害のリスク | 失効確認、端末シグナル |
| オンボーディング後のアカウント乗っ取り | ウォレットの範囲外 | 再提示しない限りなし | パスワード、セッション、アカウント復旧フロー | 重要な変更時のステップアップ |
| 本物のウォレットを持つマネーミュール | ウォレットの範囲外 | なし：すべてのチェックを通過する | すべて | 行動モニタリング、ネットワーク上のつながり |
承認する本物の利用者
TR99は次のとおりです。「攻撃者は、利用者を説得して、攻撃者または権限のない第三者との間で認証させ、取引を承認させることができる。」[8] どの要素もすべて通過します。ECBによれば、強力な顧客認証は「本来想定していた不正の類型に対しては引き続き有効」であり、2024年に欧州経済領域全体で報告された不正の総額は€4.2 billionでした。[19][20] クレジット・トランスファーでは、支払人を操作する不正が「2023年から2024年にかけて、金額ベースで65%から74%へ、件数ベースで55%から71%へ」増加しました。[19]
2人の人物、2台のデバイス
TR103：「依拠当事者とブラウザの接続の背後にいる利用者は、依拠当事者とウォレットの接続の背後にいる利用者と異なる場合がある。」[8] ARFセクション4.4.3.2は「クロスデバイスのフローはフィッシングおよびリレー攻撃に対して脆弱である」と指摘し、セクション4.4.3はこれらのフローについて近接性チェックを必須としています。[24] それでも、貴社のウェブセッションはウォレットでの承認とは切り離されたままです。
ARFの図5：クロスデバイスのフローでは、貴社のサービスはブラウザとやり取りし、ウォレットは2台目のデバイス上にあります。出典：EUDI Wallet Architecture and Reference Framework、European Commission、CC BY 4.0。改変なし。
本物のウォレットを持つマネーミュール
口座へのアクセスを売る人物や、他人のために口座を開設する人物は、本人が保有者であるため、ウォレットのチェックをすべて正当に通過します。有効な管理策は、マネー・ローンダリング防止規則（AMLR）がすでに定めている「業務関係の継続的なモニタリング」です。[13] 口座間のつながり、共有されたデバイス、繰り返し現れる顔が、ネットワークを明らかにするシグナルです。
ウォレットを標準としたままのステップアップ設計
当社が確認した文書のなかに、ウォレットに加えてライブネス検知を求めるものはありませんでした。AMLR第22条(6)(b)は、選択肢の一つとして「保証レベル『実質的』または『高』に関して規則(EU) No 910/2014の要件を満たす電子識別手段の利用」を挙げています。[13] マネー・ローンダリング防止機関（AMLA）の最終基準案は、これに「欧州デジタルアイデンティティウォレットが含まれる」としていますが、この基準はまだ案であり、法令ではありません。[14] 当社のウォレット受け入れに関するAMLRガイドをご覧ください。
AMLR第20条(2)は、措置の程度を「リスクの個別分析」に委ねています。[13] 当社の見解では、提示のたびに自撮りを求めることは、GDPRのデータ最小化の原則の下で正当化が困難です。[15] 以下の区分は当社の提案であり、法的な分類ではありません。
1イベントを分類する
オンボーディング、ログイン、または特定の操作と、そのリスク。
別人だった場合にどれだけの損害が生じうるか
ウォレットのみ
暗号学的チェックをすべて実施。生体認証なし。
ライブネス検知と顔照合を追加
顔写真、または適法に保有する顔画像と照合。
操作の時点で再検証
この操作に紐づく新たなチェックを行い、その後レビュー。
2証跡を記録する
実施した内容、結果、日付。顔写真はデフォルトでは記録しない。
判断フローの一例です。しきい値は貴社のリスク評価で設定してください。
| 区分 | 典型的なイベント | 管理策 | 理由 |
|---|---|---|---|
| ウォレットのみ | 年齢または属性の確認、通常の口座開設、低リスクのサインイン | 署名、デバイスバインディング、ステータス、nonce | 保証レベル「高」が役割を果たします。データは少ないほど望ましいです |
| ウォレットと顔 | 高リスク顧客、通常と異なるデバイスまたは所在地、長期間空いた後の初回利用 | 上記に加え、ライブネス検知と顔照合 | ARFが記述するとおり、User bindingに直接対応する[2] |
| 操作時の再確認 | 新規の支払先、高額の払出し、銀行口座情報の変更、アカウント復旧、デバイスの追加 | 新たな顔確認またはトランザクションに紐づく承認、加えて審査 | 本人をその操作に結びつける |
| ウォレットなし、または顔写真なし | ウォレットを持たない顧客、導入が遅れている国、顔写真の提供をオプトアウトした場合 | 本人確認書類、チップ読取り、ライブネス検知、顔照合 | ウォレットの利用は任意である[1] |
PIDで操作を承認することはできない。「Wallet UnitはRelying Partyから提示要求で受け取ったトランザクションデータに署名するためにPIDの秘密鍵を使用してはならない（SHALL NOT）。」[9] トランザクションの承認は強固なユーザー認証（SUA）のアテステーションが担う。SUAのアテステーションはトランザクションデータを含み、電子決済に関するARFのトピックに位置づけられている。[3] 決済法も同じ仕組みである。認証コードは「支払取引の金額および受取人に固有のもの」でなければならない。[18] PSD2の「支払不正その他の不正使用のリスクを伴うおそれのある、遠隔チャネルを通じたあらゆる行為」は、トリガーのモデルとして役に立つ。[17]
選択肢
再度ウォレット
- 新たなPIDの提示
- ウォレットを再確認する
- 操作との結びつきはない
ログインに適する
選択肢
顔確認
- ライブネス検知と顔照合
- その場にいる本人を確認する
- 適法な参照データが必要
リスクの高い変更に適する
選択肢
取引認証（トランザクション・アテステーション）
- 操作データに署名する
- 承認内容を利用者に表示する
- 発行者の対応状況による
決済に適している
注意点
PIDの鍵をデバイス識別子として使わないでください。プロバイダーは、「Relying Partyによる名寄せ（リンク可能性）のリスクを軽減する」ため、1回しか提示されないアテステーションを発行する場合があります。[2] 再訪した顧客の照合は属性で行ってください。詳しくは国境を越えた受入れに関するガイドで説明しています。
チェックリスト：今月やるべきこと
これらの手順の前提となる社内ポリシーはEUDI Walletのポリシーと統制に関するガイドに、導入経路の判断は統合プラットフォームに関するガイドにまとめています。
コンプライアンスとリスク
- ウォレットのみに依拠しているイベントを書き出す。
- 払出し、受取人の変更、アカウント復旧に対するステップアップの発動条件を定める。
- 顔照合を行う場合の法的根拠を決める。[5][15]
- 顔写真の利用に合わせてデータ保護影響評価を更新する。[15]
エンジニアリング
- すべてのリクエストでホルダーバインディングの証明を必須のままにします。[12]
- すべてのレスポンスでデバイスバインディングの署名を検証する。[2]
- 任意であっても失効状況を確認する。[3]
- 新しいnonceを使い、各提示を1つのセッションに紐付ける。
- 顔写真の値が空の場合も処理できるように顔写真の処理経路を構築する。[5]
プロダクトとサポート
- 顔写真は、登録済みの目的に含まれる場合に限り要求する。[1]
- ウォレットを持たない人のために本人確認書類による経路を残す。[1]
- ステップアップごとに、対象の操作を明示する文言を用意する。
- ウォレットが盗まれた場合はウォレットプロバイダーに失効を依頼できることを顧客に伝える。[6]
所持の問題に対してDiditができること
Diditのドキュメントでは、EUDI Walletの受入れはComing soon（近日提供予定）のステータスで掲載されています。[28] 当社のEUDI Walletページには「EUDI専用のDidit APIはまだありません」「今日から導入し、ウォレットが登場してもそのまま使い続けられます」と記載しています。このセクションでは、現時点で稼働している機能を説明します。Biometric Authenticationは、ライブネス検知と顔照合によるステップアップを実行します。
- 再確認。 Biometric Authenticationは、ワークフロー内のセッションとして、再訪した利用者をライブネス検知のみ、またはライブネス検知と保存済みの顔写真との顔照合の組み合わせで確認します。[25][27]
- 実在性。 ライブネス検知は、カメラの前に実在の人物がいることを、パッシブ、3Dアクション、フラッシュのいずれかの方式で確認します。[26]
- ステップアップ。 DiditのAuthenticationのドキュメントには、機密性の高い操作の前にステップアップのルールを適用し、確認が必要かどうかを返す呼び出しが記載されています。この機能は新しく、アプリケーションごとに有効化します。[31]
- ネットワーク Face Searchは重複アカウントを検出します。Networksは、デバイス、IP、生体情報、本人確認書類または連絡先のシグナルを共有する申請者をグループ化します。[29][30]
- モニタリング Transaction Monitoringは、設定可能なルールエンジンに照らして取引をリアルタイムでスクリーニングし、ケース管理も備えています。[32]
- フォールバック ID Verificationと稼働中の各国eIDが、ウォレットを持たない顧客に対応します。[28]
Diditが提供するもの
- 必要に応じたライブネス検知と顔照合
- 本人確認書類と各国eIDのルート
- 重複とネットワークのシグナル
- 各チェックの記録
貴社に残るもの
- リスク評価とステップアップのポリシー
- 貴社の法的根拠と影響評価
- 依拠当事者の登録
- 各オンボーディングと取引に関する判断
プランと料金は料金ページに掲載しています。保存データは貴社が設定した保存期間に従い、Diditは貴社の処理者として行動します。[33]
要点
- デバイスバインディングが証明するのは鍵です。ユーザーバインディングはその鍵を人に結び付けますが、通常は検証するのではなく信頼することになります。
- 保証レベル「高」はウォレットに関する強い保証ですが、自らの意思で協力するマネーミュールや操作された利用者には及びません。
- 顔写真は2028年8月11日から必須のPIDデータに加わります。ただしオプトアウトの対象となり、利用者の確認は法的根拠になりません。
- PIDは取引データに署名できないため、高リスクの操作には別途承認が必要です。
よくある質問
EUDI Walletにおけるホルダーバインディングとは何ですか。
ホルダーバインディングとは、データを提示する人がそのデータの発行を受けた本人であるという性質です。ARFはこれをUser bindingと呼び、holder bindingと呼ばれることもあると述べています。[2]
デバイスバインディングとホルダーバインディングの違いは何ですか。
デバイスバインディングは、データをウォレットのセキュアハードウェア内の鍵に結び付け、複製とリプレイを防ぎます。ホルダーバインディングは、データを人に結び付けます。ARFはデバイスバインディングをUser bindingの前提条件として扱っています。[2]
PIDにデバイスバインディングは必須ですか。
はい、提供者にとっては必須です。実施規則2024/2977は、PID提供者に対し、発行するPIDがウォレットユニットに暗号的に結び付けられていることを確保するよう求めています。[4]依拠当事者には署名の検証が推奨され、ウォレット自体の認証に依拠する場合は必須となります。[2]
ウォレットの顔写真と顔照合を行えますか。
PIDに顔画像が含まれ、その利用を登録済みで、ユーザーが確認し、適法な根拠がある場合に限ります。顔画像は2028年8月11日から必須のPIDデータに加わり、加盟国はユーザーにオプトアウトを認めることができます。[5]
ウォレットの提示で受け取った顔写真を保存できますか。
原則としてできません。保存できるのは、EUのデータ保護法を遵守した本人確認と認証に処理が必要な場合、またはEU法もしくは国内法が定める場合に限られます。[4][5]
AMLRは、EUDI Walletに加えてライブネス検知を求めていますか。
当社が確認した条文には、そうした要件はありません。第22条(6)(b)は選択肢の一つとして、規則910/2014の要件を保証レベル「実質的」または「高」で満たす電子識別手段を挙げており、措置の範囲は各社のリスク分析に従います。[13] AMLAの最終草案の基準は、これにウォレットが含まれるとしていますが、まだ法令ではありません。[14]
ウォレットの提示で決済を承認できますか。
PIDではできません。PID Rulebookは、PIDの秘密鍵で取引データに署名することを禁じています。[9] ARFは、取引ごとの承認には、取引データを含む強力なユーザー認証の証明を用いることを想定しています。[3]
保証レベル「高」でアカウント乗っ取りを防げますか。
保護されるのはウォレットであり、貴社のアカウントではありません。オンボーディング後のパスワード、セッション、アカウント復旧の手順はウォレットの外にあります。重要な場面で改めて提示や別の確認を求めない限り、この状況は変わりません。
マネーミュールはEUDI Walletのチェックを通過できますか。
できます。本物の保有者が本物のウォレットを使えば、すべてのチェックを通過します。チェックの内容が事実だからです。対策となるのは、AMLR第26条に基づく継続的なモニタリングと、アカウント間の関連付けです。[13]
DiditはEUDI Walletに対応していますか。
Diditのドキュメントでは、EUDI Walletの受け入れはステータス「Coming soon」と記載されており、ソリューションページには、EUDI専用のDidit APIはまだないと記載されています。[28] 各国のeID、本人確認書類の検証、ライブネス検知、顔照合は現在稼働しており、今後の計画はソリューションページに記載されています。
出典
- Regulation (EU) 2024/1183により改正されたRegulation (EU) No 910/2014、2024年10月18日時点の統合版、EUR-Lex。
- Architecture and Reference Framework v3.0.0、第6章、Trust model、欧州委員会、2026年7月23日。
- Architecture and Reference Framework v3.0.0、附属書2、High-Level Requirements、欧州委員会。
- Implementing Regulation (EU) 2024/2977、2026年8月11日時点の統合版、EUR-Lex。
- Implementing Regulation (EU) 2026/1731、EUR-Lex、2026年7月22日付官報。
- Implementing Regulation (EU) 2024/2979、2026年8月11日時点の統合版、EUR-Lex。
- 保証レベルに関するImplementing Regulation (EU) 2015/1502、EUR-Lex。
- ウォレット認証に関するImplementing Regulation (EU) 2024/2981、附属書Iリスク登録簿、EUR-Lex。
- PID Rulebook v1.7、欧州委員会、2026年7月17日。
- Topic R, Authentication of the User to the device, v1.0、ARFディスカッションペーパー、2025年10月14日。
- Topic Z, Device-bound Attestations, v1.0、ARFディスカッションペーパー、2025年9月29日。
- OpenID for Verifiable Presentations 1.0、OpenID Foundation。
- Regulation (EU) 2024/1624 (AMLR)、EUR-Lex、2024年6月19日付官報。
- 最終報告書、AMLR第28条(1)に基づくRTS草案、AMLA、2026年9月30日(最終草案であり、法令ではない)。
- Regulation (EU) 2016/679 (GDPR)、EUR-Lex。
- Regulation (EU) 2024/1689 (AI Act)、EUR-Lex。
- 指令 (EU) 2015/2366 (PSD2)、EUR-Lex。
- 委任規則 (EU) 2018/389、EUR-Lex。
- 決済不正に関する2025年報告書、EBAおよびECB、2025年12月。
- 決済不正に関するEBA・ECB共同報告書、プレスリリース、ECB、2025年12月15日。
- Remote Identity Proofing: Attacks and Countermeasures、ENISA。
- デジタルアイデンティティウォレットに関するTechDispatch、European Data Protection Supervisor、2025年12月。
- ETSI TS 119 461 v2.1.1、トラストサービス主体の身元確認、ETSI。
- Architecture and Reference Framework v3.0.0、第4章、ハイレベルアーキテクチャ、欧州委員会。
- 生体認証、Didit ドキュメント。
- ライブネス検知、Didit ドキュメント。
- 顔照合 1:1、Didit ドキュメント。
- デジタルIDウォレット、Didit ドキュメント。
- 顔検索、Didit ドキュメント。
- ネットワーク、Didit ドキュメント。
- ステップアップの作成、Didit ドキュメント。
- 取引モニタリング、Didit ドキュメント。
- データ保存、Didit ドキュメント。
ウォレットは、クレデンシャルが誰に属するかに答えます。リスク対応はその答えから始まります。本人の確認が必要な場面については、生体認証をご覧ください。ウォレットへの対応準備については、EUDI Wallet のページとeID 認証をご覧ください。