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

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

いよいよ今週はSIDI Hub東京サミットです。

そして明日は前々夜祭も開催されますので、こちらを含め準備も大詰めです。

前回に引き続きベルリンレポートを見ていきますが、今回は別れて討議したグループのもう一つを見ていきます。

Assumption: we ignore trust.

This group spent their time really drilling into one of the scenarios.

どうやらこちらのグループは一つのシナリオを深掘りしたようです。

• ‘Federated’ is not needed as it is technically similar to APIs (we can cut out that whole third piece in this diagram) 

• The group explored the example of a Nigerian traveling to Germany

• An API or system sitting in front could issue a credential to the wallet. This can be done directly via proxy or API.

• We should make a distinction between a proxy and a broker. “Broker” is a formal term with a level of trust in the Nigerian ecosystem: they acquire the PII from the issuer and retain it in a trusted fashion. The proxy would be an entity through which the data would pass – it would come from the issuer and pass through the proxy. OpenID4VC issuance is designed to think that IDPs are also issuers. 

• Proxies and brokers may have different commercial interests/drivers/opportunities 

• Is the Proxy able to sign the transaction? 

• Yes, the proxy, broker, and API are the credential issuers, so they all need to sign a credential that they issue.

• Or, the verifier could directly access the API. Again, it is done directly or through a proxy or broker. The verifier needs to become an RP to that API.
• 3rd option: this API issuer could also issue its own wallet. Verifier to wallet and wallet to APIs. 

• Federatedは技術的にはAPIに似ているので必要ない（この図では3つ目のピース全体をカットできる）
• グループはナイジェリア人がドイツに旅行する例を検討した。
• 前面にあるAPIやシステムは、ウォレットにクレデンシャルを発行することができる。これはプロキシやAPIを介して直接行うことができる。
• プロキシとブローカーを区別すべきである。「ブローカー」はナイジェリアのエコシステムにおける信頼のレベルを持つ正式な用語であり、彼らは発行者からPIIを取得し、信頼できる方法でそれを保持する。プロキシは、データが通過するエンティティであり、発行者からやってきてプロキシを通過する。OpenID4VCの発行は、IDPが発行者でもあると考えるように設計されている。 

• 代理人とブローカーは異なる商業的利益／推進力／機会を持っている可能性がある。 

• プロキシはトランザクションに署名できるか？ 

• はい、プロキシ、ブローカー、およびAPIはクレデンシャル発行者であるため、それらが 発行するクレデンシャルに署名する必要がある。

• あるいは、ベリファイアはAPIに直接アクセスできる。この場合も、直接またはプロキシまたはブローカを経由して行われる。検証者はその API の RP になる必要がある。
• 第3の選択肢：このAPI発行者は、独自のウォレットを発行することもできる。検証者はウォレットに、ウォレットはAPIにアクセスする。

このグループではAPIからウォレットへの間のやり取りを検討しています。注目すべきはインターフェイスの調整というよりもプロキシやブローカーの介在について検討が行われた点です。この議論のように既存システムへウォレットモデルを入れていこうとすると必ず出てくるのがプロキシやブローカーです。ただ、必ず課題になるのが誰がやり取りするデータへ署名をするのか？という問題です。Verifierは基本的にIssuerが発行していることを確認したいわけですが、間にプロキシやブローカーが入ることでモデルが崩れてしまうことへの対応が必要となります。

次は3つ目のグループです。こちらは先ほどの逆パターンでウォレットから発行されるクレデンシャルをAPIが受け取るモデルです。

• This is similar to scenario 3. There is a user who has a wallet on their phone with an ID credential. The user is trying to use an app that can only use restAPI, and it’s not able to connect to the wallet.
• One option is to use a component that speaks REST API and has the user ID information. This would be provided by the same entity that issues the credential to the wallet or some other entity as an alternative.
• The best solution is to fix it at the destination. The problem is scale and trust. All the burden is on verifiers!
• Another proposal: add another component to the system (proxy or broker) that speaks restAPI … but it has to be trusted. That can fail. This can make the Trust Framework problem even harder as there is another component to add to the scheme!
• これはシナリオ3と似ている。携帯電話に ID クレデンシャルを持つウォレットを持っているユーザーがいます。ユーザーはrestAPIしか使えないアプリを使おうとしていますが、ウォレットに接続できません。
• 一つの選択肢は、REST APIを話し、ユーザーID情報を持つコンポーネントを使うことです。これは、ウォレットにクレデンシャルを発行するのと同じエンティティか、代替となる他のエンティティによって提供されるでしょう。
• 最良の解決策は、デスティネーションで修正することである。問題は規模と信頼である。すべての負担は検証者にある！
• 別の提案：システムにrestAPIを話す別のコンポーネント（プロキシやブローカー）を追加する......しかし、それは信頼されなければならない。しかし、それは信頼されなければならない。これは、スキームに追加する別のコンポーネントがあるため、トラストフレームワークの問題をさらに難しくする可能性がある！

まぁ、単純にウォレットからのPresentationを受け付けられるようにAPIを作ればいいって話ですね。そしてここでもプロキシやブローカーの話が出てきます。暫定策としてはいいんだと思いますけどね。トラストフレームワークの問題は出てきますが、実際にシステム化をするときはある程度コントロールできる範囲からスタートすることになるはずですし。

The larger group then explored a number of questions together.

• Can you get to some generic solution? Is it use-case specific?
• Are we trying to solve a policy/governance issue through technical implementation?
• Economics: why not do the fix at the destination if that incentivizes the building of an ecosystem?
• Governance is a big challenge we have to face.
• Some asserted that Data privacy must come first
• Does introducing a proxy or a broker introduce cybersecurity threats? What are the trade-offs?
• Is SIDI Hub the right place? What about the OWF? Who are decision-makers?
• OWF assumes a wallet-based solution, but a SIDI Hub founding principle is domestic sovereignty over requirements and architectural choices
• Decision-makers depend on the context. The user and jurisdiction have to drive the rest of it. Governments are driving what is allowed.
• Discussed the OWF killing GAC and moving to work with ITU. Wallets have many applications and go beyond ID, which is what we discuss here.
• SIDI has a role in driving consensus on the use cases. Some components might live in
• OWF and other organizations. We need to drive consensus BUT also drive demands. Someone in the middle that drives demands.

その後、大人数のグループでいくつかの質問を一緒に探った。

• 一般的な解決策にたどり着けるか？ユースケースに特化したものなのか？
• 技術的な実装を通じて、政策やガバナンスの問題を解決しようとしているのか？
• 経済学：エコシステム構築のインセンティブになるのであれば、なぜ目的地で修正を行わないのか？
• ガバナンスは、我々が直面しなければならない大きな課題である。
• データのプライバシーが最優先されなければならないとの意見も
• プロキシやブローカーの導入はサイバーセキュリティの脅威をもたらすか？トレードオフは何か？
• SIDI Hubは適切な場所か？OWFはどうなのか？意思決定者は誰か？
• OWFはウォレットベースのソリューションを想定しているが、SIDI Hub創設の原則は、要件とアーキテクチャの選択に関する国内主権である。
• 意思決定者は文脈に依存する。ユーザーと管轄区域が残りの部分を推進しなければならない。政府は何が許されるかを推進している。
• OWFがGACを殺し、ITUとの協力に移行することについて議論。ウォレットには多くの用途があり、ここで議論しているIDを超えるものである。
• SIDIはユースケースのコンセンサスを促進する役割を担っている。いくつかのコンポーネントは
• OWFや他の組織にも存在するかもしれない。我々はコンセンサスを促進する必要があるが、同時に需要も促進する必要がある。要求を推進する中間にいる誰か。

 

まぁ、なかなか結論が出る話ではありませんが、いろいろな論点が見えてきたのは良いことではないかと思います。まだまだ混乱していますね。これは東京や次のリオデジャネイロでも議論は続くことになると思われます。

Suggestion: we have a finite number of APIs, systems, etc. Create things like mind type. It is a simple process of registering the protocol. It is like a reverse wallet proxy. Cons: we are introducing another party. Why did I move to the 3rd party model? I have added one component to make it user-centric, and now we are adding another component to make it centralized!

Analogy: SIDI Hub is like an auto part store: it is a discovery area where people can go shopping. No notion of what you should buy. Do not try to do too much: we don’t decide what is charged, who is doing what, etc.

We discussed Trust Management in the context of dynamic exchange of ID attributes (limited to Natural Persons)

• Trust Management is important so that interoperability can be streamlined and automated
• Technology interoperability around Trust Framework data is an important topic for us

提案：APIやシステムなどの数には限りがある。マインドタイプのようなものを作る。プロトコルを登録するだけの簡単な作業だ。逆ウォレットプロキシみたいなものだ。短所：別のパーティを導入することになる。なぜサードパーティーモデルに移行したのか？ユーザー中心型にするために1つのコンポーネントを追加したが、今度は中央集権型にするために別のコンポーネントを追加しようとしている！

例え話だ： SIDI Hubは自動車部品店のようなもので、人々が買い物に行けるディスカバリー・エリアです。何を買うべきかという概念はありません。あまり多くのことをしようとしない：何が課金されるのか、誰が何をするのかなどは決めない。

ID属性（自然人に限る）の動的交換の文脈で、信頼管理について議論した。

• 相互運用性を合理化・自動化するためには、Trust Management が重要である。
• トラストフレームワークのデータに関する技術的な相互運用性は、我々にとって重要なトピックである。

いろいろなデザインのパターンは見えてきましたが、そもそも論としてそれは本末転倒では？というところも見つつデザインを進めていかないとダメですねぇ。。