最近 ID 界隈で話題になっているトピックとして、デジタルIDウォレット(DIW) というコンセプトがあります。これは、身分証、運転免許証や、銀行のキャッシュカード、さらにはお店のポイントカードまで、あらゆる本人のアイデンティティに関するデータを、スマホアプリに保存し、必要に応じて、必要な情報だけ、必要あれば複数をまとめて一度に、提示できるというコンセプトです。
話題になっている背景、必要となる技術、欧米の動きなど、２０２３年１２月時点での私の理解をまとめました。
明確なソースがある情報は、極力ソースとなるURLを添付しています。
また、一般論としてここに記載する情報については、国内外の多くの識者の方のお話を、直接的、間接的に伺う中で、私の中で咀嚼、消化した内容となっております。ここの皆様のお名前は略させて頂きますが、御礼申し上げます。それでも、本ブログの内容に誤りがあれば、すべて私の責任です。
認識の間違い、意見の相違、種々あるかと思いますが、是非コメントやプルリクを頂ければうれしいです。
この記事の内容は、筆者である@kkoiwaiの私見です。所属・関係する企業・団体とは一切関係ありません。
背景
eIDASの動き
EUでは、近日中に、eIDAS2という法律が制定される見込みです。eIDAS2で決まっていることの1つとして、発効から12ヶ月以内に、EU加盟国は国民にデジタルIDウォレットを提供しなければならないと規定されています。
- For the purpose of ensuring that all natural and legal persons in the Union have secure, trusted and seamless access to cross-border public and private services, each Member State shall issue a European Digital Identity Wallet within 12 months after the entry into force of this Regulation.
eIDAS2.0 Article 1 (7) 抜粋
EUの想定しているデジタルIDウォレットでは、オンラインで運転免許証を提示してレンタカーを借りたり、銀行口座を開設したり、大学の学位や処方箋を保存したりする事ができるようになります。
European Digital Identity – Questions and Answers
確かに、大学の学位などの資格証明書が個人と紐付く形で格納でき、それを身分証明書と一緒に提示できるというユースケースは便利な気がします。
さらには、EU圏で多数のユーザがいる巨大プラットフォーマーはデジタルIDウォレットをつかって、認証（ログイン）できるようにならなければいけないと定められています。
Where very large online platforms as defined in Article 25.1. Regulation [reference DSA Regulation] require users to authenticate to access online services, those platforms should be mandated to accept the use of European Digital Identity Wallets upon voluntary request of the user.
eIDAS 前文(28) 抜粋
ここで補足ですが、たとえば Google や Facebook にデジタルIDウォレットでログインできる必要があるといっても、Google や Facebook に個人情報を渡す必要はありません。デジタルIDウォレットには、政府以外も証明書を格納できる（はず）なので、政府の発行した証明書とは独立して、 Google や Facebook のユーザであるという証明書を発行しておけば良いだけです。
アメリカ（合衆国）の動き
さらに、アメリカでも、Google Wallet、Apple Wallet上に、州の運転免許証を格納する取り組みが進んでいます。州の独自アプリも使える場合もあります。
アメリカでは、パスポートを除き、国のIDカードというモノがありません。実質的に、各州のDMV（Department of Motor Vehicles)で発行される、運転免許証と、（運転できない人も同じフォーマットで発行される）IDカードが、身分証として通用しています。
このカードの仕様も州ごとに異なっていて、州によってはICチップが内蔵されていない場合もあります。安価にICチップ付きの身分証を発行する方法として、スマホのWalletを活用するという意図もあるのではと個人的には思います。
アメリカの取り組みは、あまりデジタルIDウォレットという文脈で語られない気がしています。それは、なぜかというと、運転免許証だけに完結しているように見えるからです。アメリカは、運転免許証をスマホに格納するという機能だけが求められているように見えます。ウォレットとして、証明書の安全な保管や選択的開示の機能はあるけど、複数の証明書を格納して、まとめて提示するような用途があまり想定されていないように感じています。
デジタルIDウォレットに求められる要件
では、デジタルIDウォレットとは、どういう性能が求められるのでしょうか。
今でも既に、お店のポイントカードはスマホに入っているし、銀行のキャッシュカードは入っていなくても，スマホだけでATMからお金を下ろせるようになっているし、さらには、マイナカードの証明書をAndroidスマホに格納することもできている現在、一体何が新しいコンセプトなのでしょう。
カード入れを持ち歩かず、スマホ1台で外に出歩けられることだけがうれしいことなのでしょうか。
デジタルIDウォレットの要件においては、安全性、相互運用性、そしてプライバシーの観点、さらに、それぞれ、オンライン・オフライン双方の利用方法の観点が関連します。
安全性
まずは安全性。
電子証明書という、ITの世界では当たり前のように使われている技術を使います。電子証明書は電子署名されたデータで、記載された内容の正しさを検証できます。
では、身分証明書として使うには、それだけでいいのでしょうか。だめです。証明書を渡した相手が、その証明書をコピーして使い回して、他の人になりすます可能性があるからです。
なので、証明書を本人に紐付ける、「バインド」する必要があります。
証明書と本人との紐付け方法として、3種類に分類できると言われています。 Cryptographic(暗号), Claim(属性), Biometric(生体)です。
Holder Binding:
Ability of the Holder to prove legitimate possession of a Verifiable Credential.
Cryptographic Holder Binding: (中略)
Claim-based Holder Binding:(中略)
Biometrics-based Holder Binding:(中略)
OpenID for Verifiable Credential Issuance - draft 12 抜粋
認証の3要素(記憶・所持・生体)と違うのは、認証は記憶要素として、パスワードを使った認証ができますが、証明書にパスワードを記載したら、それを受け取った側が見てしまえば意味が無いからです。
- 暗号による紐付け(Cryptographic Holder Binding)
- 秘密鍵の所有を前提とします。当該秘密鍵に対応する公開鍵の情報を証明書に記載します。提示先から乱数のチャレンジをもらって、秘密鍵で署名することで、秘密鍵を所有している証明になります。
- 属性による紐付け(Claim-based Holder Binding)
- 本人と紐付ける情報を証明書に記載します。例えば氏名と生年月日です。よって、別の身分証（マイナカードや免許証）と一緒に利用する前提です。
- コロナワクチン接種証明書がこの例です。接種歴の確認時は、身分証明書等で本人確認を行う事が定められています。(ワクチン・検査パッケージ制度要綱 4ページ)
- 生体による紐付け(Biometrics-based Holder Binding)
- 生体情報を証明書に記載します。一番利用されるのは写真です。証明書内に保存された写真と、目の前にいる人の写真が一致することを確認することで本人である事を確認します。
３つの紐付け方法、それぞれ課題があります。
属性による紐付けは、どうやって１対１に紐付けするのか。１１桁の個人番号(マイナンバー)を使えば日本ではユニークに特定できますが、社会保障、税、災害対策など、法律で定められた用途以外の利用は禁止されています。氏名・生年月日では複数人物がいる可能性があり、確実に特定はできません。さらに、漢字氏名は外字問題、そしてかな氏名は公的な情報でないという問題もあります。
生体による紐付けは精度の問題があります。どれだけ頑張っても、2人の人が同一と判断されるリスクや、同一の人物なのに別の人物と判断されるリスクがあるし、顔写真や指紋のコピーを受けいれてしまう可能性もあります。
暗号による紐付けは、秘密鍵が漏れない限り、かなり安全といえます。
一方で、秘密鍵をどう扱うかは課題です。例えばマイナンバーカードには対タンパ性のあるICチップが入っていて、中のデータを複製できないようになっていますが、スマホアプリで秘密鍵を普通に保管したら、メモリを覗くことで秘密鍵を盗まれるかもしれません。秘密の情報を間違えてログに出力してしまい、攻撃を受けたといったようなニュースはよく目にするところです。
とはいえ、今のスマホには、マイナカード同様に秘密鍵を安全な領域の中で生成し、外に出さないまま保存できる領域があり、一般のアプリでもそれを使うことができます。Android では StrongBox, iOS では Secure Enclave がそれに当たります。
では、それを使えばOK・・・ではないのです。
ユーザのニーズとして、自分の情報が安全に守られている事も大事だけど、それ以上に、 証明書の発行元のニーズとして、証明書が複製されないこと が大事だったりします。
それはなぜか。証明書がコピーされることの責任はユーザが負担するのであれば、ユーザが自分の責任でウォレットを選べばいいのではないか。否。
証明書が複数作成されることで、意図的ななりすましの危険性が上がります。2枚証明書があれば、もう1枚を他人に売りつけることができ、それを使った不正の可能性が上がります。
例えば taspo をつかって自動販売機でタバコが買えるのは、taspoが原則1枚しか発行されず、年齢確認をした本人だけが保有している可能性が高いからと考えられます。もし10枚も発行されてしまったら、未成年に渡してしまう可能性が増えます。
お店でも、通常免許証で年齢確認をしている事が多いと思いますが、健康保険証でも普通に通る事が多いと思います。ほとんどの健康保険証には顔写真がないので、実質的に所持による紐付けでしかありません。さらに言えば、免許証であれば顔写真を比較できますが、店員さんはそこまで厳密チェックしているでしょうか。
つまり、今の世の中の現実の本人確認のユースケースは、実は、「所持」の要素に大きく依存している ことが分かってきます。
現に、日本の法律の一部でも、１枚だけ発行されているという点を重視している事が伺える記載があります。
（本人確認の方法）
第三条 法第三条第一項の総務省令で定める方法は、次の各号に掲げる相手方の区分に応じ、それぞれ当該各号に定める方法とする。
一 自然人（法第三条第三項の規定により相手方とみなされる自然人を含む。） 次に掲げる方法のいずれか
イ 当該自然人又はその代表者等（法第三条第二項（法第五条第二項及び法第十条第二項において準用する場合を含む。）にいう代表者等をいう。第十三条、第十四条及び第十六条を除き、以下同じ。）から第五条第一項第一号（ニ及びヘを除く。）又は第三号に規定する書類の提示を受ける方法。ただし、当該代表者等からの同項第一号ホに掲げる書類の提示にあっては、 当該書類は一を限り発行又は発給されたものに限る。
携帯音声通信事業者による契約者等の本人確認等及び携帯音声通信役務の不正な利用の防止に関する法律施行規則 抜粋
だからこそ、証明書の発行元として、いま証明書を発行しようとしている先のウォレットが、本当に秘密鍵を安全に生成し、守ってくれるのか、マイナカードレベルとは言えなくても、それに近いレベルで、「所持」要素を保証してくれるのか、事前に確認したいというニーズがあるのです。
Android、iOS どちらもその仕組みは用意されていますが、その確実性には若干の差があります。
まず、Android, iOS ともに、端末が Google、Apple が認める基準に基づいた真性な端末とOSであること、今動作しているアプリが、アプリストアから配布された、改変されていないアプリであることをそれぞれ確認する仕組みがあります。つまり、正しい端末で、正しいアプリで生成された鍵は、きっと、安全に鍵が管理されていると推定することが可能です。これは、アプリを作った会社と、そのアプリが載っている端末と、OSの3者を信頼している ということになります。
これで十分と思う発行元も多いかもしれませんが、もっと確実に、端末内で安全に秘密鍵を生成したことを、その秘密鍵に紐付いた形で証明する事（技術的にはKey Attestationと呼ばれる）を求めたい発行者もいるでしょう。Key Attestation であれば、秘密鍵を生成した端末のメーカと、それを認定したGoogleの２者だけを信頼すればよい ことになります。ただし、この Key Attestation は、Androidの、比較的新しめの端末の一部でしか対応していません。（つまり iOS で非対応）
さらに Google も信頼できないのであれば、秘密鍵を生成した端末、ないしICチップの Key Attestation を求める事も可能です。ICチップには、マイナカードであったり、クレカなどでも実績があるのと、認証制度があるので、信頼度が高いと言えます。ここからは私の想像ですが、Felicaも、ICチップベンダーのKey Attestationを利用しているのではと思います。
また、参考までに、Samsung の Android デバイスは、Samsung 独自の Attestation の仕組みがあります。
Enhanced Attestation uses the Samsung Attestation Key (SAK) to prove:
- The key is protected by a secure hardware.
- The device is manufactured by Samsung.
- The device ID isn’t compromised.
Samsung Knox Attestation
実は、eIDAS2で定めている事のひとつとして、デジタルIDウォレットを実現するために必要な技術要素を解放するようプラットフォーマに求めています。
引用を読む
This Regulation should build on Union acts ensuring contestable and fair markets in the digital sector. In particular, it builds on the Regulation XXX/XXXX [Digital Markets Act], which introduces rules for providers of core platform services designated as gatekeepers and, among others, prohibits gatekeepers to require business users to use, offer or interoperate with an identification service of the gatekeeper in the context of services offered by the business users using the core platform services of that gatekeeper. Article 6(1)(f) of the Regulation XXX/XXXX [Digital Markets Act] requires gatekeepers to allow business users and providers of ancillary services access to and interoperability with the same operating system, hardware or software features that are available or used in the provision by the gatekeeper of any ancillary services. According to Article 2 (15) of [Digital Markets Act] identification services constitute a type of ancillary services. Business users and providers of ancillary services should therefore be able to access such hardware or software features, such as secure elements in smartphones, and to interoperate with them through the European Digital Identity Wallets or Member States’ notified electronic identification means.
もしかしたら、最近 iPhone の充電ポートがLightningからUSB-Cになったように、iOS 端末でも、Key Attestationが利用可能になる未来が待っているかもしれません。
以上でわかる通り、どんなウォレットアプリに証明書を発行するかは、ユーザが選ぶ以前に、発行者が選択する事になります。政府の発行する身分証であれば、もしかしたら政府のつくったマイナポータルアプリの拡張版でしか使えないかもしれないし、LINEやPayPayやApple WalletやGoogle Walletで使えるようになるかもしれないけど、すべて発行者である政府次第なのです。
ところで、安全性を考えるときに留意すべきことは、総合的にみて、本当にそれが必要かどうかという点だと考えます。そもそも現状、お店で免許証を見せるときに、それが本物かどうか、どれだけの精度で確認しているでしょうか、バイトの店員さんが、偽物を正確に判定できるのでしょうか。
そういった現状の運用を考えたときに、スマホに身分証を載せたとして、どのレベルで安全性を担保した方がいいのでしょう。もちろんユースケースにも依存しますが、現行の物理的な証明書での運用と同じレベルが満たせるのであれば、必ずしも完璧を目指す必要が無いかもしれません。
もっと言えば、信頼度も、複数の要素のバランスで実現します。例えば、今のカード型身分証は、所持の要素に信頼度のバランスが大きく依存していたと思います。一方、ウォレットで提示する身分証は、より大きい、解像度の高い写真を保存しておくことで、生体情報の精度を高めることにして、逆に所有要素としての端末の生成する秘密鍵のプロテクションの強度を弱める（マイナカードと同等のICチップに対する信頼ではなく、OSに対する信頼で受け入れる）という判断もありうるのではないでしょうか。
さらに、オンラインの安全性を考えたときには、先ほどのバインディングの話がもっと複雑になります。
そもそもオンラインで相手の本人性を確かめるにはどうすればいいのでしょう。オンラインでは、対面で相手の顔を確認できないため、対面に比べて、さらに所持の要素への依存のバランスが増えます。
スマホのカメラを使った、セルフィーによる確認の方法もありますが、スマホによってカメラの精度が異なるので自動的な検知が難しく、エラー率を下げる必要があったり、スマホを改造されていたり、周りに人がいない環境で不正をやりやすくなるというリスクがあります。
そのため、オンラインでの本人確認においては「本人にしか発行されていない証明書」という特性がより強く求められるでしょう。よって、端末内の秘密鍵のプロテクションの強度要求が強くなると考えられます。
相互運用性
ずいぶん長くなってしまいましたが、次に、相互運用性です。
日本中のすべての酒屋で、Walletを見せて、それで受け付けてくれるのかという観点です。
さらには、日本の運転免許証をもっていれば、アメリカのバーでパスポートを見せずにお酒を飲めるようになる世界が来るとなお良いですね。
これには、技術的な相互運用性と、制度的な相互運用性の両方が関係します。
技術的な相互運用性
物理のカードであれば、相手に見せて、カードっぽい形で、写真がそれっぽい人であれば（人によっては、さらにラミネート加工とかキラキラとか紫外線ライトで照らして見るかもしれないけど）、それで確認ができますが、スマホの画面を提示するだけでは、スクショや偽造された画像との区別がつきません。
よって、スマホで提示するためには、店員さんが持つ端末と、お客さんが持つWalletの間で通信して、署名された情報を渡す必要があります。そのための通信規格と情報のフォーマットを揃えなければ、相互運用性は実現できません。
現時点で、この証明書を受け渡すための仕様（トランスポート層）として、主に下記の３つが提案・検討されています。
- ISO18013-5
- OpenID4VP
- DIDComm
その中でも、店頭、対面での通信のユースケースをサポートしているのは、ISO仕様です。ISO仕様では、BLEやWi-Fi direct, NFCでの通信がサポートされています。
OpenID4VPも、オンラインに加えて、BLEによる対面での仕様が検討されている途中です。
そして、情報のフォーマット（データモデル）としては、主に下記の３つが提案・検討されています。
- ISO18013-5 (mdoc 形式)
- W3C Verifiable Credentials
- AnonCreds
EUでは、Architecture and Reference Framework によって、トランスポート層はISO仕様とOpenID仕様、データモデルは mdoc と Verifiable Credentials を採用する事になっています。
アメリカでは、各州の運転免許証発行者(DMV)が集まった団体の AAMVA によって、ISO仕様が利用される事になっています。
制度的な相互運用性
物理のカードであれば、運転免許証とはどんな形か、パスポートとはどんな形のものか、人々の間に共通認識があるため、それを相手に見せればたいてい通用します。
一方、スマホの通信によって証明書を相手に提示し、それを受け入れてもらうには、提示された証明書が本当に日本の警察が発行した運転免許証なのかを、相手のスマホ内のアプリが確認できる必要があります。なぜなら、デジタルなデータは、物理的なカードと異なり、誰でも複製できてしまうためです。
例えば、印鑑は誰でも作れますし、持てますが、その印鑑が本当に特定の持ち主のものであるという証明には、自治体の発行する印鑑証明書が必要です。マイナカードに内蔵されている電子証明書は、公的個人認証サービス（JPKI）でその真正性や、有効性を確認できます。Webサイトを閲覧するとき、HTTPS通信を始める際に、ブラウザは、通信相手が本当に正しいWebサイトなのか、通信相手から電子証明書を受領して、認証局によって認証されていることを確認します。
パスポートのICチップに含まれる証明書についても、国際民間航空機関（ICAO）という国連専門機関 が、パスポートの発行者である各国政府の公開鍵を管理していて、各国はそれを参照しています。このおかげで、日本のパスポートをフィンランドの入国審査官に見せても通用します。
デジタルIDウォレットの普及においても、証明書の発行者が正当である事を確認するための仕組みの整備が必要になります。この仕組みを総じて「トラストフレームワーク」と呼ぶ場合があります。
そして、何よりも重要なのが、デジタルIDウォレットで提示された証明書が、法的に受け入れ可能かどうかです。
例えば、金融機関での本人確認方法は、犯収法の施行規則で細かく規定されています。デジタルIDウォレットによる身分証の提示は、この法律で認められた本人確認書類に該当するでしょうか。
もしくは、当事者以外の第三者が過去に本人確認を利用した結果を利用する方法を、依拠と呼びますが、現行法では、金融機関以外の第三者が本人確認した結果に依拠することはできません。もし、デジタルIDウォレットが、（ウォレットの提供者への）依拠による本人確認であるとされたら、どうでしょうか。
いずれにせよ、デジタルIDウォレットがあらゆる場所で通用するためには、あらゆる法律の改正も必要となってくる可能性があります。
プライバシー
最後に、忘れてはならない、プライバシーです。
プライバシーにも、いくつかの観点があります。
発行元からの特定可能性
まずは、発行元からの特定可能性の観点です。
たとえば道ばたでおまわりさんから職務質問にあったら、免許証を見せると思いますが、警察官は、免許証番号を警察署に伝えて、この免許証に紛失届けが出ていなかったり、指名手配や失踪届が出されている人でないことをデータベースで確認すると考えられます。
では、コンビニでたばこを買うときに、コンビニの店員さんは免許証番号を警察に伝えるのかといえば、もちろんそんなことはありません。仮にそんなことをしてしまうと、その人が、いつ、どのお店でモノを買っているのか、警察に丸裸になってしまいます。
たとえば今、あらゆるインターネット上のサービスにログインするときに Google ID や Apple ID でログインしていると思いますが、これを、Federation（認証連携）モデルと呼びます。今までのインターネットの世界の身元確認は、このFederationモデルを前提としていました。Federation モデルのプライバシー観点の弱点は、今あなたがどのサービスを使っているのか、Google や Apple は全部分かっているということです。
一方、デジタルIDウォレットの世界では、ウォレットに一度証明書を格納しておけば、それを提示するだけでよく、カードの免許証をお店に提示するのと同じように、証明書の発行元に何の情報も伝えることなく、自分の属性を証明できるようになります。
ミニマムディスクロージャー
つぎに、必要な情報だけを提示する、ミニマムディスクロージャーの観点です。今の運転免許証を年齢確認のためにお店で相手に見せると、生年月日だけでなく、住所や運転できる車の種類、そして視力が悪いかどうかまで相手に見えてしまいます。本当に必要な情報は、20才以上かどうかだけであるので、その情報だけを提示できないのでしょうか。
この対応として、ハッシュ値を使った方法が、技術的に提案されています。
ハッシュ化とは、一方向変換関数を使ったデータ変換のことで、大昔でいえば、2ちゃんねるのコテハンでも使われていたものです。何かの情報を、特定の関数を通すことで、別の値に変換します。変換された値から元の情報に戻すことは現実的に不可能ですが、関数は公開されているので、元の値を知っている人であれば、変換後の値を計算することは簡単にできます。
これをどう使うかというと、証明書を発行する発行者は、証明書の中に、証明したい情報をハッシュ化されたデータだけを格納します。
そして、ユーザが証明書をお店で提示する時は、ハッシュ化されたデータと、ハッシュ化する前の情報（例えば年齢が20才である）を一緒に渡します。すると、提示されたお店は、提示された情報を同様にハッシュ化して、その結果が証明書の中身と同一であることを確認できるので、つまり証明書が証明している情報であることが分かります。
この仕組みを利用している証明書のフォーマットの標準規格として、前述の ISO18013-5 で標準化されている、mdoc というフォーマットと、IETF で標準化されている、SD-JWT というフォーマットが存在します。
リンク(名寄せ)可能性(Linkability)
では、これでプライバシーの問題が解決したかというと、そうでもないのです。
ハッシュ化された証明書とはいえ、同じ証明書を使い回すと、たとえば、A商店とB商店で同じ証明書を提示すると、もし、A商店とB商店が結託すれば、同一人物であることが分かってしまうのです。インターネットの世界でも、異なるドメイン間のCookie共有は問題になっていますが、同じ問題が現実世界でも発生してしまう、これを「リンク可能性(Linkability)」と呼ばれる事があります。
この課題の対応として、とてもシンプルに、証明書を事前に大量に発行して、各商店に別々の証明書を提示すればいいという案があります。
それでも実は、解決していない問題があります。それは、証明書の発行元と証明書の提示先が結託した場合です。たとえば、A商店、B商店に警察が立ち入って、受け取った証明書のデータを見たら、証明書の発行者である警察には、A商店、B商店に誰が訪れたのか、分かってしまいます。
現状の店頭では、店員さんが氏名を見てもほとんどはそれを忘れてしまうので、仮にあとで警察官が訪れたとしても、誰が訪れたのか、それだけで正確に把握することは困難になります。（ここで、ポイントカードや監視カメラのことは一旦忘れておきます。）
この課題にも、既に解決策は見えていて、ゼロ知識証明と言われる方法を使うことで、証明書としての真性確認可能性を維持しながら、たとえば20才以上かだけの情報を証明したり、さらには証明書の発行者であっても本人を特定する情報が得られないような情報提供をすることができるようになります。
ただ、その仕組みがあまりに難しすぎるので、まだ理解が進んでいないのと、現行のスマホのハードウエア処理でサポートされていないのと、プログラムへの実装も未成熟でバグが見つかったりしていると聞いているので、この技術が広く使われるにはもう数年時間がかかりそうです。（完全に私見、というか私が全く分からん状態なのでものすごく適当なことを言っている自覚があります。）
このゼロ知識証明を利用可能なフォーマットとして、AnonCreds 形式や、JSON-LD 形式があります。
デジタルIDウォレットが求める世界観
個人のアイデンティティ情報を、デジタルな方式で他者と共有するというユースケースに対して、今までご説明した、安全性、相互運用性、プライバシー、の3つを実現した世界感が、デジタルIDウォレットであると言えると小岩井は考えます。
デジタルIDウォレットとブロックチェーン
ここで気づいていただきたいのは、今まで、デジタルIDウォレットの事を語るなかで一度も、ブロックチェーンに関して言及しなかったことです。
ブロックチェーンは、あらゆる技術の中の、デジタルIDウォレットを構成する技術の候補の一つでしかありません。ブロックチェーン技術を活用することで、デジタルIDウォレットの世界感を補完できるかもしれないけど、必須な技術でもありません（私見）。
少なくとも、個人の情報をブロックチェーンに格納するということは、その人の黒歴史が半永久的に残ると言うことでもあり、EUのGDPR規制でも認められていません。
Article 17
Right to erasure (‘right to be forgotten’)
- The data subject shall have the right to obtain from the controller the erasure of personal data concerning him or her without undue delay and the controller shall have the obligation to erase personal data without undue delay where one of the following grounds applies: （後略)
GDPR 抜粋
一方、ブロックチェーン上に、証明書の発行者の情報（公開鍵など）を残しておくことで、例えば大学が統廃合されて無くなってしまっても、自分の卒業証明書を検証するための大学の公開鍵は半永久的に残せるという利点は有用です。（ですが、量子コンピュータの時代に、電子証明書の暗号的な安全性が長期に保てるのかという課題もあります。）
また、ウォレットということで、仮想通貨と紐付けて考える人も多いと思いますが、端末内に秘密鍵を安全に保存して、それを使って署名するという機能以外は、何の関係もありません。でも、政府が仮想通貨を今後発行し、一般の人も使えるようになったら、同じウォレットで管理する世界感も、もしかしたらあるかもしれません。
ただし、そのときに利用できるウォレットは、今使われている Metamask 等ではなく、政府が認めたウォレットアプリに限られる可能性が高いと私は思います。（この記事の安全性についての記載を参照してください）
以上です。
以上が、２０２３年１２月時点での、私のデジタルIDウォレットに関する理解です。
デジタルIDウォレットについて、自分自身もよく分かってないし、周りの方々と雑談をしていても、全体像が見えないよねといった声を聞く中で、Advent Calendar もある事だし、ひとつまとめてみようかという気持ちに至りました。文章が長くなってしまった部分が、今の私が一番気にしている部分だという事も分かりました。
これからさらに自分が勉強していく中で、また世の中が変わっていく中で、自分の理解や考えも変わっていくのだと思います。今後、自分の考えがどう変わっていくかを確認できるという意味でも、今回この記事を書くきっかけを頂いた皆様に感謝申し上げます。
改めて、認識の間違い、足らない観点、意見の相違、種々あるかと思いますが、是非コメントやプルリクを頂ければうれしいです。
この記事の内容は、筆者である @kkoiwai の私見です。所属・関係する企業・団体とは一切関係ありません。