先日業界の憧れの方とお話しする機会があり、アウトプットのモチベーションを伺いました。
すると「自分の学んだことのメモ」なので忘れたら見返していると聞いて、成功されている方こそ日々積み重ねを大切にされているんだと改めて思いました。
モチベーションをいただいたところで、Washington D.C.のsummitに向けてSIDI Hub Berlin 2024 Draftで予習をしていこうと思います。
勢いで書きましたがいくつか記事を分けた方が見やすかったのだろうな……と少し反省です。
※Cape Townの方が気になるという方はIdM実験室でとてもありがたい記事があるのでそちらがおすすめです。この記事を見る方がいるならすでにご存じかとは思いますが念のため
※スライドがかなり多く、本記事ですべてのスライド内容まではカバーしきれていないのでご注意ください
Summary of SIDI Hub Berlin
- European Identity and Cloud Conference(EIC)の前日である2024年6月3日にベルリンで開催
- ParisとCape Townでは政府関係者が多く参加したのに対して、EICの出席者が集まった影響で技術的な専門家が多く参加
- アジェンダは相互運用の障害を挙げること、技術要件収集のためのアプローチを洗練させること、トラストフレームワークとプロトコルの相互作用を強調する内容となった
- また、チャンピオンユースケース（特にヨーロッパの文脈）についての議論や共通の研究課題の構築も行われた
Key Take-Aways
Architectural Archetypes
グローバルに相互運用できる必要があるアーキテクチャは限られる
- 特にIdPとRP間のAPI通信に基づくもの、およびエンドユーザに発行されたクレデンシャルを保持するwalletに仲介されるもの
- 相互運用性を確保するために送信元(IdPまたはwallet)もしくは宛先(RPまたはVerifier)におけるオプションが必要
- 「送信元での固定」、「宛先での固定」の両方のモデルをサポートするか議論中
Verifiers Make the Market
Verifier(ここではRPの意味)の実装に複雑性やリスクを追加することはビジネスに対して困難を招く
- 採用や利用の遅れ
- 複数業種における参入障壁
- 小規模なプレイヤーの包摂問題の悪化
どのようなソリューションを採用する場合もこれらのリスクに対応する必要がある。
その一方でSIDI Hub参加者は一旦エコシステムが機能してしまえば、多くの場合は導入コストを支払うIssuerよりVerifierが利益を得る立場だと認識している。
やはり技術があってもビジネスとして成り立たないとなかなか普及しないのでいかにしてマーケットを構築するかは課題ですね……🥲
Use Cases Ground Requirements (or: “The Perils of Abstraction”)
ユースケースを明確に定義しなければ合理的な達成に限界がある
- 国境を越えた相互運用性の取り組みが成功した例は特定の空間の問題に根差したもの
- 例：国境通過や旅行のためのパスポート、クレジットカード決済、教育機関へのグローバルなアクセスのための統一SAMLプロファイル
- 3~4件のチャンピオンユースケースの定義に取り組む予定
まだそこそこの数ユースケースが残っている気がしますが、どう絞っていかれるのか楽しみですね！国境付近の貿易や口座開設が個人的には気になってます🥰
Brokers and Proxies
相互運用性はブローカーやプロキシに依存する可能性がある
- 中央集権化されたデータベースや「phone home」アーキテクチャを必要とするものではない
- ブローカーとプロキシは同じ意味で使うべきではない
- ブローカー：長所と短所を伴う特定の市場機会や商業的利益
- プロキシ：パススルーの技術コンポーネント（ビジネスモデルに対しては何も示唆しない）
英辞郎より
いまいちphone homeアーキテクチャが分かりませんが、文脈からして特定の主体のアーキテクチャとかなのでしょうか🧐
Users of a Trust Framework Analysis Tool
OIXが主導するトラストフレームワーク比較ツール
- SIDI Hub 2024の成果物
- Berlinでは比較ツールの価値提案と要件を形成
BOLTS: Business, Operational, Legal, Technical, and Social
チャンピオンユースケース分析の中核として「BOLTS」フレームワークを使用する
初めて知りましたがモバイルアプリ用のライブラリがあるんですね✏️
Government Participation
Berlinでは政府関係者の出席が少なかったため、アジェンダは技術的な可能性を議論する技術的な聴衆に偏ってしまったため、Washington D.C.、Tokyo、Brazilではベースライン政府の参加が重要だと認識
SIDI Berlin Rapporteur Notes
Champion Use Cases:Process and Progress to Date
Berlinでは下記3つを実施
- 主要なユースケースにおけるMinimum Requirementsの基礎
- より多くのユースケースを追加し、すでに収集されたデータにさらに質感を加える
- 優先順位付けの基準について意見を得る
その日の早い段階で、他の情報源や過去のSIDI Hubイベントからのインプットを見直した
- Parisのサミットと具体的なユーザーストーリーの作成
- W3Cクレデンシャルワーキンググループ
- EU Walletのユースケース
- EUとアメリカのTTP二国間分析
- SIDI Hub Cape Town
- SIDI Hub Berlinからのインプット
午後には「難民」と「口座開設」の2つのユースケースに焦点を当てて議論
※SIDI Hub Berlin 2024 Draft p15から引用
Gap Analysis
相互運用性を阻む大きな障壁のうち単一の世界的な所有者を特定するため下記3つに焦点を当てた
- RPの登録：EUDIWの範囲内で取り組まれており、AadhaarやNIMCなどが国ごとにカバーしているが世界規模でどう相互運用するのか
- Issuing Authorityの発見：ICAOは何年も経ってから、パスポートのためにこれを一元化したが、公的機関や民間企業のIssuerにとってどのように機能するのだろうか
- 法人の識別子：例えばLEI(GLEIF)とDNS(ICANN)。取引主体のリンクを実現する最善の方法は何だろうか
RPの登録は必要だと思いますが、国際規模となると誰がどう管理するのかが課題ですよね…結局国なのか…🧐
議論のポイントは以下の通り
-
RPの登録：RP登録の本質、要件、Trustの確立がグローバルでどのように機能するかについて議論
a. 基礎的なIDのみに焦点を当てるのか、機能的なIDシステムも含めるのか
・NigeriaではID管理を担当する機関はNIMC。基礎的なIDの場合、まずVerificationと呼ばれるデューデリジェンスプロセスが行われる
・RPの登録はこの基礎的な部分のためb. なぜRPは登録するのか、その要件について
・mDLの標準の場合トラストエコシステムはIssuerだけのためにある
・自分のmDLを共有した場合になぜ信用しなければならないのか。この懸念は特にベンダーに関連するもので、例えばAadhaarでは信頼できることを確認するためにRPの指紋デバイスを政府に登録しなければならないc. ソリューションはユースケースに基づくべきか、リスクベースのアプローチにすべきか
・クレデンシャルのタイプ次第
・例えば、営利団体は成績証明書全体を必要としないd. 公的主導、民間主導、あるいはその両方の組み合わせどれがよいか
・公的主導の例：ICAO
・民間主導の例：ICANNe. ガバナンスは運営費の調達に関係するが、ICAOのように自己資金で賄うのか、外部資金とすべきか
f. グローバルなものか、地域的なものか
・AAMVAは北米にあり、運転免許証に関するものだけであるg. 以下にどのようにアプローチするか
・ライフサイクル管理
・データの種類
・正当性とKYB
・ポリシーの実施h. 選択肢について学術的な分析を行うべきか
i. 意思決定者は誰か、その理由j. 適切な役割
・政府？
・UNのようなNGO？（UNの独立性は十分か？）
・標準化団体？k. 合意形成に何が必要か
チャンピオンユースケースは、最大限広範な相互運用性を目指す場合に直面する問題の幅広さを示すものであることを議論
続いてガバナンスについて3つの重要なポイントを議論
- 長期的に考える必要性：出発点はチャンピオンユースケース
- 運営主体として考えられる前例：世界基金やビル&メリンダ・ゲイツ財団のように、政府間の交渉やルール作りの複雑さ、時間を避けるために設立された組織がある。また、マラリアやその他の病気に焦点を当て、豊かな北から南へワクチンを流すために設立されたGAVIも存在
- Global Southを巻き込む：彼らのためにユースケースを作ることはできないため、彼らのところに行き、ニーズを聞く必要がある
EUのEIDAS2.0に触発された多くのリスクについて議論した
- EUの国民ID：すべての国が独自のリストを作成し、管理する
- 人々はヨーロッパを越えてクレデンシャルを使用したいのか
- これらのルールはすべてwalletの中にあるわけではない
- Issuerがどのようなポリシーをwalletに与えることができるかを考える必要がある
- トラストマークは地域的なものから機能的なものまで多数ある。エージェントは
ユーザにアドバイスを与えるwalletのエージェント。walletが法域を超えて機能するにはどうすればいいのか
「RP登録は必要なのか」という問いも投げかけられた。
セクションの論点まとめ
- ユーザの保護：すべての取引についてRPを特定する必要がある。これはRPの登録を行うのではなく、認証を行う。(現在あるものを複製)
- RPの資格：EUでは登録制に移行しつつある。誰が何をする権利があるのかを誰かが決定しなければならないのだ。どう行うかではなく、その問題を探ることを推奨
- BOLTS：チャンピオンユースケースに関するビジネス、運用、法務、技術、社会的慣行を分類し、リスクをマッピングする
Issuing Authorityの発見と法人の識別子については今後のワークストリームやsummitで取り上げる予定
Minimum Technical Requirements
グローバルな相互運用性のために必要最低限の要件を抽象化することは困難な作業だが、SIDI Hubの設立原則に管轄区域に対して、どのようにシステムを構築すべきかを指示すべきではないというものがあるため検討中
- ここではID情報の交換(データプレーン)に焦点があてられた
- 3つのグループに分かれて9つのシナリオを検討するグループワークを実施
- Federated：SAMLやOIDCなど、標準ベースのフェデレーションに基づいて構築されたアーキテクチャ
- Wallet-Based：issuer-holder-verifierのthree-party modelに基づいて構築されたアーキテクチャで、walletのようなものがデータ交換において重要な役割を果たす
- API：独自のAPIやカスタムAPIの上に構築されるアーキテクチャ
- 各グループは3つのシナリオをもとに、どこで相互運用性が達成される可能性のあるかと、その長所と短所を検討
REPORTING GROUP 1
シナリオ3
※SIDI Hub Berlin 2024 Draft p20から引用
- 送信元固定
- 機能するが、送信元固定と宛先固定のどちらをサポートするかはIssuerの判断
- ToIPに関する様々なソリューション
- 一度に解決策を見つけることに固執すべきではない
- ネットワークのネットワークについて議論
- プライバシーは表裏一体であるため、提供するソリューションのプライバシーは考慮が必要
シナリオ6
※SIDI Hub Berlin 2024 Draft p21から引用
- walletはどこにあるか
- どのソリューションも似ている
- ユーザーはどこにいるのか
- ユーザーの同意はどこにあるのか
- データの品質はどうか
- データと発行者の信頼をどのように確立するのか
シナリオ9
※SIDI Hub Berlin 2024 Draft p21から引用
- 課題
- 誰がtranslatorを信頼するのか
- 中間に位置するブローカーが主な問題
- ブローカーは鍵の管理と鍵の完全性を保証する
- APIからAPIへの接続は安全に行われる必要がある
2つのテーマ
- トラストレイヤーが重要
- プライバシーの側面とトラストチェーンを考慮すべき
REPORTING GROUP 2
シナリオ5
※SIDI Hub Berlin 2024 Draft p22から引用
- Federatedは技術的にはAPIに似ているため不要
- ナイジェリア人がGermanyに旅行するを検討
- APIやシステムは、walletにクレデンシャルを発行することが可能で、これはプロキシやAPIを介して直接行える
- プロキシとブローカーを区別すべき
- 「プローカ」はNigeriaのエコシステムにおけるトラストレベルを持つ正式な用語であり、彼らはIssuerからPIIを取得し、信頼できる方法でそれを保持する
- プロキシは、データが通過する主体であり、Issuerからやってきてプロキシを通過する。OpenID4VCの発行は、IDPがIssuerでもあると考えるように設計されている
- プロキシとブローカーは異なる商業的利益、動機、機会を持つかもしれない
- プロキシはトランザクションに署名できるか
- 可能
- プロキシ、ブローカー、およびAPIはクレデンシャルIssuerであるため、それらはすべて、それらが発行するクレデンシャルに署名する必要がある
- もしくはVerifierはAPIに直接アクセスできる
- この場合も直接またはプロキシ/ブローカーを経由
- VerifierはそのAPIのRPになる必要がある
- 第3の選択肢として、API Issuerは独自のwalletを発行することもできる
- Verifierはwalletに、walletはAPIにアクセス
REPORTING GROUP 3
シナリオ4
※SIDI Hub Berlin 2024 Draft p23から引用
- シナリオ3と類似
- IDクレデンシャルの入ったwalletを携帯に入れているユーザがいる
- ユーザはrestAPIしか使えないアプリを使おうとしているが、walletに接続できない
- REST APIを話し、ユーザーID情報を持つコンポーネントを使うこと
- walletにクレデンシャルを発行するのと同じ主体か、代替となる他の主体によって提供される
- 最良の解決策は、宛先で修正することだが、問題はその規模と信頼
- この場合すべての負担がVerifierにある
- REST APIを話す別のコンポーネント（プロキシやブローカー）をシステムに追加すること
- 信頼が不可欠
- スキームに追加する別のコンポーネントがあるため、トラストフレームワークの問題をさらに難しくする可能性がある
- REST APIを話し、ユーザーID情報を持つコンポーネントを使うこと
全体での議論
- 一般的な解決策を導き出せるか、ユースケースに特化したものなのか
- 技術的な実装を通じて、政策やガバナンスの問題を解決しようとしているのか
- 経済学的な観点：エコシステム構築のインセンティブになるのであれば、なぜ宛先で修正しないのか
- ガバナンスは我々が直面しなければならない大きな課題
- データのプライバシーが最優先されるべきだという意見もあった
- プロキシやブローカーを導入することはサイバーセキュリティの脅威をもたらすのか、トレードオフは何か
- SIDI Hubは適切な場か、OWFどうなのか。意思決定者は誰か
- OWFはwalletベースのソリューションを想定しているが、SIDI Hubの設立原則は要件とアーキテクチャの選択に関する国内主権
- 意思決定者はコンテキストに依存する。政府は何が許されるかを推進している
- OWFがGACを消滅させ、ITUとの協力に移行することについて議論
- walletには多くの用途があり、ここで議論しているIDを超える
- SIDIはユースケースの合意取得を促進する役割がある
- 同時に要望も推進する必要がある(推進するための中間的な存在が必要)
提案
- APIやシステムなどの数には限りがあるためマインドタイプのようなものを作る
- プロトコルを登録するだけの簡単なプロセス(逆walletプロキシみたいなもの)
- 短所：別のパーティを導入している
- なぜサードパーティーモデルに移行したのか
- ユーザ中心にするためコンポーネントを1つ追加したが、今度は中央集権化するために別のコンポーネントを追加しようとしている
類推
SIDI Hubは自動車部品店のようなもので：人々が買い物に行けるディスカバリーエリア
- 何を買うべきかという概念はない
- あまり多くのことをしようとしない：何に課金されるのか、誰が何をするのかなどは決めないなど
ID属性(自然人に限る)の動的交換の文脈で、トラスト管理について議論
- 相互運用性を合理化・自動化するためにトラストマネジメントは重要
- トラストフレームワークのデータに関する技術的な相互運用性は、我々にとって重要なトピック
※SIDI Hub Berlin 2024 Draft p25から引用
上記スライドに追加
- GlobalPlatform認証
- ToIP：トラストレジストリプロトコル(TRP)
- TRAIN：Fraunhoferが開発したプロトコルで、その実装はレジトラストと呼ばれる（UNDPと共同）
- AAMVA：ルートオブトラストIssuerレジストリを管理する
- x509に適合する公開鍵のレジストリであり、リストに追加する必要があるかどうかは不明
この作業を調整するグループについて言及した参加者がいた
- Content Authenticity Initiative
- ToIP内のCreator Assertion Community Group
- どのようにx509をVCに接続するか
- x509証明書に挿入するDIDはどうするか
Q：ICAOのデジタルシートはそこに適合するのか
提案：定義が必要であり、ToIPで開発された用語集ツールが良い出発点となる
Minimum Requirementsのセッションは以上で終了
EICで指摘された収穫は以下の通り
- ブローカー/プロキシが必要な場合、再び集中化するリスクがある
- 技術ドメインでの分析は有益だったが、将来的にはあらゆるBOLTSを取り込む必要がある
- ソリューションの決定にはユースケースのコンテキストと商業的な要素が必要
- FederatedとAPIは崩壊する可能性がある（原文Federated and API can be collapsedなんですがこれであってる🧐？）
NZの最近の動向
- 2023年4月にデジタルID規則が成立
- 2021年国会に法案提出され、2023年に可決
- 2005年NZは世界で2番目か3番目にSAML2を導入
- 政府主導のデジタルIDサービスに移行
- AustraliaではDIACCとTrusted Digital IDフレームワークが導入され、試験運用が行われている
- NZはトラストフレームワークと実装を並行して進める
- 政府内の専門知識の低下とコンサルタント会社への依存
- 政権交代
- 来月までに実装
Trust Frameworks
この節はスライドが多く、すべてを転載はしないため本家を見ていただく方が手っ取り早いと思います🐈
- DIACCが過去に行った作業をベースに、相互運用性の4つのレイヤー（法的、組織的、意味的、技術的）について議論
- 続いて、RP/Verifierの観点からの検討事項について議論
- 主に自らのビジネスに集中し、新しい種類のリスク、コンプライアンスにかかるコストと複雑さのバランスをとる必要性などが含まれた
- 事業の規模によって負担は異なり、包摂も課題
- Trust Over IPのガバナンス・ワーキンググループの活動についてのレビュー
- テクノロジーとガバナンスを含む次世代のスタックに取り組んでいる
- 重要なのはシステムの各レイヤーが（システム全体と同様に）ガバナンスを必要としていること
- 新しいエコシステムがToIPのコンポーネントを選択し、ローカルな実装のコントロールを維持することを目標としている
- 彼らが構築しているツールセットはTOIPコンポーネント上に構築された様々なエコシステムが互いに信頼関係を確立し、維持することを可能にする
- 具体的にはTrust Spanning Layerとして知られるプロトコルを介して行われる
- TSLは、トラストレジストリのプロトコルを含むトラストサポートの上位に位置し、多くのタイプのトラストシステムを照会する
- OIXのNick Mothershawは、OIXが8つのトラストフレームワークを分析し、各法域におけるトラストフレームワークを構成する政策分野を特定したことを紹介した
- その結果「General Policy Rules」と「Identity Assurance Policy」という2つの主要テーマと「DNA of Digital ID」として知られるサブ領域が生まれた
- この作業の一環として、それぞれのユースケースで相互運用性を実現するために標準化され、世界的に採用される必要がある5つのgolden credentialタイプを特定
1. National ID Cards
2. Passports
3. Bank Accounts
4. Driving Licenses
5. Telco Accounts - さらに、これらのクレデンシャルは、National IDスキームを持たない管轄区域での識別に不可欠な基盤
- そのような場合、上記のクレデンシャルなどのインプットに基づいて構築された保証レベルを定義するポリシーモデルがある
- 次のステップとしてトラストフレームワークワーキンググループはOIXと連携して、下記のことを行う予定
- 調査結果の公開
- 新しい管轄区域でのさらなる分析の実施
- 比較ツールの構築
- メタデータ交換のポリシー基準の提案
- ポリシーメタデータ交換とは何か？
- トラストフレームワークのマッピングと分析は、メタデータ交換要件の基礎となる
- 最終的にはトランザクションごとに動的なやり取りを可能にするテクノロジー(Smart Walletsなど)を促進
- エコシステムで必要となるすべての行為者とルールセットをマッピングすると、その多くが実際にeIDAS2.0のフレームワークで定義されていることが分析で示されているため比較的包括的な基盤となる
Identifying Other Gaps
ガバナンスとメトリクスのワークストリームに管理される、相互運用性に対する障害リストに新たな懸念を追加することに着目
- 国の収斂に追加
- Bhutan
- UNHCR
- African Union：54/55カ国で汎アフリカの枠組みが策定された
- 彼らはアドバイスを求めている
- 彼らを会話に参加させるべき
- ASEAN
- GCC
- Bahrain, Oman, Saudi, UAE (Golf cooperation)や人の自由な移動
Use Case Elaboration
特定のユースケースを確認し、次の点を評価
- 分析に十分なリストを作成する
- それぞれが「チャンピオン」ユースケースを代表することに対する会場の意欲
- ユースケースのサブセットについて詳しく説明する
※この節も主要なメモはスライドにあり、すべてを転載はしないため本家を見てください🐈
その他のトピック
- patient ID:：個人と紐づけ
- 国内の避難民
- 奴隷制
- ID2020(UNICEF)のチェック
- 平等に認められたID
- 機関の権限委譲
- 法人登録/口座開設
検討対象
- 不安定/疎外された声
- 2カ国以上の国が関与する問題
- デバイスへの差別的アクセスを伴うユースケース
- CYNFINフレームワーク
- Kaliya Youngの「Domains of Identity」で提案されているフレームワークに従うべきではないか
- ユーザ/人間に尋ねる
- 他のユースケースへの依存
- 解決/貢献する資格のある人を含める
その後
下記のようにグループでユースケースを具体化
※SIDI Hub Berlin 2024 Draft p38から引用
Critical Research Questions and How to Fund Them
Cape Townでの結果をベースに「独立した研究者が分析する必要のある質問は何か」という質問をした
例：過去の資金提供要請の「Asks」
- 管轄区域をまたいだトラストフレームワーク分析のスケーリング
- RPのガバナンス
- チャンピオン ユースケースに関するフィールド調査
Berlin
- プライバシー、トラッキング、不正使用に対するsuper trackingの救済策
- 例：ベストプラクティスと人権の保護
- バインディング/証明/認証中のさまざまな攻撃ベクトルの検出
- デジタルIDの信号は従来の検証方法と以上に効果的か
- 経済的な疑問: Verifierは節約し、Issuerはコストを負担する
- コストと負担者へ利益をどう転嫁するか
- 開発ツールとしてのIDの使用：アイデンティティと社会経済開発の相関関係/因果関係
- 仮説をテストする
- 生体認証と暗号化はエコシステム全体を支える：研究の信頼性と目的に合致し続けること
- 偽の情報や誤報を回避するための教育
- 例：アメリカ/ヨーロッパのFB