SIDI Hub - ベルリンレポートを読む（７）

こんにちは、富士榮です。

なかなか終わらないSIDI Hubベルリンレポートです。再来週の東京サミットに間に合うかな・・・

ようやくユースケースが終わり、相互運用性を確保するための最低限の要件（Minimum Requirements for Interoperability/MR4I）のパートです。

Minimum Technical Requirements - Debora

To abstract the minimum requirement for global interoperability is an incredibly difficult task. We are looking not only at how to integrate different types of ID systems but also the abstract requirements that underpin the goal. We believe that the goal is a Network of Networks - inclusive of many different networks because a founding principle of SIDI Hub is that we should not tell jurisdictions how to build their systems.

グローバルな相互運用性の最低要件を抽出することは、非常に困難な作業です。私たちは、異なるタイプのIDシステムを統合する方法だけでなく、その目標を支える抽象的な要件についても検討しています。私たちは、この目標は「ネットワークのネットワーク」であるべきだと考えています。なぜなら、SIDI Hubの設立理念は、管轄区域がシステムを構築する方法を指示すべきではないというものです。

相互運用性の課題は非常に難しい問題です。ネットワークのネットワーク、ネットワーク間を繋ぐためのネットワーク、考えてみるとまさにインターネットですね。

GAINもそうですが、やはりインターネットにアイデンティティのレイヤを載せていく、というアプローチが最終的には必要になるのではないかと思います。それまでの間はそれぞれのアイデンティティ・ネットワークを連携させるためのインターコネクトをどうデザインするのか、というところに着目し対応し続けないといけないのかもしれません。

In this effort, there are two protocol types:

• Trust services layers (the control plane)
• ID info exchange (the data plane)

While the RP Registration conversation focused on the former, the SIDI Hub Minimum Technical Requirements session focused on the latter and did so using group exercises to explore nine scenarios in 3 groups (each group had 3x scenarios).

この取り組みには、2つのプロトコルタイプがあります。

• トラストサービスレイヤー（コントロールプレーン）
• ID情報交換（データプレーン）

RP登録に関する会話では前者が中心でしたが、SIDI Hubの最低技術要件セッションでは後者が中心となり、3つのグループに分かれて9つのシナリオを検討するグループ演習が行われました（各グループには3つのシナリオがありました）。

相互運用性を担保するためには、ルール面（トラストフレームワークやガバナンスなど）とテクニカル面（データ構造、スキーマ、署名形式、通信プロトコルなど）の両方について相互に合意が取られることが必要ですが、こちらのパートではテクニカル面にフォーカスしています。一方でルール面については後ほど出てくるTrust Framework Mappingのワークストリームで対応を進めています。

The simple terms used in this diagram were taken to mean:

• Federated = architectures built on standards-based federation, e.g., SAML and OIDC
• Wallet-Based = architectures built on a “three-party model” of issuer-holder-verifier in which something akin to a “wallet” plays a key role in data exchange, e.g., the EUDI ecosystem emerging in the European Union.
• API = architectures built atop another proprietary or custom API, e.g., the NIN in Nigeria

Each group, armed with their three scenarios, was asked to consider where interoperability might be achieved and the pros and cons of those different approaches.

この図で使用されているシンプルな用語は、次のような意味で使用されている。

• フェデレーション型 = 標準ベースのフェデレーション、例えばSAMLやOIDCを基盤とするアーキテクチャ
• ウォレット型 = 発行者、保持者、検証者の「三者モデル」を基盤とするアーキテクチャで、データ交換において「ウォレット」に似たものが重要な役割を果たすもの、例えば欧州連合で台頭しつつあるEUDIエコシステム。
• API = 別の独自仕様またはカスタム仕様の API を基盤とするアーキテクチャ、例えばナイジェリアの NIN

3つのシナリオを武器に、各グループは相互運用性が実現できる可能性がある場所と、それらの異なるアプローチの利点と欠点を検討するように求められました。

大きく分けてアイデンティティを連携するための方式はフェデレーション、ウォレット、APIの3類型があるので、それらのアイデンティティシステム間を接続しようとすると、それぞれについてどのようなことが必要になるのかを検討していくわけです。

REPORTING GROUP 1:

Scenario 3: 

Fix at source:

• It works. It becomes a matter of the issuer deciding which one to support
• Different solutions on ToIP:
• We should not be stuck trying to find solutions in one shot. We are talking about networks of networks.
• We have one layer of understanding first before jumping to more.
• Privacy is the other side of the coin. We need to work on that for all the solutions we provide.

ソースでの修正：

• 機能します。どちらをサポートするかは発行者が決定すればよいだけの問題です
• ToIPではさまざまなソリューションが提案されています：
• 一発で解決策を見つけようとして立ち往生すべきではありません。私たちはネットワークのネットワークについて話しているのです。
• さらに踏み込む前に、まず理解すべきことが1つあります。
• プライバシーは表裏一体です。私たちが提供するすべてのソリューションにおいて、プライバシーにも取り組む必要があります。

このシナリオはWallet（ウォレット型）からRP（フェデレーション型）への接続を行う際にソース側となるWalletと宛先となるRPのそれぞれで対応するにはどうするか、という議論をしています。

まぁ、単純な話、ソース側のWalletがOP/IdPとしてRPに対してid_tokenやSAML Assertionを発行すればいい話です。もしくはRP側がIHV（Issuer/Holder/Verifier）モデルにおけるVerifierとしての機能をもてばいいわけです。

Scenario 6:

• Where is the wallet?
• All solutions are similar; they are variations. Where is the user? Where is the user consent? Quality of data? How do you establish trust in the data and the issuer?
• ウォレットはどこにあるのか？
• すべてのソリューションは類似しており、バリエーションにすぎない。ユーザーはどこにいるのか？ユーザーの同意はどこにあるのか？データの品質は？データと発行者の信頼をどのように確立するのか？

次のシナリオはAPIとRPの間の連携です。

今回はソース側がAPIなので、単純にREST APIベースのIDサービスならOpenID Providerになればいいじゃないか、という話です。もしくはRP側がREST API Clientとして構成されれば問題ないですよね、という話。

Deboraも現地の声としてレポートしていますが、フェデレーション型のIdPはAPIベースのIdPの一類型でもあるので単にプロトコル合わせをしているだけですね。

Scenario 9:

• Issue: who trusts the translator? Broker in the middle is the main issue. The broker ensures key management and key integrity.
• APIs to APIs need to be securely done

Two themes:

• The trust layer is important
• privacy side of things and chain of trusts should be considered
• 問題：誰が翻訳者を信頼するのか？仲介者が存在することが主な問題である。仲介者は、鍵の管理と鍵の整合性を確保する。
• APIとAPI間の通信は安全に行う必要がある

2つのテーマ：

• 信頼レイヤーは重要である
• プライバシーの側面と信頼の連鎖を考慮すべきである

API同士の連携においても互換性がなければ先ほどのフェデレーションーAPIの間の話と同じです。ここでブローカーモデルが登場しますが、いわゆるプロトコルコンバーターを中間に介在させることで、どうやって中間者を信頼するのか、直接的にソース・デスティネーションの間で信頼関係が作れなくなることをどう考えるのか、などの課題が浮き上がってきます。

ということで、まずは一つ目のグループでの議論の内容について見ていきました。

次回は2つ目のグループの議論も見ていきましょう。