本文へ移動

属性証明の課題整理に関する有識者会議 技術ワーキンググループ（第1回）

最終更新日:

概要

  • 日時：令和7年（2025年）12月3日（水）16時00分から18時00分
  • 場所：オンライン（Microsoft Teams）
    • ※ライブ配信は終了しました
  • 議事次第：
    1. 開会
    2. 会議の進め方について
    3. 座長の互選
    4. 議事：「論点2 技術面・運用面の対策」に関する協議
    5. 閉会・諸連絡

資料

議事録

事務局（北井上）： それでは、定刻になりましたので、ただいまより「属性証明の課題整理に関する有識者会議技術ワーキンググループ」第1回を開始いたします。
皆様、本日はお忙しいところ、お時間をいただきましてありがとうございます。私は、事務局を務めますデジタル庁の北井上です。よろしくお願いいたします。
早速ではございますが、本会議の開催に当たり、事務局を代表してデジタル庁デジタル社会共通機能グループ長の楠より一言ご挨拶申し上げます。

事務局（楠） 開会に当たりまして、事務局を代表して一言ご挨拶をさせていただきます。デジタル庁デジタル社会共通機能グループの楠です。よろしくお願いします。

行政手続のデジタル完結やデータ利活用のために必要となるデジタルにおける属性証明の実現を目的とした議論をする場として、属性証明の課題整理に関する有識者会議を今年度新たに立ち上げまして、本年10月にはこの本体会議の第1回を開催したところでございます。そこの中でVCやDIWをはじめとした先進的な技術に関して、推奨される具体の技術要件を示していくために専門的な知見に基づいた議論が必要となるだろうと考えられたので、本体会議の下に技術ワーキングを設置することとなりました。

本ワーキンググループにおきましては、本体会議で整理をした、なりすましや名寄せ等のVC・DIW活用において特に対応が必要なリスクを対象として、どのような技術面・運用面の対策を講ずるべきか、というところについて、ご議論いただければと思います。この議論の結果はVC・DIWによる属性証明の活用に向けたガイドラインとして取りまとめることを想定しておりまして、今年度はこの骨子を示すことができればということを目指しております。

これらの技術の早期の社会実装を適切に進めるために、委員の皆様からはぜひ忌憚のないご意見をいただいて活発にご議論いただければと思います。よろしくお願いします。

事務局（北井上）： 続きまして、本会議の進め方について説明いたします。
資料1の設置要綱を御覧ください。行政手続等のデジタル完結や自動化等に必要な属性証明の実現をしたい、このような我々の大目的に向けまして、VC・DIWの利活用を進めていきたいと考えております。一方、新しい技術であるがゆえに想定されるリスクですとか、リスクに対する適切な技術面・運用面の対策といった点が整理されていない状況です。このため、本会議ではその技術的・運用的対策について専門的な見地からご議論いただきたいと考えております。委員は、御覧の11名というところになります。お一人お一人の御紹介は時間の都合上割愛をいたします。
次のページを御覧ください。座長は委員の互選により決定、事務局はデジタル庁となります。また、要すればゲストスピーカー及びオブザーバーを求めることが可能です。
最後に、本会議は原則公開とし、資料や議事録なども公開いたします。
説明は以上となります。本会議の進め方について御質問、ご意見などがございましたら挙手を、オンライン参加の委員におかれましてはTeams機能の挙手ボタンを押してください。

＜質問・意見なし＞

特段なさそうですので、次の議題に進めます。
それでは、設置要綱に従いまして、委員の互選により本会議の座長を決定させていただきたいと思います。事務局としては昨年度の「Verifiable Credential (VC/VDC) の活用におけるガバナンスに関する有識者会議」に引き続き、中村素典先生を御推薦したいと考えておりますが、いかがでしょうか。御異議がある方は挙手を、オンライン参加の委員はTeams機能の挙手ボタンを押してください。

＜異議なし＞

それでは、御異議がございませんでしたので、本会議の座長を中村素典先生にお願いしたいと思います。中村座長、一言ご挨拶をいただけますでしょうか。

中村座長： 京都大学の中村でございます。

このたびは座長ということで、有識者は私より詳しい方々にお集まりいただいているかと思います。大学という立場でも、このVCというのは身分証をどうやってオンライン化していくかというところで非常にホットな話題ですので、皆様のご議論とともに一緒に考えていけると良いかなと思っておりますので、よろしくお願いいたします。

事務局（北井上）： 中村座長、ありがとうございます。

それでは、次の議題に移りますが、議論に入る前に事務局から会議の設置目的や今年度のゴール観、議論のスコープ、議論対象とするリスクとその対策等についての資料説明をさせていただきます。資料説明の後、議論に関する進行を中村座長にお願いできればと思っております。
それでは、事務局から資料2に基づいてそれぞれ説明をさせていただきます。

事務局（中川）： 参事官を仰せつかっております中川と申します。改めましてよろしくお願い申し上げます。

私のほうは3分の1ぐらい説明させていただきました後、さらに詳しい説明は同僚からさせていただきたいと思います。最初のほうの背景・課題及び派生証明書などで出てくるところも含めて、発行権者の留意点というところも、改めてこちらからもこのように考えてございますというのをご説明申し上げたほうが、今後の議論、またさらに技術的な部分も含めて担保できるのかどうかというところを含めて考えていただくときの参考にしていただけると思いましたので、まずそこから説明をさせていただければと思います。

このワーキングの親会に相当します本体の有識者会議の資料からも再掲していますので、御覧になられた方もいらっしゃるかもしれませんが、重複を恐れずご説明さしあげたいと思います。よろしくお願いします。

まず、背景・課題でございますけれども、マイナンバーカードはご案内のとおり、もう普及をしてきておりまして、1億枚までもう少しみたいな、もう達成したかもしれないのですけれども、ちょうど1億枚みたいな話がありましたが、そういう状況でございます。他方で、まだ手続や申請の点で身元証明書のところは実現したけれども、資格や属性の証明書というところ、例えばまだ住民票の写しみたいなものが残っていますよね、ということであるとか、課税証明を出すみたいなものもありますよねとか、あと民間企業の中でも例えば学校などで在学証明、成績証明、もしくは在籍証明、企業にて転職するときには、民間企業や半分民間みたいなところもそういった証明書を出されるニーズというのはあると思います。

その証明書ですけれども、デジタル化という意味ではPDFで提供される例もあると思います。他方で、偽造などはやりやすくなってしまうという面もあるのかなと。それを防ぐ技術もあるとは思うのですけれども、さらに、なりすましの点で、今、紙で提供されている住民票もそうではないかというところもあるかもしれませんが、そのようなリスクなども高いと思っています。また、PDFはどうしても機械可読性という意味では劣る部分もあると思いまして、自動的なデータ処理も困難ではないかと考えているところでございます。

そういう意味では、この次なる本丸といいましょうか、便利になったなと感じていただけるためには資格証明、属性証明というのが重要と思っています。その意味で、次のページの趣旨・目的というところになりますけれども、このVC・DIWというものを使って、いかに便利にしていくのかというところを次に取り組みたいと考えてございまして、さらに言うと、これを普及させなくてはいけないということを考えると、これは安価で簡便で迅速に実施できるということが良いと思ってございます。セキュリティを求めるあまり使いにくいと、ユースケースにもよると思いますのでこの辺りは一元的に全部これとはいかない部分もあると思いますが、この辺りでバランスをどうやって取っていくのか、というのは普及という側面を考えても大事だと思います。可用性を確保するという意味でも重要だと思います。

その可用性というか、使いやすさという点にも関係すると思いますが、制度としては法律、法令、省令、政令などがあったりしますけれども、こういうものが本当に必要かどうかというのはもう一度考えないといけないと思います。ここは不必要にとは言いませんけれども、必要だと思って最初からきちっとしたものをつくってしまうと、そこはまた使いにくいということにもなってくると思いますので、この辺りのバランスは考えないといけないと思っています。

他方で、何かしら示していただきたいという声もあるとは思っていますが、必要最低限、必要十分というのはどういうものかというのを考えないといけない、そういうところを問いながら、常に目的を問いながら検討を進めたいと考えているところでございます。

次のページは飛ばさせていただきますけれども、VCやDIWとは改めてこういうものですという紹介となります。

6ページが今、画面にも出ているかと思いますけれども、今回、一番左のマイナンバーカードで示されるような身元証明書というところは比較的カバーできつつあるというところをお伝えしたかと思いますけれども、「要対応」としている右側がまさに資格証明書や属性証明書で、△、×となってございます。こういうところを電子化に向かって取り組んでいきたいと考えてございます。これも御参考に見ていただければと思います。

8ページに飛んでいただきますが、証明書の電子化というところではあるのですけれども、住民票の写しでも例になってくると思いますが、これが適切かどうかというのはまた別として、あくまで分かりやすさのために言いますけれども、住民票というのはそのままコンビニで出したらこれは確かに市町村が証明した内容のものとして住民票の写しが出てくるのですけれども、住民票の写しの写しを提出すれば良いみたいなものも、民間で結構なされている形になると思います。本当にそれって証明力があるのか、というのはあるのかなとは思われます。これは正当な機関から証明書というのが発行されて、それが同等の原本性や法的証拠力というのを確保するということも必要なユースケースというのはあるはずで、これをしっかり担保するということが、行政機関が発行する公的証明書としては重要になると思われます。ここについて留意が必要ということを書かせていただいています。

ページの左側でいきますと、従来の紙などの公的証明書の発行権者として書かれていますけれども、これは、いわゆる住民票であれば各市町村から発行されているということになりますけれども、これを例えばコピーしたら私が発行したということになるのですね。私がコンビニでコピーしたら、私が発行したということになる。それは違うでしょうということになると思っています。

ページ右側から言うと、そういう意味では正当な機関からVCが発行される、例えば業務委託などで正当な機関がされるということもあるでしょうということを書いていますが、仮に法令上の権限を有しない方がVCを発行した場合は、これも似たような形になってコピーになってしまうのではないかというところは留意しておかなければいけないと思います。

次の9ページが、これも派生証明書ということにはなってきますけれども、コピーに近いものですが、さらに言うと、ほかの情報も加味して、今、現実世界にあるケースではないのですけれども、例えば住民票に課税証明書みたいなものも含めた証明書みたいなものを作ろうと思ったらできてしまうという世界だと思うのですが、それぞれについて本当にちゃんとそれぞれの市町村等から認証を得て発行しているものというのは、本当に証明書と言えるのかどうか、というところがあると思います。まず住民票のデータがあって、例えば私が住んでいて、子供たちがこれだけいる、という住民票があって、仮に誰かがそれに対して課税証明に相当するような収入の証明書も含めて書きましたと。これで世帯全体の収入になりますみたいなものを仮に作ったとしますと、これは派生証明書となりますけれども、それは本当にそのときにぺたぺたとつけたものというのは違うでしょうと。ちゃんとそれぞれがそれぞれの情報の正当な発行元に対して照会ができて、それが正しいというものになっているとか、本当に発行したものがその人のものであるというところが確認できないと証明にはならないのではないか、というのをお伝えしています。

これは文章になっていますが、派生証明書は証明書の原本と同等の法的証拠力というのを有しない者が、もし仮に発行したら、それは当然有しませんよねということだと思います。第三者が、ある時点の証明書の原本を確認したことというのは、まさにそのときにそれを見てそのコピーを取った人というのがまさにそのコピーを作ったということは言えるけれども、それ以上のものではなく、それが正しい情報かどうかはやはりちゃんと元の発行した人に確認しないといけないということだと思っています。

説明が分かりにくくなったかもしれませんけれども、基本的に証明書というのは発行する者が責任を持つものでなければいけないということです。誰か別の人がそれをコピーしたり、何かしら改変して作ったものというのは、さすがに証明書とは言えないでしょうと。紙の上でもそうだし、電子でもそうですということをお伝えしたかったというところにはなります。
最初にそれをお伝えさせていただいた上で、次のページ以降は同僚にお願いしたいと思います。よろしくお願いします

事務局（澤田）： デジタル庁の澤田と申します。

中川から申し上げたところは本日の議論の全体の中の一部ではあるのですけれども、特に認識を合わせておきたいポイントだったため、ハイライトしてご説明をさせていただきました。

次に、これまでの議論の振り返りや動向の紹介をさせていただきます。まず、昨年度の会議の簡単な振り返りからですが、昨年度の「DIWアドバイザリーボード」では、DIWには各ステークホルダーに様々なメリットがあることを整理いたしました。なお、VCとDIWは一体ですので、この紙面上「DIW」とありますが、VC・DIWと読み替えていただいても大丈夫です。

また、DIWの活用が期待できる3つのユースケースの類型も整理いたしました。そして、それらVCやDIWを活用する際に懸念されるリスクについても洗い出しました。そして、そのリスクの対策として、Verifier、あるいはWallet Providerに対して必要なガバナンスが何かについてのご意見を頂戴いたしました。また、昨年度のもう1つの会議体である「Verifiable Credential (VC/VDC) の活用におけるガバナンスに関する有識者会議」では、特にIssuerが担う責任などを議論いたしました。

これらの議論を踏まえまして、「DIWアドバイザリーボード」の報告書では、各種のリスクに対して既存のガバナンスでカバーできないVCやDIWに固有に必要な対策について、青枠のとおり技術面、運用面、制度面のガバナンスがある、このようなフレームワークを整理いたしました。今年度はこの議論の継続と捉えていただけたらと思います。したがって、このVC・DIWのリスクの全体像は昨年の議論に則るものとさせていただければと思います。以上が昨年度の簡単な議論の振り返りとなります。

続いて、VC活用への期待の高まりについてご説明します。こちらのページでは、証明書の電子化・高度化の展望のイメージを図示しております。この中で我々行政がまず注力すべきは、濃い青のところの住民票のような、官発行であったり、あるいは就労証明書のような官が検証する証明書だと考えております。これに対して、ガイドラインの策定をはじめとしたルールメイクなどを行いながら推進していくところであります。加えて下にある民同士のユースケースの促進であったり、将来的には右に書いてあるようなプッシュ型の行政サービスなどの高度な証明書活用を見据えています。このような展望のイメージを議論の前提として共有していきたいと思います。

続いて、VCやDIWに関する直近の動向として、EUや米国をはじめとするトピック、また、関連する技術の標準化について、18ページに紹介しております。時間の都合で説明は割愛しますが、OID4VPやOID4VCIの仕様が最終承認されたり、SD-JWT仕様がRFCとして公開されるなど、社会実装に向けたパーツが揃いつつある段階であると認識しています。

続いて、第1回本体会議の振り返りです。まず、本体会議の協議論点が何だったかと申しますと、昨年度の会議で整理をしたVC・DIWの固有のリスクに対してどのような規律が必要か、つまり、どのように対策を促すかについて議論をいたしました。その結果、VC・DIW活用のガイドライン策定に着手をするという方針についておおむね合意が得られました。また、ガイドラインの対象範囲や想定読者、強制力をどうするかが重要であるというご意見であったり、ユースケースのイメージを具体化して、リスクの低いユースケースも含めて議論をすべきではないかといったご意見を頂戴しました。これらを踏まえて今回の技術ワーキングの論点を設定しています。その他、法的措置や認定制度の必要性や普及活動の期待に対する様々なご意見も頂戴いたしました。

次に、本日の論点の説明に入ります。まず、本日開催のこちらの技術ワーキングでは、技術面・運用面の対策について議論します。これは、先ほど申し上げた本体会議が対策の規律方法を議論したのに対し、技術ワーキングでは対策の実施内容を議論いただきたいということであります。

議論に入る前に、この会議を通じて策定予定であるガイドラインのスコープの想定をお話しします。まず、こちらのページの上部の記載のとおり、必ずしも全てのユースケースで厳密な対策が求められるわけではないところ、対策要件の水準を2段階に分けております。具体的には、全てのユースケースで最低限実施すべき対策手段と、比較的高リスクのユースケースに対して推奨する対策試案の2段階に分けて考えております。これによって、過剰な対策にならないよう、また、推奨する対策を各機関が選択できるようなドキュメントにしていきたいと考えております。

また、右の欄にありますが、ガイドラインの適用対象は基本的には行政機関を想定しておりますが、民間事業者でも参考にできる想定でおります。また、ガイドラインの適用方法や運用方法については、本技術ワーキングではなく本体会議で協議をする予定です。

続いて、今年度の会議のゴールについてです。ゴールイメージとしましては、公的なユースケースへの脅威リスクに対して講じるべき対策を示した、ガイドラインの骨子を取りまとめることを想定しています。ここでいうガイドラインとは、例えば政府・社会のデジタル化のために策定しているデジタル社会標準推進ガイドラインに位置づけることなどを想定しております。重ねて、本技術ワーキングでは、ガイドラインに記載すべき技術面・運用面の対策の在り方について議論いただきたいということであります。

また、右の欄のとおり、ガイドラインに期待する効果としては、仕様検討の円滑化、相互運用性の確保、あるいはリスク対策の実施を確保することによる利用者の安心などとなります。ただ、特にこの骨子の議論の段階では、行政機関でのVCの導入の可否の判断や、あるいはこういった方向性を民間企業に周知するような意味合いのドキュメントになると考えております。

続いて、本体会議の委員からのコメントも受けまして、今回、議論の題材とするユースケースを2つ用意しましたので紹介します。ただし、ページの赤字のとおり、あくまでリスク対策の議論用の架空のユースケースでありまして、目指すガイドラインは特定のユースケースに特化せず、公的ユースケースに共通のドキュメントであるということを御留意ください。

1つ目のユースケースが、官発行の証明書として住民票の写しのVCです。これは紙の住民票と同様に、提示先の制限は設けず、世帯情報や居住者の証明として使われることを想定しています。基本的には自治体から、住民票の写しは本人のWalletに発行し、そこからオンライン、もしくは対面で民間の企業などに対して、選択的属性開示をするような用法を想定いただければと思います。

2つ目が、官が受け取るユースケースとして、就労証明書のVCです。これは紙の運用同様に保育所の入所の審査などに使われるようなものを想定しています。こちらは本人の勤務先の企業から就労証明書のVCを本人に発行しまして、オンライン、もしくは対面で自治体などに提示をする、もしくは電子申請システム上でVCをAPI連携するような用法を想定いただければと思います。

本日はこの2つの具体ユースケースを想定した議論の時間も後ほど設けます。

続いて、議論対象である脅威とリスクの説明に入ります。まず全体像についてですが、こちらのページは昨年度議論したリスクの整理を踏まえまして、VCのライフサイクルに沿って脅威を整理し直したものです。例えばなりすましにより、第三者にVCを発行してしまう、スマートフォンからVCのデータが漏えいしてしまう、あるいは偽のIssuerによるVCの提示を受け付けてしまうなど、様々な脅威が考えられるかと思います。

次に、これらの脅威についてリスクの類型をまとめて整理したのが30ページになっております。上から①正規VCの盗用や再利用による詐称・なりすまし、②偽造VCや派生VCの受け入れ被害、③VCに起因するプライバシーの侵害、④VCの可用性や利便性の低下、この4つがあります。各リスクの詳細については、この後ご説明いたします。

なお、補足ですが、今年度の議論で必ずしも全てのVC・DIWのリスクを網羅できているわけではありません。ウェブサービス一般に発生するリスクや、対策内容にあまり論点がないようなものは議論の対象外としています。また、例えば秘密鍵の漏えいなど、VCに限らず署名付PDFなどほかの手段でも共通の論点もあるかと思いますが、これらの脅威の対策は議論が十分にされていない部分があると思いますので、本会議で取り上げているものもございます。続けて、先ほどの4つのリスクの具体の対策の案について紹介をいたします。

事務局（石井）： それでは、デジタル庁の石井から以降のページをご説明させていただきます。

まずは公的ユースケースで求められる対策の考え方についてご説明をいたします。35ページは本体会議の再掲ではございますが、公的ユースケースで求められる技術面・運用面の全体像について示しております。36ページから、リスクの類型①から④のそれぞれで講じるべき対策の詳細をご説明させていただきます。

1つ目のリスクは、VCの盗用・再利用によるリスクについてです。これはVCのライフサイクルの様々な場面で、攻撃によってVCが盗まれ漏えいするなどして、第三者がVCを悪用するリスク全般のことを指しております。VCの盗用・再利用に対する主な対策については、4つの観点から対策を示しております。まず入り口は、「VC発行時の本人確認」です。VC発行時にマイナンバーカードによる身元確認、あるいはID・パスワードによる当人認証などを行い、発行段階で第三者のなりすましを防ぐ仕組みが考えられます。次に技術的な要となるのが、「VCとHolderの紐づけ」、いわゆるHolder Bindingですが、属性情報や暗号鍵などを使ってVCとHolderを紐づけることで、窃取したVCを利用しようとしても検知できる仕組みが考えられます。さらにその鍵自体を守るのが「暗号鍵の安全な管理」で、スマートフォンのSecure Elementや外部HSMなどの安全な領域に鍵を格納し、Walletからの不正な取り出しを防ぐ仕組みが考えられます。鍵管理の方式は複数の実現パターンが考えられるため、2ページ後で詳細を示しております。最後に、リスク低減策として「有効性や失効状態等の管理」があり、有効期限の設定や提示回数の制限、また、Status Providerによる失効管理などにより、万が一VCが盗まれた場合でも悪用リスクを最小限に抑える対策が考えられます。

37ページでは、VCの盗用・再利用のリスクに応じた対策レベルの考え方を事務局案として示しております。まず、どのようなユースケースであっても最低限実施すべき対策として、発行請求者に対する基本的な「本人確認」と、氏名や生年月日などの属性情報による「VCとHolderの紐づけ」が必要であると考えております。その上で、重要な手続に利用可能なVCや、盗用・再利用時の影響が大きい高リスクのユースケース、例えば住民票の写しや本人確認書類に活用される顔写真付公的証明書、重要な手続に利用され得るものなどは厳格な対策を追加的に講じる必要があると考えております。具体的には、「VC発行時の厳格な本人確認」に加えまして、暗号鍵や生体情報によるHolder Bindingを実施し、さらには「暗号鍵の安全な管理」としてSecure ElementやHSMといった高度なセキュリティ領域を活用するなどの対策が考えられます。

このように、ユースケースにおけるリスクの大きさに応じて対策のレベルを段階的に設定することで、全てのユースケースで過剰対策にならないようにできると考えております。また、ここで示す対策の内容、そして最低限の対策と追加的な対策の分け方の是非について、この後、ご議論いただきたいと考えております。

38ページでは、参考までに鍵管理の方式と制約について示しております。時間の都合上、詳細な説明は割愛しますが、Walletの提供形態と鍵の格納領域の組合せについて、EU DIWのARFを参考に大きく4パターン示しており、各パターンの考慮事項を示しているので、お手元でご確認ください。

2つ目のリスクは、偽造VCや派生VCに関するリスクについてです。偽造VCのリスクとは、架空の企業や大学によりVCを発行し、給付金の不正受給や経歴詐称に利用されてしまうリスクを指しており、派生VCのリスクとは、冒頭の派生証明書のページの繰り返しにはなりますが、そもそも正当な証明書とはみなされず、Verifierが受入れできないリスクやそれにより社会的混乱を招くリスクを指しております。偽造VC、派生VCどちらもデジタル署名だけでは詐称やなりすましを防げないため、追加的な対策が必要になると考えております。

偽造VCや派生VCに対する主な対策については、2つの観点から対策を示しております。まず対策として重要になるのが、「VCの署名の本人性の保証」です。VCに付された発行者の署名を検証するための公開鍵と実際の発行者を紐づけることで、その署名が期待する発行者によって付されたものであり、偽のIssuerや原本と異なる発行元でないことを確認できる仕組みが考えられます。ただし、本会議ではDecentralized Identityなどで用いられる場合もある分散リポジトリではなく、PKIやX.509証明書などを用いた従来のトラストアンカーをここでは前提としております。　もう1つの対策が、「VCの発行者の適格性の保証」です。単に署名が正しいことに加えまして、そのVCの発行者が特定の条件を満たす適格な組織であることを確認できる仕組みが考えられます。例えば発行者の属性情報をリスト化して公開する、あるいは適格性を保証するIssuerのリストを整備することで、Verifierが自ら発行者の適格性を判断することが可能となります。こちらは参考までに諸外国の導入事例を2ページ後に示しております。

42ページでは、偽造VCや派生VCに関するリスクに応じた対策レベルの考え方を事務局案として示しております。まず、どのようなユースケースであっても最低限実施すべき案として、「VCの署名の本人性の保証」は必要であると考えております。その上で、Issuerが多数存在する場合や頻繁に変化する場合などでは、Verifier側でIssuerの適格性を個別判断することは難しいため、VC発行者の属性リストや適格性リストを公開することで発行者の適格性をVerifierが判断できるよう、追加的な対策が必要であると考えております。

参考までに、Issuerの適格性検証を実現するための各国の仕組みについて示しております。時間の都合上、詳細な説明は割愛しますが、EU DIWではTrusted List、米国のモバイル運転免許証ではVICALという仕組みを導入しております。

3つ目のリスクは、プライバシーリスクについてです。VCには署名値などの名寄せしやすい情報が含まれるところ、複数のVerifierが提示を受けたVCの情報を意図的に共有しあうと、選択的開示で守られたプライバシーが逆に侵害されてしまうリスクなどがあります。

プライバシー関連脅威に対する主な対策については、まず基本となるのが「選択的開示」です。VCに含まれる属性情報の一部のみ開示することで、不必要な情報の露出を避け、属性による名寄せリスクを根本から低減する仕組みが考えられます。しかし、選択的開示ではVCの署名自体が識別子として悪用されるリスクがあるため、その対策として「署名値による名寄せ軽減策」が必要となり、複数VCの一括発行やローテーション機能など、署名値によるトラッキングを防ぐ仕組みが考えられます。さらに、署名値以外にもVCに含まれるメタデータ、例えば発行時刻や各種識別子の名寄せも考えられるため、その対策として「メタデータによる名寄せ軽減策」が重要となり、メタデータの最小化やランダマイズ、識別子の短命化などの仕組みが考えられます。最後に、技術的対策を補完する形で「Verifierの制限による名寄せ軽減策」があり、VCの提示先を特定の信頼できるVerifierに制限することで、そもそも複数のVerifier間で情報が共有されるリスク自体を低減する仕組みが考えられます。なお、このうち多くの対策はVCフォーマットに依存し、IssuerだけでなくWalletやVerifier側での実装も必要となります。

47ページでは、プライバシーリスクに応じた対策レベルの考え方を事務局案として示しております。基本的な考え方として、プライバシーリスクはVCの用途によって大きく異なるため、特定のVerifierにしか提示されない特定用途のVCも含めて最低限実施すべき対策を設けないことが妥当であると考えております。他方、多用途のVCでは選択的開示の必要性は高く、また、提示頻度が高く多数のVerifierに対して提出されるVCでは名寄せリスクが高まるため、追加的な対策が求められます。具体的には、「選択的開示」、「署名値による名寄せ軽減策」、そして「メタデータによる名寄せ軽減策」などの各種対策を講じることが望ましいと考えております。なお、ゼロ知識証明ベースの技術やVerifierの制限による名寄せ軽減策については、技術的成熟度や実装の難易度の観点から、現時点では対策基準の候補外といたします。

参考までに、VCフォーマットとプライバシー関連対策の関係について示しております。時間の都合上、詳細な説明は割愛しますが、「述語証明による提示属性の最小化」や「ゼロ知識証明」が実装できるかは、VCフォーマットによる対応可否が分かれる場合がございます。

最後、4つ目のリスクは、VCの可用性や利便性に関するリスクについてです。これはWallet Provider、Issuerのサービス終了、端末交換などに際してVCに必要な互換性がないと、VCが移行できずに使えなくなるなどのリスクです。VCの可用性や利便性の低下に関する主な対策については4つの観点から対策を示しております。まず基本となるのが、「VCの移行可能性及び端末・Wallet間の技術互換性の確保」であり、デバイスの紛失、あるいはデバイスの交換に備えてVCのバックアップ、復元、再発行機能や別WalletへのVCエクスポート機能を整備するなど、Holderが継続的にVCを利用可能とするための仕組みが考えられます。さらに、時間経過とともに発生する課題として、「仕様変更が及ぼす影響に対する技術的・運用的対策」があり、旧仕様で発行されたVCの有効性保証や新旧仕様のVCを併用する場合の失効状態管理、マルチバージョン対応などの対策が考えられます。また、本会議で策定予定のガイドラインの変更に伴い、現行機能を改修する場合、このような互換性を確保するために適切な影響調査を行う必要があると考えております。

52ページでは、VCの可用性や利便性に関するリスクに応じた対策レベルの考え方を事務局案として示しております。基本的な考え方として、端末紛失・交換は発生頻度が高く、影響も大きいため、前のページで整理した対策は、どのようなユースケースでも最低限実施すべき対策として事務局としては位置づけております。

続いて、論点2に関して議論いただきたいポイントをご説明させていただきます。ガイドライン策定に向けて議論いただきたいポイントは、大きく3点ございます。論点2－1では、ただいま説明した4つのリスクに対する技術的対策の内容と、最低限実施の対策か、あるいは追加の対策かという対策水準の妥当性について、本資料で整理した内容に過不足ないかをご確認いただき、全てのユースケースに適用される最低限実施すべき対策について重点的にご議論いただきたいと考えております。論点2－2では、技術的対策だけでは解決困難なリスクがあるかという点について、技術的対策を補う規律などの手当ての要否をご意見いただき、必要なものは次回本体会議の議題候補として考えております。論点2－3では、以上の一般論としての対策が、具体的な題材である住民票の写しや就労証明書などにおいて、実際に適切に機能するか御検討いただき、これらリスク対策基準についても併せてご議論いただきたいと考えております。

事務局からの資料説明は以上となります。それでは、改めましてこれ以降の議論の進行を中村座長にお願いしたいと思います。よろしくお願いいたします。

中村座長： ご説明ありがとうございました。

事務局にご準備いただきました資料がありますので、それに沿って議論を進めていくということになるわけですけれども、最初にご説明いただきました背景のところのこれまでの経緯からしたときに、いろいろな証明書をデジタル化していかないといけない、DIWやVCという新しい技術があるのでそれを前提とした議論をしていくというところがまず大枠にありますというところで、そこまではよろしいかと思うのですけれども、その上で、今回の資料をまず皆さんに御覧いただいた上で、本日、これからの議論の進め方についてまず何かご意見いただくと良いかなと思います。

既にご案内があったと思いますけれども、この技術ワーキンググループは今年度2回、本日が1回目で、あと1月に2回目を開催するなかでガイドラインというのを作りたいということで、ひとまず今年度末に向けて取りまとめをするというスケジュール感で進むことになっているわけですけれども、この2回で議論が全部まとまって、まとまったガイドラインというのが出来上がるとは皆さん思っておられないのかなと思うところです。ただ、せっかく皆さんにこうやって集まっていただいて議論する場ですので、いろいろ意識合わせをしつつ、オフラインのところでやり取りしながら、よりブラッシュアップできる部分については並行してといいますか、会議の合間に進めていくことができると良いのかなとは思っております。

それで、この資料につきましては、最初にいきなりVC・DIWというキーワードが出てきて、その定義は一体何なのかということについても、全く触れられていないというところで、一体我々としては何を議論したら良いのかというのがまず分からないので、そこの意識合わせを最初にする必要があるのかなと思っています。

資料をざっとご説明いただきまして、飛ばしていただいた部分もありましたけれども、資料全体を見て、何となく事務局として想定しているものはこういうイメージなのかなとは思いつつも、そうはいっても何となく意識が統一されていない色々なキーワードが入ってきていて、あれ、これは思っていたのと違う、みたいなところもあったりするので、そこの確認を最初にしたほうが良いのかなと思います。私も事前に資料を頂いて事務局といろいろ確認などをさせていただきましたけれども、まずVCといってもいろいろなものが想定し得るわけで、特定の規格を指定しない限り、皆さんの想像しているVCというのがまちまちだと思っています。

まず大きく分けて、トラストがどういう形のものを想定していますかというところで、いわゆるPKI的な従来のものと、流行りの分散トラスト的なものというのを考えたときに、当然VCというのは分散トラストというのも想定したアーキテクチャというのもあるわけで、そこはどうなりますかという点につきましては、取りあえずこの会議では分散トラストについては想定をしませんということですので、まずそこは最初の合意になるのかなと思いますけれども、大枠としてその点はその認識で合っているということでよろしいですね。

その上で、従来型のPKIのトラストモデル、PKIに限る必要はないのかもしれませんけれども、分散ではない従来型で、実際に我々の議論しているもののゴールとしては、ガイドラインを作るだけではなくて実際に皆さんに使っていただけるものを実現するために必要なガイドラインとして、早く証明書のデジタル化というのが世の中で進むということを目指そうということですので、そういう意味では、既存のトラストの仕組みといったものが使える部分は使っていったほうが、効率が良いという面はあるかと思いますが、そういう観点においてもいろいろご意見があろうかと思います。

それで、まずはその前提ですけれども、その上で、トラストというのが何らかの形で構築できたとして、VC・DIWというか、IssuerがあってVerifierがあってという関係で、この資料の中でも本人性をどう確認するのかとか、Holderとしての確認とか、IssuerがHolderを確認するみたいな関係もありますし、VerifierとしてHolderを確認するとか、Issuerを確認するとか、いろいろな関係性でトラストというか相手の確実な身元確認的なものが必要になってくるわけです。しかし、どういう関係がそもそも存在するのかというところも、この資料ではまだあまり整理ができていないというところで、そこは実際のユースケースも想像しながら議論を進めていかないといけない。その間でこういう関係について確認が必要だけれども、そのときになりすましなどのようなリスクがあるのかどうかということを、個別に細かく見ていくというのが本来、我々の最終的にやるべき確認作業になるのかなと思っています。そうしたときに、相手をどう確認するかということについて考えると、IDという意味合いでidentifier的なものですけれども、Issuerとしてこれが実際に正しい組織として発行されたものなのかというのは、当然IssuerとしてのIDを確認しないといけないですし、Verifyされるべき、例えば住民票の情報について証明書を発行してもらうというのだったら、誰に対する住民票なのかというのを示すためのIDというのはどうあるべきなのか、そこも公的個人認証では基本4情報しかもらえなくて、マイナンバーなどの個人を識別する情報というのは基本的に公的個人認証のほうからはもらえないことになっていますので、その前提でどのように証明されるべき人を識別するのかというところも多分いろいろな考え方があって、そこもIDという観点ではあまりこの資料の中には触れられていないという面があるということで、そこもどう整理するかというところを最初に皆さんと議論しないといけないのかなと思っている、というのがまず私の感想です。

この意味合いで今日議論を進めるに当たって、最初に確認しておくべきことというのが何かほかにいろいろとご意見があるようでしたら、まずそこについてご発言をいただきたいなと思いますが、どなたかご意見ございますか。 では、﨑村委員。

﨑村委員： 実は私は事前にコメントを送ろうと思って課題点を書き出したら、それだけでA4 10枚以上になってしまって、本来、課題を書いたらそれに対する解決案も一緒に提示しなくてはいけないのですけれども、そうすると、とてもではないけれどもできないし間に合わないので結局送らずじまいになりました。

観点的にインターオペラビリティーの検討が結構欠如している、その辺は技術ワーキンググループでちゃんとケアしてあげないと駄目な点だと思うのですね。ボードルームレベルの話でVCというけれど、例えばヨーロッパでもVCと一言で言いますが、企業をやるときにはvLEIで、AnonCredsでと言わると、うっと思うわけですね。そういったところも含めてどうするのかということをちゃんと考えてあげる。あと、実際には実装に英語ないし日本語の規格書を読んでつくった実装というのはばらつきが出るはずなので、テストスイートみたいなものも整備していく必要があるだろうということが全然ないので、ちょっと気になりました。

あと、プロトコル層です。OpenID4VCIやOpenID4VPについてファイナルが出ましたという話は、ニュースの紹介でしたらあるのですけれども、本来やはり技術ワーキングなので、そのレベルのことをきちんと話していかないと駄目かなと思います。中間者攻撃とか、あるいは何をもって正規VCというかというのはあるのですけれども、そういうものの再利用の防止というのはこのプロトコルに依存するところが非常に大きい気がするのですね。なので、そういう観点も入れなければいけない。

今の話の関連で言うと、言葉を大切に使ってほしいなというのがある。技術的な話になるので親会では言わなかったですけれども、中村素典先生がおっしゃいましたけれども、VC・DIWの定義は何なのとか、分散トラストとは何か、とか、それから、親会でもこれは指摘がありましたけれども、「適格」という言葉は、「認証」で我々は懲りていますね、AuthenticationとCertificationで。またやるのですかという感じなのでちゃんと別の語を当ててほしい。それから派生VC、派生証明書も例えばNIST FIPS 201の派生証明書との差とか、ちゃんと言わないと駄目だなと思うので、きちんと定義してほしいなと思いました。

脅威、リスク、スコープとプライバシーの扱いに対するもので、重大なプライバシーやセキュリティ脅威で、今年度対象外としているものがあります。必要以上の情報の要求だとか、Wallet ProviderによるWallet内データの不正閲覧、利用履歴収集などは、DIW特有かつ重大なプライバシーリスクだと思うのですね。これをウェブサービス全般に共通だとか、対策の促進への影響が小さいといって、外してしまうのはちょっと早計かなと思います。偽Verifierにより、がさーっと持っていかれるというのはWalletに特有の問題だと思うのです。

あと、プライバシーが名寄せ中心に、非常に狭く捉えられているという問題があって、
その辺ですね。細かく言うと時間がかかってしまうので言わないですけれども、プライバシーは例えばOECDでも8原則、ISOだったら11原則ありますから、それをバランス良く見てやるというのはどうしても必要なので、そういう観点でちゃんとフレームワークに則って見ていく。

それから、Verifier制限を取らないという前提があるような印象を持ったのですけれども、これもどうなのかなと。一般的にはそれで良いし、ユーザーがオーバーライドできる必要はあると思うのですけれども、殊に機微なデータに関しては流通範囲を制限するというアプローチもあるのかなと。

あと、ゼロ知識証明が高度なプライバシー技術としてもありますけれども、スケーラビリティーを確保するための技術という側面も大きいですね。これは、あまり使われていないうちは良いが、Batch Credential Issuanceというのは、ものすごくVCが使われるようになると、多分Issuerは過負荷になるのですね。この辺はちゃんと技術ワーキングが検討しないと駄目かなと思います。

あと、派生証明書というものがちゃんと定義されていないということでもあるのですけれども、これの排除の傾向が非常に強いと思っていて、それによる課題というのがあるかなと。あまりそれを打ち出すと、例えばFIPS 201-3だとか、NIST SP 800-157を例に出すまでもなく、Derived Credentials全般に対して影響が及んでしまう可能性があるので、それはよろしくないかなと。

アイデンティティの世界では、信頼できる第三者機関が紙の原本を確認した上でデジタル証明書を発行するNotarization modelというのも一般的だし重要ですね。eIDAS 1.0などでは公的なアイデンティティドキュメント、紙ですけれども、これを窓口で確認した事実とその方式等を、日時などのメタデータをつけて銀行がQTSPにIDトークンとして発行して、それをQTSPが短期適格証明書を作って、ユーザーがこの適格書、今の適格はQualifiedですよ、Qualified CertificateをつくってQualified Signatureをするというモデルが、現在普通に使われているので、完全に排除してしまうのはどうかなと。DXが進まない中小企業の証明書などの、過去に発行されて現在は再発行が難しい証明書をVC化するというときにどうするのだというと、やはりNotarization modelが非常に有効だと思うのですね。なので、そこはちゃんと考えるべきかなと思います。今のままだと、原本データを持つ組織がVC発行に対応しない限り、Walletには入ってこないというモデルになってしまうと思うのですよ。

今のに関係するのですけれども、Notarizationというからには、ちゃんとした人がちゃんとした手続に則ってやらないと駄目で、だから、認定、監査、インシデント報告の枠組みが必要なはずなのですけれども、この資料には一切欠落している。監査性をどうするのかというのも本当は技術ワーキングでやらなければいけない話だと思います。

あと、ユースケースの設定にも課題があります。住民票VCなどは、何となく今は本人だけではなくて代理人が取りにいくとか、家族が取りにいくモデルが結構あったりして、本人だけがというのは現実とギャップがあってどうするのだとか、就労証明書VCのエコシステムが非常に簡略化されて、企業の人事システムから行政への提示が基本になっているけれども、人事アウトソーサーだとか、SaaSベンダーとか、中間ゲートウェイとかいろいろあるので、そういったところをどうするのかなとか、2回では検討できないだろうなと思います。

本当は、VCは複数のVCを一つのVPにまとめて提示するというのがユースケースとして最も重要だと思います。そういうものをちゃんとユースケースの中に入れて検討しないといけないかなと。そうでないと、下手したら普通にフェデレーションで良い、という話になるのですね。

あとは、Wallet間のVCのポータビリティー問題は51ページで触れられていますけれども、これも技術的にどうするのかというのをちゃんと検討しなくてはいけないのだけれども、2回ではできないと思います。

Holder Bindingと鍵管理、端末依存の課題です。Holder Binding要件と、代理利用の部分をどうしたら良いのかというのも技術的に検討しなくてはいけないし、あと、鍵ライフサイクルとアルゴリズムのアジリティーと将来性の話とか、この辺の検討もほとんど触れられていなかったと思います。
大枠で言うとこのくらい検討項目が抜けているかなと思いまして、結構難しさを感じています。以上です。

中村座長： ありがとうございます。

事務局（加藤）： 事務局からですけれども、オンラインの富士榮委員からご発言がありますということです。

中村座長： 富士榮委員、お願いします。

富士榮委員： 﨑村委員の発言が長かったので、手短に言ったほうが良いかなと思いながら、私も同じぐらいのコメントがあったりするのですが、なるべく短めに行きます。

まずは視点として、抜け漏れ含めてありますかという中村座長のお話からすると、圧倒的に欠けているなと思ったのはHolder、つまり利用者の視点ではないかと感じた部分が1つです。もう1つは、先ほど﨑村委員がお話をした、相互運用性というところ、並びに言葉の使い方というところが、技術ワーキングとしてやるにはかなり荒っぽいことをされている部分が目についたなというのがまずあります。この2点が大きくあります。

最初のHolder視点、利用者視点というところで言うと、やはり派生VCだという話とか、リスクがという話がありましたけれども、では、それをどうやってHolderが分かるようにするのかというところを含めたUIの観点というのを含めていかないといけないのではないかなと思うわけです。例えば民から官、官から民というユースケースが指定されておりましたけれども、これが派生であるということをユーザーが分かるようにするのが大事ですし、Verifierが本当に原本を求めているのか、それともコピー、もしくは派生でも良いということを言っているのかどうか、ということがHolderからすると分からなくてはいけなくなってくる。こうなってくると、技術的に言うと先ほどIssuerの適格性やTrusted Listみたいな話がありましたけれども、Verifierに関するメタデータというものをどう公開するのか、Trusted Listに入れる属性というものを何にするのかというところがEUのケースなどで言うと一緒に議論になった部分ではございますけれども、こういうところの議論というのをちゃんとやらなくてはいけないだろうなと思うわけです。

もう1つがプライバシー、これは﨑村委員の話の中でもありましたけれども、やはりLinkability、Unlinkabilityというところに話が行き過ぎている部分というのと、最後のほうに話がありましたけれども、VPの中に複数のVCを入れるということをどのようにみなすか、というところも、実はこのHolder Bindingという話というか、VC同士のバインディングの成立を何とみなすかという話も必要になってくるわけです。例えば民間の出している資格証明と公的機関が出している身分証明というものを同一VPの中にくるんで出すことによって、Walletから出てきているというところの前提がある程度あるという前提において、その2つがバインドされているということで同じ人を指すであろうということが成り立つのであれば、例えば資格証明側にはPII（Personally Identifiable Information）に関する情報というのは極限まで削るということもできたりするわけですね。こういうところを、ユースケースを検討される中では技術での担保というところを含めて検討ができると、非常に有用なのではないかなとは感じました。

あとは、2つ目の点の言葉の正確性というところは、インターオペラビリティーの話になってきていますけれども、先ほど資料としては飛ばしてしまわれたと思いますが、資料が公開されるという前提で言うとある程度修正をしなくてはいけないのだろうなと思った部分が特に48ページなのですけれども、クレデンシャルフォーマットとか、フォーマットという言葉が何度か資料の中で出てきているのですけれども、私が個人的に感じたところが、データモデルとフォーマットの話が混ざって議論されているように感じました。例えばW3C VCsと書かれているのですけれども、これがData Integrity VCのことを指しているのか、W3C VCDMのことを指しているのかというところが資料上から読み取れていないのですね。これは、選択的開示、ゼロ知識証明の実現可否というところが表の中にあるところを鑑みると、恐らくData Integrity VCの話をしているのではないだろうかと。なぜならば、採用する署名方式によってこれができる、できないという話が変わってくるのがData Integrity VCの特徴だと思っていて、これはW3C VCDMとは全く異なった、つまりデータモデルの話とは違ったレイヤーの話です。このレイヤーがちゃんと違うということをどこかで表現しないと、恐らく議論が何となくVCというキーワードの中で進んでしまって、何を指して話をしているのかというところがシャープに議論できなくなってしまうので、最終的にはインターオペラビリティーというところに大きな影響を及ぼしてしまうのではないだろうかという懸念をしておりますので、特に技術ワーキングではその辺を繊細に議論ができるような準備というものが重要なのではないかなと感じております。以上になります。

中村座長： ありがとうございました。

事務局（澤田）： 事務局から補足させていただくと、まず言葉の定義が不足というか、粗かったところは恐縮です。ただ、せっかく本日皆さんにお集まりいただいている時間をうまく使うため、定義そのものの議論は可能な限り、後に回していただいて、ここではどういう体制が必要かの発言、必要な範囲での確認にとどめていただければ幸いです。

また、内容が網羅されていないというのは説明の中でも触れたとおり承知していて、どうしてもいきなり全部扱い切ることはできないので、幾つかピックアップしてという形にはなっていまして、そのピックアップしているものが、これはメインどころではないのではないかというのはもちろんご意見として頂戴できればと思うのですけれども、ただ、今回取り上げたいくつかは本体会議で既に提示した内容でもあるので、そこに対して技術的観点から、この技術ワーキングでの意見をまとめて返すということはしていきたいところであるので、そこは意識の上でご発言いただけると大変幸いでございます。事務局からは以上です。

中村座長： 私からも補足しておきますと、今回の議論で実際のユースケースとして住民票の写しや就労証明書みたいなものを取り上げていただいているわけですが、親会の議論でも非常に抽象的な話題でVC・DIWというのが語られていて、技術ワーキングをやるにしてもどこに焦点を当てると良いというか、そもそも事前の我々の理解の共有というのが不十分だろうなということが予測されましたので、いくつか具体的なユースケースというのを想定したほうが、技術ワーキングとしても議論がしやすいですねということで、住民票の写しや就労証明書というのを出していただいています。とはいえ、住民票の写しの取扱いといっても、今日の資料でもまだまだ曖昧で、いろいろな使い方がありますねというところで、結局そこが曖昧で具体的にこういうパターンだと技術的にどのようにできますかというところを詰めたいところですが、そこもなかなか具体的にこういうパターンでというところまで踏み込めていないので、そういう意味ではあまり今日の段階で住民票の写しと就労証明書という具体的なユースケースについてどうこうという話を踏み込んでも仕方がないのかなと思いはしつつ、そこも想定した上でこの資料全体に対して、まずは今日のところはご意見いただくと良いのかなと思っています。

それで、定義の話などは後でまた整理していただいた上で、意識のすり合わせをするというので良いかと思いますけれども、まずは今日の段階でどういう議論をしたら良いかというか、どの部分が抜けているかというところを中心にいろいろとご意見いただければいいのかなどと事前に事務局と最終的にどういう形にしていくのでしょうねという話をしていましたけれども、最終的な取りまとめの資料を作る上で、踏み込んだ詳しいところまではガイドラインとしてまとめられないとしても、目次程度の項目として、こういうことは検討しないといけない、今回は時間切れだけれども、引き続き来年度も、もし可能であれば詰めていく必要があるということで、そういう項目レベルでは今年度は少なくとも洗い出しておきたいということですので、そういう観点からいろいろと抜けている面について、今回ご指摘いただいておくのが良いと思っています。

引き続き何かまだ補足などがありましたら、よろしくおねがいします。

板倉委員： 確認なのですけれども、今日のゴールとしては対策で抜けていると思われることを発散的にみんなで挙げていくみたいな会にするということで良いでしょうか。

中村座長： そうですね。考慮すべき、検討すべき項目としてあれば、そこはご指摘いただければと思います。

板倉委員： ありがとうございます。

その前提で話すのですけれども、まず定義の話は今日しないということなのですけれども、やはり私が思ったのは、圧倒的にリスクをどう考えるのかというところがぶれるなと思っていて、何が高リスクなのか、何が低リスクなのかというところで、それによって対策の度合いは変わってくるので、そこはちゃんと整理いただかないと、議論がぶれるなというところを思いました。

対策において足りない視点というところで言うと、いくつかあるのですが、まずVC以外のアイデンティティのライフサイクル全般を保護する必要性という観点で、VCの仕組み単体で取る対策だけではなくて派生するような技術というのも、ちゃんとカバーしないといけないと思っています。例えばVCとHolderを紐づけるみたいなときに、VCの中でバインディングをする方法もあれば、mTLSみたいな技術を使うみたいな方法も考えられるとは思うので、もう少しVC単体でというよりは、アイデンティティのライフサイクル全般で考えられるものがあるのではないかと思いました。

もう1つは、Issuer、Holderというところが結構出てくるのですけれども、Walletの観点があまり出てこないなと思いました。例えばHolderとVCのバインディングだけではなくて、Walletとクレデンシャルのバインディングが必要なのではないかとか、そのWallet自体がちゃんと管理されたものであって、悪さしていないよねというところをどうやって検証すればいいのかとか、IssuerがそのWalletをどうやって管理すればいいのかといった視点が必要なのではないかなと思っています。

あと、ユースケースについてもおっしゃったとおり、住民票VCだったり就労証明書のその先にもう一段踏み込まないと、リスクというのは変わってきてしまうので、そういう意味だとこの2回で話すのは結構難しいと思います。何かもう少し論点を絞って対策を議論できるといいのかなと思いました。

中村座長： ありがとうございます。

そうですね。だから、住民票についてはもうちょっと突っ込んで、いろいろなパターンがあるけれども、まずはこのパターンで最後まで検討してみましょうみたいなことをやると良いのだろうなとは思うのですけれども、それがそもそも我々のというか政府の目指しているモデルなのかというところがよく分からないというのがあります。その辺りの進め方も踏まえてまだ何かご意見があるようでしたらお願いします。

新崎委員： 先ほど鍵管理のお話が出て、スマートフォンとICカードの違いみたいなものがあって、ICカードは持っている間はリーダーに近づいていないですね。独立していて、使うときだけリーダーにかざす。スマートフォンはセキュアチップがあったとしても、周りはいますね。常時いて、その代わりスマートフォンはモニタリングできるというか、ちゃんと動いているかというのを確認できるということで、2つ違ったものを扱うので、Walletが入っているスマホはどう考えたらいいかという話があるのかなと思っています。Secure Elementの話なども、例えばCC認証を取ったアプレットをSecure Elementに入れなくてはいけないという話なのか、OSが提供しているキーストア、APIが提供しているキーストアを使ってもいいよとか、いろいろな段階はあると思っています。EU DIWも最近、Secure Elementとキーストアを分けて記載しているので、こういう使い方だったらこうですというのがあっても良いのかなと思っています。

あとは、これは発行プロセスが入るような気がしていて、今までは確認のプロセスだけをしていたような気がするのですけれども、Issuerが行政機関になって、それまで含めてVCの範囲になると、発行プロセスをどうするかというのがガイドラインに入るのか入らないのか、そこら辺はあるのかなと思っています。

中村座長： ありがとうございます。では、中村委員。

中村健一委員： 挙げると切りがないのですけれども、これをもし社会実装して市民の方々が安心して使えるようになるとしたときに、ユーザーとのインタラクションのところをいかに軽くするかということが非常に重要になっていきます。特に証明書類を発行するときは、当然市民の方が、免許証だったら教習所で卒業証書と住民票を持ってきているのですけれども、結局これが正しいものかどうかというのを確認するためということになってくると、この証明書もデジタルでちゃんと正しい発行者が証明しなくてはいけないとなっていき、どんどんいろいろなものに対して負荷がかかってきてしまいます。そういうときに、VC、我々の世界ではモバイルドキュメント（mdoc）という名前をしているのですけれども、その使われ方、用途、それからそこに格納されているデータの機微性なども含めてカテゴライズをしていって、特に民間で発行しなくてはいけないもので非常にコスト的に負荷がかかるものを強制してしまうと、そこが抜け道になりやすいので、実装の有効性、経済負担などを含めて適切なドキュメントが発行できるような仕組みをつくっていくために、うまくガイドラインというのを作って、例えばこういう証明書であれば最低このぐらいはやっておいてくださいね、ここまでやるとコストがかかるからここまでやらなくていいですよと、やらなくていいですよとは書かなくていいと思うのですけれども、そういうことが分かるようにしなくてはいけないというのが1つあります。

また、もう1つは、今度は受け取る側です。アナログの場合はコピーなどというのは特に何回もコピーしたら画像が劣化して、すぐこれはコピーだなというのが分かるし、原本がカラーなのが白黒で出てきたら一発で分かるし、見る人が見れば字が潰れているので分かるのですけれども、デジタルになるとその区別がつかなくなるのですね。そういうときに、1つはそのクレデンシャルが本当にどれだけの効力を持っているのか、派生証明書という言葉が多分悪くて、Derived Credentialsのほうがまだ良いかなと思うのですけれども、要するに本来のIssuerが発行したクレデンシャルだったらこれだけの効力を持ちます、ただ、これから派生したものに関しては、こういうことは証明できるけれども、本来の証明書が持っている全てができるわけではありません、と。それをどうやってユーザーに伝えるかというのが非常に分かりにくい状況になっています。

デジタルの世界なので、それをデジタルの力で、これは例えばこれだけの効力を持つものだからこれに使えます、使う方も、それを受け取る側にしても、これは本来の効力を持っているクレデンシャルだからそのまま受け入れていいですよと、あるいはこれは派生のものだからちゃんと原本を持ってきてくださいということがデジタルの世界でも分かるようにということをきちんと仕組みに落としていって、利用者が困らないような仕組みをつくっていくという視点が必要ではないかなと思います。

中村座長： ありがとうございます。

南井委員： 南井と申します。よろしくお願いいたします。

技術的に踏みしめなくてはいけない話は、もう﨑村委員から10ページぐらいあるというお話で、それを示しているだけで終わりそうなので、そちらの話は逆に全くせずに発言いたします。

板倉委員からコメントがあったWallet側の話があまりない、というのは私も思っています。なぜそれを気にしているかというと、デジタルでいろいろなものがやり取りできるということが進んでいった結果、人間の生身の操作の感覚からずれてきている部分があって、本人が何をやっているのかよく分からないまま、実はやってしまっているという話が結構たくさんあると思っています。それがある程度進む、特にWallet側の話として進むということを前提で考えていくと、そこの中でやり取りされるVCが、どのようにして発行から受渡しされるかによって、対策しなければいけない強度というのは結構変わってくるのではないのかなと思っています。ですので、そういった点も含めて議論という話になると、結構今回の議論2－1、2－2、2－3みたいな話を聞いたときに、踏みしめなくてはいけない課題は何ですか、というところのレイヤーを書くという話と、ユースケースで見るみたいな話が鶏と卵になってしまっているなという印象をすごく受けています。そうすると出口をどうするのだろうか、というところを今、結構懸念しているところでございます。以上です。

中村座長： ありがとうございます。では、栗山委員。

栗山委員： NTTドコモの栗山と申します。

過不足の観点なのですけれども、今回、「属性証明」というところが出てきていると思っていまして、最初に私が資料を読ませていただいて感じたのは、そもそも何の属性情報を証明したいのか、ということです。Holder Bindingのところにも記載があるのですが、氏名、生年月日、住所なのかというと、恐らく違うのかなと思っております。例えば住民票であれば御家族の方の氏名、生年月日、住所、続柄になると思っております。また、ユースケースが出ている就労証明書であれば会社で働いていることと、それ以外にも就労証明書で検索したらものすごい数の情報になっていて、これを全部入れるのか、となっています。そういったいろいろな情報がまずあると思っています。そこの情報がまず何なのか、どんな情報があるのかを洗い出した上で、リスクの話をしないと、毎回皆さんの議論が氏名、生年月日、住所を念頭にプライバシーや個人情報保護法という話になっていくので、そこは何の情報を証明したいのか、というのをまず明確にして議論したほうが良いと思っています。

そういった観点で、先ほど富士榮委員もおっしゃっていましたが、名寄せというところがもしかしたら要らないかもしれないという議論ができるかもしれないと思っています。例えば年齢判定みたいなところは年齢の情報が欲しかったら年齢を判定した結果しか出さないということができれば、ある程度のリスクは減らせるのではないのかなと思いました。

もう1つ、ガイドラインのスコープとして、官の発行であるVCと民間の発行であるVCという2つがあると思っています。官の発行に関してはある程度認証といったところは明確にできそうだなと思います。一方で、民のものに関してはそのサービスがコンシューマー向けのサービスなのか、エンタープライズ向けのサービスなのかで大きく認証の考え方が変わっていくと思っています。コンシューマーサービスに関してはセキュリティを強化してという普通の考え方になると思うのですが、エンタープライズに関しては、例えば就労証明書も社内のシステムに入ってそれをVCとして発行していただくみたいな感じになると思っていて、そこに認証や本人確認というのは出てくるので、そういった観点も入れてガイドラインを策定していくべきなのではと思っております。

以上でございます。

中村座長： ありがとうございます。

今、いろいろいただいた意見として、先ほどの発行プロセスに遡って、もうちょっと詰めないといけないのではないですかという話も出ました。逆にVerifyした後の情報の取扱いにどういうイメージを持っているのかというところも、このIssuer、Verifierのモデルにおいては、真ん中は責任を持つけれども、両端は知らないといった感じで技術はよく語られると思いますけれども、結局いろいろな手続をする上で、Verifyして得られた情報をどう扱うのか、みたいな点で、それはデジタルになっていないといけないのか、例えば就労証明はその内容を確認するのは結局人間ではないのかと思ったとすると、それは属性としてちゃんとデジタルとして扱えるようにしておく必要性はどこまであるのか、もよく分からないなと思いながらお話を聞いていました。そうしたときに、今までのPDF的なもので良いのではないか、発行する会社もいろいろな属性を扱うわけなので、それは統一するのも大変ではないか、と思うと、我々としてどこまで統一するニーズがあるのか、というところもよく分からないですね。

そこも、実際の手続としてどういうところまで確認して、その情報がどう扱われるか、Verifyした後どう扱われるのか、というところも含めて議論をしないと、そこまで議論した上で名寄せの危険性がとか、そこを法律的にちゃんと規制しないと、という話に持っていかないといけないです。それを実際にやるというのは本体会議の議論なのかもしれないですけれども、我々としては技術を語る上でも、そこら辺の手続の流れというのは把握した上で技術を押さえないといけないのかなとご意見を聞きながら思いました。
ご意見は言い尽くした感じですか。

新崎委員： Holder Bindingなのですけれども、要素として分解すると、本人認証と本人の意思の確認も入っているような気がしていて、普通のバインディングの結果などを、またエビデンスに使うということになるのかなと。その人が本人の意思を持って提示しましたというのを、そういう組み立てになるのかなと。

あと、プライバシーに関してなのですけれども、VCが自分のWalletに書き込まれたときに、そのVCの中身はこういうものを書き込みますよというのは、必要なのではないかなと思っていて、実際に書き込まれているデータはこういうデータをこれから書き込みますよというのはあってもいいのかなという気がします。

中村座長： ありがとうございます。

そうですね、そこも多分いろいろなユースケースがあって、例えば成績証明書みたいなもので本人に開示せずに提出先に渡してくださいみたいな封のされているような証明のモデルもあったりするので、その辺も含めてちゃんとユースケースを立てないといけないのかなとは思いました。

あと、Holder Bindingなどの話ですけれども、住民票の事例でも代理人が、という話が資料の中でも説明がありましたけれども、それはどういう設計で代理で証明書を取らせるのかとか、取ってきた証明書は一旦本人に渡すのか、という辺りもいろいろな事例が想定できて、それで実際に代理人が取ってきたものを正しく本人に渡すのかどうかとか、そこもしっかり検証が必要だというのだったら、そこの手続やそこの確認などをフローとしてしっかり設計しないといけなくて、そこは非常に自由度があるから、どこまで代理人モデルを検討すればいいのか、よく分からないなということもあります。それも、実際に役所に取りにいかないといけないから代理人がという話があるわけですけれども、オンラインでやり取りができるのだったら、別に代理人が行かなくてもネット経由で証明が取れればそれで十分なので、そうすると、どういうシチュエーションで代理人が必要なのか、みたいなところをもう1回ちゃんと考えなくてはいけないのではないかなと。

﨑村委員： 例えばICUに入っているときなどは代理人でないとどうしようもないですね。本人は操作できないですからね。

事務局（楠）： 分かりやすい事例で言えば、例えば税理士の方にいろいろ申告をいただいている場合とか、証明書類をかき集めるところも御本人がやられるのか、代理できる範囲があるのかをはじめとして、必ずしもITに精通していなかったり、制度に精通していない方をサポートするというのはよくある話かなと思います。

中村座長： そうしたときに、この代理は正しいのかみたいなところで、確かに今おっしゃったICUに入っているときにどうやって代理を指定するのだという話もあるので、どういうシチュエーションだったら代理が可なのか、というところも割と制度面に踏み込む話になってくるので、そこを我々としてはどこまで想定した上で技術を考える必要があるのか、ちゃんと前提を示しておく必要があります。

中村健一委員： 代理人に頼むこと自体は楽なのですけれども、それが正しく頼まれたかどうかの証明が一番大変です。

小岩井委員： でも、それは紙でも変わっていないから、ここで議論すべきなのかという話もありますね。

事務局（澤田）： 補足ですが、自然な流れで住民票などに話が移ってきているかなと思うのですけれども、今回、我々は代理での取得というのは想定ユースケースから外しています。おっしゃるように、実際に現場で市民が活用するにはそういうことが必ず想定に入るのですけれども、本当に使うとしてもまず一番基礎的なところからVCを実装していくことになるかなということで、一旦代理ではなくて本人が取得して本人が使ってというところを想定いただければと思います。

中村座長： ありがとうございます。では、﨑村委員お願いします。

﨑村委員： 一旦という話が出たので思ったのですけれども、これはガイドラインを作るのですよね。そうすると、やはりガイドラインのタイトルとスコープがまず欲しい。それに対して目次案が必要で、その目次案がちゃんと充足しているかを技術的観点で見て、ここは今年度はやりませんでしたけれども認識していますよ、というのをちゃんと残しておいて先送りにする。読んだ人もここは残っているのだなというのが分かるという形にしていくのがガイドラインを作るという意味では必要なのだろうなと思います。

中村座長： そうですね。だから、可能性としてあるけれどもまずは考えませんといったときに、そこのことを全く忘れて議論して技術を詰めたとして、後から考えましょうといったときにそれをもう一回全部取り壊して一から考え直さないといけないというのは非常に大変なので、当然最初から想定した上でどうなるかというのを考えないといけないということを言いたかったところでした。

板倉委員： そういう意味だと、今回のアジェンダの中に技術的対策を補う手当てについての話などもあったと思っていて、それこそユーザー教育だったり、プロセスをどうするのか、失効管理のプロセスをどうするのとか、いろいろ論点があって、多分そこまで及ばないと思うので、そこはスコープアウトにして、私たちは技術だけについて話しますといったドラスティックな判断も必要になってくるのかなと思いました。

﨑村委員： 新崎委員でしたか、中村委員だったか忘れましたが、発行プロセスの話をされたと思うのですけれども、例えばアメリカで今問題になっているので、mDLの発行に当たって各州が発行したmDLを金融機関が見て、それがリアルID法やCIP規制などに合致しているのかどうかが判断できないから、メタデータを足しましょうという話が出ています。その手の話というのは極めて技術的な話だと思うので、技術ワーキングの対象になるわけですね。

中村健一委員： 効力をどうやって伝えるかということですね。

中村座長： そういう意味では、全体のガイドラインを作るに当たって、目次案レベルで考えたときに、将来的に考えますという部分と、最初から考えません、でも課題ですよという部分というのはちゃんと書いておくということで、そこも今、ご発言いただいた以外にもいろいろまだあるのではないかとは思いますけれども、そこはまた後でお気づきの点があったらコメントいただければと思います。ほかにこの場でご発言は大丈夫そうですか。時間としてはもうあと30分になって、想定の進行としては残りの30分で住民票と就労証明書の場合についての検討、リスク対策等についてどうかというのをそれぞれご意見をいただきたいということとなっているのですけれども、せっかく資料も用意していただいておりますので、おおむねご意見は既に出ているかとは思いますが、もしそこでお気づきの点が何かありましたら、お願いします。

中村龍矢委員： 1つよろしいでしょうか。日々エンタープライズや伝統的な産業のDXに邁進している者としての所感なのですけれども、全体的に結構いろいろな登場人物がいて、いろいろなことをお願いして、いろいろなことをつくってもらうというところかなと思うのですけれども、インセンティブやモチベーションの観点が少し気になったところでした。

インセンティブというのはいろいろな意味があって、プライバシーの議論をする上で攻撃者側とか、脅威の元になる側のインセンティブという意味もありますし、守る側というか、全体のプロトコルを運営する登場人物のモチベーションというところもあるのかなと思っています。ずっとこのテーマに関して考えていることとしては、VCとかこの辺りのテーマというのは普及した先の世界というのは非常にわくわくして面白いなというのがありつつ、そこに至るまでの目先のユースケースというのは正直言ってかなり地味なものが多いなというのがあって、そこに至るまでの道のりのモメンタムのイメージをどうつくっていくのかというのが難しいなと思っています。ここで言うと、お酒を買うときにそれを確認しますとか、給与証明を会社がやりますというところのコストをどのようにやってもらうのかというところがすごく気になるところです。ここはセキュリティやプライバシーを考える上でも、みんながちゃんと言うことを聞くだろうかという上で重要というのもありますし、技術ワーキングということですので、テクノロジーやプロダクトでそういう負担を下げたり、やる気を出すようなエコシステムをつくるというところもある意味やり得るというか、やりたいことではあるので、そういった観点が入っても良いのかなというのが全体に思っているところです。ある意味PayPayの支払いすらも今はみんな確認しないと思うので、そういう世界線の中でどのようにVerifierをやってもらうのか、というのは前々から気になっているところであります。

中村座長： ありがとうございます。

小岩井委員： 今の題材とするユースケースというところで1つ気になったのが、これで発行するドキュメントの有効期限がどのぐらいを想定するかによって、考えなくてはいけないことが全然変わってくるなと思いました。住民票だと現在の紙のものでは、大体の人たちが過去数か月以内に発行したものみたいな制約をかけているので、大体皆さん必要になったときに取り直しに行くのですけれども、こと卒業証明書みたいなものは一生ずっと使われるものです。そうすると、長いものというのを考え始めると、スマホをなくしたときとか、バックアップをどうするのだという話とか、鍵のアルゴリズムの耐性をどうするかとか、いろいろな話が出てきてしまうので、それを逆に考えるべきだということではそういうことを入れなくてはいけないですし、一旦もうちょっと簡単なところから考えるべきだというのだったら、本当に発行して数か月以内に消費されるものを前提として議論を進めていくという考え方でもいいと思うのですけれども、そこは1つあるかなと思いました。

中村座長： ありがとうございます。

そういう意味では、実際に今、紙でやり取りされている証明書の有効期限をそのまま踏襲する必要は必ずしもないわけですけれども、その状況において発行にお金がかかるのだったらそれはやはり長いこと使いたいなという話ですし、デジタル化もするわけなので、そんなに再発行のコストがかからないようになっていくのであれば、そこは必要なときに発行してもらえばよくて、その場合の有効期限はそんなに長くなる必要もないし、Walletを紛失したからといってそれのリカバリーをどうするのみたいなところも実はあまり考えなくてもいいのかもしれないので、そこもいろいろなケースを想定しないといけないかと思います。でも、有効期限が長いものが1つでもあるのだったら、Walletはやはりしっかり管理されないといけないのかもしれなくて、そこら辺のWalletの設計はどうあるべきなのかというところも、ある程度どういう観点で我々としてはWalletを設計しないといけないのかみたいな、どういう条件のWalletを使わないといけないのかということは、ガイドライン的にはきちんと定義をしておく必要があるのかなというところかと思います。

佐古委員： 別のコメントなのですけれども、これは論点2－1に関係するかと思うのですけれども、ページ47で「リスクに応じた対策のレベルの考え方」で事務局案が出てきています。これの2行目に、「特定のVerifierにしか提示されないVCでは名寄せリスクも想定しにくく、特定の用途のみで用いられるVCでは選択的開示のニーズはないため、全てのユースケースに共通する「最低限実施すべき対策」は設けないことが妥当と考えられる」と書いてあり、これは低いところを決めるためのユースケースの議論だと思います。この表現（特定のVerifierにしか提示されないVCや特定の用途のみで用いられるVC）ではどういうユースケースを想定しているのかが分からなくて、そもそもこのユースケースで本当にVCを使う必要があるのか、というところまで疑問になります。ガイドラインの最低レベルを検討するのであれば、そこの具体的なユースケースがないと、本当は対策が必要なものも、「最低限の対策をしているから良いのです」という言い訳に使われそうだなと思いました。以上です。

中村座長： ありがとうございます。そこは何か資料を作った側として、もしコメントがあればお願いします。

事務局（澤田）： おっしゃるとおり、まずどういう証明書を今後VCにするかというのはまだ見えていないし、決まっていない部分がどうしてもあります。ただ、逆に、これは鶏と卵なのですけれども、各省庁や行政の中でも証明書をデジタル化するときにVCが使えそうかなと思ったときに、どういった論点とか、紙の場合、もしくはPDFの場合とどういう違いがあるのかということがまだ分からない状態です。そこの粗々の要素でも示して、最終的に自分が管理している証明書が高レベルなのか低レベルなのかはその後判断することになるとしても、大まかな目安や考え方などの参考情報がないと、今は取っかかりがないというのが行政の中での状況です。そのため、どういう場合が高リスクかというのが今は抽象的になってしまっているというのはご指摘のとおりなのですけれども、ある程度架空のユースケースの状況で考えてみるという形でご意見いただければ幸いです。

佐古委員： 今、私が言っていたのは低リスクとしてどういうものを想定するかというところのユースケースが具体的にないから考えにくいと思った、ということを言いました。

事務局が低レベルでどうしても入れたいというわけでないのであれば、今回、①と②のユースケースをベースにそれを考えたときの低レベルを考えるほうが良いのかなと思っております。

事務局（澤田）： ありがとうございます。

ここのプライバシーのところは下の最低限のところがなくなっているのでややこしいと思うのですけれども、それこそVCのそもそもの内容が例えばあまり重要ではない情報で、仮に漏えいしてもそこまで問題がないと考えられるようなものであったり、あるいは本当に特定の者にしか提示をしなくて、そこでしか管理をされないものだったりという、ある種そこの高リスクに書いているところの裏返しのものが低リスクになると考えております。

中村健一委員： 恐らくドキュメントというのは本来用途があって、大体のものは本来用途で閉じるのですよ。そういうものは転用される可能性は低くなるわけですね。ところが、免許証やパスポートというと身分証代わりにいろいろなところで使われる。だから、本来用途以外に使ったときにどんな使われ方がされるか分からないからリスクが増えるわけですね。なので、そのように具体的にこういう使い方をするから、このドキュメントというのはこれにしか使わないから、リスクが少ないよねと、これはこのようにも派生して使われているからリスクを考えなくてはいけないよねということで、具体的にどういうことによってリスクが発生するかというのを定義しないと議論しづらいかなと思います。

中村座長： そうですね。

板倉委員： 今、いろいろな議論があって、先ほどインセンティブやモチベーションという話もあったのですけれども、これからVCをどう使ってもらおうかという話と、今、既に広まっているサービスをどう閉めていくかというのはちょっとアプローチが違うと思っていて、両方を議論できるのがベストですけれども、どちらかに絞って今回はより低リスクなところをちゃんと議論していきましょうみたいなアプローチもあるのかなと思いました。

あと、論点2－3で言われている、住民票の写しだったり就労証明書というケースにおいて適切なのかという点に関してですが、これが不正に利用されてリスク事象が発生したときに何が起こるのか、というところをもう少し整理しないと、対策の妥当性というのも検討しづらいと思うので、もう少し深掘ったほうが良いかなと思いました。

中村座長： ありがとうございます。

そうですね。先ほどからの話に関連しているわけですけれども、例えば24ページで今回のガイドラインのイメージを図にしていただいているものがあって、最低限実施すべき対策手段というのが一律で書かれているわけですけれども、そもそもそこは一律に決まるものなのか、というのが今のご意見だと思うのですね。それもユースケースごとにもっと低くても良いという事例もある中で、では、全体的なガイドラインとしてどこを目指すのというところで、いろいろなユースケースがあって、そうしたときにもっとリスクを低く評価できるものもあるのだけれども、いろいろ柔軟性を大きくしてしまうとややこしくなるから最低ラインをここに合わせましょうみたいなことで、それでユーザーが分かりやすくなるのだったらそれはそれで1つのアプローチだと思います。でも、そのように最低ラインをある程度のレベルで決めてしまうと、こういうシーンでは使いにくくて今まで簡単にできていたことが難しくなるよねというのだったら、そこはさらに下げることを考えておかないといけなくて、そうすると、最初からこういうガイドラインを想定していますと言われても、なかなか本当にそうなのという疑問がでてきます。そこは具体的なユースケースなどを落とし込みつつ、1つのガイドラインの方向性として、こういうこともあるかもしれないぐらいのイメージとして共有しておくぐらいにとどめたほうが、このページの説明としては良いのかなと思います。先ほどからの話はそのような議論ですね。

中村健一委員： 例えばリスクとして考えられる1つなのですが、住民票や就労証明書を受け取った場合です。本来デジタルのVCが来たときに、それは電子署名がAuthenticityとIntegrityを証明するから、そこで本来だったら閉じるのですね。ところが、これでもしAuthenticityを保証できなかったら、結局アナログのときと同じで、下手したら発行者に電話をかけてこの人がこんなものを持ってきたけれども正しいですかと言ったら、もうプライバシーも何もないわけですね。

だから、一番避けなくてはいけないのはそういうことで、ちゃんと就労証明書なり住民票を受け取ったら、正しい発行者によって発行されたものだから一々問い合わせなくても証明できるというものが必要で、そうすると、住民票というのはいくつの自治体で発行しているのだ、これをどうやって正しいことを分からせるのだ、とか、あるいは就労証明書だったら会社はその比ではない数があるので、そんな中でどのようにこの発行者の署名は信用して良いか、というのをいかに低コストで、要するに経済的に負担をかけない中で実現していくかというのが技術的に考慮していくべきことかと思います。

﨑村委員： 一言で言えば、VCというか、VPを受け取ったときに、そこからいかにトラストチェーンを再構成するかという話ですね。

中村座長： そうですね。だから、そういう技術が実際に世の中に本当に必要なのとか、技術としてどこまで考えるべきなのか、というのは本体会議側で議論すべき話なのだと思うのですけれども、そこのすり合わせはどうやるのというところが、なかなかまたこれはこれで難しいと思っています。技術としてはいろいろなことを想定しながら詰めて議論しないといけないわけですけれども。

新崎委員： これから人口は減っていくので、自動化しないとたまらないですよねという話はあると思います。

小岩井委員： おっしゃるとおりで、自動化するために何かドキュメントとしてシステムで処理しやすいものをつくっていきましょうというところがここのゴールだとしたときに、それはVCなのか、という話も絶対出てくると思うのですね。ですけれども、それも含めてこれで実現したいというのが国ないし事務局さんないし本体会議の意思なのかどうか、というところはちょっと気になります。

中村座長： そうですね。﨑村委員がおっしゃったようにフェデレーションでできることはそれで良い、という話もある中で、いきなり決め打ちでVCについて議論すると言われても、やや困っているというところです。

事務局（楠）： なぜVCに着目をしているかは、御存じのように昨年の研究会もあったわけですけれども、1つは、結局マイナンバー情報連携が一定進み、マイナンバーカードが普及したにもかかわらず、紙は全然減っていないし、そもそも政治の方々などとお話をしていても、コンビニ交付が便利だ便利だと言うのだけれども、なぜそもそも紙を打ち出しているのだということは必ず言われるわけです。課税証明書もあれば、住民票もあれば、そのほか結構そういった紙を打ち出す事務というのはすごくたくさん役所の中にもあり、そういった受渡しも含めて今のままでは自動化の目途が立っていません。ここはバックオフィス連携でできない部分をどのようにやるかという中で、当然フェデレーションという選択肢もあり得べしですが、バックオフィス連携というのはN×Nで無限につなぐところが増えていって、本当にできるのですかということは考えないといけないです。

あともう1つは、これも社会の中でVC化するみたいな感じでDerived IDがいっぱい出てきてしまっています。そこの中でDerived IDを認めるのは、例えばある種電子署名法の認定認証局だってDerived IDとしての面があるけれども、監査の仕組みがしっかりとあるし、法律でこれをきちんと位置づけているわけです。一方で、そうではないVCもいろいろいっぱい出てきていて、これは金融庁と一緒にFinTech実証実験ハブで昨年度も整理をしたこともありましたし、何をやって良くて何をやっていけないかというのは、ちょっと考えれば分かると思うのですけれども、意外とドキュメント化されていないので、ここは世の中が大きく混乱する前に整理し切っておかないとまずいことになる、という点です。

1つはきちんと、デジタル化の妨げとなっている証明書、添付書類というものをマイナンバー制度だけでできなかった部分をどうやってさらにデジタル化したり、AIエージェントネイティブにしていくかということ、もう1つは実社会のほうでVCといってよく分からないいろいろなものが出てきていたり、Walletも10個も20個も出てきているという状況とどう向かい合うか。ここはしっかりと考えて、早くメッセージを出していく必要があるのかなと思ってはいます。

中村健一委員： それはまさに同意で、私は個人的にはDIWやVCなんてどうでもよく、一番大事なのは、要するに文書を信頼して、検証して、次の処理をする、この属人的な処理をいかにAIエージェントにやらせて処理の負荷を減らすか、です。そのためにトラストがあり、署名されたデータがあるわけなので、そういうところにもう少しフォーカスして考えるべきだと思います。

事務局（楠）： ですので、別に署名付PDFでも良いとは思います。ただ、住民票をそうしようとしたら、総務省からお叱りを受けて、プリントアウトして本物の住民票みたいに見えてしまってはいけないとか、いろいろな議論が住民制度課の検討会でもありました。中間報告は出ていて、住民票が広く証明書として官民で使われているがゆえに、彼らの心配しているリスクプロファイルみたいなものをどのように充足する手段があるかみたいな点は、ぜひ整理いただけると助かるので、そこはきちんと情報提供できればと思います。

中村座長： リモートから富士榮委員が発言したいということなので、お願いします。

富士榮委員： 多分終わらないと思うので、サジェスチョンといいますか、いろいろお話を伺っていてなのですけれども、どこまで立ち返るかはあるかと思うのですけれども、昨年度のVCガバナンスの話というのは今も話題に上っていたDerived Credentialsというものに対してどういう手を打っていくのみたいな話からスモールでスタートしていたと僕は記憶しているのですね。

技術というところも、全般的にガイドラインをという話で、あまり区切らずにガイドラインを全部作りましょうという話をしていたら、恐らく今回もそうでしたけれども、次回でも当然終わらない話になってくると思います。出来上がるドキュメントも、これができるのだったら世界中の人が参照するよという大作になってしまうのだろうなと思ってしまいます。ですので、そもそもDerived Credentialsというものそのものについて、発行する側の視点、使う側の視点、提示される側の視点、そのぐらいの3つの中で、どうやってそれを適切に技術的に判別をして手を打っていくということができるのでしょうか、くらいに絞らないと、リスクの話をし始めるとリスクは無限に出てくるでしょうし、いろいろなユースケースも出てきてしまうので、この場で答えを出す必要はありませんけれども、その辺を事務局の皆さんで絞っていただいた上で、我々からどういうところに対してコメントを技術的な観点ですればいいかという話を次回はしていただけると良いかなと思いました。

中村座長： ありがとうございます。そうですね、今回はもうほとんど時間は終わりなので、あと来月に1回を残すのみという状況なわけですけれども、そこでできるだけ効率の良い議論ができるように次回に向けて準備をしていければと思います。ということで、あともう残り時間僅かですけれども、最後にどうしてもこれは言っておきたいみたいなことがもしありましたら、お願いいたします。

大丈夫ですかね。ありがとうございました。そうしましたら、事務局からこの後のご説明等をお願いできればと思います。

事務局（北井上）：
ご議論いただきまして誠にありがとうございました。閉会に先立ち、事務局から事務連絡をさせていただきます。まず、本日いただいたご意見、様々いただきまして誠にありがとうございました。いただいたご意見については次回の議題や議論などに反映してまいりたいと考えてございます。特に最後に富士榮委員から、広がっていく中でどこに今年度は特に焦点を当てて議論をしていくべきか、目次案が必要である、との力強いご意見もいただきましたので、次回の会合ではその目次案を詳細に書いてお持ちできればと思っております。それをベースに、特にここは中心となって議論するべき部分だとか、あるいはこういった部分は将来的には考えていかなければいけない部分だとして記録していく、そういった形でしっかりと見せていければと事務局としては考えてございまして、次回のご議論もお願いできればと考えている次第でございます。

また、本日の議事録につきましては、後日、委員の皆様にご確認いただいた後、デジタル庁ウェブサイトにて公表をさせていただきます。また、次回の開催などにつきましては、今、投影しております資料3に記載のとおり予定しているところでございます。まさにご指摘いただいたとおり来月の冒頭でのご議論をお願いしているところでございますので、関係委員の皆様におかれましては、引き続きどうぞよろしくお願いいたします。

それでは、閉会に当たりまして、事務局を代表してデジタル庁デジタル社会共通機能グループ参事官の中川よりご挨拶申し上げます。

事務局（中川）： ありがとうございました。閉会挨拶として資料を用意してもらっていたのですけれども、こちらは見ずに話そうと思います。

私も今まで役人を20数年やってきて、こういう目的を持ってユースケースを持たれた方が委員として入っていない委員会は初めてでした。例えば、住民票だったら住民制度課が、住民票のVCを発行したい企業の方と一緒に来られるケースがあって、これをやりたいのだけれどもという話から、それを皆さんでご議論いただくというのが多分通常であろうと思います。なかなか私もどうしたものかな、というのもあるのですけれども、ただ、何かしらアウトプットしないと前に進まないのは間違いなくて、皆さんにもそこをご理解賜りながらご議論いただいたのだと思っています。

お聞きしていて、目次というのはなかなかハードルが高いのであれば、ちょっとカテゴライズしたタスクリストだけでもすごくありがたいかなと思います。これを基にカテゴライズした形で、サブワーキングを来年度開いていくのかなと。例えば、用語の定義から入らなくてはいけないというのであれば、用語定義サブワーキング。あとやはりユースケースですかね、ユースケースにも応じてリスクが考えられるから、それを一体的に扱うサブワーキンググループというのがあってもいいし、さらにユーザーインターフェースについて、ここは証明できているけれどもここは証明できていないということをどう分かるようにするのか、みたいな点を考えるというサブワーキングも必要でしょう。例えば、住民票なら住民票でもいいのですけれども、そういう方々が一緒に入った上で住民票はどういうケースが世の中で使われていて、それでどういう人が困っているみたいな点が、一人称で語れる方と一緒にやらないと、手段ばかり話をすることになって難しいなと思います。皆さんには本当に申し訳ないのですけれども、そういう意味ではなかなか空を掴むような点があったかもしれないなと感じています。そこは我々もどう場をつくっていくのかなというところで反省もあります。

そういう意味では、他方でこれは本気でやると1年半以上かかるものなので、そうすると、来年度から、予算も含めてスタートするのですけれども、来年度から1年半かけたりしてサブワーキングの構成をどうするとか、タスクリストはどうするということをアウトプットいただくだけでも、大変助かると感じております。先に目次ということで事務局案を出させていただきましたけれども、そういう出し方というのも、もしかするとあるのかなということで、中村先生にも御相談させていただきたいなと思いながらお聞きしました。

そういう中のご議論をいただきながら取り込んでいきたいと思いますし、その意味では本体会議にも技術ワーキングとしてなのか、それともよく分からないですが、技術的な側面を語る上でこれは整理しなくてはいけないのか、という技術ワーキングの出力というのもありなのかなと思いながらお聞きしましたので、そういうところを今日お伺いして思いました。なので、そういう具体のアウトプットを目指して取り組んでいきたいと思います。引き続きお付き合いを賜れればと思います。今日は少し発散気味だったと思いますけれども、そういう点も含めて少し手前のまとめ方みたいなものも考えさせていただきたいなと思います。

今日はお忙しいところ、ありがとうございました。

事務局（北井上）： それでは、以上をもちまして、属性証明の課題整理に関する有識者会議技術ワーキンググループ第1回を終了いたします。ありがとうございました。