昨今、「Googleアカウントでログイン」や「Facebookアカウントでログイン」に代表されるような、IDプロバイダに登録されたユーザーに関する情報（本稿では広義の「ID情報」と呼称）を用いてサービスを利用することが当たり前の世界になっております。このID情報を連携する仕組みの一つとして、ユーザーが自分自身のID情報をウォレットに保持し、連携したいサービスへ提供することができる「デジタルアイデンティティウォレット」という技術が注目を浴びています。
このデジタルアイデンティティウォレットはまだ世界的にも仕様検討・実証実験段階のものも多くみられます。本稿では国内外の先行事例を紹介しつつ、実際にサービス化するにあたり検討が必要になると考えられる論点を紹介します。
▶「経営層を納得させるセキュリティ予算獲得術」をダウンロードする
デジタルアイデンティティウォレットが注目される背景
現在主流のデジタルアイデンティティ管理モデルの課題及び解決策について説明し、デジタルアイデンティティウォレットが注目されている背景を説明します。
①デジタルアイデンティティ管理の主流モデル
デジタルアイデンティティとは、個人に関する、電子化された属性情報の集合を指しています。オンラインを経由したサービスの利用や取引など、社会におけるやりとりが非対面で行われることが増えていますが、顔を直接確認できない従業員や顧客を「本人」だと確認し、必要なものを提供するために、デジタルアイデンティティの重要性が高まっています。
デジタルアイデンティを管理するモデルを２つ紹介します。１つ目は、「Centralized（集中型）モデル」です。各事業者がIDプロバイダとなり、個別にデジタルアイデンティティ管理とサービス提供を行います。ユーザーはサービス毎にデジタルアイデンティティ管理が必要となります。
２つ目は、現在の主流となる「フェデレーションモデル」です。各事業者とIDプロバイダは別の事業者が担い、ユーザーは各事業者のデジタルサービスにアクセスする際、IDプロバイダのデジタルアイデンティティ情報を用います。各事業者は、IDプロバイダから認証情報を連携されることでユーザーの認証を完了とします。ユーザーはサービス毎にログインする必要はなく、特定のIDプロバイダのアイデンティティ情報をもとに、複数のサービスにアクセスできます。
②フェデレーションモデルにおける課題
現在の主流となる「フェデレーションモデル」については、事業者・ユーザー双方に対して課題が存在しています。フェデレーションモデルにおけるID連携について、事業者目線では、連携に際しIdP同士で連携のための設定を行う作業負荷が生じます。上の図で示した通り、依存関係が強く、特定のIdPを親にして他IdPに連携を行う場合は連携数は限定されます。
一方で、相関性が低く、互いに自身が親になりたがるIdP同士の連携では連携対象が増大するため、接続の設定負荷が重くなる「①事業者の課題」があります。また、ユーザー目線では、そもそもユーザーがアイデンティティ情報を連携したいデジタルサービス間がIdP同士で連携済みでない場合は、アイデンティティ情報を連携することができないという「②ユーザーの課題」があります。
③課題解決を期待されるデジタルアイデンティティウォレットが登場
昨今、デジタルアイデンティティウォレットという構想が登場し、フェデレーションモデルの課題解決が期待されています。デジタルアイデンティティウォレットにより、ユーザーは自身のアイデンティティ情報をウォレットに保持し、ウォレットをハブとしたIdP間でのアイデンティティ情報の連携が可能となります。その結果「①事業者の課題」で述べた、各IdP間の連携の設定が不要となることが期待されます。
また、デジタルアイデンティティウォレットとのインターフェースを持つIdPであれば、ユーザーは任意のID情報連携先を選択可能となるため、「②ユーザーの課題」で述べた連携先が限定される、という課題の解消が期待されます。
④デジタルアイデンティティウォレットを実現する技術DID、VC
デジタルアイデンティティウォレットを実現する手段の１つとして、DID(Decentralized Identifier)、VC（Verifiable Credentials）という技術があります。トラストフレームワークに参加する各事業者、ウォレットに識別子（DID）を持たせ、アイデンティティ情報に情報発行事業者の電子署名を付けたデータ（VC）をユーザーはデジタルアイデンティティウォレットに格納できます。
ユーザーが格納したデータ（VC）を事業者に連携する際に、事業者側はVCに付いている署名を検証することで正当な発行者から発行されたデータであることを判断することができます。この仕組みを実現するために、分散データベースが活用されています。
デジタルアイデンティティウォレットの動向
現在、国内外においてデジタルアイデンティティウォレットやDID、VCに対する仕様検討・実証実験が進められています。デジタルアイデンティティウォレット、DID、VCの先行事例をいくつか紹介します。
①European Digital Identity Wallet
2021年6月に欧州委員会（European Commission）が欧州デジタルアイデンティティフレームワークに関する規制の修正提案を公開しました。本提案の中で取り上げられているのがEuropean Digital Identity Wallet（EUDIW）です。
EUDIWは、EUの公的・民間のデジタルサービス利用における本人確認/属性証明に利用できるデジタルアイデンティティウォレットを、希望する全EU市民、在留者、企業が利用できることを加盟国に求めるものです。EUDIWにより、利用者は本人に紐づく属性や証明書等を、利用者の判断に基づいて必要なデータに限定し、認証を求める相手に開示・提供することができるようになります。
EUDIWの構想は取り組み途中でありますが、EU加盟国は規則発行後12ヶ月以内にEUDIWを発行することが規定されています。EU域内で非常に強制力が高いプロジェクトであり、EU域内の各サービスはEUDIWの仕様に従って開発・改修されることが想定されます。そのため、日本国内におけるデジタルアイデンティティウォレットの開発についても、EU域内での展開を考慮する場合は相互運用性の観点でEUDIWの仕様に合わせる必要があると考えられ、動向を注視すべきプロジェクトであると言えます。
本稿執筆時点(2023年4月末)のEUDIWの最新状況としては、2023年2月に技術的なアーキテクチャと参照フレームワーク、共通規格、技術仕様などをまとめたThe European Digital Identity Architecture and Reference Framework（ARF）の初版が公開されました[1]。今後の予定としては、このARFを基とした大規模パイロットが予定されており、大規模パイロットの結果をARFにフィードバックすることが予定されています。
②Verified.Me
カナダでは、SecureKey Technologies社が、カナダの主要金融機関7社(BMO, CIBC, Desjardins, National Bank of Canada, RBC, Scotiabank and TD)のコンソーシアムと共に、Verified.Meというサービスを2019年5月から提供しています。本サービスは、ユーザがサービスにアクセスするために、信頼できる情報源（金融機関、政府など）から、ユーザー情報を共有できるようにすることで、アイデンティティ検証プロセスの簡素化を実現できるものとして位置づけられています。
本サービスは、コンソーシアムが運営する許可型の分散型台帳をベースにします。また、他のネットワークとの相互運用を可能にするために、DID、VCのモデルとしてW3Cの分散型アイデンティティ標準（W3C DIDs and Verifiable Credentials）[2]に準拠しています。
③Trusted Web
日本国内の事例としてTrusted Webを紹介します。2022年8月に発行されたTrusted Webホワイトペーパーver2.0[3]に記載されているとおり、2020年6月の「デジタル市場競争に係る中期展望レポート」の提言を受け、2020年10月に「Trusted Web推進協議会」が発足しました。
Trusted Webでは、デジタル社会が直面している課題として、様々な社会活動において求められる責任関係やそれによってもたらされる安心を体現する仕組みが不十分な状況であり、ユーザーが信頼の多くをプラットフォーム事業者などに依拠する中で、以下のような様々な課題があると考えています。
- フェイクニュースや虚偽の機器制御データなど、流れるデータへの懸念
- 生体情報も含めたデータの集約・統合によるプライバシーリスク
- COVID-19等を契機に議論されているプライバシーと公益のバランス
- サイロ化された産業データの未活用
- 勝者総取り等によるエコシステムのサステナビリティへの懸念
- 社会活動を行う上での社会規範によるガバナンスの機能不全
このような課題を解決するカギとなるのが、"Trust"であり、デジタル社会における様々な社会活動に対応するTrustの仕組みをつくり、多様な主体による新しい価値の創出を実現することをTrusted Webでは目的としています。
本稿執筆時点(2023年4月末)の「Trusted Web推進協議会」の最新状況としては、Trusted Webの実現に向けた構成要素・アーキテクチャの提示などを行ったTrusted Webホワイトペーパーver2.0を2022年8月に発行しており、プロトタイプの実装において、Web上を流れるデータの正当性を確認する技術として、DID、VCが採用されています。今後の予定としては、ユースケース実証事業を予定しており、デジタルアイデンティティウォレットに関するPoC開発・調査[4]も2023年度に予定されています。
デジタルアイデンティティウォレットの実装における6つの論点
上記のように、デジタルアイデンティティウォレットに対する仕様検討・実証実験が進められていますが、デジタルアイデンティティウォレットを実際にサービス化するにあたり検討が必要な論点があると考えられます。その論点として、以下の6つを紹介します。
デジタルアイデンティティウォレットの構成
論点を紹介する前に、まずデジタルアイデンティティウォレットの一般的な構成を説明します。
デジタルアイデンティティウォレットを利用するトラストフレームワークの主な構成要素として以下が存在します。
- 「ユーザー情報提供者（Issuer）」：ユーザーのアイデンティティ情報を発行する事業者等。
- 「サービス提供者（Verifier）」：ユーザーからアイデンティティ情報を提供される事業者等。
- 「ウォレット」：ユーザーの指示に従い、Issuerから発行されたアイデンティティ情報を保持し、Verifierに提供する。ユーザーにユーザーインターフェースを提供する「スマホアプリ」とビジネスロジック機能を持つ「サーバ」に分かれることが想定される。
- 「ユーザー」：ウォレットを利用し、Issuerからアイデンティティ情報を取得し、Verifierに提供する。
- 「検証用データリポジトリ」：ウォレットやVerifierが受け取ったアイデンティティ情報が正当なものかどうかを判断するために必要な情報を格納するデータリポジトリ。
ユーザーがウォレットを利用し、Issuerからアイデンティティ情報を取得してVerifierに提供する主な流れは以下になります。
- ①Issuerがユーザーの指示に従い、アイデンティティ情報をユーザーのウォレットへ発行する。発行するデータに対し、Issuerの秘密鍵を用いてデータに電子署名を付与する。
- ②ウォレットはIssuerが発行したデータを受け取る。検証用データリポジトリにアクセスしてIssuerの公開鍵等を取得し、それを用いてIssuerが発行したデータの正当性を検証する。
- ③ウォレットがユーザーの指示に従い、アイデンティティ情報をVerifierに提供する。提供するデータに対し、ウォレットの秘密鍵を用いてデータに電子署名を付与する。
- ④Verifierはウォレットからデータを受け取る。検証用データリポジトリにアクセスしてIssuer、ウォレットの公開鍵等を取得し、それを用いてIssuer、ウォレットが発行したデータの正当性を検証する。
①論点１ ウォレットタイプの選択
デジタルアイデンティティウォレットのタイプとして、主に以下の２つが存在します。
- 「カストディアルウォレット」：ウォレット提供事業者がウォレットの管理主体となり、ウォレットの秘密鍵を事業者側のサーバで管理する。ユーザー側で管理するものが少ないため、利便性が高いという特徴を持つ。
- 「ノンカストディアルウォレット」：ユーザーがウォレットの管理主体となり、ウォレットの秘密鍵をユーザー側で管理する。ウォレット提供事業者の内部不正や倒産によりウォレットに格納した資産を失うリスクが少ないという特徴を持つ。
端末紛失や機種変更時のウォレットの復旧について、ノンカストディアルウォレットでは、「ニーモニックコード」と呼ばれる復元のための単語・英数字等を用いたバックアップが一般的であり、ユーザー自身で「ニーモニックコード」を管理する必要があります。
「ニーモニックコード」を紛失するとウォレットの復旧が不可となりますが、ユーザーのITリテラシーは様々であり、ITリテラシーの低いユーザーを中心に「ニーモニックコード」を紛失するケースが発生することが想定されます。そのため、ITリテラシーの低いユーザーへのサービス提供を考慮する場合は、ユーザー包摂の観点で「カストディアルウォレット」の方が適合すると考えられます。
②論点２ 利用シーンに応じた固有機能の要否
当然のことながら、デジタルアイデンティティウォレットの利用シーンによって、持つべき機能は異なります。例えば、ストリーミングデータのような大容量データをウォレットで扱うことが想定されるケースでは、ウォレットの端末・通信容量を圧迫しないような仕組みの検討が必要となります。
また、ユーザーの端末がオフラインの状況下でVerifierにアイデンティティ情報を提供したいといったケースも考えられます。オフラインケースの例として、情報連携を行う場所が山間部や地下など電波が悪い場所での利用シーンが想定されます。本稿では、オフラインケースへの対応に必要な機能例として、２つ紹介します。
１つ目は、アイデンティティ情報をユーザー端末に保存する機能です。アイデンティティ情報の保存場所として、「スマホアプリ」と「サーバ」が選択肢となります。アイデンティティ情報保存場所を「サーバ」とする場合、「スマホアプリ」－「サーバ」間は端末オフライン状況下では通信不可になるため、「スマホアプリ」から「サーバ」へデータ連携の指示を出すことができなくなります。そのため、「スマホアプリ」にデータのコピーをダウンロードしておく必要があります。
２つ目は、近接通信機能です。端末がオフラインの場合は当然インターネットにつながらないため、インターネットを経由したアイデンティティ情報の提示は不可となります。そのため、QRコード、Bluetooth LE、NFCといった近接通信でのデータ連携機能を持つ必要があります。
また、Verifier側もオフラインである場合は、Verifierが検証用データリポジトリにアクセスできないため、ウォレットから連携されたデータの検証に必要な情報を取得できず、データ検証ができないという課題が想定されます。そのため、以下のような対応案の検討も必要となります。
- Verifierは、公開鍵等データ検証に利用する情報を検証用データリポジトリから取得してキャッシュしておく。
- オフラインでのデータ連携は、リアルタイムでの検証が不要な情報にとどめる。
③論点３ 責任分界の整理
デジタルアイデンティティウォレットを利用するトラストフレームワークに参加するユーザー・事業者が安心して枠組みに参加できるように、トラストフレームワーク内で問題が発生し、ユーザー、Issuer、Verifier等のステークホルダーに損害が発生した場合、誰がその損害を負担することになるのか規約を設けておく必要があります。損害の例として、以下のようなものが考えられます。
-
Issuerが発行したデータに誤りがあり、そのデータを利用したVerifierが損害を受ける。
-
ユーザーのウォレットが悪意者による攻撃を受け、個人情報が流出する。
EUのPayments Services Directive (決済サービス指令 第2版、PSD2)[5]では、損害発生時にはまず事業者が損害を負担し、ユーザーの過失有無で損害を請求するか判断するとしています。また、ユーザーに過失がない場合には、事業者間で協議の上、損害の負担割合について決めることとしています。ユーザー包摂の観点でもユーザーに責任を押し付けるような責任分界では、フレームワークの拡大を妨げる要因になり得るため、避けるのが望ましいと考えられます。
また国際非営利団体のOpen Identity Exchange（OIX）が公開しているガイドライン[6]では、損害が発生した場合、損害を発生させた当事者がフレームワークのルールに全て従っていたことが証明できれば、その当事者に責任が発生しないことになるとしており、各事業者に対して損害発生時の過失有無の証明のために、履歴や監査証跡の保存に関する考慮が必要となります。
④論点４ プロトコル移行過渡期への対応
現状、DID型プロトコルに対応したサービスはまだ存在せず、徐々に増加してくることが予想されます。しかし、DID型プロトコルへの対応は、要否判断やシステム開発対応の期間を要することから対応時期はサービスごとにバラバラであり、またDID型プロトコルへの対応を必要とせずフェデレーション型プロトコルを採用するサービスも存在し得るため、DID型サービス・フェデレーション型サービスが混在した環境が継続することが予想されます。このような環境下では、プロトコルが異なるサービス間でのデータ連携もユーザーは望むことが予想されるため、プロトコルが異なるサービス間を繋いであげる必要があります。各サービス側で、DID型・フェデレーション型の両プロトコルに対応するには、各サービス側に開発コストや保守・運用コストが両プロトコル分かかってしまうため各サービス側に負担がかかり、デジタルアイデンティティウォレットを利用するトラストフレームワークへの参入障壁になることが懸念されます。そのため、プロトコルを変換してデータ連携する仕組みの提供が必要になります。
⑤論点５ ユーザー包摂への対応
「論点① ウォレットタイプの選択」でも述べた通り、デジタルアイデンティティウォレットは、幅広い層のユーザーを対象とする可能性があります。幅広い層の中には、ITリテラシーが低いユーザーやモバイル端末を持っていないユーザーなども想定されるため、ウォレットの利用に障壁がないようにすることも非常に重要です。このようなユーザー包摂に関する対応例として、以下が挙げられます。
- ITリテラシーが低いユーザーが安心安全にサービスを利用できるようにヘルプデスクを設置する。
- スマートフォン等のモバイル端末を持っていないユーザーでもサービスを利用できるように、PCからも利用できる仕組みとする。
- ウォレット利用者の身元確認方法として、マイナンバーカード等に限定せず複数の方法を用意することで、特定情報の保持を前提としない仕組みとする。
デジタルアイデンティティウォレットの対象ユーザー・ユースケースを想定した上で、ユーザー包摂の観点でも仕組みを検討する必要があります。
⑥論点６ ユーザーのプライバシー保護
昨今のEUにおけるGDPR（General Data Protection Regulation：一般データ保護規則）制定や、日本における個人情報保護法の改正に代表されるように、ユーザーのプライバシー保護については年々重要度が増しています。デジタルアイデンティティウォレットのサービスにおいてもプライバシー保護は重要な観点であり、論点を２つ紹介します。
１つ目は、ユーザーの身元確認に関するプライバシー保護です。デジタルアイデンティティウォレットで取り扱うサービスによっては、ユーザーの身元確認が求められるケースがあります。例えば、ウォレットで金融サービスを扱う場合、マネー・ローンダリング及びテロ資金供与に利用されることを防ぐための考慮が必要となります。しかし、消費者の過半数が金銭的利益やポイントの有無に関わらず、個人情報の提供に慎重の姿勢を見せているというアンケート結果[7]もあり、消費者に対して過度に身元確認を求めることは、不信感を招くなどユーザー体験の低下に繋がります。
そのため、ウォレットの初期設定時からあらゆる情報の提示を求めるのではなく、身元確認が必要なサービスの利用開始のタイミングで初めてユーザーに身元確認を求めるといった仕組みが期待されます。求められる情報とタイミングに納得感があれば、ユーザーは安心して情報を提供することができると考えられます。
２つ目は、名寄せに関するプライバシー保護です。ウォレットからVerifierにアイデンティティ情報を連携する際に、Verifier側で受け取ったデータの正当性検証の観点の１つとして、本当にウォレットの利用者に向けて発行されたデータか検証する必要があります[8]。
この観点を検証しない場合の具体的な懸念として、窃取されたアイデンティティ情報を用いた”なりすまし” が可能となります。
これを防ぐためには、Issuerがアイデンティティ情報を発行する段階から、発行するVCとユーザーを紐づける形で、VC発行を行う必要があります。しかし、VCとユーザーを紐づけることにより、同情報を用いた不当な名寄せが懸念されます。具体的には、ウォレットが同じDIDを用いて複数のVerifierにVCを提供する場合、Verifier が結託し使用されたDIDからユーザーを紐づけて名寄せすることが可能となります。
これに対する対策の１つとして、VCを提供するVerifier ごとにウォレットのDIDを切り替えるという方法がありますが、あるDID向けに発行されたVCはそのDIDに紐づけられているため別のDIDからはVerifier に提供できず、別のDIDから提供する場合はVCの再発行が必要になるという「DID切替における課題」があります。
この課題への対策に期待できるものとして、ゼロ知識証明を活用したユーザー識別サービス「Polygon ID」[9]でも利用されている「Iden3」[10]を紹介します。
Iden3では、「Identity Profiles」という機能に言及しており、この機能によりユーザーはVerifier との通信において自身の識別子を隠すことができ、代わりにIdentity ProfileによってVerifier から識別されます。Identity Profileは、ユーザーの識別子とランダムな値とのハッシュから生成され、Verifier によってIdentity Profileを変えることも、１回限りのIdentity Profileを作成することもでき、Verifier による名寄せを防ぐことができます。
また、上記の「DID切替における課題」では、あるDID向けに発行されたVCはそのDIDに紐づけられているため別のDIDからはVerifier に提供できない点に言及しましたが、「Identity Profiles」では、あるIdentity Profileに発行されたVCについて、VCを保持することの証明を別のIdentity Profile からVerifier に提供することが可能です。まだ「Iden3」は開発中の仕様であり、今後もデジタルアイデンティティウォレットへの有益な情報が期待されます。
おわりに
本稿では、デジタルアイデンティティウォレットの仕様検討・実証実験の先行事例と実際にサービス化するにあたり検討が必要な論点を紹介しました。EUDIWの強制力もあり、デジタルアイデンティティウォレットはEU圏を中心に確実に広がっていくことが予想され、日本国内でもEUDIWの動向は注視されています。まだサービス化しているものが少ないことから、今後様々な課題が出てくることが予想されますが、デジタルアイデンティティウォレットの登場がユーザー・事業者双方にとってより良い未来へ向かう一助になると感じています。
[1] The European Digital Identity Architecture and Reference Framework（ARF）
https://digital-strategy.ec.europa.eu/en/library/european-digital-identity-wallet-architecture-and-reference-framework
[2] 金融庁：ブロックチェーン技術等を用いたデジタルアイデンティティの活用に関する研究報告書
https://www.fsa.go.jp/policy/bgin/ResearchPaper_NRI_ja.pdf
[3] Trusted Webホワイトペーパーver2.0
https://www.kantei.go.jp/jp/singi/digitalmarket/trusted_web/pdf/trustedweb.pdf
[4] 「令和４年度補正 Trusted Web の実現に向けたユースケース実証事業」公募実施のお知らせ
https://www.toppan.co.jp/biz/social/trusted_web2023_koubo.html
[5]PSD2
https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32015L2366&from=EN
[6] OIX Guide to Trust Frameworks for Smart Digital Identity v1.2
https://openidentityexchange.org/networks/478/item.html?id=556
[7] METI プライバシーガバナンスに関するアンケート結果
https://www.meti.go.jp/press/2021/10/20211018002/20211018002.html
[8] 金融庁：ブロックチェーン技術等を用いたデジタルアイデンティティの活用に関する研究報告書
https://www.fsa.go.jp/policy/bgin/ResearchPaper_NRI_ja.pdf
[9] Polygon ID
https://polygon.technology/polygon-id
[10] Iden3
https://docs.iden3.io/protocol/spec/
