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

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

今日からワシントンD.C.での会合が始まるSIDI Hubのワールドツアー（？）ですが、第1回のケープタウン会合、第2回のベルリンのレポートが公開されており、ここまでケープタウンのレポートをみなさんと一緒にみてきました。

参考）各レポートはこちらで紹介していますので原本はこちらをみてください。

https://idmlab.eidentity.jp/2024/08/sidi-hub.html

第3回目となるワシントンD.C.会合の前までにベルリン会合の概要だけはみておきましょう。（ちなみに私も現地で参加しましたが、各テーマごとに会場でディスカッション〜アイテムへまとめていく、というワークショップ形式なので個人的にはまとめる時間が取れなかったのでこのレポートは相当嬉しいです）

ということで見ていきます。（まずは全体サマリーと技術に関連するところまでを）

サマリー

The SIDI Hub Summit in Berlin, Germany, followed the 2023 inaugural event in Paris and was the second of 5 Summits in 2024. The five summits are critical forums for progressing the five workstreams throughout the year.

ドイツのベルリンで開催されたSIDIハブ・サミットは、2023年のパリでの初開催に続くもので、2024年に開催される5つのサミットの2番目となる。この5つのサミットは、年間を通じて5つのワークストリームを推進するための重要なフォーラムである。 

5つのワークストリームはこれまでも書きましたが、以下の通りです。

1. Champion Use Cases
2. Trust Framework Mapping
3. Minimum Technical Requirements
4. Governance
5. Metrics of Success

Approximately 50 attendees joined SIDI Hub Berlin on June 3, 2024 - the day before the European Identity and Cloud Conference (EIC). Due to the nature of who attends EIC, far more technical experts attended the Berlin Summit, whereas the Paris and Cape Town Summits included heavier representation from Governments. For this reason, the agenda emphasized naming barriers to interoperability, refining the approach for technical requirements gathering, and the interplay between Trust Frameworks and protocols. It also included a discussion on Champion Use Cases - particularly for the European context - and building a shared research

agenda. The feedback from these sessions will shape workstream activities and the structure of Summits to follow.

欧州アイデンティティ・クラウド会議（EIC）の前日である2024年6月3日、SIDIハブ・ベルリンに約50名の参加者が集まった。パリとケープタウン・サミットでは政府関係者が多く参加したのに対し、EICでは技術専門家が多く参加した。

このため、アジェンダでは、相互運用性の障壁を挙げること、技術要件収集のアプローチを洗練させること、トラストフレームワークとプロトコルの相互作用が強調された。また、チャンピオンのユースケース（特に欧州の状況）についての議論や、

の共有研究アジェンダの構築も行われた。これらのセッションからのフィードバックは、ワークストリームの活動と、その後のサミットの構成を形作ることになる。

→レポートに書いている通り、European Identity & Cloud Conference（EIC）の前日に開催されたため、ケープタウンに比べると少し技術寄りだったかもしれません。また、アフリカに比べるとEUという一つの経済圏がすでに構築されていることがユースケースを考える上での特徴点となるのかもしれません。

主な成果

This section synthesizes that information into the high-level themes that the co-organizers took away from the event. Part 2 of this report consolidates the Rapporteur’s notes and many of the slides from the event itself.

本セクションでは、これらの情報を統合し、共同主催者がこのイベントから持ち帰ったハイレベルなテーマを紹介する。本報告書の第2部では、報告者のメモとイベントでのスライドをまとめた。

 

アーキテクチャのタイプ 

While there are vast numbers of configurations, profiles, and proprietary APIs related to the transmission of identity data, there are a limited number of architectural archetypes that need to be able to interoperate globally. In particular, those that are based on API connections between Identity Providers (IdPs) and Relying Parties (RP’s) and those that are mediated by an agent (“wallet”) that holds credentials issued to an end-user. Interventions to ensure interoperability of these solutions include options at the source (the IdP or the wallet) or at the destination (the Relying Party or Verifier). SIDI Hub participants remain in active discussion about whether there is a need for broad guidance about which interventions may be more appropriate or if the group should support both “fix-at-source” and “fix-at-destination” models.

ID データの伝送に関連する構成、プロファイル、および独自の API は膨大な数に上るが、グローバルに相互運用でき る必要があるアーキテクチャの原型は限られている。特に、ID プロバイダ（IdP）と依拠当事者（RP）間の API 接続に基づくもの、およびエンドユー ザに発行されたクレデンシャルを保持するエージェント（「ウォレット」）に仲介されるものである。これらのソリューションの相互運用性を確保するための介入には、ソース（IdP またはウォレット）またはデスティネーション（依拠当事者または検証者）におけるオプションが含まれる。SIDI ハブの参加者は、どの介入がより適切であるかについての広範なガイダンスが必要であるか、またはグループが「送信元での固定」と「宛先での固定」の両方のモデルをサポートすべきかについて、活発な議論を続けている。 

→従来のIdPとRPのモデルに加えてウォレットが間に入るモデルを考える場合の相互運用性等に関する深掘りが必要になる、という話です。抽象度を上げていくと単純に送信者と受信者になりますが、それぞれの特性がアーキテクチャによって異なるため相互運用のためのプロトコルや信頼性を確保するためのトラストフレームワークの互換性なども考慮する必要があります。

Verifierがマーケットを作る

A significant theme of feedback at both SIDI Hub and the EIC event that followed was that Verifiers (in this paragraph, the term is used interchangeably with Relying Party) represent the more challenging side of the marketplace - and that adding complexity or risk to Verifier implementations may make it harder to do business. This would lead to:

1. Slow adoption and use

2. Barriers to entry in multiple verticals

3. Exacerbated inclusion issues for smaller players.

Any solution needs to address these risks. On the other hand, SIDI Hub participants are also keenly aware that once an ecosystem is functioning, verifiers stand to benefit more than the issuers, who often bear the cost of implementation. The group was eager to explore opportunities to address this imbalance.

SIDI ハブとそれに続く EIC イベントでのフィードバックの重要なテーマは、検証者（この段落で は、この用語を依拠当事者と同じ意味で使用する）が市場のより困難な側面を代表しており、検証者の実装に複雑性やリスクを加えると、ビジネスが困難になる可能性があるということであった。その結果、以下のことが起こる：

1. 導入と利用の遅れ

2. 複数の業種における参入障壁

3. 小規模プレーヤーのインクルージョンの問題の悪化。

どのような解決策も、これらのリスクに対処する必要がある。他方、SIDI ハブの参加者は、エコシステムがいったん機能すれば、多くの場合、導入コストを負担す る発行者よりも検証者の方がより多くの利益を得る立場にあることも強く認識している。グループは、この不均衡に対処する機会を探ることに熱心であった。

→この話もいつも議論になるところですね。ビジネスモデルをどうするか、という話です。現状ではやはりVerifierが一番便益を得ることができそうだ、ということなので基盤やサービスを開発するときは十分に年頭におく必要がありそうです。

ユースケースの根拠となる要件（あるいは「抽象化の危険性）

 In exploring the set of 9 communication patterns between architectural archetypes, the Minimum Technical Requirements workstream concluded there was a limit to how much could reasonably be accomplished without the solid definition of a use case. As participants have pointed out, examples of successful cross-border interoperability efforts have been rooted in a specific problem space: passports for border crossings and air travel, credit card payments, a unified SAML profile for global access to educational institutions, etc. For this reason, the SIDI Hub Community continues its global listening and will work to define a set of 3-4 “Champion Use Cases” (and dive deeper into their respective requirements) throughout the next several Summits.

アーキテクチャ原型間の9つの通信パターンを検討する中で、最小技術要件ワークストリームは、ユースケースの確固とした定義なしに合理的に達成できることには限界があると結論づけた。参加者が指摘したように、国境を越えた相互運用性の取り組みが成功した例は、特定の問題空間に根ざしたものであった。たとえば、国境通過や航空旅行のためのパスポート、クレジットカード決済、教育機関へのグローバルアクセスのための統一SAMLプロファイルなどである。このような理由から、SIDIハブコミュニティはグローバルな聞き取り調査を継続し、今後数回のサミットを通じて、3～4件の「チャンピオンユースケース」の定義（およびそれぞれの要件への深掘り）に取り組む予定である。

→難しいところです。抽象化をしないと汎用的で互換性のあるシステムを構築することは難しくなりますが、ユースケース分析を進めれば進めるほど、「ユースケース依存」の話が大きくkなってくる、ということです。この辺りはアーキテクトの役割になるかと思います。

ブローカーとプロキシ

 Given the expectation that these archetypes continue to exist because states make sovereign choices, it is prudent to assume that interoperability may depend upon brokers and proxies. While this undermines any attempt at a global, fully decentralized, and peer-to-peer architecture - and it necessitates careful consideration for privacy (i.e., masked data) and governance - it does not necessitate a centralized database or “phone home” architecture.

The terms “Broker” and “Proxy” should not be used interchangeably. Instead, the former may imply a specific market opportunity and commercial interest with pros and cons. Meanwhile, “Proxy” is intended to be a pass-through technical component and implies nothing about a business model.

国家が主権的な選択をするからこそ、こうした原型が存在し続けるという期待を考えれば、相互運用性はブローカーやプロキシに依存する可能性があると考えるのが賢明だ。このことは、グローバルで、完全に分散化された、ピアツーピアのアーキテクチャの試みを損なうものであり、プライバシー（すなわち、マスクされたデータ）とガバナンスに対する慎重な配慮を必要とするものであるが、集中化されたデータベースや「フォンホーム」アーキテクチャを必要とするものではない。

ブローカー 「と 」プロキシという用語は、同じ意味で使うべきではなく、前者は特定の市場機会を意味し、長所と短所のある商業的利益を意味する。一方、「プロキシ」はパススルーの技術コンポーネントを意図しており、ビジネスモデルについては何も示唆しない。 

 →システム構成を考えるとブローカーやプロキシを配置するモデルが安易で現実的な解になるのは想像に硬くないのですが、どうしても依存度が上がってしまう（場合によってはSPOFとなってしまう）ことはリスクとして捉えておかないといけないと思います。また、ブローカーとプロキシの違いはビジネス的な価値の創出が行われるかどうか、というところで区切りをつけた、ということもこれからのアーキテクチャの詳細化に向けて重要な合意事項だったと思います。

他にもトラストフレームワークや政府の関与のあり方などもまとめられていますが、この辺りは次回にでも。まずは技術にフォーカスした部分だけを先行してお届けしました。