資料１

事務局説明資料

令和４年３月22日
トラストを確保したDX推進SWG（第７回）

トラストを確保したDX推進SWGスケジュール
2021年12月末
2021年12月末

2022年3月末

2022年6月末• トラストスコープで集中的• トラスト実態調査分析結果• トラストポリシー基本方針にニーズやユースケースを検討する範囲特定• 電子化できる手続・取引の主要事例に基づく対応検討• Identificationのアシュアラ
ンスレベル整理• トラストサービスのアシュ
アランスレベル整理• ユースケース選定• 報告書とりまとめ（日・英）アウトライン
1. Identificationアシュアランスレベルの検討
2. トラストを確保したDX推進サブワーキンググループのアウト
プット案
I.

前回の議論の振り返り

II. マルチステークホルダーモデルのご提案

Identificationアシュアランスレベル検討

IALにおけるユースケースのマッピング案
既存の国際標準等を参照した上で、行政手続を中心に、日本の実情に応じたIdentificationアシュアランスレベルの整理が提案された。
IAL

本人確認方法

Identifier

IAL-3 発行元保証されている身元証 対面で確認
以上？ 明可能なもの
信頼できる機関により電子的 対面で確認に身元証明可能なもの

IAL-3

発行元保証されている
身元証明可能なもの

IAL-1

マイナンバーカードの発行
マイナンバーカードを使用した対面での申し込み

対面での有資格者に対面での身分証明必須のID/PASSの発行 (e-Tax 等)
よる確認
対面相当オンライン(eKYC)

オンラインでの身元証明書上の本人写真とリアルタイム本人
画像のマッチング…

IAL-2

ご議論いただきたいこと

マイナンバーカードを用いた電子署名

…

…

?

非対面

ユースケース

発行元保証されている身元証 オンライン登録後
明可能なもの対面で確認

オンラインでの銀行口座開設→カード受け取り時本人確認

信頼できる機関により電子的に身元証明可能なもの

オンラインでのマイナンバーカードリーダーを用いた口座開設

非対面で確認発行元保証されている身元証
非対面で確認
明可能なものオンラインでの本人確認書類 (画像アップロード 等)を用いたECサイト会員登録

身元確認のない自己表明
可能なもの

サービス登録時におけるメールアドレスでの通達確認

身元確認なし1• 「行政手続におけるオンラインによる本人確認の手法に関するガイドライン」にインプットするにあたり、各マスに入れるべきユースケースはどのようなものがあるか２• ユースケースは、技術進化
とともに、継続的な見直し、反映が必要になるが、国の役割はどうあるべきか。

AALとユースケースのマッピング案
既存の国際標準等を参照した上で、行政手続を中心に、日本の実情に応じたIdentificationアシュアランスレベルの整理が提案された。

AAL

AAL-3

AAL-2

認証プロセス

ユースケースAAL2に加えて、認証取得済みのハードウェ
アベースのなりすまし耐性を持つ認証子の利用が必須

マイナポータル：マイナンバーカードの利用者証明用電子証明書利用のユー
ザ認証によるログイン
eTax: ICカード方式・リモート署名利用による申告
ビジネスバンキング：FIDO Security Certification L3を取得したセキュリティ
キーを利用した二要素認証を使った大金の送金

多要素認証、認証取得済みの暗号化手法の利用が必須。なりすまし耐性を持
つ認証子の利用が推奨。

eTax: Smart-ID方式・リモート署名利用による申告
ネット証券：ユーザ名・パスワード+ソフトウェアトークンを使った認証取得済みの暗号化手法によるワンタイムパスワードによる認証を使った振込先銀行の変更

一要素認証

AAL-0

認証なし

…

…

AAL-1

ご議論いただきたいこと

ネット証券：ユーザ名・パスワードによるログイン
ビジネスチャットサービス：AAL-1のメールアドレスへのリンク送信とそのリンクを踏むことによるユーザ認証

eコマース：新規Cookieによる顧客の新規カート維持

1• 「行政手続におけるオンラインによる本人確認の手法に関するガイドライン」各レベルに入れるべきユースケース
はどのようなものがあるか２• ユースケースは、技術進化
とともに、継続的な見直し、反映が必要になるが、国の役割はどうあるべきか。

Identificationアシュアランスレベルの議論のアウトプット案
SWGで出た意見•

マイナンバーカードの発行は、自治体職員が対面で本人確認した上で発行しているため、IAL3よりさらに上のレベル。その結果、マイナンバーカードと顔写真の本人が一致することを対面で確認したもの及びマイナンバーカードの電子証明書を使った署名がなされているものはIAL3相当と言えるのではないか•

マイナンバーカードの発行以外のところでは、マイナンバーカードを用いた電子署名を使って本人確認に代えるという「まえばしID」のように全て電子にしてしまうことは可能ではないか。そうすると、本人の写真とリアルタイムの本人の画像
マッチングが本当に要るのかということが論点になる•

民間サービスにおいては、身元確認を必要以上に求めるとサービス加入者が減るといった弊害もあるため、マイナンバー
カード以外にもeKYCのような多様な本人確認の選択肢が必要ではないか•

新型コロナワクチン接種証明書アプリは、マイナンバーカードを利用して簡単に登録できるという点で、ID Proofingのユーザビリティやコストが改善された•

Identificationと行政データの連携が可能な仕組みの整備が必要（マイナポータルの「自己情報取得API」において、マイナポータルアプリによる公的個人認証を用いたログインが必須となっている。）

SWGのアウトプット案•

SWGで整理したIdentificationアシュアランスレベルの考え方、ユースケース、国の役割ついて、デジタル庁技術検討会の「行政手続におけるオンラインによる本人確認の手法に関するガイドライン」見直しにインプットを行う•

行政手続におけるアシュアランスレベルだけではなく民間サービスにおいてもこれを整理することが重要。本人確認レベルに関するアーキテクチャ整備については、マルチステークホルダーモデルの中で、DADCの検討成果も踏まえて検討を進めていくべきトラストを確保したDX推進サブワーキン
ググループのアウトプット案

トラストサービスの基準で担保すべきもの
トラストサービスでは、データの信頼性のみならず、フィジカル空間とサイバー空間のつながりにおけるトラストや、時間経
過後のトラストも考慮するべきだと指摘された。

「Society5.0」における産業社会を３つの層に整理し、セキュリティ確保のための信頼性の基点を明確化

将来的な担保：時間経過後のトラスト

サイバー空間におけるつながり【第３層】
自由に流通し、加工・創造されるサービスを創造するためのデータの信頼性を確保
フィジカル空間とサイバー空間のつながり考慮すべき要素【第２層】
フィジカル・サイバー間を正確に“転写“する機能の信頼性を確保（現実をデータに転換するセンサーや電子信号を物理運動に転換するコ
ントローラ等の信頼）
企業間のつながり【第１層】
適切なマネジメントを基盤に各主体の信頼性を確保

現状の担保：
紙が持つ真正性・非改ざん性をデジタルに持ち込むこと将来的な担保：情報の発出者（ソシキ、ヒト、モノ）と、当該情報を表現する媒体に関わらず改ざんされていないことを担保するときに必要になるトラスト
Source：経済産業省、サイバー・フィジカル・セキュリティ対策フレームワーク（CPSF）のポイント

トラストのスコープについて前回の議論の振り返り
紙持つ真正性・非改ざん性をデジタルに持ち込む際のトラスト（第２層）の確保をまず行うべきという意見がある一方、実社会におけるコンテクストを踏まえたトラストの確保が重要という意見も挙がった。

トラストサービスは手続面を保証するものであり、内容の真実性はベースレジストリが担うべき。
トラストに関する技術が進展する中、現段階でデータの中身の真正性までを国の制度で固めることは困難
将来的に第１，3層のトラスト確保への拡張性の余地を残しておくことは重要だが、まずは第２層の担保を固めることで議論を収れんさせるべき実社会においては、技術基準だけでなくコンテクストを踏まえてトラストが確保されている現状を踏まえ、
DFFTの“T(Trust)”を担う本SWGにおいては、専門家による技術的な担保だけでなく、トラスト基盤が社会から受け入れ可能なものになるよう、ケースごとのコンテクストを踏まえ、関係者を巻き込んだ議論をしていくということが必要
考慮すべき要素
第２層のトラスト確保を中心として、多様なステークホルダーを交えてコンテクストに沿ったトラストの担保を進める必要がある

Multi-stakeholder model(MSM) for Trust base
マルチステークホルダーからの提言を受け、政府でトラストサービスの政策を策定
諮問

Business Owner(BO)
概要：TC及びCSからの意見を踏まえ、Regulatorへ提出する提言を取りまとめる

提言

構成員：システム所管府省、サービス運営企業

Regulator
概要：提言を受けて政策に反映
構成員：関係府省

アウトプットTech Community(TC)Civil Society(CS)

概要：技術的な側面から提言にインプットを行う

概要：誰一人取り残されない観点から、トラストサービ
スの多様なユーザーの声を提言に反映する

構成員：JDTF, JNSA, その他標準化団体等

構成員：消費者団体、利用企業、企業団体• GPKI,LGPKI,JPKIの技術基準• 処分通知用eシール
技術基準• 関係法令見直し
・・・

MSMからのトラストサービスにおける提言の例
政府システムの仕様の最新化や技術基準の設定を行い、まずはデジタル臨時行政調査会での「公的な証明書・講習・閲覧に対面・書面を求める規制」見直し等において、トラストサービス活用を推進する
処分通知、公的な証明書等• GPKI、JPKI、LGPKIの技術基準の最新化• 公文書におけるタイムスタンプ・eシールの技術基準及び活用方策の検討⇒デジタル臨時行政調査会の「公的な証明書・講習・閲覧に対面・書面を求める規制」見直し（次ページ）
において、Phase2「類型１③：受講票、受講修了証等のデジタル発行」、「類型２③：証明書等のデジタル発行」及びPhase３でトラストサービスの活用を推進する
政府システムでの本人確認• 政府調達における電子契約
中長期的な情報収集・調査研究• 国際的な相互通用性を持った ID Wallet等

R4.2.8(参考)公的な証明書・講習・閲覧に対面・書面を求める規制の類型化(案)PHASE１
紙・人の介在①法令等において、対面で「講習」受講、紙発行の公的証明書等を「掲示」、公的情報を役所等へ訪問して「閲覧」「縦覧」と規定②法令等において、 「講習」受講、公的証明書等を「掲示」、公的情報を「閲覧」「縦覧」と規定しているが、デジタル原則に適合する手段が可能かが不明確

類型１①

PHASE２
デジタル原則に適合する手段を可とする

講習

オンラインによる講習受講を可とする
例）
・介護支援専門員更新研修
・一級建築士等定期講習
・危険物取扱者保安講習
類型１②※デジタル手続等の実装については、
利用者数や費用対効果等の状況を鑑みながら検討

受講申込のオンライン手
続※を可とする
例）
・一級建築士等定期講習

公的証明書等の掲示申請による公的情報の
閲覧・縦覧

類型２①

類型３①

インターネットの利用による公示（証明書等閲覧等情報のデジタル化を可とする

記載事項又はデジタル発行証
明書等）を可とする
例）
・サービス付き高齢者向け住宅の登録事項の公示

例）
・農業信用基金協会の定款、事業報告書等の閲覧
・食品衛生法における登録検査機関の財務諸表等の閲覧

類型２②

類型３②

公的証明書等申請のオン
ライン手続※を可とする

閲覧等申請のオンライン
手続※を可とする※申込・申請のオンライン手続に手数料のキャッシュレス納付を含む

PHASE3

デジタル完結を基本とする

公的証明書等以外の情報の掲示
申請によらない公的情報の縦覧・閲覧
類型４①

掲示・縦覧等情報のデジタル化を可とする
類型４②

インターネットの利用による公開・縦覧等を可とする

類型１③

類型２③

類型３③

受講票・受講修了証等のデジタル発行を可とする

証明書等のデジタル発行を可とする

インターネットの利用による閲覧等を可とする①＋②の例）
・住宅宿泊仲介業約款の公開
・都市計画案の縦覧
・金融商品取引業者の業務状
況等説明書類の縦覧

類型１

類型２

類型３

類型４

申込～受講～受講修了証
等発行のデジタル完結を基本とする

申請～証明書等発行～公示のデジタル完結を基本とする

閲覧等情報～申請～閲覧等のデジタル完結を基本とする

掲示・縦覧等情報～公開・縦覧等のデジタル完結を基本とする

例1) GPKI・JPKI・LGPKIの技術基準の最新化
マルチステークホルダーからの提言を受けて、デジタル庁でGPKI, JPKI, LGPKIの最新化の政策を策定する
Business Owner(BO)
概要：技術基準に係る課題の整理・素案作成

諮問
提言

構成員：デジタル庁

Regulator
概要：提言を受けて政策に反映
構成員：デジタル庁

アウトプットGPKI, JPKI,LGPKIの
技術基準

Tech Community(TC)Civil Society(CS)

概要：技術面からの素案の提唱と改善点の提案

概要：立場に応じて、意見をインプット

構成員：JDTF, JNSA, その他標準化団体等

構成員：ユーザー企業の団体、トラストサービス事業者

例2)公文書におけるタイムスタンプ・eシールの技術基準等MSからの提言を受けて、公文書においてタイムスタンプ・eシールを利用する場合の技術基準及び活用方策を策定する
Business Owner(BO)
概要：技術基準及び活用方策の素案作成

諮問
提言

構成員：デジタル庁

Regulator
概要：提言を受けて政策に反映
構成員：デジタル庁

アウトプットタイムスタンプ・eシールの技術基準
及び活用方策Tech Community(TC)Civil Society(CS)

概要：技術面からの素案の提唱と改善点の提案

概要：立場に応じて、意見をインプット

構成員：JDTF, JNSA, その他標準化団体等

構成員：ユーザー企業の団体、トラストサービス事業者

MSM運営における論点
1. 何をもってMSMでのコンセンサスとするのか
2. それぞれのコミュニティの意見や提言への拘束力をどう考えるか
3. Regulatorの諮問に対して、MSMの提言の素案を誰が作るか
4. MSMの構造や運営の定期的な見直しプロセスはどうあるべきか
5. Regulatorでの提言の政策への反映の仕方

（参考）既存の規制に関する適合性点検作業の進め方
R3.12月下旬

R4.１月

規制の適合性点検対象リスト洗い出し作業（対象：法令、約5千条項に該当あり）の進め方の照会と各省庁への情報提供
各府省と連携し、通知通達、独法の規律も含めて、点検・見直しの作業方針を確定。
※事務局及び規制改革推進室において、国民･産業界等の要望や追加的な洗い出し作業を実施し各省庁に情報提供〈作業部会の設置〉
各省庁による自主的な見直し⇒規制見直しプランに反映
見直しに関する課題がある事項⇒作業部会において検討

各省庁と事務局で見直し方針を協力して確認規制見直しプランの取りまとめ（自治体の後押しの方策含め具体化）

R4.春
法律⇒一括見直しの累次具
体化

政令省令通知・通達、運営要領等⇒スピード感をもって改正

技術的検証やシステム整備
等の検討

集中改革期間（3年程度）で原則への適合を実現

スケジュール（案）
2023年度

2022年度
4~６
月

7~9
月

10~12
月

1~3
月

4~６
月

7~9
月

10~12
月

1~3
月

4~６
月

7~9
月

デジタル臨調規制見直し集中改革期間（3年程度）

方針決定

概算要求時期
GPKI等の技術基準の最新化等の取組をインプット
トラスト基盤のマルチステークホルダーモデル

新重点計画にSWGのアウトプットを
インプット
トラストを確保したDX推進ＳＷＧ

2025年度

2024年度
10~12
月

1~3
月

4~６
月

7~9
月

10~12
月

1~3
月

議論いただきたいこと• 環境変化や社会的ニーズを踏まえ、GPKI・JPKI・LGPKIの課題や技術基準の最新化についてどう考えるか• 公文書におけるタイムスタンプ・eシールのニーズを踏まえ、これらの技術基準では何を定めるべきか（セキュリティ強度と利便性のバ
ランスの考え方等）• マルチステークホルダーモデルにはどのような関係者が参加するべ
きかMSMの参考事例

ICANNのMSM（組織体制）

それぞれ独自に理事会に提言ができる

ICANNのMSM• インターネットの安定した運営のため、MSMでのボトムアップ及びコンセンサスベースで、インター
ネット資源のポリシー策定を行う非営利組織• 理事会でのポリシー採択にあたっては、各コミュニティ及びコミュニティ間でのコンセンサスについての詳細なルールがBylawsで定まっている。
メンバー
ポリシー提言を行うSupporting Organization（SO）とポリシーに対して助言を行うAdvisory
Committee（AC）、ポリシーを採択する理事会（Board of Directors ）から成る。
SOやACへのメンバー加入参加は、それぞれ独自の申請方法や申請基準を定めている。
ダイバーシティを確保し多様な意見を反映するため、コミュニティ以外の組織との連携も認められている。
意思決定方法
SOにてポリシーを作成し、理事会へ提出し、ACからの助言を経て、理事会でポリシーを採択する。
意思決定は、マルチステークホルダーでのコンセンサスを基本とする。
SOでのポリシー策定、ACでの助言策定、理事会でのポリシー採択にあたっては、 ポリシー採択方法、ACからの助言に対する一連の取るべき手続きが、 ICANN Bylawsにおいて詳細に規定されている。
ポリシー採択にあたり、HPでの公表、関係者からコメントする機会もBylawsに規定されている。
Source：ICANN Bylaws(https://www.icann.org/resources/pages/governance/bylaws-en)ICANN AOI及びBylaws抜粋(Mission&Vision)
ICANN Articles of Incorporation
II. This Corporation is a nonprofit public benefit corporation and is not organized for the private gain of any person. It is organized under the Nonprofit Public
Benefit Corporation Law for charitable and public purposes. The Corporation is organized, and will be operated, exclusively for charitable, educational, andscientific purposes within the meaning of § 501(c)(3) of the Internal Revenue Code of 1986, as amended (the “Code”), or the corresponding provision of any
future United States tax code. Any reference in these Articles to the Code shall include the corresponding provisions of any future United States tax code. In
furtherance of the foregoing purposes, and in recognition of the fact that the Internet is an international network of networks, owned by no single nation,individual or organization, the Corporation shall, except as limited by Article IV hereof, pursue the charitable and public purposes of lessening the burdens ofgovernment and promoting the global public interest in the operational stability of the Internet by carrying out the mission set forth in the bylaws of the
Corporation (“Bylaws”). Such global public interest may be determined from time to time. Any determination of such global public interest shall be made by
the multistakeholder community through an inclusive bottom-up multistakeholder community process.
ICANN Bylaws
Section 1.1. MISSION(a) The mission of the Internet Corporation for Assigned Names and Numbers ("ICANN") is to ensure the stable and secure operation of the Internet's unique
identifier systems as described in this Section 1.1(a), (i) …That are developed through a bottom-up consensus-based multistakeholder process and designed toensure the stable and secure operation of the Internet's unique names systems.
(iv) Collaborates with other bodies as appropriate to provide registries needed for the functioning of the Internet as specified by Internet protocol standards
development organizations. In service of its Mission, ICANN's scope is to provide registration services and open access for registries in the public domain requested
by Internet protocol development organizations.
Section 1.2 COMMITMENT AND CORE VALUES(b)CORE VALUES
In performing its Mission, the following "Core Values" should also guide the decisions and actions of ICANN:(ii) Seeking and supporting broad, informed participation reflecting the functional, geographic, and cultural diversity of the Internet at all levels of policy
development and decision-making to ensure that the bottom-up, multistakeholder policy development process is used to ascertain the global public interestand that those processes are accountable and transparent;
Source：ICANN Articles of Incorporation（ https://www.icann.org/resources/pages/governance/articles-en ）ICANN Bylaws(https://www.icann.org/resources/pages/governance/bylaws-en)ICANN Bylaws抜粋（Comment on Policy actions）
Section 3.6. NOTICE AND COMMENT ON POLICY ACTIONS(a) With respect to any policies that are being considered by the Board for adoption that substantially affect the operationof the Internet or third parties, including the imposition of any fees or charges, ICANN shall:(i) provide public notice on the Website explaining what policies are being considered for adoption and why, at least
twenty-one days (and if practical, earlier) prior to any action by the Board;(ii) provide a reasonable opportunity for parties to comment on the adoption of the proposed policies, to see thecomments of others, and to reply to those comments (such comment period to be aligned with ICANN's public comment
practices), prior to any action by the Board; and(iii) in those cases where the policy action affects public policy concerns, to request the opinion of the Governmental
Advisory Committee ("GAC" or "Governmental Advisory Committee") and take duly into account any advice timely
presented by the Governmental Advisory Committee on its own initiative or at the Board's request.
(d) Where a Board resolution is consistent with GAC Consensus Advice (as defined in Section 12.2(a)(x)), the Board shallmake a determination whether the GAC Consensus Advice was a material factor in the Board‘s adoption of such resolution,in which case the Board shall so indicate in such resolution approving the decision (a “GAC Consensus Board
Resolution”) and shall cite the applicable GAC Consensus Advice. To the extent practical, the Board shall ensure that GAC
Consensus Board Resolutions only relate to the matters that were the subject of the applicable GAC Consensus Advice andnot matters unrelated to the applicable GAC Consensus Advice. …

Source：ICANN Bylaws(https://www.icann.org/resources/pages/governance/bylaws-en)ICANN Bylaws抜粋(Reconsideration Request)
Section 4.2. RECONSIDERATION(a) ICANN shall have in place a process by which any person or entity materially affected by an action or
inaction of the ICANN Board or Staff may request ("Requestor") the review or reconsideration of that action or
inaction by the Board. For purposes of these Bylaws, "Staff" includes employees and individual long-term paid
contractors serving in locations where ICANN does not have the mechanisms to employ such contractors
directly.
(b) The EC may file a Reconsideration Request (as defined in Section 4.2(c)) if approved pursuant to
Section 4.3 of Annex D ("Community Reconsideration Request") and if the matter relates to the exercise of
the powers and rights of the EC of these Bylaws. The EC Administration shall act as the Requestor for such a
Community Reconsideration Request and shall act on behalf of the EC for such Community Reconsideration
Request as directed by the Decisional Participants, as further described in Section 4.3 of Annex D.
(c) A Requestor may submit a request for reconsideration or review of an ICANN action or inaction("Reconsideration Request") to the extent that the Requestor has been adversely affected by:

Source：ICANN Bylaws(https://www.icann.org/resources/pages/governance/bylaws-en)ICANN Bylaws抜粋（GAC Advice）
ARTICLE 12 ADVISORY COMMITTEES
Section 12.1. GENERAL…
(ix) The Governmental Advisory Committee may put issues to the Board directly, either by way of commentor prior advice, or by way of specifically recommending action or new policy development or revision toexisting policies.
(x) The advice of the Governmental Advisory Committee on public policy matters shall be duly taken
into account, both in the formulation and adoption of policies. In the event that the Board determines totake an action that is not consistent with Governmental Advisory Committee advice, it shall so inform theGovernmental Advisory Committee and state the reasons why it decided not to follow that advice. Any
Governmental Advisory Committee advice approved by a full Governmental Advisory Committee consensus,
understood to mean the practice of adopting decisions by general agreement in the absence of any formal
objection ("GAC Consensus Advice"), may only be rejected by a vote of no less than 60% of the Board,and the Governmental Advisory Committee and the Board will then try, in good faith and in a timely andefficient manner, to find a mutually acceptable solution. The Governmental Advisory Committee will state
whether any advice it gives to the Board is GAC Consensus Advice.
(xi) If GAC Consensus Advice is rejected by the Board pursuant to Section 12.2(a)(x) and if no such mutuallyacceptable solution can be found, the Board will state in its final decision the reasons why theGovernmental Advisory Committee advice was not followed, and such statement will be without prejudice tothe rights or obligations of Governmental Advisory Committee members with regard to public policy issues
falling within their responsibilities.

Source：ICANN Bylaws(https://www.icann.org/resources/pages/governance/bylaws-en)ICANN Bylaws抜粋（GNSO Policy Development Process）
Annex A: GNSO Policy Development Process
The following process shall govern the GNSO policy development process ("PDP") until such time as
modifications are recommended to and approved by the Board. The role of the GNSO is outlined in Article 11of these Bylaws. If the GNSO is conducting activities that are not intended to result in a Consensus Policy,
the Council may act through other processes.
Section 1. Required Elements of a Policy Development Process
The following elements are required at a minimum to form Consensus Policies as defined within ICANN
contracts, and any other policies for which the GNSO Council requests application of this Annex A:…
g. PDP Recommendations and Final Report shall be forwarded to the Board through a Recommendations
Report approved by the Council; andh. Board approval of PDP Recommendations.
Section 2. Policy Development Process Manual
Board Request: If the Board requested an Issue Report, the Council, within the timeframe set forth in the
PDP Manual, shall initiate a PDP. No vote is required for such action.
GNSO Council or Advisory Committee Requests: The Council may only initiate the PDP by a vote of theCouncil. Initiation of a PDP requires a vote as set forth in Section 11.3(i)(ii) and Section 11.3(i)(iii) in favor of
initiating the PDP.
Source：ICANN Bylaws(https://www.icann.org/resources/pages/governance/bylaws-en)ICANN Bylaws抜粋（Board Approval Process）
Section 9. Board Approval Processes
The Board will meet to discuss the GNSO Council recommendation as soon as feasible, but preferably not later than
the second meeting after receipt of the Board Report from the Staff Manager. Board deliberation on the PDP
Recommendations contained within the Recommendations Report shall proceed as follows:a. Any PDP Recommendations approved by a GNSO Supermajority Vote shall be adopted by the Board unless, by a voteof more than two-thirds (2/3) of the Board, the Board determines that such policy is not in the best interests of theICANN community or ICANN. If the GNSO Council recommendation was approved by less than a GNSO Supermajority
Vote, a majority vote of the Board will be sufficient to determine that such policy is not in the best interests of theICANN community or ICANN.
b. In the event that the Board determines, in accordance with paragraph a above, that the policy recommended by a
GNSO Supermajority Vote or less than a GNSO Supermajority vote is not in the best interests of the ICANN
community or ICANN (the Corporation), the Board shall (i) articulate the reasons for its determination in a report to
the Council (the "Board Statement"); and (ii) submit the Board Statement to the Council.
c. The Council shall review the Board Statement for discussion with the Board as soon as feasible after the Council's
receipt of the Board Statement. The Board shall determine the method (e.g., by teleconference, e-mail, or otherwise)by which the Council and Board will discuss the Board Statement.
At the conclusion of the Council and Board discussions, the Council shall meet to affirm or modify its recommendation,and communicate that conclusion (the "Supplemental Recommendation") to the Board, including an explanation for thethen-current recommendation. In the event that the Council is able to reach a GNSO Supermajority Vote on the
Supplemental Recommendation, the Board shall adopt the recommendation unless more than two-thirds (2/3) of theBoard determines that such policy is not in the interests of the ICANN community or ICANN. For any Supplemental
Recommendation approved by less than a GNSO Supermajority Vote, a majority vote of the Board shall be sufficient todetermine that the policy in the Supplemental Recommendation is not in the best interest of the ICANN community or
ICANN.

Source：ICANN Bylaws(https://www.icann.org/resources/pages/governance/bylaws-en)IETFのMSM• IPv6やDNSSECのプロトコル等のインターネット技術の標準化を推進するMSMの標準化団体• 技術仕様策定にあたりラフコンセンサスが取られており、改善を加えながら前に進むことが可能
メンバー• IETFではメンバーになる基準を設けておらず、テックコミュニティ以外にも個人を含めて多様な方々が加入可能。
• IETFでの技術的なポリシーの作成は、トピックごとにWGで行われいる。
意思決定方法• 意思決定にあたっては、ラフコンセンサス（大きな了解）が取られれば、ランニングコードとして実際に実行し、改善を加えながら詳細な仕様を策定する方式を取っている。
• ほとんどの議論はメーリングリストを通して行われ、議論はアーカイブに保存される。（会合は年３回行われる。）
WGの設立• WG設立にあたり、Birds of a Feather(BOF)というIETFコミュニティへの関心トピックの議論を行うことがある。
• IABの助言に基づき、IESGがWGの設立趣意書を承認する• WGは、WG ChairとADで合意した設立趣意書の内容に焦点を当てる。
• WGは、設立趣意書記載の作業が完了すればクローズされる
Source：IETF About, IETF94: 94-newcomers-Japanese.ppt, RFC 2418

IETFのMSM（組織体制）• ISOCがIETFの組織・管理の本部として機能している。
• インターネットアーキテクチャと標準化プ
ロセスの助言及び監督• IETFの対外的な調整• RFC Editorの任命及び監視• WG設立と設立趣意書についてのIESGへの情報提供• ワークショップの招集 等

ISOC（Internet Society）

IAD
IESG
IASA

IAB

（Internet Architecture Board）（IETF Administrative
Support Activity）

IRTF（Internet Research Task Force ）インターネットの長期的課
題を研究するIETFの組織的・管理的機能を担う（例：IABの設立許可、IASA本部、IAD雇用主、IETFの上訴システム）

RFC
IANA

IANA

（Internet Assigned Number Authority）（Internet Assigned Number Authority）“the IETF”• IETFが標準化する技術及び標準化プロセスの技術的観点からのレビューグループ（Internet Engineering Steering Group）• IABやコミュニティの助言を

area

area

元にWGの作成を承認• IETFの進行管理• WGの作成・承認

area

Source：IETF Newcomer presentation(https://trac.ietf.org/trac/edu/attachment/wiki/IETF94/94-newcomers-japanese.ppt,
https://datatracker.ietf.org/meeting/101/materials/slides-101-edu-sessb-ietf-newcomers-overview-japanese-translation-03.pdf)

IETF Mission Statement 抜粋
Best Current Practice[Page 1]
RFC 3935
IETF Mission Statement
October 2004
technically competent input from any source. Technical competence also means that we expect IETF output
to be designed to sound network engineering principles - this is also often referred to as "engineering
quality".
Volunteer Core - our participants and our leadership are people who come to the IETF because they want to
do work that furthers the IETF's mission of "making the Internet work better".
Rough consensus and running code - We make standards based on the combined engineering judgementof our participants and our real-world experience in implementing and deploying our specifications.
The Internet is a global phenomenon. The people interested in its evolution are from every culture under
the sun and from all walks of life. The IETF puts its emphasis on technical competence, rough consensus
and individual participation, and needs to be open to competent input from any source. The IETF uses the
English language for its work is because of its utility for working in a global context.
Source：A mission Statement for the IETF

IETFのMSM（RFCの作成）• WGの文書をIESGに投稿し、IETFコミュニティのレビューを経て、RFCとして出版される

IETF の投稿の場合

WG文書、もしくは
個人スタンダードトラック文書

投稿

懸念事項

RFC Production

IESG“Last Call”
IETF コミュニティの
レビュー

可能性

コメント、
提案

RFC Publisher

RFCとして出版
Source：IETF; https://trac.ietf.org/trac/edu/attachment/wiki/IETF94/94-newcomers-japanese.ppt

IETFのMSM（WGの設立）• ボトムアップ方式で、IETFの参加者からWG設立の提案がされる• BOFを開いて関心のある分野の問題提起を行うことにより、WGの設立につながることがある。

チェア、説明（description）、
ゴール、マイルストーン

community

BOFがあるかも

new-work と
IETF-Announce のメイリングリスト

設立趣意書についての最終決定権を持つ。

AD

IESG

Working group 作成

WGチェアとADとでマイルストーン付きの限定的な設立趣意書を作成する

IAB

WGは、設立趣意書の内容にフォーカスした運営を行う（作業が完了すればクローズされる）・WGの提案を行う
・WGの進行を確かめ、運営変更の権限を持つ
・IESGに先立ち、WGのドキュ
メントのレビューを行う。

IABの助言に基づき、IESGがWGの設立趣意書を承認する。

Source：IETF; https://trac.ietf.org/trac/edu/attachment/wiki/IETF94/94-newcomers-japanese.ppt
RFC2418, https://www.potaroo.net/ietf/all-ids/draft-ietf-poisson-wg-guide-00.txt

IGFのMSM• 多様なステークホルダーが参加できるインターネットについてのパブリックポリシーを議論する国連管轄のフォーラム• 意思決定を目的としていないため、ステークホルダー間で議論を行い、課題の特定や解決策の模索を助ける役割を持つにとどまる
メンバー
政府、企業、個人などインターネットに関わる官民の多様な関係者が対話を行う。
登録を行えば、個人でもフォーラムに参加可能

意思決定方法
交渉結果のアウトカムを出すのではなく、議論、情報交換、ベストプラクティスの共有を行うことを目的とする。
オープンかつインクルーシブなプロセスを採る

Source：About IGF(https://www.intgovforum.org/multilingual/tags/about)Tunis Agenda for the Information Society抜粋
72. We ask the UN Secretary-General, in an open and inclusive process, to convene, by the second quarter of 2006, a meeting of the newforum for multi-stakeholder policy dialogue—called the Internet Governance Forum (IGF). The mandate of the Forum is to:• Discuss public policy issues related to key elements of Internet governance in order to foster the sustainability, robustness, security,
stability and development of the Internet;• Facilitate discourse between bodies dealing with different cross-cutting international public policies regarding the Internet and discuss
issues that do not fall within the scope of any existing body;• Interface with appropriate inter-governmental organizations and other institutions on matters under their purview;• Facilitate the exchange of information and best practices, and in this regard make full use of the expertise of the academic, scientific andtechnical communities;• Advise all stakeholders in proposing ways and means to accelerate the availability and affordability of the Internet in the developing world;• Strengthen and enhance the engagement of stakeholders in existing and/or future Internet governance mechanisms, particularly thosefrom developing countries;• Identify emerging issues, bring them to the attention of the relevant bodies and the general public, and, where appropriate, makerecommendations;• Contribute to capacity building for Internet governance in developing countries, drawing fully on local sources of knowledge and expertise;• Promote and assess, on an ongoing basis, the embodiment of WSIS principles in Internet governance processes;• Discuss, inter alia, issues relating to critical Internet resources;• Help to find solutions to the issues arising from the use and misuse of the Internet, of particular concern to everyday users;• Publish its proceedings
77. The IGF would have no oversight function and would not replace existing arrangements, mechanisms, institutions or organizations, butwould involve them and take advantage of their expertise. It would be constituted as a neutral, non-duplicative and non-binding process.
It would have no involvement in day-to-day or technical operations of the Internet.
Source：Tunis Agenda(https://www.itu.int/net/wsis/docs2/tunis/off/6rev1.html)

ISO/IECのMSM• ネジからセキュリティ認証まで幅広い分野の標準化を行う国際標準化団体• 標準策定はWTO TBT協定に則りコンセンサスプロセスが取られいる。
メンバー• 各国ごとにNational Body(NB)を形成し、そこを通じて参加する。参加者はNBのポリシーにもよるが、多くの国で政府関係者、
民間企業、学識経験者などで構成されている。
• この他にNBを通ささないリエゾン団体（例：EDPB, IAC）からの審議参加も行われている。

意思決定方法• 意思決定にあたっては、コンセンサス（強い継続的な反対をするものがいないこと）がとられている。これを、NP-AWI-WD-CDDIS-FDIS-ISというステージを通じて繰り返すことにより文書の完成度を上げていく形をとる。DIS以降では、NBによる投票が行われる。
• コメントはコメント表の形で提出し、これに対してエディタが処理方法の提案をし、審議参加者でのコンセンサスを取る形で進める。審議は対面ないしはリモートの会議で行われる。

プロジェクトの設立• Form A という一定の形式の趣意書が提出され、これがNBの投票にかけられ、５つ以上のNBが審議に加わる人名を指定した上での賛成を表明することによって規格化の開始が承認される。Form Aには規格の範囲などが指定され、多くの場合初期文書が添付される。
• 承認されたプロジェクトはこれはWGにアサインされ、ここで審議が始まる。WGレベルではNBはなく、全員個人のExpertとしての資格で審議に参加する。

OECD/Committee on Digital Economy Policy(CDEP)のMSM• OECDの中でデジタル経済と社会の発展に関する諸課題の検討を行っている。OECDプライバシー原則
やサイバーセキュリティ原則、AI原則などのLegal Instrumentsはここで策定されている。
メンバー• 各国の代表の他に、ステークホルダーとしてCivil Society, Business and Industry, Trade Union,
Internet Technical の４つのAdvisory Council からの代表者および事務局がラウンドテーブルに座り、多様な視点からの検討を行っている。
• 主な会合は年に２回実施。この他に適時Workshop が開催され、学識経験者などが招聘され、上記に対するインプットを作っている。
• また、３年に１回閣僚級会合が実施される。

意思決定方法
• 検討の中で表明された意見（intervention）は事務局がその場で回答するとともに文書に反映し、コン
センサス（強い継続的な反対をするものがいないこと）が得られたところでWorking Party からCommitteeに上げられ、そこでDeclassify することによって公表が行われる。
プログラムの設立• 事務局の予算提案(Programme of Work) をWPおよびCommittee で審議し、承認をもってプログラムが開始される。

（参考）構成員・オブザーバー
構成員
手塚

悟

慶應義塾大学環境情報学部 教授
(主査)

濱口 総志

慶應義塾大学SFC研究所 上席所員

宮内
宏
林
達也
宮村 和谷

宮内・水町IT法律事務所 弁護士
LocationMind株式会社 取締役
PwCあらた有限責任監査法人 パートナー

太田 洋
崎村 夏彦
佐古 和恵

西村あさひ法律事務所 パートナー弁護士
東京デジタルアイディアーズ株式会社 主席研究員
早稲田大学 基幹理工学部情報理工学科 教授

その他関係行政機関
総務省
サイバーセキュリティ統括官付参事官
法務省
民事局商事課長
経済産業省 商務情報政策局サイバーセキュリティ課長

オブザーバー
伊地知理

一般財団法人日本データ通信協会 情報通信セキュリティ本部

袖山 喜久造 ＳＫＪ総合税理士事務所 所長・税理士

タイムビジネス認定センター長

中武

佐藤

創一

一般社団法人新経済連盟 政策部長

西山晃

電子認証局会議 特別会員（フューチャー・トラスト・ラボ 代表）

山内徹

一般財団法人日本情報経済社会推進協会

若目田 光生

浩史 Global Legal Entity Identifier Foundation ( GLEIF )日本オフィス 代表小松
中須博明 有限責任あずさ監査法人 東京ＩＴ監査部 パートナー
祐二 SAPジャパン株式会社 政府渉外 バイスプレジデント

常務理事・デジタルトラスト評価センター長

小倉隆幸 シヤチハタ株式会社 システム法人営業部 部長

一般社団法人日本経済団体連合会 デジタルエコノミー

島岡

政基

セコム株式会社IS研究所 主任研究員

推進委員会企画部会 データ戦略 WG 主査佐藤

帯刀

クラウド型電子署名サービス協議会 協議会事務局
PwCあらた有限責任監査法人 パートナー

太田

大州

デジタルトラスト協議会 渉外部会長

三澤

伴暁

小川

博久 日本トラストテクノロジー協議会 運営委員長

小川幹夫 全国銀行協会 事務・決済システム部長

豊島一清

DigitalBCG Japan Managing Director

サイバー・セキュリティ戦略グループ 主任研究員
野崎
孝一 セイコーソリューションズ株式会社 DXサービス企画統括部 担当部長 田中
兼トラストサービス推進フォーラム 企画運営部会 部会長英司

金融庁 監督局 総務課長

彰子

厚生労働省 医政局 研究開発振興課
医療情報技術推進室長

兼株式会社三菱総合研究所 デジタル・イノベーション本部
柴田

肥後 彰秀

独立行政法人情報処理推進機構（IPA）デジタルアーキテクチャ・デザインセンター（DADC）
インキュベーションラボ デジタル本人確認プロジェクトチーム プロジェクトオーナー