属性証明の課題整理に関する有識者会議 技術ワーキンググループ（第2回）
- 最終更新日:
概要
- 日時：令和8年（2026年）1月8日（木）14時00分から16時00分まで
- 場所：オンライン（Microsoft Teams）※ライブ配信は終了しました。
- 議事次第：
- 開会
- 技術ワーキンググループ（第1回）でのご意見を踏まえた方針のご説明
- 議事：「題材ユースケースにおける検討事項等に関する協議」
- 閉会・諸連絡
資料
議事録
事務局（北井上）： ただいまより「属性証明の課題整理に関する有識者会議技術ワーキンググループ(第2回)」を開始いたします。皆様、本日はお忙しいところ、お時間をいただきまして誠にありがとうございます。どうぞよろしくお願い申し上げます。
時間も限られておりますので、早速ではございますけれども議事に移りたいと思います。
議論に先立ちまして事務局から資料の説明をさせていただきます。
資料説明の後、議論に関する進行を中村座長にお願いできればと考えておりますので、よろしくお願いいたします。それでは、事務局から資料1に基づいて説明いたします。
事務局（澤田）： それでは、まず、前回の議論を踏まえた会議の方針について説明させていただきます。
第1回技術ワーキングでは、会議のスコープや今年度のゴールなどの全体についての意見を多く頂戴しました。
例えば、技術的なガイドライン検討には検討項目が不足しており、リスク対策議論は難しいのではないかといったご意見や、提示した住民票の写しや就労証明書のユースケースについて、技術的な議論をするにはユースケースの粒度が粗いのではないかといったご意見をいただきました。あるいは、議論スコープをもっと具体に絞って明示をしてほしいといったご意見も頂戴しました。これらのご意見を踏まえ、課題や背景から振り返りの上、今年度のゴールと議論の進め方を再整理いたしました。
この会議のそもそもの検討の背景から一度振り返りますと、行政手続のデジタル化を目指す中で、行政機関同士の情報連携による書類削減、デジタル化は進んだものの、行政と民間の間のやり取り、ここでは、まだ多く紙や単純なPDFでの証明書のやり取りが行われています。そこで、さらなる電子化や利便性の向上には、VC・DIWを用いた利用者を介した情報連携についても取り組むことが有効という示唆を昨年までの会議で得ているところであります。
また、前回の会議ではリスク対策にフォーカスをしておりましたが、一歩引いて、VC・DIWを行政が活用していくときの阻害要因の全体像を見てみますと、まず、技術面では、前回の会議のとおり、VC・DIW活用の仕様検討や実装への課題・制約が明らかになっていないことがあります。環境・インフラ面では、例えば、署名鍵やWalletなどの利用環境や、それを維持するためのエコシステムが未整備であることがあります。また、法令・制度・ガバナンスの面では、公的な証明書をVC形式で発行・活用できる法令・制度の整備がされていないことなどが課題として大きくあると考えております。
これらに立ち返った上で、今年度の検討のゴールと議論の進め方について再整理しました。まず、議論の題材ユースケースについては、引き続き住民票の写し、就労証明書、これを題材としていきます。また、今年度のゴールとしては、まず、題材ユースケースの実装に向けて検討すべき事項の全体像を「検討事項リスト」案として整理します。こちらは、本日の会議外に別紙で議論をいたします。また、そのうち、特に検討の阻害要因となる、先行して対応が必要な事項、これを明らかにすべく、本日は特に重要と思われる課題をピックアップして議論をさせていただきます。
このような形で本日の技術ワーキング第2回では特に技術の視点で、2月に予定しております本体会議第2回では、技術だけでは対応できないガバナンスなどの視点も含め議論したいと思います。踏まえて、次年度以降の動き方のイメージとしましては、まず、個別ユースケースの具体的な推進をステークホルダーを巻き込んで議論するであったり、検討事項に対する対策基準、つまり、前回フォーカスしておりましたガイドラインを改めて検討することであったり、その他、VCの扱い方に関する個別論点の議論などがあり得るかと現時点では考えております。
それでは、続いて、2つのユースケースを題材とした具体の検討事項の議論に移ります。
事務局（加藤）： 1つ目のユースケースですが、民間が発行して行政が受け取る証明書の例である就労証明書になります。ここでのユースケースの前提についてですが、まず、VCの用途につきましては、民間企業が発行し、保育所等への入所に際して自治体へ提示することを想定しております。年1回の現況届においても利用されることを想定しております。VCの発行方法につきましては、マイナポータル上での申請手続に際し、所属企業の担当者の手入力、または、人事労務システムとの連携により就労証明書VCが発行される方法を想定しています。発行については、VCをマイナポータルへAPI連携する方法と、VCを利用者のスマートフォンに格納する2パターンを想定いたします。VCの提示方法については3パターンございまして、1つ目がVCの発行プラットフォーム上から発行された就労証明書VCを、マイナポータル上での申請における添付書類として提示する方法、2つ目が、申請者が自治体の電子申請システムを利用する際に、スマートフォンから就労証明書VCをオンライン提示する方法、3つ目が、申請者が市役所の窓口等で就労証明書VCを対面提示する方法の3パターンとなります。発行から提示までの一連のフローにつきましては、こちらの資料の右側の図をご覧いただきますと幸いです。
続いて、本ユースケースにおいて想定される課題とその解決策について、皆様にご議論いただきたい事項を説明いたします。3点ございまして、1点目は、VCのデータ構造の差異による相互運用性の課題についてです。現状、就労証明書の様式は運用面で差がございまして、VC化に際してデータ構造が統一されない場合、本来であれば、どのようなデータ構造であれWalletに格納でき、Verifierが検証できるといった、相互運用性が確保された状態が理想である一方、例えば、ある自治体においては特定のデータ構造を扱えないため、就労証明書VCを受け取れないといった相互運用性に関する課題が顕在化するのであれば、整理が必要だと考えております。ご議論いただきたいポイントとしましては、VCのデータ構造の差異による相互運用性の低下が、発行から提示・検証に至るその一連の中でどのように顕在化をするのか、また、その解決に際して、例えば、行政で共通のVC様式を策定するといったことも検討しておりますが、本当に解決策はそれだけなのかという点についてご議論いただけますようお願いいたします。
2点目は、自治体が就労証明書VCを簡便に検証するための課題についてです。就労証明書VCを受領した自治体が当該VCを信頼する、具体的には、発行元企業の実在性確認と、就労証明書VCの非改ざん性の検証が必要となってまいりますが、VCに付された署名検証が有効であると考えられる一方、それだけで充足するのかというところについて検討する必要がございます。
3点目ですが、発行主体が異なる場合の署名の検証についてです。2点目の課題に合わせまして、署名検証の有効性が認められるとなった場合に、実際に就労証明書の発行主体となる各民間企業ですけれども、就労証明書を発行するプラットフォーム上でどのように署名を付すことができるのかについても検討する必要がございます。
議論ポイントとしましては、右側、青枠で書いているところですけれども、2点目、3点目で共通していると考えておりまして、就労証明書の発行主体となる各民間企業がVCの発行プラットフォーム上で、簡便かつ共通して利用可能な署名方式と、その提供方法は何かという点です。また、就労証明書の検証におきまして、特に重要な企業の実在性確認として、後ほど例示をしておりますけれども、資料上の署名方式で充足し得るかについてご議論いただきますようお願いいたします。また、署名方式についても種類があるかと思いますので、補足の例示を基に妥当な方式についてご議論いただけますと幸いです。
このような観点の下、以降はそれぞれ具体的な課題内容と議論ポイントについて示しております。就労証明書でVCが統一されないことにより一部の利用者、検証者がVCを利用できない懸念、これが、どこでどのような形で顕在化し得るのか、こちらのページで示しております。
続いては、就労証明書VCの検証に求められる企業の実在性、それから、非改ざん性の検証において、こちらで例示している書面方式で充足するのかどうか、利便性も含めて妥当な手法となり得るかについてそれぞれまとめております。
また、このほかにも、もちろん就労証明書VCの実現においては課題が多くあると思っておりますので、一部を参考として記載しております。それでは、この就労証明書を題材とした想定課題と解決策について、皆様にご議論いただきたいと考えております。
以降の進行は中村座長にお渡しさせていただきます。中村座長、よろしくお願いいたします。
中村座長： ご説明、ありがとうございました。
それでは、本日は2つのユースケースについて順番に議論するということで、まずは1つ目について資料をご説明いただきました。資料の中にもある程度想定している前提条件が記載されているかと思いますけれども、議論を進めていく上で、まずは資料に対する疑問点とかがもしあれば、先にそちらをお伺いするのがいいかなと思うのですけれども、資料の内容については、皆様、ご理解いただけた感じでしょうか。
例えば、7ページ目にVCの発行方法として2つ記載があって、後ろの資料もそのような形で分類がされているわけですけれども、1つ目の、VCをマイナポータルにAPI等で連携すると書かれている部分のフローのイメージが、私はいまいちつかめていません。マイナポータルというのは、基本的に個人がアクセスするサイトだとしたときに、そこにどうやって企業側が就労証明書をアップロードするのかという、そこの証明される側の個人と証明する側の企業との間の関係がマイナポータルに対してどう関わるのかというところがいまいちまだ分からないので、そこを補足していただけるとありがたいです。
事務局（澤田）： この点、担当の省庁とも相談してというところですが、具体的に何か仕様が決まっているわけではなく、この場で具体的な想定をお示しするのは難しいところであります。
事務局（加藤）： 補足をさせていただきますと、VC発行プラットフォームと規定しておりますけれども、その環境を使って就労証明書の発行元となる各企業はVCを発行することができると。今申し上げたとおり、そこからマイナポータルへのデータ連携の方式は、まだ決定されたものはございませんけれども、申請に対する添付書類として扱われるようなイメージで、VCの発行プラットフォームからマイナポータルに対してVCが連携されてくるというフローをご想像いただければと考えております。
中村座長： そうしたときに、1と2を区別しているというわけですけれども、その2というのは、Issuerとしての企業が証明書を発行して、それがWalletに入って、それを政府なりに提出するというフローになるわけですけれど、1に関しては、そのWalletというのがなく、代わりにマイナポータルを使うみたいな、これをWeb Walletというのかどうか分からないですけれども、そういうイメージを想像すれば良いのですか。
事務局（澤田）： そうですね。利用者がこの端末に入って、もしくはログインして使うWalletを介している場合と、手続関係のプラットフォームを介している場合の2パターンを想定しているという意味です。Walletの有無と両方あると捉えていただければと思います。
新崎委員： 図で言うと、2の「VC発行」のほうがWalletに書き込むほうで、1の「VC発行」のほうが、API連携でマイナポータルに提示するということで、VC発行プラットフォームというものがあって、そこがデータ互換性とかそういったものを保証するとか、そんなイメージですか。
事務局（加藤）： ありがとうございます。最後におっしゃられた互換性を保証するというところは、まさに、例えば①のところですね。①のところで課題として挙げさせていただいておりますが、そういったところを一定手当てをする必要があるのかというところも含めてご議論いただきたいという趣旨で資料のほうはしたためております。
新崎委員： そうすると、例えば就労証明書のデータフォーマットを誰かが決めて、それに基づいて企業が発行する場合もあるし、ひょっとしたらプラットフォームが全部束ねて、同じデータの就労証明書のVCを発行するのを担当するという、両方あるという想定ですか。
事務局（加藤）： 基本的には、就労証明書の発行元である所属企業、申請者の所属企業が発行プラットフォームを利用してVCを発行するということを想定しておりますので、発行プラットフォーム自体が自主的に何かデータを発行するということは想定していないところでございます。
新崎委員： 図を見ると手入力とかいろいろな連携とかと書いてあるので、極端な話、そこまで手が回らない企業に対して、プラットフォームがデータをもらって、きれいな形でVCとして発行するとかそんなイメージですか。
事務局（加藤）： そちらも、もともと企業のほうで用意されていた労務関係のシステムからデータ連携がされてくるということも一定想定はされておりますので、その中で必要なデータを受け取って、それをVCとして変換して発行していくということも想定はされるのだろうと考えております。
中村健一委員： 申し訳ないのですけれども、この絵を見ると、なぜVCを一旦マイナポータルに対して発行しなくてはいけないのかが分からない。マイナポータルは知らなくて良い情報も知ってしまうことになると思います。だから、マイナポータルとして、例えばマイナンバーカードを使って利用者の確認をして、利用者の確認ができたから、そういうことを自治体に知らせて、自治体がVC発行プラットフォームに取りに行くのだったら非常によく分かるのですが。
事務局（加藤）： この資料上は表現できておりませんけれども、おっしゃっていただいたプライバシーに関わるような問題もあると思っていますので、もちろん、この資料に書かれていない部分での課題というものもあると思います。
中村健一委員： 分かりました。要するに、詳細は今後詰めるけれども、ルートとしては、本人に直接発行するのと、ネット経由に大別していますというところまでということですね。今日の議題は。
﨑村委員： 確認なのですけれども、要するに、①はIHVモデルではない。②③はIHVモデルであると言っているということでいいですか。
事務局（澤田）： はい。そのご理解で大枠としては大丈夫です。
﨑村委員： もう一点確認なのですけれども、このVC発行プラットフォームがVCを発行するときに使う鍵は何ですか。
事務局（澤田）： そこは、まさに今回論点として挙げているところです。
﨑村委員： 分かりました。先走りました。
中村座長： 今の鍵というのはIssuerとしての鍵という意味ですね。
﨑村委員： Issuerとしての鍵です。
富士榮委員： 共通のVC発行プラットフォームがVCを発行して、Walletも、何かしら共通のものがあって、そこから自治体に対して提示をするというところも、一定のプロトコルを含めたところについては標準化がされているという前提で、この課題1のところのデータ構造について相互運用性を考えましょうという理解でいいですか。つまり、通常、相互運用性という話をするときは、プロトコルの話とかを含めて、署名の打ち方の話も含めていろいろ考えなくてはいけないのですけれども、今回はあくまでデータ構造の差異について相互運用性があるかないかというところがスコープということですか。
事務局（加藤）： おっしゃるとおりです。補足をさせていただきますと、運用面での差異ということにはなりますけれども、現状、必ずしも発行される就労証明書としては統一した様式で発行されているものではないという現状があると考えております。それがそのままVCになったときに、目指すべき理想としては、データ構造という表現をしていますけれども、どんなVCであってもWalletが扱える、Verifierとなる自治体は検証ができるというのがあるべき姿だと思いますが、必ずしもそうはならないというような懸念事項もあると思っています。
下のところで、どのような場所でどのような形で受け取れないパターンがあり得るのか、これ以外にも様々パターンはあると思いますけれども、一部例示をさせていただいておりまして、このような懸念点といいますか、そういったものが顕在化する可能性があるのであれば、そういったところを整理しなければいけないというところが、まず議論の背景にございます。
富士榮委員： つまり、この絵で言うと、VC発行プラットフォームは共通なので、発行に関するところの足回りは全部既にそろった前提があるのだけれども、Walletについては、もしかしたら自由なWalletが入ってくるかもしれないから一番下のところはバツがついていて、提示の部分についても、基本的には自治体に渡すというところは、足回りがちゃんとそろっているという前提があるので、プロトコルレイヤーに関しては大丈夫なのだけれども、データの差異というものがあるので、そこの受け取りのところで問題になるケースがあるよねということですね。
事務局（加藤）： はい。
栗山委員： 質問をよろしいですか。VCを利用者のスマートフォンに格納するというほうのユースケースなのですが、これは、利用者としては、VC発行プラットフォームにスマートフォンでアクセスをしてWalletにVCを格納するというような想定をしているという理解で合っていますでしょうか。
事務局（加藤）： はい。合っております。おっしゃるとおりです。
栗山委員： 分かりました。その際の認証方式というのは今回対象外なのか、スコープに入れて議論するのかというと、どちらになりますでしょうか。
事務局（加藤）： ありがとうございます。その認証の部分に対して、まだ規定したものがございません。今回はスコープには含めていないところでございます。ただ、もしそういったところを議論しなければ、しかるべき、今回挙げているような課題の部分の検討ができないということであれば、ぜひおっしゃっていただければというところでございます。
栗山委員： 分かりました。分からなかったのは、そもそも何で認証するのかなというところでして、所属企業がVC発行プラットフォームでVCを発行した際に、利用者の方は何のIDとパスワードで認証するのだろうかと。社員番号と会社のパスワードで認証するのか、はたまたマイナンバーカードの公的個人認証等で本人確認、認証するのかというところが議論されていないと、そこが不正アクセスのもとになるなと思ったので、ここの部分が記載されていないというのが確認ポイントでした。
﨑村委員： そこができないとHolder Bindingができないです。
事務局（澤田）： そこの認証のところは、住民票の写しのユースケースのほうで議論ポイントとして取り上げているところで、ここの就労証明書では、今回、議論のポイントからは外れている形で、まだいろいろと想定が定まっていないので落ちています。
事務局（勝原）： 今、栗山委員からいただいた意見の趣旨は、マイナンバーカードで認証するみたいな話ではなくて、所属企業で誰なのという観点の認証みたいなところを意図されていたと思うので、その部分の観点は、こちらでむしろコメントをいただくほうが適切かなと思います。
中村座長： そういう意味では、最初の認証もそうですし、VCを発行するときに、そのVCは誰に対する発行なのか、という点は、多分認証に絡む議論になると思います。それが、マイナンバーカードでも何でもいいのですけれども、企業側のIDとどう紐づけている前提なのかとか、紐づけていないのかとか、そこの前提もいろいろあるはずです。そこを明確にしないと後ろの設計が全部変わってくると思います。ですので、そこがまだ決まっていないということなので、いろいろな自由度があるという中で、いろいろな可能性を今日は議論しないといけないのかなという認識ではいるのです。
富士榮委員： 仮定として、こういうユースケースがあったとしたらという話だから、そこはgivenなものとして決めるしかないのではないですか。
中村座長： そういう意味では、今日提示していただいているこの2つのパターンでということで、ほかのパターンもあり得るけれども今日はそこには触れない、あるいは、触れるとしても、こういうことは考えないといけないのではないですか、程度のコメントをするぐらいで進めるということですか。
中村健一委員： 一点よろしいですか。多分、日本語で「発行」と書いているからごちゃごちゃになっていて、所属企業からVC発行プラットフォーム、ここはただのIssuanceで、そこからVC発行と書いてあるところは、IssuanceではなくてProvisioningですよね。全く別なものなので、もう少しそういう区別がつくように日本語を使って、別に英語を使えというわけではなくて、何をするかが明確に分かるような用語を使っていただいたほうが、紛れが少ないかと思います。
事務局（加藤）： ありがとうございます。おっしゃるとおりです。
事務局（楠）： 大事なところだけれども、みんなが片仮名を使っているところは大体良い日本語がないから。IssuingとProvisioningと極めて重要なお話をされていて、ここが漢字にできると、それ自体、大変なアウトプットだなと思います。大事なところです。
中村健一委員： 認証と発行は怪しいですよね。
事務局（楠）： 怪しいですよね。認証と認可も怪しいし、その手のものがこの世界は多いですよね。
小岩井委員： 小岩井でございます。方向性がずれていたら補正していただければ嬉しいのですけれども、VC発行プラットフォームというのが具体的にイメージがついていなくて、例えば、これはどこかの国ないし国が認めた何らかの公的な機関が、信頼できる第三者として、国として1つ立ち上げる想定をされているのか、もしくは、民間として、どこかの企業が複数存在し得る場としてこれを想定しているのかというところも含めてお伺いしたいです。
事務局（加藤）： 前提が補足できておらず失礼いたしました。前段でおっしゃっていただいた行政のほうで用意する考え方です。
小岩井委員： そうだとしたときに、それを実現するときに、本当にこれはVCが必要なのですかというところに戻ってしまうような気がしていました。結局、今回の課題としては、行政と民間の間の情報のやり取りが大変だから利用者を介してやろうという話になっているのが前提なのですけれども、VC発行プラットフォームを国として1つ用意して、そこと企業が連携されて、さらに、そこと自治体が連携されるということであれば、そこは、ここでご提案いただいているとおり、直接、プラットフォームから自治体にそのデータを連携していただくというのが実はできてしまうのではないかなと思ったのです。
事務局（加藤）： 非常に大事なご意見だと思います。まず1つ、VCとしてVerifiableであるということがメリットとして生きてくるであろうという点はあると考えております。それから、資料のほうでも、②③の課題のところで記載させていただいておりますけれども、保育所への入所等において就労証明書が自治体に渡っていくわけですが、そのときに企業の実在性の確認や、証明書自体の非改ざん性の検証がニーズとしてあるといったところで、そのようなニーズに応え得る技術を有した媒体としてVCというものが活用し得るだろうと。この2点が大きいのかなと我々としては考えているところでございます。
事務局（楠）： 今のご指摘はもっと大事な話をしていて、つまり、国のエンティティ同士で信頼できる経路しか通っていないのであればVCは要らないよねと。つまり、間に人が介在したり、信頼できない経路が挟まったりするから、そこで保育所に有利に入れるよう書き換えるリスクをなくすためにVerifiableにするのであって、これで言うと、VC発行プラットフォームからマイナポータルに直接API連携するのであれば、単に最初からAPI連携をすればよくて、VCは要らないというご指摘になる。
中村健一委員： もう一つ踏み込んで。そうなると、要するにトラストポイントは、VC発行プラットフォームになりますよね。Verifiableである必要があるのは、各所属企業が発行元になったときに、この発行元が信用できるかどうかということが問われる話なので、トラストポイントをどちらに置くかによって話はがらっと変わってしまうかと思います。
事務局（楠）： この話をするときは、多分、主たる脅威が何かというところをきちんと語らないといけなくて、一番多いのは、企業の総務部ではなくて、本人が自分でエクセルを埋めて提出してしまうというリスクなのです。だから、このVC発行プラットフォームが、GビズID経由なり認証をしてくれて、ちゃんと会社として正当な代理権を持った者が就労証明書を発行している、これをVerifyしたいと。そこでVCを使えるのではないかという話だったのだと思うのですけれども、一方で、VC発行プラットフォームとマイナポータルが密結合して、APIで直接データが一気通貫で通るのであれば、そもそもVCは要らないのではというようなご指摘をいただいているということですよね。
中村座長： では、﨑村委員。
﨑村委員： 2点あります。さらっと読んでいたときに、このプラットフォームは複数あるのだと思っていたのですけれども、1個だとすると極めて中央集権的な仕組みでございますね。IHVの思想の全く対極にあるものだと思います。そうなったとして、僕はそれはどうかなと思うのです。大きい企業などは自分でちゃんとVCを発行したいと思うのでどうかなと思うのですが、それと同時に、もし、そのような密結合でやるのであれば、ほかのリスクも考えたほうがよくて、極端な話、プラットフォームが発行する、特に直接発行するものは署名がかかっていないほうが良いです。署名がかかっていると、それの転用リスクというのが出ますから。署名がかかっていないデータだったら、直接受け取った人しかそのデータを信用できない。何を言っているかというと、要は、このマイナポータルはVC発行事業者から受け取ったということが確実に分かるので、そこが発行したデータだということは知っているわけですよね。そこから、例えば、何らかの経路でそのデータが再利用されるというようなリスクを考えると、署名がかかっていないほうがその再利用リスクは低くなる。提示された人は、署名がかかっていないから信頼できないから信じないよねという話になるので、そういう話はあり得ると思います。
ドイツなどでeIDAS 1.0で署名付データを出さなかったのは、それが結構背景にあって、受け取った人がそれを勝手に再利用する可能性というのを考えて署名をつけなかったらしいのです。今、eIDAS 2.0ですごくHolder Bindingにこだわっているのは、その再利用リスクを下げるためです。このAPI連携で、①のようなプラットフォームからマイナポータルに直接VCを発行するのであれば、当然にしてHolder Bindingはできないので、ドイツが懸念していたような再利用リスクというのは顕在化するわけですから、そのことは考える必要があろうかと思います。
事務局（楠）： 全く同じ議論が実はマイナポータルのときにもあって、あえて自己情報APIのPDFとかCSVに、最初、署名を入れなかったというのは背景にそれがあったのですけれども、現実には、その後、ダウンロードしたものをアップロードさせるような電子申請もあるかもしれないので、なかなか意識が伝わるというのは難しいなというのはあるのです。大事な点だと思います。
﨑村委員： そこでダウンロードされてアップロードされているものだということを、Relying Partyが理解した上で、そのリスクを引き受けるのだったら、それはRelying Partyの責任だから良いと思います。それを気にするべきでもないと私は思うのですけれどもね。ただ、その区別はつくべきだろうと思います。
富士榮委員： 先ほどの①②の議論は、①が入ることによって訳が分からなくなったので、①は多分消したほうが良いと思います。要は、Walletの話とかVCの話をしているのだったら、②の話にフォーカスして話をしたほうが、多分議論は分散しないだろうというのがまず1つ目です。
もう1つが、今のVC発行プラットフォームは1つなのですかという話です。こちらに関連するのですけれども、論点1に書かれているのが、先ほどのデータ構造の差異というものの話をされているのですが、プラットフォームが1つなのであれば差異が生まれることはないのではないかという気がしていまして、僕も複数あると思っていました。これが、行政が提供する共通プラットフォームなのであれば、議論ポイントの①、「行政で共通のVCの様式を策定する必要があると考えているがいかがか」と書いていますけれども、「そうでしょうね」という答えになると思ってしまうのですが、そういう認識で大丈夫ですか。
事務局（加藤）： ありがとうございます。そちらも補足が足りておらず失礼いたしました。VCの様式といいますか就労証明書の様式につきましては、自治体で策定ができるということになっておりますので、その仕様はプラットフォーム上でも生きているといいますか、適用されるものになっておりますので。
富士榮委員： では、VCプラットフォームとしては1つなのだけれども、僕は東京都に出したいから、東京都の様式を自分で選んでみたいなことをやらなくてはいけないようなプラットフォームだということでしょうか。
事務局（加藤）： おっしゃるとおりです。様式は自治体のほうで策定すると。
新崎委員： それをすると、ひどい場合は2,000個できるという話ですよね。
事務局（楠）： これは実務上結構しんどい話らしくて、結局、3パターンぐらいあるのです。要は、もともと自由に保育園に入るようなところであれば、それは別に標準の様式でよい。簡単に入れないところであまり人口が多くなければ、電話をかけて1個1個ヒアリングするとかもできると。非常に競争の倍率が高くて、例えば一々電話もかけていられないような場合というのは、できるだけ細かく書いていただかないとなかなか事務が難しいみたいなご事情があるようなのです。私も標準化すべきだと思いますけれども、そのためには業務から変えていくということをお考えいただくのだろうなと。
富士榮委員： そうなると、この場での議論である必要はなくないですか。
事務局（楠）： それは業務の話なので、VCとしてどうやるべきか、というところで、発行のプラットフォームが1つであるべきかというのは重要な問題提起で、実際には企業の総務部にIDを配らなくてはいけないわけだから、では、みんながGビズIDを使ってくれるのか、大企業の事業所単位で、万単位の従業員のところも含めて全部この仕組みで普及するのかと考えるとどうなのでしょうねというところは、いろいろご意見をいただきたいかなと思います。
富士榮委員： そういう意味で言うと、VCプラットフォームというのを1つ行政が用意すべきなのか、それとも、複数のものを受け入れるようにすべきなのかという議論だったら、この場で議論する意味があるのではないかなと思います。
事務局（楠）： ぜひ、そういったことをご議論いただければと。
中村座長： 幾つか確認事項が既に出ているわけですけれども、まず最初に、﨑村さんが質問した1番目のプラットフォームからマイナポータルに直接入れるというのも、我々の議論として、IHVモデルではないですよねと言われたら、そうですというお返事でしたけれども、それは、ここの場の議論として考えるのですか。
事務局（澤田）： 今のは、IHVモデルに該当しないのだったら、そもそもここの議論の設定から外れるのではないかというご指摘でしょうか。
中村座長： ここの議論の前提としてIHVモデルですよと、だからPDFとかを考えないのですみたいな、そういう前置きがあったと私は理解しているのですけれども、そもそも、その前提がそのとおりなのですかというところを最初に確認しておきたいです。
事務局（澤田）： そういう意味では、VC・DIWを使った場合の議論をしたいというのは、まずおっしゃるとおりで、API連携だとそもそもVCが要らないのではないか、IHVモデルと違うのではないかというご指摘もあり得るかと思います。そうであれば、②のWalletを介した場合のみという形でご意見をいただくのでもいいかと思っております。というのも、今回、提示しているユースケースは、あくまで関係者の業務状況などを踏まえて、今あり得る可能性を一旦提示したものですので、これを全部無理にこの場で拾い切る必要もないかなと考えております。このAPI連携というところが、混乱を招いてしまっているので、ユースケースの②、Walletを介した場合にフォーカスいただいてご発言いただければと思います。
中村座長： ありがとうございます。その辺の前提によって、今日の時間、大半がそこに費やされてしまうような感じもするので、そこは、ここの場としてはIHVモデルを前提として、Walletがどういう要件が必要なのかとか、そういうところの議論を中心にすべきなのだろうと思います。そうしたときに、先ほどから話題に出ているBindingをどうするのか、みたいなところが多分設計に関わってきて、そのVCの内容をどう標準化するかというところも、項目という意味では、ある程度、氏名など統一できるところもあれば、それ以外のところは自由度を用意しておけば良いというような気もするのですけれども、それに加えて、サブジェクトIDとか、そういうのは、ここで我々として何を入れることを想定するのか、みたいな話というのは、多分、IHVモデルの本質に関わってくる議論になると思うのです。eIDASとかで、ある程度方針というのが定められているというような仕様もあるにはあるけれども、我々として、それに関係なくなのか、参考にしながらなのか、議論をどう進めていくのか、検討をどう進めていくのかという話なのかなと思うのです。そうしたときに、名寄せの問題とか個人情報漏えいがどうのこうのみたいな議論を、我々としてというか、国として、デジタル庁としてどう考えますかというところを、多分、最初の設計として意識合わせをしておく必要があると思います。リスクとしてはいろいろなところで記載はされているわけですけれども、それは前提のところの設計がどうあるかによってリスクの想定が変わってくるので、それを、我々としては、こういうパターンもありますというのをまずは例示して議論を広げていくことをすればいいのか、ある程度、デジタル庁としての方針、こういう方向みたいなものがあるのだったら、まずはそれを、そのパターンに絞り込んだ上でここで議論をすればいいのかという、そこのあたりの議論の進め方についてもどうしたらいいのかというところが、何かもし想定があるのでしたらお願いしたいと思うのです。
事務局（澤田）： 今、どの部分についての確認かが理解し切れていないのですが。
中村座長： 例えば、VCを発行します。そこに、氏名とか人間が読めるような記載事項は入るとして、それ以外に、例えば、先ほどの議論であった、このVCは誰に対して発行されたVCなのですかというのは、機械としてBindingする情報というのが何かしら必要になるわけですけれども、そのBindingする情報として何を入れるのですかというところは、多分、3種類、4種類とかあると思うのです。グローバルユニークなPIDを入れるみたいなのもあれば、PPIDを入れるみたいなものがあれば、証明書でやるみたいなものもあるという、いろいろなバリエーションがある中で、その識別子、VCにそもそも識別子を入れるのか入れないのか。入れないという選択肢も当然あって、そうすると、個人認証と連携しながらVCを提示するみたいなそういうシステムを設計しないといけなくて、VCのIDとして何を入れるかという最初の設計が全体に影響を与えることになると思うのですけれども、そこの想定がどうなっているのかなというところが、まず重要なポイントだと思っているのです。
事務局（加藤）： ありがとうございます。先ほども軽く触れさせていただいた内容かなと思いますけれども、もちろん、今おっしゃっていただいたような課題というのは、我々、今後、就労証明書であったり住民票の写しのVC、今回、あくまで例としてモデルとして挙げているだけですけれども、VCの利活用を進めていかなければいけない、具体的にシステムの仕様を考えたり進めていかなければいけない立場ですので、その検討に際しておっしゃったような議論が必要であれば、その背景も含めて頂戴したいとは思っております。一方で、今回挙げさせていただいた就労証明書ですと、①から③まで課題を挙げさせていただいておりますけれども、そういった検討を進めるに当たって我々が特に懸念していること、その懸念事項が顕在化しないのであれば、それはそれまでだと思いますし、顕在化し得る懸念で、それに対して一定の手当が必要であるというのであれば、その手当の内容についてご議論いただく必要があるというところが今回の会議の背景というか設定目的だと思っております。特にご議論いただきたいのは、やはりこの①から③の課題に該当するのだろうと思っています。その検討に踏まえて、もしくは、加えておっしゃっていただいたような、例えば、もっと細かい議論が必要で、今、VCのデータの中身に関するようなお話を頂戴したものかと思っていますけれども、クレデンシャルサブジェクトをどうするのか、といった部分の検討が必要であれば、そこも踏まえてご発言、ご議論いただければなと思っているところでございます。
中村座長： ありがとうございます。最初のユースケースの議論の時間としてはあと10分ぐらいなのですけれども、もうちょっと確認をしておきたいポイントが2つぐらいあるのですが、7ページの③の対面で提示というところの想定が、どういうやり取りをここで想定しているのかが不明瞭なのです。画面を見せて確認させるみたいな対面なのか、対面だけれどもmdocみたいに、NFCとかでデータをやり取りして、そこでデータが正確にデジタル的に受け渡されるという対面を想定しているのかによって、ここも議論が変わってくると思うのですけれども、そこはいかがですか。
事務局（澤田）： そこも具体な詳細が、今、決まっているわけではおらず、恐縮なのですが、お時間が限られているので、そこがあったほうが議題のポイントが議論しやすければとは思うのです。正直、我々の今回のユースケースは、あくまで全て仮のものなので、仮にこういう設定だったとしたら、それぞれの論点に対してどういった技術的課題とかが懸念されるかという観点でご意見をいただきたいと思っております。ユースケースを細かく精緻に掘り下げるというよりかは、一旦、イメージで言える範囲でご意見をいただけたらいいなと思っているところなのです。
事務局（楠）： 今のサブジェクトIDをどうするというのは実はすごく大事な話で、このフローだと、結局、Issuingのところでは、要は、本人ではなくて会社がIssuingのトリガーを引いているから、会社が発行した就労証明書が確実に本人に届くようにするためには何か仕組みが要るよというのが中村先生のご指摘で、ここはちゃんと僕らが答えないといけない部分で、現状のフォーマットにはないわけですよね。基本4情報で、基本的には住民登録地、生年月日、氏名、性別の4情報でもって名寄せをしていく。これも非常にフラジャイルではあるけれども、みんながちゃんとマイナンバーカードで本人確認をしていればワークしないことはない。
いやいや、やはりサブジェクトIDは要るし、社会保障分野だからマイナンバーで良いのではないですかというご議論でしたら、番号法の見直しを検討する必要があるわけだし、それはプライバシーインパクト上、もっと別のものではないといけないでしょうというご指摘もあり得ると思います。このユースケースの場合、どういうものがサブジェクトIDとしてふさわしいか、あるいは、サブジェクトIDを設定しなくても、会社であればメールアドレスなりでもって、企業が発行したタイミングで本人宛てにメールを送ってリンクを踏ませるなりメールアドレスで名寄せをするとか、いろいろなサブジェクトIDの設定の仕方があると思います。そこのご意見というか、こういうものはサブジェクトIDにすべきではない、例えば、証明書シリアルナンバーとかは危ない気がするわけですし、マイナンバーもどきどきするわけですが、その辺はご意見があったりされますか。
﨑村委員： 1つクラリフィケーションクエスチョンなのですけれども、受け取り手は、この場合自治体に限られるのですか。
事務局（澤田）： はい。そのように考えています。
﨑村委員： それがまず前提として書いてあったほうが良いと思うのですけれども、その自治体において、これの提示を受けたときに、そのVCのサブジェクトが、今申請している人であるということは、どういう業務フローで確認することを想定されているのでしょうか。今、楠統括官がおっしゃったように、4情報を突き合わせますといった場合には、今度、その申請している人が、肉体が4情報とマッチしているということを何らかの形で確認する必要が出てきて、そうするとマイナンバーカードと一緒に出しますという業務フローになってくると思うのです。そうすると、データの中に入っているコアスキーマとして、証明書シリアルが入っているなら、それで突き合わせるという話になるし、4情報で突き合わせるというのだったら、そのコアスキームの中に4情報が入っていなければいけないという話になると思うのです。
事務局（澤田）： 逆に、どちらのほうが望ましいみたいなご示唆があれば。
中村健一委員： そもそも詳細な運用が分からないと。例えば、代理人を認めているか認めていないかによっても全然やり方が変わってくるので。
中村座長： 我々は、今日は2つのユースケースについて議論するということになっているのですけれども、それぞれのユースケースについて、こういうIHVのVCの設計が望ましいみたいなのを、それぞれについて何か方向性を出すみたいなことを我々としてはやっているのか、あるいは、あくまでもこの2つは題材であって、そういうものを踏まえたいろいろな手続が載るような1つのプラットフォームを我々としては目指そうという議論をしているのかというところも、どちらなのというところを意識を共有しておきたいと思うのです。
事務局（澤田）： どちらかというと後者の話で、ユースケース、あくまでこの2つ、就労証明書と住民票の写しを挙げてはいるのですけれども、議論の題材で、必ずしも、今、仮で示している設定どおり今後されるのかも分からない、決まっていないものです。あくまでほかの、例えば、この就労証明書というのは、民間企業が発行して行政が手続の中で受け取る書類の例として挙げているもので、ある種、ほかの証明書においても参考になるような、後の在り方や想定される課題がどこにあるかという議論をしたいと思っています。
先ほど中村先生がおっしゃっていた1つのプラットフォームを目指すというのは、今回の例ですと、1つ手続プラットフォームがあるというものでしたけれども、ほかの証明書では必ずしもそうではないので、それもあくまでここでの、この場合の手続の過程であるというところです。
中村座長： そういう意味では、プラットフォームと言っているものがどういうものなのかというところも、多分いろいろな捉え方があると思うのですけれども、例えば、eIDAS 2.0で規定される標準にのっとったIHVのシステムがあって、それを使うと、その上でいろいろなVCが運用できますよみたいなものがあるとして、同じようなものの日本版を目指すという議論なのか、いやいや、そこはそうではなくて、幾つかの標準というのをまた別に考えて、それは、もしかするとプラットフォームとしては1つにならないかもしれなくて、いろいろな手続ごとにプラットフォームができるかもしれませんよという方向なのか、そこもいろいろな考え方があると思うのです。
中村健一委員： このプラットフォームは、役割的に言うとブローカーにしか見えないのです。だから、ブローカーという役割なら役割で、ブローカーとしてあるべきガバナンスモデルは何なのかというのが定義できるので、それならそれで、そう言ってしまったほうがモデルは作りやすいかなと思います。プラットフォームは、そういう意味では非常に漠然としているので、もうちょっとロールモデルで言うとどんな役割をするのかと言ったほうが定義はしやすいと思います。
﨑村委員： ここでプラットフォームがブローカーというのはそのとおりだと思うのですけれども、端的に言うと、企業が発行した何らかの形の証明書を受けて、それに基づいて自治体がコンシュームできる派生証明書を発行する人ですよね。
中村健一委員： そうです。
小岩井委員： 今回、あくまでIHVモデルをどう使うかというところのユースケースの例としてこちらをご提示いただいていると思っていて、そういう意味だと、就労証明書のことだけを考えると、もちろん提出先は自治体になりますけれども、すごく似たような書類で在籍証明書みたいなものを企業が発行して、例えばそれを転職活動のときに使わなくてはいけないとか、そういうことも似たようなユースケースとしてあり得ると考えたときに、受け手は自治体だけではないですよねという話になってくる。先ほどのID、サブジェクトアイデンティファイアーをどうするかというところに、マイナンバーを使えないのではないかという話も出てきてしまうかもしれないですし、あと、旧姓の話とか別名の話とかがいっぱい出てきてしまうと思うので、そういうところも踏まえて、あとは、そのように幅広く使えるようにしておかないと、企業としてもそれをやるモチベーションが出てこないという話もあると思っています。
あと、今、議論が出ているとおり、プラットフォームというところが分かりづらかったかなと思っているのですけれども、ただ、別で、チャットの中でも話が少しあったのですけれども、企業のサイズとか企業の業態によって、どのようにこういう書類が発行されるのかが全然変わってくるので、プラットフォームというのも1つで良いのかな、というのも少し思います。もしかしたら、企業が自分で秘密鍵を持って自分で発行してしまったほうが楽という企業もあるかもしれないですし、小さい企業だったら、それを含めてどこかにお任せしたいというところもあると思います。そのように複数出てくるということを考えると、やはりIHVモデルでやったほうがうまくいきそうな気がしますし、そうしたときに、この①②③の課題が、今度、顕在化するなと思ったのです。漠とした意見ですけれども、以上です。
中村座長： では、板倉さん。
板倉委員： 今のご意見に追加するところでもあるのですけれども、私もやはり受け取るのは自治体だけではないと、多分皆さんも思われていると思っていて、しかも国内だけではないと思っています。例えば、ほかの国のビザを取るときに、ほかの国に対して提示したり、大使館に提示したりみたいなケースとかもあると思うので、多分、相互運用性は、何に対する相互運用性かみたいなところもあるのかなと思うので、このユースケースはお題としてはいただきつつ、多分、将来的な波及可能性というか、全体感を見て議論しないといけないのだろうなと思っています。
プラットフォームのところも、やはり1個のプラットフォームは私も現実的ではないと思っていて、所属企業が発行するケースは普通に大企業とかだったらあると思うのです。あと、プラットフォームといっても、新たなプラットフォームなのか、既存の保活情報連携基盤みたいなものをイメージしているのか、就労証明書作成ウェブみたいなところなのかによっても変わってくると思うので、そういったところを、決まっていないところは論点として議論できればいいのかなと思っています。
中村座長： では、中村委員。
中村健一委員： eIDASの例がありましたけれども、プラットフォームというからには、ツールボックスアプローチで、このユースケースの場合はこのツールボックスとこのツールボックスを使って、このようにやればセキュリティー問題とかプライバシー問題はこの分野ではクリアできます、この用途の場合は、これとこれを使えば良いという意味でプラットフォームという言葉を使われようとするならありかなと思います。
新崎委員： データフォーマットとかその辺を一定の範囲に収めようと、標準の中に収めようとするのであれば、名称が何になるか分からないですけれども、こういうような仕組みは要るだろうなと思います。ましてや自治体が決めて良いというのであれば、何かコントロールするような枠組みは要るだろうなと。使い道も、おっしゃっていたとおり、今、泥縄で調べてみると、賃貸を借りるときにも就労証明書が必要だったり、ほかでいろいろ使う、民間に対しても提出することがあって、それはありますよねと。そうすると、Walletを使ってオンラインなり対面なりで民間に対して提出する場合もあるだろうと。
あと、やはり自動化するときに、もともとの趣旨が、バリエーションがたくさんあるものを自動化していきたくて、自動化をするに当たってVCを使いましょうということだったら、VCを何かコントロールしなくてはいけないのではないかなという気はしています。フォーマットとかそういうデータとかプロトコルとか、その辺は何か仕組みが要るのではないかなという気がします。
事務局（加藤）： おっしゃっていただいたように、まだ考えないといけないことはたくさんあると思っております。行政のほうでVCの発行に対して共通で一定の何かしらのものを設けるということに関してもその1つと考えます。おっしゃっていただいたように、例えば海外での利用を想定するというようなことも、今後必ず検討していかなければいけないと思いますけれども、いきなりいろいろなユースケースで使われるもの全部を手当てするというのはなかなか難しいと考えております。今回であれば、保育園の入所という手続において自治体で検証されるというユースケースにおいて、VCが使えないかというところにスコープを絞っているわけです。
小岩井委員がおっしゃったような、インセンティブみたいな問題も含めて、いろいろなユースケースの形態があり得るわけで、どこから手をつけるのかみたいなことも必ず決めていかなければいけないと思っています。
中村健一委員： 逆に、絞らないと議論が発散してしまうので、トライアルをやるのだったら、例えばこの用途でといって決めてしまって、まずはそれでうまく回るかどうかというのをチェックする方針で良いと思います。
佐古委員： 今までなかった観点で1つ意見です。
そもそも、就労証明書は何を証明するものなのかということにたちかえると、遠い将来の話かもしれないですけれども、本来は、所属企業と従業員の関係を示す全ての情報、例えば就労契約書みたいなものがVCになって本人が持っていて、その中から本人がセレクティブディスクロージャーで、いつ契約しましたとかそういう情報を自治体に見せることによって、就労証明になると思っています。自治体が就労証明書として要求する記載内容がいろいろ違っていても、VPのセレクティブディスクロージャーで調整できるというのが理想かなと思いました。以上です。
﨑村委員： 逆に、それを考えると、プラットフォームを国が持って、それを中央集権的にコントロールするということになり、極めて気持ち悪いです。
事務局（楠）： 現実問題としては、負担を下げようと思うと、データを持っているところに口を置かないといけないので、仮に国がそういったものを提供したとしても、お付き合いしてくれるのは、ある程度、よほど人がいっぱいいて入力をしてくれる場合とか、中小企業で設備投資に対してセンシティブである人たちになってくるのかなと。結果として、複数プラットフォームでインターオペラビリティーを確保していくのであれば、VCは有益であるという議論は多分あるのだと思うのです。
一方で、新崎さんからご指摘のあった、型をつくっていこうとすると何がしかシステムが要るのではないかというのは結構気にしている点で、つまり、VC発行が大変だからプラットフォームをつくるべきという議論が出てくるわけで、エクセルのフォームをちょこっといじるよりも、VCのスキーマをいじるのは、今のところきっと結構大変なのです。多分、大変と思っている人が多いから一生懸命考えて、こういうプラットフォームが要るのではないかという議論が出てくると思うのですけれども、これは、スキーマフルな文書がずっとたどってきた歴史で、どうなのでしょう。エクセルと同じぐらい簡単にVCが発行できれば良い話なのか、どういう方向に行くのだろうなと。
中村健一委員： 個人的な意見かもしれませんけれども、昔は物理的に発行した印刷なりチップに入れるなりである程度まとめて発行しておいて、それだと余計なデータが取られるからというのでセレクティブディスクロージャーになっているのですけれども、これは、データベースからリアルタイムに必要なものを発行できるようになったら、はっきり言ってセレクティブディスクロージャーなどは要らないのです。むしろ、どこがきちんとデータベースというか、データとしてきちんと持っていて、それに対してリアルタイムに必要なものを発行できるというのが、中長期で見ると必要とされるものだと思うのです。そうすると、どこかで変換するというよりも、やはり大元で何を聞かれてもいいようにデータを持っておかなければいけないという方向に行くのではないかなと思います。
中村座長： そろそろ時間なのですけれども、もう1つだけ確認をしておきたかったことがあります。10ページのところの、署名代行事業者の署名鍵というのが下に出てくるのですけれども、ここは、代行事業者というのが署名鍵を1つだけ持つというイメージなのか、署名代行をさせるのだけれども、当然、就労証明を発行する企業ごとに鍵を別々に持って、それでIssuerをちゃんと検証できるようにするということも一応想定範囲なのかというところは確認しておきたいなと思うのですけれども、そこはイメージがあったりするのでしょうか。
中村健一委員： eIDASのリモート署名だと、リモートHSMに、この人の鍵はこれ、この人の鍵はこれと複数持って運用します。
中村座長： その意味で考えると、それぞれちゃんと鍵を変えるというのをやるべきだと思うのですが、ここの書き方だと、それはあまり考えていませんみたいに読めてしまうので、そこがちょっと気になったかなというところでした。
事務局（澤田）： 企業それぞれが分かる形の鍵であるべきだというご意見でしょうか。
中村座長： Issuerの署名にそれなりの責任を持たせるのであれば、そこはちゃんと区別しないといけないだろうと思います。
中村健一委員： 要するに、その鍵は、ハンコで言うと社印に相当するわけなので。
﨑村委員： それが先ほど聞いた話なのです。誰の鍵ですかと。
小岩井委員： それが社印である限り、それが、その会社の社長が押そうが総務部長が押そうが、代行先のBPOの会社の人が押そうがコンセプトとしては変わらないという話ですよね。
中村健一委員： そうです。普通は、署名権限のある人に署名して、と言うと署名するようになっているわけですよね。
小岩井委員： なので、そういう前提において、代行事業者の署名鍵みたいなコンセプトというのは、考える必要はないということですよね。
中村健一委員： ただ、代行事業者がというと、その会社がということが分からないのですよね。代行がプラットフォームを持っていたとしても、この鍵だったらこの会社のものだというのが分かれば構わないわけで。
事務局（楠）： お伺いしたい点なのですけれども、例えば、今、いろいろな企業の人事総務システムとかがSaaSにあったりすると。そこのシステムに入っているTLSの鍵というのは1個ですよね。鍵に入っている、証明書に入っているアトリビュートというのが大事なのかという点をお伺いしたいのです。逆に、少なくとも代行事業者の実在性が確認されていたならば、それが正当な権限者によって署名された、認証されたものであるか否かということは、その事業者に聞けば分かることなので、それでもなお、企業ごとに異なる鍵で署名をしていねばならないのか、そういうところはぜひよくご意見をお伺いしたほうがいいのかなと。
例えばですけれど、これはどちらかというと、この後の住民票の写しの話ですけれども、マイナンバーカードは、今、交付しているのは市町村だけれども、発行はJ-LISに集中をしていますし、パスポートも昨年から国で集中発行している。だから、脅威に対して対応できるのであれば、鍵が会社によって違う必要があるのかというのは、議論としてあり得ると思うのです。
中村座長： そこは、Verifierとして何を検証すればこの署名が正しいと認識するのかというのと、共通の鍵を使う場合に、そのガバナンスはどこが担保するのか、という制度の話になっていくと思うので、技術としては別にどちらでも良いので、あとは制度で頑張ってということになると思うのです。だから、それを、この段階で鍵は1つでいいですよと決めつけるように読めてしまうのはまずいということであって。
中村健一委員： 鍵が1つというモデルもあることはあるのです。この鍵で署名しているものが信頼できるからと。
﨑村委員： その鍵が非改ざん性を保証していて、その代行事業者が正当に元の発行主体から委託を受けているという関係性をどのように証明するかというのがポイントになってくると思っていて、そこが分からないシステムがそれなりにあるのです。
中村座長： だから、透明性を担保するかというところで、ログを見て、会社の何かを調べれば分かるというのだったらそれでも良いのかもしれないですけれども、それは制度でそういうことができるようにしておかないといけないわけで。
中村健一委員： 鍵のサブジェクト、公開鍵の証明書だったら、サブジェクトが信頼できれば良いのであって。
新崎委員： でも、両方とも実在証明が要りますよね。代行も就労先も両方とも。
﨑村委員： もちろん実在証明が要るし、それから、代行事業者に対してちゃんと委託をしているということの証明も本当は要りますよね。そうやってトラストチェーンをつくっていかなければいけないので。
中村座長： そういうところで、またこの議論は次も出てくるような気がするので。
事務局（澤田）： 後半のところで署名のところも取り上げているので。
中村座長： では、後半をお願いします。
事務局（加藤）： では、住民票の写しの話に移らせていただければと思います。
次に、行政が発行して民間が受け取るユースケースの例です。住民票の写しVCについてですけれども、ここでもユースケースの前提についてお話しさせていただければと思います。まず用途ですけれども、自治体から発行された住民票の写しVCを、本人が民間事業者に対して世帯情報を証明するために提示する用途というところで定義しております。VCの発行方法はオンライン発行のみとしておりまして、発行の請求者も本人のみといたします。また、記載事項は、世帯全体のものを対象として、個人番号については紙の住民票と同様に発行時に記載有無を選択可能といたします。一番下、VCの提示方法については、オンライン提示、対面提示、いずれの利用も可能といたします。選択的開示も可能として、同一のVCを複数のVerifierに提示するような使い回しについても可能といたします。
続いて、本ユースケースにおいて想定される課題とその解決策について、皆様にご議論いただきたい事項として説明いたします。こちらは4点ございます。
1点目が、偽造・改ざんを検知するための署名の課題についてです。住民票の発行主体は各自治体の市区町村長でありますけれども、デジタル署名をVCに付すに当たり適切な手法については検討する必要がございます。議論ポイントとしては、複数のアーキテクチャーが想定されると思いますけれども、住民票の写しVCの実現に適した方式は何か、また、その署名方式を決定するに当たり、その理由である重要な観点があると思いますので、ご議論を頂戴したく思っております。
2点目が、なりすましを検知する手法の課題です。こちらは、一番下に補足として書いておりますけれども、「デジタル技術を活用した効率的・効果的な住民基本台帳事務等のあり方に関するワーキンググループ」の中間取りまとめでも触れられている課題でございますが、VCの提示者がVC上の対象者本人であり、なりすましではないことを確認するために、例えば生体情報とのBinding等も含めて実効性・コスト等の観点も踏まえ妥当な手法について検討する必要がございます。ここでは特に、VC提示時のWalletの操作者がVC発行時の人物と同一かといったところを確認するために、Walletの当人認証等も含めて何が妥当かについてご議論いただきますようお願いいたします。
続いて、3点目ですけれども、Walletの形態による利用環境の課題とさせていただいております。ネイティブアプリなどのWalletの場合ですと、例えばスマートフォンを保有しない利用者が使えないとか、ハードウェアやOSの仕様に依存する、プラットフォーム事業者の個別対応が必要になる等の課題があると考えておりますけれども、住民票の写しVCの普及促進をするために、このようなデバイス環境を問わず利用可能なWalletの在り方は何かと。例えば、Web Walletというのが選択肢に上がる一方で、オフライン利用やWallet Bindingの手法をどうするか等、懸念、検討事項があると認識をしておりまして、これらWeb Wallet実装時の重大な懸念事項及びその解決策についてご議論いただきたいと考えております。
最後に4点目ですけれども、安全かつ便利なWalletの提供への課題です。Walletの堅牢さとか相互運用性を評価する仕組みというのは現状においては存在しておりませんでして、各Wallet ProviderがそれぞれでWalletを開発している状態でありますので、定量的な安全評価及び相互運用性の確保が十分であるかという議論があるかと考えております。これに対して、住民票VCの普及促進に必要な安全性、相互運用性を確実に確保するために、例えばコンフォーマンステストのようなものが必要ではないかと。ただし、その対応コストの増加を防ぐためには、要件を最小限にするべきではないかと考えておりますけれども、その妥当性とか代替策の有無についてはご議論いただきたいと考えております。
以降は、それぞれ課題別に具体的な課題や議論ポイントについて示しておりまして、偽造・改ざんの検知のための署名の課題につきましては、今、表示しておりますけれども具体的に想定し得るアーキテクチャーのイメージを記載しております。例示したアーキテクチャーについて何が適しているか、どのような観点でアーキテクチャーを決定すべきかについてご議論をお願いいたします。
続いて、なりすましを検知する手法の課題についてですけれども、特に提示されるVCの本人性を担保する観点において、ここで例示しております方法の妥当性についてご議論をお願いいたします。
3点目、Walletの形態による利用環境の課題についてですけれども、先ほどご説明差し上げましたとおり、ネイティブアプリ型とWeb Wallet双方で課題と懸念事項、整理すべき論点を記載しておりますので、それぞれの論点についてご議論いただければと思います。
最後、安全かつ便利なWalletの提供への課題についてですけれども、Walletの堅牢さ、相互運用性を評価・確保するためにコンフォーマンステストが有用であると考えられる一方、懸念事項もあると思いますので、ご意見賜りますようお願いいたします。
では、この住民票を題材とした想定課題、それから、解決策についてご議論いただければと思います。再度、進行を中村座長にお渡しさせていただきますので、中村座長、よろしくお願いいたします。
中村座長： ありがとうございます。そうしましたら、後半のユースケース、2つ目ですけれども、まずはこの内容について、もし質問等がございましたらお願いいたします。
栗山さん、お願いします。
栗山委員： まず、14ページの「証明書の真正性確保」のところなのですが、この住民票の写しVCというのは、紙と同じ法的効力を持たなければならないのかというところがあまり理解できていませんで、記載した趣旨を具体的に教えていただけないでしょうか。
事務局（澤田）： ありがとうございます。住民票をVCとして活用するときに、果たして、どこまで紙との同等性が求められるか、ここについては、ここで明らかにするものではないのですけれども、ここはあくまで行政が発行する何らかの証明書をVC化して、今まで紙で発行したものに代えてVCで発行するというときには、紙のときと同様の効力とか用途が使えないとそれは困るであろうという一般論の下に、一旦このように書いているものです。
事務局（楠）： 補足をすると、もともと要望として、住民票の写しの電子交付を認めてほしいという声が市区町村から出ていて、それを受けて総務省の検討会において検討が進んでいると。その中で、署名付PDFで良いのではないかといったような議論もあったのですが、それでは駄目であるという話になったと。今年の春頃だったと思います。何で駄目かというと、既に電子化されている課税証明書というのは、そんなあちらこちらで使うものではないが、住民票の写しというのは、結構いろいろな局面において身元の確認に使われるものであって、それ自体は身分証ではないけれどもかなり重要な身元証明書類の一種なので、受け取ったものをほかの人に提示できるみたいなことが安易にできてはいけないと。かなり具体的に、今回あるような要件について提示をいただいているので、今のVerifiable Credentialでこういうことを充足できるのかというところで例として出させていただいているという背景があります。ここではセレクティブディスクロージャーがあったほうが良いのではないかみたいなところも含めて、かなりご意見をいただいたという経緯があって、それが、今、中間報告では、これからデジタル庁が考えるよねとなっているというような背景があります。
栗山委員： ありがとうございます。追加で質問になるのですが、私も総務省のものはざっと読ませていただいたのですが、身元確認に関しては、マイナンバーカードの公的個人認証を活用していくべきという話になるのかなと思っていまして、この住民票の写しVCに関しては同等で良いのかという議論があるのかなと思ったのです。あくまで世帯情報を証明するという観点において扱うという形になるのかなと思ったので、ここの書き方と、住民票の写しのVCというユースケースを使うのであれば、身元確認は違うよというところは明確に書いておいたほうが良いのかなというところでコメントをさせていただきました。以上です。
事務局（楠）： 問題は、慣習法も含めて、別に住民票の写し単体で身分証として認めているわけではなく、住民票の写しが、広くそういった、それを本人確認書類とは言うべきではないとして、何がしかの身元確認であれ属性証明で使われているのは法定されているものではなくて、社会の慣習であったり事実行為としてそういう使われ方をしているから、それが転々譲渡されるリスクに対しては対処されるべきであるというのが基本的に総務省における議論だと理解をしていて、ここでは、それが住民票の写し単体で身元証明になっているという前提では議論をしていないということかなと思います。
中村座長： そうすると、その議論を踏まえて住民票を電子化するに当たっては、これは身元確認、本人確認をするために使うものではないですということを明確にした上で皆さんに使っていただくようにするというところを何か具体的に書いておくのが良いのかなと思うのです。なので、本人確認、当人確認という機能と、記載内容の属性情報の証明の用途というのは明確に我々としては切り分けた上で、ここでは住民票の内容というのは、単に属性情報の証明の用途であると。それを本人が提示するかどうかというのは、また別の手段を組み合わせて確認するなりすればよくて、そこを明確にちゃんと検討結果として書いておけば良いみたいなことになるということですか。
事務局（澤田）： 今回の議論のユースケースの想定としては、あくまでも世帯情報、属性情報を示す用途で住民票の写しを使う場合にどうかということでご意見をいただければと思います。
小岩井委員： 今の話の流れに沿っての話なのですけれども、翻って、今回、新しく住民票の写しと同じ効力を持つものとしてVCをつくったときに、それが本人だけが提示可能にするということをしたせいで、逆に、今、事実上、住民票が身元確認の方法として通用してしまっているという、そこをさらに助長するようなことになってしまうのではないかなというところをすごく気にしていまして、そこはかなり気をつけて考えなくてはいけないなとは思いました。
中村座長： ありがとうございます。そういう意味では、Walletからどう出すかというところの設計だと思うのですけれど、それを、単に記載内容をいろいろな人に見せる、提出するという意味で、本人であるという情報はつけずに渡すという方法と、本人から提出しているよということをちゃんと証明できる形で渡すというのと2つの手段が提供されていて、それがちゃんとユーザーが分かりやすく使い分けられるようになっていれば良いのかなと思うのですけれども、そうはいってもきっと難しいかなという気はします。
ほかに何かありますか。富士榮さん。
富士榮委員： 一応、ただし書のところに、ユースケースの妥当性については議論の対象外とあるので、多分、技術の部分にフォーカスして、何が結局、事務局が確認したいのかという話をもう1回確認させてほしいのです。議論を聞いていると、これはユースケースと妥当性の話が大半になってしまっているような気がするので、論点を挙げていただいているのですけれども、これは技術的に、具体に何を確認したいですかというのをもう1回教えてもらえますか。
①は、どういう署名アルゴリズムが良いですかということを聞きたいということですか。
事務局（加藤）： はい。例示しているようなアーキテクチャーについては妥当性を評価する必要性があると考えておりますので、この例示しております内容についてはご意見を頂戴したいと考えております。
富士榮委員： 2つ目は、クレデンシャルとHolderのBindingをいろいろな場面でどうやって確認するのがいいですか、それを、かつ、一気通貫でやるにはどうしたらいいですかという方法を聞きたいのですね。
事務局（加藤）： 資料の右側に「懸念されるなりすましの例」という形で記載をさせていただいておりますけれども、これが我々が懸念しているところの住民票のなりすましの顕在化の仕方といいますか、例になります。これに対してどのような手当が考えられるのかといったときに、一般的なWallet Bindingみたいなところでは充足していないのではないかというところがまず考えとしてありまして、追加の対策が必要であるといったところで、ここでは当人認証に用いる情報を用いたBindingといったところで追加対策を2点挙げさせていただいております。発行時にWalletが操作者を当人認証するといったところと、提示時もWalletが操作者と当人認証できなければならない、発行時と一致しているかというところを確認しなければならないというその2点は挙げさせていただいておりますので、ここも妥当な手法は何かというような書き方をさせていただいていますけれども、ご意見を頂戴したいと考えておるところです。
富士榮委員： そういう意味で言うと、ユースケースは例として挙げていただいているのですけれども、今の2点を聞いても、確認したいのはやはり技術のところなのですよね。
事務局（加藤）： おっしゃるとおりです。
富士榮委員： 分かりました。そのテイストで、この後、確認というか質問をしたいことがあれば出したいと思います。
中村座長： そのまま続けると、②のところの、なりすましというのがどういう想定のなりすましなのかというところもちょっと曖昧なのですけれども、本人が提示しているのかという意味合いでのなりすましもあれば、記載の内容についてのなりすましというところもあって、記載内容についてなりすまし、偽造・改ざんも含めた話になりますけれども、そうしたときに、それをどう提示するのか、そこは、多分Issuerの署名があるのだから、その署名が正しければ、内容についてはなりすましがないと思えばいいのかというところ。だから、ここで言っている「なりすまし」というのが、何に対して懸念したなりすましということを言っているのかというところが分からなくて、ただ、ここのユースケースでは本人確認は想定していませんという話になっていたので、そうだとすると、この「なりすまし」は何というのがよく分からなくなっているのです。
事務局（澤田）： 資料で、ちょうど赤文字になっているところなのですけれども、ここでは第三者が持ち主になりすましをする。そこのVCの内容自体は正当なものであるという場合についてのリスクの話です。
富士榮委員： Issuanceをしたときの人とプレゼンテーションするときの人が変わっていないよということだけを確認すれば良いのですよね。
事務局（澤田）： はい。Holder Bindingがどのようにできる、どのようにされ得るべきか。
事務局（勝原）： スマートフォンのPINロック解除みたいなものをもって同一であると確認するレベル感、あるいは毎回何らかJPKIとかそういったものを使って、Issuanceのタイミングと同じ身元確認みたいなものを繰り返して提示をするのかという、そのレベル感みたいなところの議論を、ぜひご意見を伺いたいという内容です。
富士榮委員： 普通に考えるとシングルサインオンをせよという世界の話ではないですか。今、勝原さんがおっしゃっていた後半の議論というのは、少なくともVerifierが依拠するというモデルにおいては必要ですよね。Verifierが依拠しない、Verifier自身が確認するというモデルであれば、例にも書いていただいていますけれども、生体というのが顔写真なのかどうか分からないですけれども、クレデンシャルの中に書いてある生体の情報と、プレゼンテーションする人の情報を直接Verifierが観測して同一性を確認するという方法になり、これを充足できる方法を持ったクレデンシャルを発行せよというお話のこの2択にしかならないのではないかと思ってしまいます。
中村座長： 我々の議論するリスクというのは、そこまで厳密なプレゼンターの本人確認というのを求めているのかどうかというところは、我々として判断する話ではないとは思うのですけれども、そこまで想定して我々は議論すべきなのかどうかというところは、まず前提として共有しておきたいです。あくまでもスマートフォンのそういう生体認証の機能というのは、それが正しく使われるということを前提としてシステムが成り立っているのですよと。それが、意図的に悪用されても、それは我々の責任ではないと思うのか、そこでさえ、そういう悪用ができないような技術的な対応を我々は考えておかないといけないのかというところで、多分、システムの設計は変わってくると思うのです。
事務局（楠）： 何がしか前提を置かないと議論にならないと思うので、それはどういう条件の下で何が成り立つというところをご議論いただければ十分なのかなと。スマホの貸し借りとか生体認証を突破されるとか双子とか、そういう議論は別に分けていいのかなと思います。例えばですけれども、直近で私自身が2年ちょっと前に悩んだ、まだ解けていない問題で言うと、入社時の番号確認というのがありまして、このときは本人のマイナンバーだけではなくて被扶養者全員分のマイナンバーが必要となります。これはマイナンバーカードだけでは難しくて、紙の住民票が必要ですというような場合になります。戸籍も住民票もそうですけれども、戸籍に関しては戸籍情報連携システムができましたけれども、住基ネットというのは実は世帯の情報は持っていないので、今は、国機関同士であっても、実は家族の話などを調べようと思うと紙にフォールバックするということが結構あります。そういうのも含めて、やはりデジタル化しないと、結局紙がないと何も前に進まないというのは実は変わっていなくて、ここは何とかデジタル化したいと。そういったときに、ただ、署名付きPDFでは不十分であると総務省の検討ではなりましたので、では、彼らが心配していることに対して、きちんとテクニカルに説いて、こうやればここまではできますよというところをご議論いただけると大変ありがたいなというところはあります。
中村座長： 関連して、例えば、今日のユースケースの中で、マイナンバー入りの住民票というのも事例としてあったように思いますけれども、それの取扱いについて、ある程度厳しい取扱いを技術的に考える必要があるのか、そこは、もう普通のマイナンバー記載なしの住民票と同じようにして運用に任せますという観点で議論をすればいいのかという点については何かありますか。
事務局（楠）： 紙とデジタルにおいて、紙と比べてデジタルは複製が容易であるという懸念は広く共有されている中で、14ページ目にあるような「本人だけが提示可能」など、こういった要件を満たさない限り電子交付は適当ではないというような議論が、これまで総務省において行われていて、これらの要件を満たすということを簡便に実現できるのかというところが論点です。どうしてもHolder Bindingは対応しているビューアが限られてしまうなど、環境が相当制約されるので、例えばブラウザとFIDOだけでできるかどうかなど、一般的な世界でどこまでができて何が難しいかというところは、ぜひ技術的にはご意見をいただきたいところです。
事務局（澤田）： オンライン参加で、今日、中村龍矢委員と南井委員に参加いただいていて、少し前にチャットでもご意見を頂戴していたのですけれども、お二人からもぜひ口頭でご発言いただければと思います。
南井委員： 先ほどのチャットは平場で大きく話すような話でもなかったため、チャットで書いたというところがあります。現状、特に平場でのコメントは特にございません。
中村座長： では、また何かありましたらお願いいたします。
では、佐古委員お願いします。
佐古委員： 今月開催される「暗号と情報セキュリティシンポジウム」に論文を書いたのですけれども、このケースこそまさしくマイナポータルが出てきてほしいなと思っています。WalletがVCを持つものなのか、Holder Bindingの秘密鍵を持つものなのか分からないのですけれども、マイナンバーカードがHolderの秘密鍵を持つことにしてしまえば、マイナポータルにVCがあって、マイナポータルからVCをダウンロードして、自分が持っているマイナンバーカードの秘密鍵で、これは確かに自分に発行されたVCであると証明することができます。そのときにVC内で隠さなくてはいけない情報は、ちゃんとセレクティブディスクロージャーで隠せるということが、今のマイナンバーカードのAPIをたたけばできるということを学生とともに見つけました。このような方法も、将来、住民票VCの手軽な実現方法になるのではないかなと思いました。
﨑村委員： Web Walletの定義によると思うのですけれども、最近、Walletウォッシングが起きて、これがWalletなのかというようなものが結構あるのでどうかなと思うのですけれども、例えば、eIDAS 2.0のコンテキストでギリシャの大学のネットワーク(GUnet,Greek Universities Network)等でやっているようなものというのは、学生証、スマートカードに鍵が入っていて、それをキオスクなどに行ってピッとやると、サーバーサイドから暗号化されたBlob(Binary Large Object)がブラウザに落ちてきて、そのブラウザ上でテンポラリーなWalletがつくられて、それを使って提示したりすることができる。セレクティブディスクロージャーも当然できる。ログアウトすればそこからは消えるということをやっていました。なので、ここで言っているWeb Walletというものでイメージされるものは、そういうものが参考になるのではないかなと思います。
中村座長： あくまでもテンポラリーであると。
﨑村委員： 結局、スマホを持っていない人たちへの対応ですよね。その場合はきっとPCもない。そうすると、もはやキオスク端末でやるとか、そういう話になってくるわけです。日本だと、きっとコンビニで使えるATM機器等だと思うので、そこで使えるようにしてくれ、などという話になると思うのです。
事務局（楠）： ここでWeb Walletの話が出てくる理由は幾つかあると思います。なかなかスマートフォンにおける鍵へのアクセスというのはハードルが高い中で、Walletの普及を待っていても、欲している様々なユースケースで自由にWalletが使えるようにならない中で、どうやって鶏と卵のジレンマを断ち切っていくかという点で、今いただいたようなギリシャの事例もあると思います。ほかも含めて、特に今、AIエージェントが自律的にいろいろな申請とかサポートしていこうみたいな議論をしていくと、Walletも多分1種類ではなくて多種多様な、サーバー型のものもローカルで動くものも含めていろいろなニーズが出てくると思うので、その辺、多様なWalletというのを早期に実現できる、障壁がない、インターオペラビリティーのある世界にどうやっていくかみたいなところは多分技術的にも論点があろうかと思うので、ぜひご意見をいただければと思います。
新崎委員： Web Walletですけれども、クリプトアジリティは結構簡単になるのかなと思います。簡単というか、扱いやすくて、ローカルであるものを置き換えていくよりは、サーバーから置き換えたほうが楽ですね。というところもあるのと、もともと真正なデータベースを持っているのが行政系であれば、別にクラウドに置いてもどうなのか、一緒なのではないかなと。すごく乱暴なことを言っていますけれども。
﨑村委員： 極端なことを言うと、毎回取るのだったら普通にフェデレーションで良いのではないのかと思う。
新崎委員： ただ、本人同意みたいなので、本人が提示しましたよというものを残したいというのであれば、プロキシみたいな形になってしまうのでしょうけれども、Walletを介して提示しましたというのもあるのかなと思います。ただ、確かに、フェデレーションの本人同意とどう違うと言われたら、難しいですけれども。
事務局（楠）： 接続のパスというのは、やはりフェデレーションだと増えないですかね。それぞれ見せたい場面によって全部やっていかないといけない。マイナポAPIとかは、ある種、フェデレーションでAPI連携で実験をしているわけですけれども、では、日本全国の会社とつなぐことができるか。
中村座長： だから、IHVモデルでIssuerとVerifierをどこまで厳密に確認するかという問題と同じような議論ですよね。それは多分、自由なIssuerの署名鍵というのはきっと許されないと思えば、それなりに管理はしないといけないはずです。
事務局（楠）： そこはユースケース次第で、例えばレシートみたいなものを全部VCにしていこうと思うと、あらゆる人たちがIssuerとなり得る世界まで含めて考えないと結構苦しいと思うのです。みんなが住民票の写しを発行する社会は要らないとは思うのですけれども、これが領収書とか請求書とかそのほか、広く紙で流通している証票一般というとなかなかAPI連携でカバーできる規模には収まりがたい気がします。
中村座長： それは、ユースケースを幾つかのレベルに分けて、このレベルのVCであればIssuerはこういう検証が必要だみたいな、そういう分類をしないといけないような気がするのですけれども、そこの設計をどうするか。どれぐらいのレベルをつくらないといけないか。
小岩井委員： その話も関係すると思ったのですけれども、結局、Issuerのほうが、多分、自分が発行するVCにどのくらいのセキュリティーを担保させたいのかみたいな話を要求すると思います。そうすると、やはりIssuerがWalletを選ぶみたいな世界になってしまう気がしています。そうしたときに、住民票の写しの話だけを考えれば、国のWalletだけでも良いかもしれないですけれども、先ほどの在籍証明書とか、今後様々なVCが出てきたときに、それを全て国のWalletに格納するのですかといった話も出てきますよね。そうなると、Walletはもう少し様々な人が提供できるような形を少なくともつくっておかないといけないのかなという気がしています。
中村座長： そうしたときに、Walletも多分幾つかのレベルがあるはずで、1つのWalletで全部扱える必要はないと思うのですけれども、ただ、ユーザーの観点からするとアプリがたくさんあるというのも、それはそれで使いにくいので、そこはユーザーエクスペリエンスも含めてどういうWalletの設計なのかという話をしなくてはいけないと思うのです。
小岩井委員： 逆に言えば、広くあまねく使えるようなWallet、使えるところを目指すと、現実的にできるセキュリティーレベルはここまで、なので、このぐらいで我慢してもらえませんかみたいな話も、もしかしたらIssuer側にしなくてはいけないかもしれないということも考えとしてはありますよね。
中村座長： そういう意味では、官が絡むWalletとしては、このレベル以上のものを使いましょうと。それ以下の、あまりリスク的に問題にならないようなものは民で自由にやってくださいみたいな、そういう整理は当然あるとは思うのです。
富士榮委員： 今の、いろいろなWalletがとかいろいろなクレデンシャルが入る可能性というのを考えていくと、ユースケース単体で、このレベルであればいいであろうとか、こういう機能を備えていればいいだろうという話が恐らく成り立たなくなってくると思っていて、というのは、やはり重要なポイントの1つとして、複数のクレデンシャルを同時に提示するというのが、このIHVモデルの1つの大きな利点だと思うのです。そのときに、クレデンシャル単体で見たときのレベルというものと、複数のクレデンシャルを提示するときに、もう片方のクレデンシャルが違うレベルだった場合、そちらに引きずられるということは当然発生してくるはずなのです。例えばですけれども、住民票の写しと卒業証明書を、就職するときに日本企業では提示をするということを考えた場合というのは、日本に閉じたユースケースの中でのレベルを考えたらいいのですけれども、卒業証明書は海外の大学に提示することもありますよね。それが、例えばEUの大学に提示するときは、こういうレベルをEU側のレギュレーションに求められていますという話があったら、そちらに引きずられると思うのです。住民票の写しに関しては、同時に提示をするものだし、同じWalletに入っていなくてはいけない話があるのです。ですので、今回、社会実装をするときにはそういうことを考えなくてはならなくなってくるのだけれども、これを、今回はこのユースケースに閉じて考える。でも、シングルVC、シングルWalletのケースで良いとするのか、そこまで広げて考えたときにどうなるのか、という話は決めなくてはいけないかもしれないなと思って聞いていました。
小岩井委員： ちょっとだけ補足すると、結局そこで、何をもってBindingするかも変わってきてしまうわけです。最悪の最悪、Walletを2つ持って2つから別々に提示することもできるわけではないですか。でも、そうしてしまうと、その2つの提示者が同じだということの証明ができなくなってしまうのです。そうすると、そこはやはり属性でBindingしなくてはいけないよねとなってしまうと、その属性はどうするのだという話になってしまいます。
富士榮委員： だから、Wallet1つで複数のクレデンシャルを入れて、Walletによるバインドというものを一定信じるということを前提と置くのか、そうではないのかという話も、このユースケースを考えるときには多分重要な観点だと思います。
新崎委員： 先ほどの住民票の写しの本人ではない人が使うときの話がありましたけれども、住民票の写しについては名前しかない。やはり、身分証明書みたいなものをもう1つ持っていって、それと2つで提示するというのが、本当に住民票の写しを重要な行政手続で使うときにはそうなるだろうと思います。
似たような感じで、ワクチン接種証明書。海外向けのもので、パスポートとパスポート番号が記載されたワクチン接種証明書と2つ併せて使っていた事例もありますよね。そういう組合せというのが、VCだけ、片方だけで足りないときにはもう片方を使うとか、そういう話はあるのかなと思います。
事務局（楠）： おっしゃるとおりで、まさに番号法のユースケースも、ワクチン接種証明書と同様に、番号確認書類としての住民票の写しと、加えて、身元確認書類としてのマイナンバーカードであったりカード代替電磁的記録をどのようにバインドするかという問いであり、例えば、家族全員分のマイナンバーを提出するときに、今だと5人がカードリーダーをかざしてPINを入れなくてはいけないわけですけれども、5人分の住民票の写しと一緒にマイナンバーカードをかざせば、それの世帯主であったり誰かが提出をしている場合に残りの番号も正しいと推認できるか、など、ワクチン接種証明書もそうですが、今、本当に高いレベルの身元確認が求められるものは、属性証明としての確認書類と身分証を併せて出すということが考えられます。そこのBindingをテクニカルにWalletでどうやるかというところは、恐らく、証明書発行時にBindingのための別の証明書を出すなど、様々なやり方があると思うので、できれば、何とかこの①②③④の要件というのがVCで実現不可能なものがなさそうかという点を、よく確認していただけると大変ありがたいなというところではあります。
中村座長： もうそろそろ時間なのですけれども、資料に記載されていることであと気になるのは、例えば③のところの「スマートフォンを保有しない利用者が使えない」みたいな記載がありますが、これは我々としてどう検討することが求められているのかがよく分からなくて、スマートフォンでVCを使えない人は従来の方法が提供されるので、もうそれで良いよねというスタンスなのか、将来に向けて、とにかくVCで何らかのデジタル化をする仕組みというのを検討することを目標とするのかというあたりについても明確にしておいたほうがいいかなと思います。
もし、別に、従来のスマートフォンを持たない人はもう仕方がないよねということなのであれば、ここはスマートフォンを持たない場合どうのというのは言及しないほうが良いと思うので、そこは、制度設計をする側として、どちらを目指しているのかというところは明確にしておいていただけるとありがたいなとは思いました。
中村健一委員： やろうと思えばできるのですけれども、要するに、どこまで救済するかによってどれだけコストがかかるかの話になってしまうような気がします。コスト的にそんなに負担にならない程度だったら、どこまで拾えるから、ここまでやるので、ここまで広がってくると、これをやったほうが便利だなと思って、例えば、スマホを持つ人が増えてきたり、そのように段階的に考えていかないと、結構際限なくなってしまうかなとは思います。
小岩井委員： スマホを持っていない、パソコンを持っていない人が、マイナンバーカードの暗証番号をどれだけ覚えているのだというところも踏まえてですよね。
板倉委員： 多分、最初はスマートフォン前提で良いのではないかという気がします。
中村座長： もう残り時間がなくなってしまいましたので、どうしても、もうちょっと最後に何か付け足しておきたいというご発言があればお願いします。
小岩井委員： なりすましの検知の話に戻ってしまうのですけれども、ここでVCを提示するときに、Verifierが正しいかというところをちゃんと確認できますかというところも論点として重要かなと思いました。それだけです。
中村座長： ありがとうございます。
その辺、そういう意味では、いろいろなところでeIDAS 2.0というのが出てくるわけですけれども、では、既にある程度仕様が議論されてきているeIDAS 2.0の枠組みで我々のやろうとしていることが実際に反映したときに、どこが問題なのかとか、あるいは日本の制度的にここが合わないとか、そういうような議論がもしあるのだったら、そういうところも踏まえて我々としては議論できるのかなと思うのですけれども、ある程度詰められたそういう枠組みというものがあるのであれば、それで、どこまで我々の制度設計というか、手続がデジタル化できるのかというところは、一度評価してみても良いかなとは思うのですが、そういう取組は既にあったりするのですか。
事務局（楠）： 恐らく、総務省の検討会向けには、そこでは私は有識者としてそういう話をしなくてはならないと思うのですけれども、eIDASとの関係で言うと、非常にヘビーな体系が提示されている一方で、そこで実現することは、我々、おおむねマイナンバーカードで実現をしてしまっていて、この検討会の射程というのは、より多くの書類をどうやってデジタル化していくかというところなので、本来、eIDAS 2.0の射程に入っている部分もあるかもしれないし、我々は大いにそこは勉強しなくてはいけない一方で、おおむね、やっていること自体は世界のトップランナーレベルのことを既に実現しているという前提で、その先をどうやって提案してつくっていき、諸外国を含めて巻き込んでいくかということは多分考えていかなければならないと思います。
今、この検討会、今回で技術ワーキングは一旦今年度は終わりますので、来年度以降どうしていくかという議論はあるのですけれども、議論をしていくことが良いのか、きちんとかっちりやっていくためには、手元でものを動かしながらやったほうが良いのかなども含めて、何を詰めていくとより具体的な議論ができ、解決すべき課題が整理されていくかというのは、この2回の技術ワーキングにおいて相当ご指導いただいたところがあると思います。そこを踏まえて、しっかりとたたけるものをお示しできるようにはしていかなくてはいけないのかなと思っております。
中村座長： 2回にわたって、今回は今年度最後ということで、これをまとめて親会に報告するという形になるわけですけれども。
事務局（石井）： 今、オンライン参加の南井委員から1個だけ発言があるというところですので、おつなぎさせていただければと思います。
南井委員： 先ほど楠さんからもコメントがありましたけれども、結構絡むのだと思うのですが、AIエージェントがいるがゆえに野放図なVC発行みたいな話、ちゃんと止めたいみたいなwillがあって、VC発行プラットフォームみたいな話をやりたいみたいな、そういうwillが結構前に行くような話があるのであれば、勝ち筋のwillはこれだという話を結構前提でぼんと書いてしまったほうが議論はやりやすいのかなと思いました。
中村座長： そこも含めて、来年度に向けて議論をどう続けていくのかというところはまた相談しながら、来年度も皆さんにお集まりいただくのかどうかも含めて、状況を見ながらということになろうかと思います。本体会議に対しては、技術の観点からある程度整理をして、それに基づいて、どちらかというと制度面で何を考えないといけないのかみたいな議論をしないといけないというところですが、そこも含めて、また引き続き皆様からご意見を頂戴できればと思います。Slackはいつまで維持されるのですか。
事務局（北井上）： 本日の会議が終わっても、今年度いっぱいと言えるかどうか分かりませんけれども、本体会議が終わるまでは少なくともSlack自体は続きますので、その場でのやり取りというのは続くだろうと認識しております。
中村座長： では、引き続き、何かまた気になる点とかがありましたらSlackなどで議論させていただければと思いますけれども、そういうことで、また次回がありましたら引き続きよろしくお願いいたします。
あとは事務局にお戻しすればよろしいですか。
事務局（北井上）： ありがとうございました。
閉会に先立ちまして、事務局から今後のまとめ方等を含めた事務連絡をさせていただきます。技術ワーキングについては、発言も出ておりますけれども、今年度は今回が最終回ということになってございます。本日ご議論いただいた資料をもって本体会議に報告をするということではなくて、本日いただいたご意見もしっかりと反映した形で、報告用の資料というものを別途作成いたしまして、それを2月26日に予定しております第2回の本体会議で報告するということを予定しております。委員の皆様におかれましては、今、座長のお話もありましたとおり、今後、この会議の場にとどまらず、Slackなども活用して引き続き確認などをお願いするということになろうかと思いますが、引き続きご協力のほど、よろしくお願い申し上げます。
また、本日の議事録につきましては、後日、委員の皆様にご確認いただいた後、デジタル庁ウェブサイトにて公表をさせていただければと考えておりますので、こちらも併せてよろしくお願いします。
それでは、閉会に当たりまして、事務局を代表してデジタル庁デジタル社会共通機能グループ長の楠より一言ご挨拶申し上げます。
事務局（楠）： 閉会に当たりまして事務局を代表してご挨拶を申し上げます。
技術ワーキングの会合、本当にわずか2か月という短期間の開催となってしまいまして、委員の皆様から本当に多くの、その限られた時間の中でもご意見をいただけたと考えております。まずは心よりご礼申し上げます。
数年、Walletをめぐる検討会、形を変えて繰り返してきていて、やはり思ったより時間がかかっているのです。これは日本だけではなくて世界中で見て、ヨーロッパを見ても相当苦しんでいるところが多くある状況です。一方で、AIエージェントの話もそうですけれども、ここへ来て大きく環境が変わって、本人を介して情報を連携していくということのニーズというのは、より一層具体化しているところもあり、急いで整理をしていかなくてはいけないところがますます出てきているところの中で、口を開けて待っていれば良いということではなくて、佐古さんも今回ご提案いただいたという話ですけれども、課題を解決するということを一緒にコミュニティーの中で、この検討会だけではなくて、社会全体でまさにこれらの課題と向かい合っているという状況なのかなと認識しております。
今年度の技術ワーキンググループの会合につきましては本日をもって終了となりますけれども、本体会議へのフィードバックや、また、本体会議第2回を踏まえた会議の成果物につきましては、委員の皆様にも引き続き机上のご確認をお願いしていくことになってまいるかと思います。ちょうど年度末の大変な時期になるかとは思いますけれども、引き続きご協力を賜れればと考えております。本当にありがとうございました。
事務局（北井上）： それでは、以上をもちまして「属性証明の課題整理に関する有識者会議技術ワーキンググループ」を閉会いたします。ありがとうございました。
以上