【EUDI Wallet 2.6.0を流し読み】初めてEUDIW ARFに関わるための要点整理
credit.recept0702
こんにちは。私はDID/VCウォレットソリューション「proovySDK/API」の開発、導入支援をメインに開発業務を行っています。
先日、EUDI WalletのARF（Architecture & Reference Framework）2.6.0を読み進め、実務実装の観点で「ここは抑えておくべき」と感じたところを整理してみました。EUでのウォレット実装のタイムリミットが迫る中、日本でもその動向をチェックされている方や、新たなプロジェクトの要素技術として利用を検討されている方が増加しているように思います。
そこで、EUDIWのARFを規格の読み物としてではなく、SDK/Wallet実装、Relying Party連携、等々を議論する上での共通のプロトコルをキャッチアップするという目的で概念を整理してみました。今後技術要素についてある程度語れるが実務を行ったことがない、といった方でもEUDIWについて調べる際に立ち返ってみられるような内容をお届けできれば幸いです。
ウォレット構成要素の全体像
いきなり概念図のようなものから始まってますが、ウォレットというアプリケーションを因数分解していくことでそれぞれの役割や概念が簡単になります。ARFの図解が非常にわかりやすいため画像を利用させていただいております。
User Deviceの枠の中にはWallet Instance, WSCA, WSCDとあり、その外側にWallet Providerが提供するWallet Provider Backendとあります。そして、上述の構成要素を点線で囲んでWallet Unitとなっています。つまり、ARFではWallet Unitというのがいわゆるウォレットアプリケーションのことを指していて、バックエンドからフロントエンド、端末内保存領域を含みます。
ウォレットの構成要素をまとめると以下のようになります。
ウォレット構成要素要約
- Wallet Unit（WU）
ユーザー端末上で動作するウォレットの実体。以下のコンポーネント（Wallet Instance/WSCD/WSCA/Wallet Proider Backend）と設定を含む構成体で、発行・提示・鍵管理・ユーザ承認を担う。 - Wallet Instance（WI）
ユーザー端末にインストールされるアプリ本体。提示プロトコル（OpenID4VP／ISO 18013‑5）・発行プロトコル（OID4VCI）・ユーザ承認フロー・失効確認などを実装する。 - Wallet Secure Cryptographic Device（WSCD）
秘密鍵と暗号処理を安全に実行する耐タンパ環境。以下の4種または、ハイブリッドを利用すると定義されている。- Remote WSCD: HSMのようなリモートでアクセス可能なデバイス。
- Local external WSCD: スマートカードのような外部デバイス。
- Local internal WSCD: 端末内SE/UICC/eSIMなど。
- Local native WSCD:OSのAPIを経由して利用するセキュア領域。。
- Wallet Secure Cryptographic Application（WSCA）
WSCD上の暗号アプリ/制御モジュール。鍵生成・署名・削除などの暗号操作を提供し、Wallet InstanceからSecure Cryptographic Interface（SCI）で呼び出される。Local internalではJava Cardアプレット、Local nativeではOS暗号APIがWSCA相当。 - Wallet Provider Backend（WPB）
ユーザーサポート・保守など運用やウォレットアプリケーションの処理を行うバックエンド。
基本的にどんなウォレットであったとしても上記の構成は変わりません。一方で、ウォレットプロバイダーごとにWallet Unitで提供するユーザー体験が異なり、それに伴ってバックエンドの処理も異なるということは想像がつきます。全て同じ構成ではありますが、Wallet Unitによって利便性が異なり支持を集めるウォレットが決まるのかもしれません。
また、ウォレットの秘密鍵などの保存に利用されるWallet Secure Cryptographic Deviceは４種類が定義されています。Remote HSMのような端末の外部で保管する形式や、各種スマホが提供する端末内SEを利用する形式などが記載されており、ハイブリッド形式も可能とあります。
これはスマホごとの対応の差をなくすという意図でもありそうです。例えばAppleが提供するiphoneはベンダーロックが激しいことでも有名で、EUでもさまざまな観点で問題になっています。ハイブリッド形式など複数の選択肢を設けることで諸々の制約を排除しているとも言えます。
ステークホルダーの役割の切り分け：発行・提示・検証の責務
また、VCを語る上では誰が発行者であり、誰が検証者なのか？も気になるところです。こちらのEUDIWでは単なる発行者という言葉ではなく、それぞれの用語で解説されていますので、ここで整理します。
以下がEUDIWにて発行者と呼ばれる主体です。それぞれ用語が利用されているので、ややこしいですが、そんなものなんだなと読み流していただければ。
- PID Provider: EU法・各国法に基づきLoA Highでユーザーの本人確認を行い、WalletへPIDを発行する公的・準公的機関。氏名・生年月日・国籍・識別子などの本人識別属性を管理し、失効確認用のステータスリストやレジストリ情報を提供する。PIDの存在はWallet Unitの状態（Valid/Operational）を規定する。
- QEAA:QTSP（Qualified Trust Service Provider）としてQEAAを発行する民間または公的機関。資格・在職・権限・年齢しきい値等の属性を、SD‑JWT VCやISO mdocで表現・提示。
- PuB‑EAA:公的セクターの責任主体（Authentic Source）またはその委任機関が発行するPuB‑EAAの提供者。QTSPが発行する適格証明書で署名チェーンを構成し、RPはPuB‑EAA本体の署名→機関証明書→トラストリストの順に検証する。法的効果は紙の証明と同等で、技術仕様・提示プロトコルはPID/QEAAと整合する。
- EAA Provider: QTSPではないトラストサービス事業者が発行する非適格EAA。教育・フィンテックなどのセクター規制や契約に基づき運用され、SD‑JWT VC／ISO mdocのフォーマットとOID4VCI/OID4VPで発行・提示。相互運用のためにAttestation Rulebookでスキーマ、検証手順、失効方式を明確化するのが基本。
PIDとは各国が発行する本人識別データのことになります。日本でいうところのマイナンバーということになるのでしょうか。QEAAは資格や属性を法的に担保されたもので、日本でいう医師免許などがこれに該当します。PuB‑EAAもQEAAと同様なのですが、異なる点は、Qualified Trust Service Providerではない事業者が発行するという点でしょうか。そしてEAAが上記以外のEAAのことで、例えば大学の学歴証明のような、民間レベルで発行するものがこれに当たります。日本で事業化を目指すようなプロジェクトのほとんどはEAAということになります。
この辺りは法的な枠組みによるものですので、調査すればよりしっかりとした情報もありますので、ぜひ詳細に知りたい方は色々と調べてみてください。
https://sbiferi.co.jp/assets/pdf/review/review_vol06_04_202408.pdf
また、以下はVCの検証者と呼ばれる主体になり、以下のように定義されています。
- Relying Party: Walletへ提示要求を行う。RPはWalletと通信するインターフェースを持ち、リクエスト時にRP認証を行い、受け取った属性の真正性確認ができる。
VCフォーマット: 現実解は“SD‑JWT VC／ISO mdoc”二本柱
VCのフォーマットが何が採用されるのか？というのも大きな議題の一つです。まだ未確定というのが現時点での回答ではありますが、現在のARFには以下のような記載となっています。
- 必須対応はISO/IEC 18013‑5（mdoc）とSD‑JWT VC。W3C VCDM v2.0は原則非適格EAA向けの任意。
- SD‑JWT VCはHAIPプロファイル必須、mdocのリモート提示はISO 18013‑7 Annex Bに則る。
- QEAAのペイロードは資格・在職・年齢しきい値等。大学等はQTSP認定や公的真正源の指定があればQEAA/PuB‑EAA側へなり得る。そうでなければ非適格EAAとして発行する。
現状の情報では、SD-JWT, mdocが現実的な回答ということになります。一方で、IETFのSD-JWTはいまだにドラフト。今後仕様が明確化されてるということなのでしょうが、読めない状況であることは確かです。
上記を参考に、仮に日本で実装するという観点で見た時に民間事業者は基本的に非規格EAAということになるので、取り得る選択肢としてはSD-JWTまたはW3C VCDM v2.0になるのでしょう。W3Cの仕様書にはSD-JWTへの互換性の記載もあり、現実的な選択肢と言えます。なお、弊社のproovyはどちらも対応しております。
Pseudonym（Passkey）について
ウォレットの機能、という第2章のセクションにおいて、ここが難解なポイントかと思います。要はWalletが各種サービスへのユーザー認証を安全・匿名に行うための仕組みをPseudonym（仮名化）としています。ウォレットがあればPIDなどを開示せずに各種サービスに安全にログインできるという機能を搭載するということです。ここで利用される具体の技術はパスキーと記載されています。
パスキーについては以下の記事が参考になります。
https://www.android.com/intl/ja_jp/articles/420
大変便利そうには聞こえるのですが、一般的にパスキーでログインをしているユーザーはiosならばapple keychain、androidならばsumsungやgoogleパスワードマネージャーを利用している気がするので、どのようなユーザービリティになっていくのかは気になるところです。
アンインストール時の鍵ライフサイクル
ARFではウォレットアプリがインストールされてから削除されるまで、どのようなステータス管理がなされるかが記載されています。例えば、PIDが発行されて初めてWallet UnitがValid（有効）となるなどです。
当然、ウォレットがユーザーにアンインストールされれば鍵の情報などは削除され無効状態となるわけですが、鍵の即時物理削除が困難なケース（外部カード未提示、端末オフラインでHSM等）の場合、運用設計が必要と記載されています。
実際にどのように対処するかまでは明言されていませんが、Wallet提供事業者は最低限上記のような場合への対処を考えておかねばならないということですね。
まとめ
個人的に読み進める中で、難解だったりややこしくなりそうな部分を整理してみました。法律や制度とも絡むような内容もあり、誤りがある場合もございますので、ご指摘いただけると幸いです。
まずはこの範囲を押さえておけば、EUDIWについて概念をある程度正しく理解し読み進めることができるのではないかなと思います。技術者でない限りこれ以上の情報は必要ないのでは？とも思いますが、何かこの記事を読んだことで理解が促進することができれば嬉しいです。
