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 が重要である。
• トラストフレームワークのデータに関する技術的な相互運用性は、我々にとって重要なトピックである。

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

Auth0 Labの生成AI向けの認証・認可のサンプルを試す

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

イベント続きでほぼ毎日プレゼンしている気がしますが、ストレスが溜まるので現実逃避です。

Auth0が生成AI向けの認証・認可に関するサイトをオープンしました。

https://www.auth0.ai/

まぁ、もともとOpenAIの認証はAuth0だったこともあり、この分野は以前から取り組んできていたんだと思います。

生成AIの認証・認可といっても単純にチャットボットへのログインだけでは面白くないわけで、ユーザの代わりにAPIを読んだり、RAGの認証をしたり、ユーザの確認を非同期で行ったり、とやることはたくさんあります。

この辺りをAuth0 Labでパッケージングしたサンプルを公開している、ということですね。

Auth0 Labのアカウントで先ほどのサイトのデモを試すと、ChatGPTもどきのアプリケーションが動きます。

なお、このソースコードはこちらのgithubレポジトリで公開されているので、自分のローカル環境でも試すことができます。

https://github.com/auth0-lab/market0

こういうフロントエンドとAPI管理周りは生成AIのエンジンとは独立したレイヤですが、自前で作るのは面倒な領域なのでこういうものがあると便利ですね。

SD-JWT draft 13がリリース

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

SD-JWTのdraft 13が10/18に発行されています。

https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/

draft12→13での変更点はこの辺り。

   -13

   *  WGLC (part 1) updates
   *  Rewrote introduction
   *  Added note on algorithm for Holder's verification of the SD-JWT

これまでは用途は問わない、としていましたが今回からJWTの選択的情報開示がプライマリユースケースだと明記されています

This specification defines a mechanism for the selective disclosure of individual elements of a JSON-encoded data structure used as the payload of a JSON Web Signature (JWS).  The primary use case is the selective disclosure of JSON Web Token (JWT) claims.

イントロダクションが全面的に書き換えられています

明示的な型付けの部分でtypに加えてペイロードのコンテンツタイプ（cty）に関する記述が追加された

Use of the cty content type header parameter to indicate the content type of the SD-JWT payload can also be used to distinguish different types of JSON objects, or different kinds of JWT Claim Sets. 

 

このくらいかな、と。

IPSIE WGが爆誕（企業向けのIAMプロファイル策定に向けたWG）

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

ちょっと前に某MLで話題になっていたIPSIE（イプシー） WG（Interoperability Profiling for Secure Identity in the Enterprise Working Group）がOpenID Foundationに爆誕しています。

https://openid.net/announcing-ipsie-working-group/

Identity and Access Management (IAM) within the enterprise is a multifaceted endeavor, as indicated by the growing Body of Knowledge maintained by IDPro. There is a broad range of specifications that are relevant to securing the many IAM functions that underpin operations. Some of these are OIDF standards - like OpenID Connect, FAPI, and Shared Signals - while others are maintained in different standards bodies. For example, IPSIE has already identified the IETF's OAuth 2.0 and System for Cross-Domain Identity Management (SCIM) as relevant to their initial scope (below). But these specifications are written to support many contexts and use cases; they contain optionality that reduces the likelihood that independent implementations will interoperate. 

The IPSIE Working Group will develop secure-by-design profiles of these existing specifications with a primary goal of achieving interoperability across enterprise implementations.

企業内のアイデンティティとアクセス管理（IAM）は多面的な取り組みである。運用を支える多くの IAM 機能のセキュリティ確保に関連する幅広い仕様がある。OpenID Connect、FAPI、Shared Signalsなどの OIDF 標準もあれば、別の標準化団体で維持されているものもある。例えば、IPSIEはすでにIETFのOAuth 2.0と System for Cross-Domain Identity Management (SCIM)を初期スコープに関連するものとして特定している（下記）。しかし、これらの仕様は多くのコンテキストやユースケースをサポートするように書かれており、独立した実装が相互運用できる可能性を低くするオプション性を含んでいる。

IPSIE ワーキンググループは、企業実装間の相互運用性を達成することを主な目的として、これら 既存の仕様のセキュアバイデザインプロファイルを開発する。 

名前の通り、エンタープライズシナリオにおける各種仕様のIDPro/BoKのベストプラクティスをプロファイルとしてまとめていきましょう！というプロファイルですね。（プロファイル＝プロトコルや仕様の組み合わせ。ここでいうとOpenID Connect、FAPI、OAuthやSCIMなど）

これはいよいよCIDProが流行る時代が来るのかもしれません。

そういえば最近メンテナンスできていませんが、IDProのBody of Knowledgeの日本語化プロジェクトもありますので、ご興味のある方はお声がけください。（一応、公認日本語化プロジェクトです）

https://idpro.jp/

最新化したいんですが、マンパワー不足です。

G7メンバー国のデジタルアイデンティティガイドラインのマッピングが発表されています

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

G7メンバー国でやっているIdentityガイドラインのマッピングエクセサイズのレポートが出ています。

https://www.oecd.org/en/publications/g7-mapping-exercise-of-digital-identity-approaches_56fd4e94-en.html

This report presents a mapping exercise to identify commonalities in digital identity approaches among G7 members that can support future interoperability efforts. These commonalities include shared concepts and definitions, the use of international technical standards and approaches to levels of assurance. The report was prepared at the request of the 2024 Italian G7 Presidency and G7 members, to inform discussions within the G7 Digital and Technology Working Group. It was launched during the G7 Digital and Technology Ministerial Meeting in Como, Italy, on 15 October 2024.

本報告書は、将来の相互運用性の取り組みを支援することができる、G7 メンバー間のデジタル ID アプローチの共通点を特定するためのマッピング作業を提示する。これらの共通点には、共有される概念および定義、国際技術標準の使用、保証レベルへのアプロ ーチなどが含まれる。この報告書は、2024 年イタリア G7 議長国および G7 メンバーの要請により、G7 デジタル・ テクノロジー作業部会での議論に情報を提供するために作成された。2024年10月15日にイタリアのコモで開催されたG7デジタル・テクノロジー閣僚会合で発表された。 

中身は順次見ていきたいと思いますが、カナダ、欧州、日本、英国、米国のそれぞれのガイドライン（例えば日本ならDS-500、米国ならNIST SP800-63-3）の比較・マッピングをしています。

これはSIDI Hubのワークストリームとも協調していくべき動きで、今後国境を跨いだコミュニケーションの中でデジタルアイデンティティがシームレスに利用できる世の中の実現に向けて非常に重要なステップですね。

Credential Exchange Format/Protocolの新Working draft

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

Authenticate 2024が10/14-16で開催されましたね。

各社イベントに向けて色々と実装をして発表にこぎつける、というのは世の常ですが、これはもちろんスペックライターについても同じようです。

ということで満を持して発表されましたね。

https://fidoalliance.org/specifications-credential-exchange-specifications/

• Credential Exchange Format
• Credential Exchange Protocol

これらの新しいWorking draftが今週金曜日18日にリリースされるようです。

以前から触れていたCredential Exchange Specificationsですがパスキーのインポート・エクスポートのための仕様という冠で登場って感じですかね。

同期パスキーなど色々と新しい考え方が盛り込まれてきたFIDO関係ですが、NISTを含めちゃんと利用ガイドを整えていかないといけませんね。（まぁ、そもそも鍵はデバイスから出ないっていうのが原則だったわけなので、考え方を変えていかないといけません）

信頼できるAIに関するG7のアクションプラン

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

10/9〜11にローマで開催されたG7のラウンドテーブルでDFFT（Data Free Flow with Trust）文脈でTrustwothy AIに関するアクションプランについての宣言が出ていますね。

こちらEUのプレスですが。

Data Protection Authorities Collaborate to Shape the Future of AI and Privacy

https://www.edps.europa.eu/press-publications/press-news/press-releases/2024/g7-roundtable-2024-data-protection-authorities-collaborate-shape-future-ai-and-privacy_en

ざっくりですが、

• 第4回G7データ保護当局（DPA）ラウンドテーブルがローマで開催された
• イタリアのデータ保護当局が主催し、カナダ、フランス、ドイツ、日本、英国、米国、欧州データ保護委員会（EDPB）、およびEDPSのプライバシーおよびデータ保護規制当局が一堂に会した
• 倫理的で信頼性の高いAIの開発におけるデータ保護の重要性に関するグローバルな議論の形成に貢献することが目標だった
• DFFT、新興技術の影響、執行協力の3つの主要分野が焦点だった
• 人工知能（AI）の倫理的かつ信頼性の高い開発に特に注目して議論した
• AI技術が信頼に足るものであり、責任を持って使用されることを保証する上で、データ保護当局が重要な役割を果たすことを強調する声明が採択された
• 子供のプライバシー保護に向けた緊急の行動を呼びかける「AIと子供に関する声明」を発表した
• 個人情報を保護する強固な国境を越えたデータ転送メカニズムの重要性が強調された
• DPAは2024/2025年に向けたアクションプランを承認し、2024年コミュニケで概説されたように、DFFT、新興技術、執行協力に引き続き重点的に取り組むことを表明した

という感じです。

子供のプライバシーの話題など、ますます気をつけていかないといけませんね。

こちらのポストにも書きましたが、ドイツテレコムの出しているAIと子供のプライバシーに関する動画はなかなかショッキングなところもありますので、しっかりと議論をしていってもらいたいところです。

ISO/IEC 18013-7が発行されました

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

マイナンバーカードとか免許証など、mDL/mdocの話題がつきませんが、そういえばISO/IEC 18013-7、Mobile driving license (mDL) addon functionsがリリースされました。

https://www.iso.org/standard/82772.html

全然どうでもいいんですが、イギリス英語なんですね。。。「licence」

なんとなくlicenseって思ってましたがタイトルはlicenceでした。

そういえばGNAPがRFCになりました

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

そういえばOAuth 3.0とかXYZとか言っていたGNAP（Grant Negotiation and Authorization Protocol）がRFC9635になりましたね。

https://www.rfc-editor.org/rfc/rfc9635.html

それに伴いGNAP WGはクローズされた模様です。

https://mailarchive.ietf.org/arch/msg/txauth/smCNPKB2vMPkMX9LCXONGZ-c5Oo/

うーん、まだ息してたんですね・・・（Justinに怒られそう）

ということで著者のJustinもブログ書いてますね。

https://justinsecurity.medium.com/gnap-a-conversation-of-authorization-5b603d850fe9

まぁしかしOAuth2.0の周辺仕様が多くなりすぎたのでシンプルにしましょう、というのは良かったのですが、フレームワークとプロファイルという意味でマイクロ化された仕様が組み合わさるOAuth2.0は複雑化する一方で柔軟性を提供して来たわけで、歴史の長さも含め広く浸透して来ているわけです。

そこをシンプルではあるものの新しい仕組みで置き換えるのは、正しいかもしれませんが実際の普及という観点では非常に難しい話になりそうです。

今後、実際に使われていくかどうか、見守っていきましょう。

OpenID Connect for Identity Assurance日本語版が公開

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

先日もお伝えしたとおり、OpenID Connect for Identity Assurance（通称OIDC4IDA）が正式化されましたが、早くもOpenIDファウンデーションジャパンの有志により日本語化が完了しています。

こちらが日本語版のお知らせ

https://www.openid.or.jp/news/2024/10/openid-connect-for-identity-assurance.html

ぜひ読んでみましょう！

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つ目のグループの議論も見ていきましょう。

 

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

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

なかなかボリュームがあってなかなか終わらないベルリンレポートを引き続き見ていきます。

GAP分析の途中からです。ガバナンスの部分ですね。

We then discussed three essential points about governance:

• The need to think long-term: We cannot yet define what we will establish. A good starting point is champion use cases. 

• Possible precedent for governing entity: there are organizations like the Global Fund or Gates Foundation set up to avoid complexity and time in inter-government negotiation & rule-making.

• a. Another good example is GAVI, which was set up to channel vaccines from the rich north to the south with a focus on malaria and other diseases. Complex structure. 

• Engage the Global South: We cannot create use cases for them. We need to go to them and ask their needs; otherwise, how can we expect them to engage?

 そして、ガバナンスについて3つの重要なポイントを議論した：

• 長期的に考える必要性： 長期的な視点が必要である。出発点としては、チャンピオン・ユースケースが良い。
• 世界基金やゲイツ財団のように、政府間の交渉やルール作りの複雑さや時間を避けるために設立された組織がある。
• a. もう一つの良い例はGAVIで、マラリアやその他の病気に焦点を当て、豊かな北から南へワクチンを流すために設立された。複雑な構造。
• グローバル・サウスを巻き込む： グローバル・サウスとの関わり：彼らのためにユースケースを作ることはできない。彼らのところに行き、彼らのニーズを聞く必要がある。

これはなかなか難しいお題ですね。

SIDI Hub自体が現状は特定の法人ではなく国際コミュニティでしかないため、まずはこの状態をどうしていくのか？の戦略が必要になりそうです。そのためには成果物をどういう位置付けで何に使ってもらうことを想定するのか、という団体としての目指す姿、存在目的ですね。

The group then returned to the problem statement and how we might hone in on a methodology.

その後、グループは問題提起に戻り、どのように方法論に磨きをかけるかについて話し合った。

We discussed a number of risks inspired by the European Union’s EIDAS 2.0:

1. EU national ID: every country establishes and manages its own list and
2. Do people want to use credentials across borders beyond Europe, e.g., California DL accepted by the Estonian gov?
3. It seems that some are assuming that all these rules are going to be on the wallet. That’s not going to scale.
4. We need to think about what kind of policies an issuer can give to a wallet
5. There are a large number of trust marks, some regional, some functional. Agents in the wallets that will give users advice. How can we have wallets to work across jurisdictions?  

EUのEIDAS2.0に触発された多くのリスクについて議論した：

1. EUの国民ID：すべての国が独自のリストを作成し、管理する。
2. 例えば、カリフォルニア州のDLがエストニア政府によって受け入れられるような。
3. これらのルールはすべて財布の中にあると思い込んでいる人がいるようだ。それでは規模が拡大しない。
4. 発行者がどのようなポリシーをウォレットに与えることができるかを考える必要がある。
5. トラストマークは地域的なものから機能的なものまで数多くある。ユーザーにアドバイスを与えるウォレットのエージェント。どのようにすればウォレットが法域を超えて機能するのか？

Walletモデルを考えるとやはり先行しているEU/eIDAS2.0を分析するアプローチになるのは自然かと思います。越境シナリオについても現実味がある地政学的な特色もありますし。

A member of the group asked, “Do we want RP registration at all?” and suggested a vote and working to clarify the problem statement. If yes, are we reinventing the wheel, or do we have what we need somewhere in the public sector?

グループのメンバーは、「RP登録を本当に必要としているのか？」と問いかけ、投票を行い、問題の明確化に取り組むことを提案した。もし必要だとしても、私たちは同じことを繰り返すのか、それとも必要なものは公共部門のどこかにあるのか？

リライングパーティの管理とスケーラビリティ・ガバナンスの問題はしばしば議論されてきましたが、ユースケース次第じゃないの？っていういつもの結論になりそうな予感しかしません。

The final discussion points in this section included:

• User Protection: we need to identify the RP for every transaction. That does not mean that the RP is registered. We have a mechanism called attestations. We can replicate what we have today.
• RP Entitlement: In the EU, we are heading to Registration. Someone has to make a decision about who is entitled to do what. Recommendation to explore that question rather than the how. We need to solve this fundamental question now.
• BOLTS: Catalog business, Operational, Legal, Technical, and Social practices with respect to the Champion Use Cases and map risks.

このセクションの最後の議論のポイントは以下の通りです。

• ユーザー保護：すべてのトランザクションの RP を特定する必要があります。ただし、RP が登録されるということではありません。アテステーションと呼ばれる仕組みがあります。現在行っていることを複製することができます。
• RP 権限：EU では登録に向かっています。誰が何を実行する権利を有するのかについて、誰かが決定する必要があります。方法ではなく、その問題を調査することを推奨します。この根本的な問題は今すぐ解決する必要があります。
• BOLTS：チャンピオンユースケースに関する業務、運用、法務、技術、および社会慣行をカタログ化し、リスクをマッピングする。

確かにRPが特定される状況でないとユーザは安心してサービス利用できません。そういう意味ではガバナンスが重要、っていう話（このセクションがそういうセクションですし）でしょう。

We did not cover the other two major rocks in detail and will return to those items in the workstreams and in future summits.

他の2つの主要な岩については詳しく取り上げなかったが、それらの項目についてはワークストリームや今後のサミットで再び取り上げる予定である。

まぁ、結局は業界やユースケースによってもガバナンスの主体や対象が異なるのに、国際的な相互運用ができるのか？っていうことです。そういう意味ではユースケースを特定してステークホルダーを明確化、その中で合意可能な範囲を探していく、というアプローチはしばらく続けないといけない気がします。

ようやく次はテクニカルな要求に関するセクションです。 

 

 

Windowsのパスキー対応の今後

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

いよいよ来週はAuthenticate 2024ですね。残念ながら参加できませんが。

ということで、Authenticateに向けて各社パスキー周りの話題が進んできていそうです。

MicrosoftからもWindowsのパスキー対応について記事を公開しています。

Passkeys on Windows: Authenticate seamlessly with passkey providers

https://blogs.windows.com/windowsdeveloper/2024/10/08/passkeys-on-windows-authenticate-seamlessly-with-passkey-providers/

こちらの機能がWindows Insiderチャネルで配信されるようです。久しぶりにWindows PCでも触ろうかな・・・

• A plug-in model for third-party passkey providers
• Enhanced native UX for passkeys
• A Microsoft synced passkey provider

サードパーティプロバイダとの連携では1Passwordなどとの連携ができるようになるようです。3点目のMicrosoftが提供する同期ファブリックと連携できたりすると面白そうです。Credential Exchange Specificationが実装されてくると面白いと思います。

いずれにしても来週のAuthenticateで詳しく言及されるのかと思います。楽しみですね。

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

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

引き続きSIDI Hubベルリンレポートを読んできましょう。

今回はユースケースをベースにしたGap分析です。Deboraがレポートしてくれています。

相互運用性を担保する上で大きな障壁になりそうな課題として以下を挙げています。

We focused on three topics:

• Relying Party Registration: it is tackled in the scope of EUDIW and covered by Aadhaar, NIMC, and others on a country-by-country basis. But how does this interoperate across borders on a global scale?
• Issuing Authority Discovery: ICAO centralized this for passports after many years. But how will this work for public and private sector issuers?
• Legal Entity Identifiers: the LEI (GLEIF) and DNS (ICANN) are two current examples. What is the best way to achieve legal entity linking?

We then facilitated a discussion, and the following summarizes the key points addressed in the room.

我々は3つのトピックに焦点を当てた：

• リライングパーティの登録：EUDIWの範囲内で取り組まれており、AadhaarやNIMCなどが国ごとにカバーしている。しかし、世界規模で国境を越えてどのように相互運用するのか。
• 発行機関の発見： ICAOは何年も経ってから、パスポートのためにこれを一元化した。しかし、公的機関や民間企業の発行者にとってはどのように機能するのだろうか。
• 法的実体識別子：LEI（GLEIF）とDNS（ICANN）が現在の2つの例である。取引主体の連結を実現する最善の方法は何か？

その後、ファシリテーターによるディスカッションが行われ、その中で取り上げられたポイントを以下に要約する。

どれも頭の痛い問題ですね。特に2点目、3点目は答えが出そうにない課題ですねぇ。。いつまで経ってもIssuerのディスカバリは難しい問題です。ここで言っているのは単純に公開鍵を取得するためのURLのディスカバリだけじゃないですからね・・・どうやってIssuerが正当な機関であることを信じられるか、みたいな話です。また、識別子も非常に難しい問題です。DNSは比較的成功したモデルではありますが、それでも過去に使っていたドメインを別の機関が取得するという問題などもありますので、長期的に運用する上では非常に難しいかと思います。

それぞれ深掘りしていきます。

Relying Party (RP) Registration:

The group discussed the nature of Registration, its requirements, and how Trust establishment could work globally.

• Are we focused only on foundational identity, or do we include functional identity systems?
• Example from Nigeria: the agency responsible for ID management is NIMC. In the case of foundational identity, one of the first things they do is a process of due diligence called Verification. RPs are registered mainly for the foundational part. It is specific to the country.

依拠当事者（RP）登録：

このグループでは、登録の性質、要件、および信頼性確立がグローバルにどのように機能するかについて議論した。

• 私たちは基盤的 ID のみに焦点を当てているのか、機能的 ID システムも含めるのか。

• ナイジェリアの例：ID 管理を担当する機関は NIMC である。基盤的 ID の場合、最初に行うことの 1 つは、検証（Verification）と呼ばれるデュー・ディリジェンス・プロセスである。RP は主に基礎部分のために登録される。これはその国特有のものである。
• Why are RPs registering? What are the requirements? What are the types of problems we are trying to solve?

• Example of the mDL standard: the Trust ecosystem is only for Issuers. If I share my mDL with you, why should I trust you? This concern is especially relevant for a commercial vendor, e.g., Aadhaar they have to register all RP fingerprint devices with governments to know they are trusted 

• なぜRPは登録するのか？要件は何か？どんな問題を解きたいのか？ 

• mDL標準の例：トラスト・エコシステムは発行者のためだけのもの。mDLを共有した場合、なぜ信用しなければならないのか？この懸念は特に商業ベンダーに関連する。例えば Aadhaar の場合、信頼できることを知るためにすべての RP 指紋デバイスを政府に登録しなければならない。

• Should the solution be based on use cases? Should it be a risk-based approach?

• It depends on the type of credentials, e.g., education with entity categories. A commercial entity doesn’t need your entire transcripts.
• ソリューションはユースケースに基づくべきか。リスク・ベースのアプローチにすべきか？

• クレデンシャルのタイプ（例えば、エンティティ・カテゴリーを持つ教育）によって異なる。営利団体は成績証明書全体を必要としない。 
• Should it be public or private-led, or a combination of both? 

• Example, more public-led: ICAO 

• Example, more private-led: ICANN
• 公共主導か民間主導か、あるいは両者の組み合わせか？ 

• より公共主導の例：ICAO 

• より民間主導の例：CANN
• Governance relates to funding the operating costs: would it be self-funded like ICAO? Should it be external funding? What are good reference models? 

• ICAOのように自己資金で運営するのか？外部資金とすべきか？良い参考モデルは何か？ 

• Should it be global or regional? 

• AAMVA is in North America and only about driver's licenses 

•  グローバルかリージョナルか 

•  AAMVAは北米にあり、運転免許証に関するものだけである。 

• How would we approach the following: 

• Lifecycle management? 

• Type of data? 

• Legitimacy & KYB? 

• Policy enforcement? 

• 以下について、どのようにアプローチしますか？ 

• ライフサイクル管理？ 

• データのタイプ？ 

• 正当性およびKYB？ 

• ポリシーの施行？
• Should we pursue an academic analysis of the options?
• オプションについて学術的な分析を行うべきでしょうか？ 

• Who are the decision-makers, and why?
• 意思決定者は誰で、その理由は？ 

• Is there a hierarchy or a pre-existing way to navigate views?
• 階層やビューをナビゲートする既存の方法はあるのでしょうか？ 

• What is the appropriate role for: 

• Governments? 

• NGOs like the UN? Is the UN sufficiently independent? 

• Standards Organizations? 

• 以下について適切な役割とはどのようなものか： 

• 政府？ 

• 国連のようなNGO？国連は十分に独立しているか？ 

• 標準化団体？
• What is required to achieve consensus?
• コンセンサスを得るために必要なことは何でしょうか？ 

We discussed that the Champion Use Cases will indicate the breadth of the issues we have to face if we go for the widest possible interoperability

チャンピオンユースケースは、最大限の相互運用性を実現しようとする場合に直面する問題の広がりを示すことになるだろう、という点について話し合いました。

当然ですが、相互運用を考えるとかなり幅広い議論が必要となりますね。

もう少しスコープを絞って議論をシャープにしていかないとまとまらない気もします・・・（少なくとも一気に全体ミーティングでまとまる量じゃない）

リライングパーティだけで上記ボリュームだったので、他にもガバナンスなどもあるので、この辺りは明日以降に。

 

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

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

引き続きSIDI Hubベルリンイベントのレポートを見ていきます。

今回はユースケース分析です。相互運用性を目指しましょう、といっても具体的なユースケースを見つけてボトムアップで考えていかないと進まないので、このワークストリームでは有用なユースケースを各地域ごとに発見して分析して行きます。

Champion Use Cases: Process and Progress to Date - Elizabeth

The Champion Use Case workstream is in the process of identifying champion use cases and then prioritizing using an agreed framework. In Berlin, the Champion Use Cases workstream sought to do three things throughout the day:

1. Ground Minimum Requirements conversations in salient use cases
2. Add more use cases and more texture to the data already gathered
3. Gain input on prioritization criteria

チャンピオン・ユースケース・ワークストリームは、チャンピオンのユースケースを特定し、合意されたフレームワークを用いて優先順位を決定しているところである。ベルリンでは、チャンピオン・ユースケース・ワークストリームは、一日を通して3つのことを行おうとした：

1. 重要なユースケースにおける最低要件の会話の基礎固め
2. より多くのユースケースを追加し、すでに収集されているデータにさらに質感を加える。
3. 優先順位付けの基準について意見を得る 

これまでパリ、ケープタウン、ベルリン、ワシントンDC、そして東京の企画を通して見てきていますが、やはりユースケースに関する関心度、優先順位の置き方は地域によってかなり異なるイメージです。その意味で各地域を回りながら状況をヒアリングして回る、というSIDI Hubのアプローチは理にかなっていると思います。（どうしてもUSとEUだけで話が決まっていく傾向がある世界ですし）

つまり、せっかくなのでアジアからも意見を出していかないとダメですよ、ってことです。

Early in the day, we reviewed the inputs from other sources and past SIDI Hub events:

• Paris Summit and write specific user stories
• W3C credentials working group
• EU Wallet use cases
• EU + US TTP bilateral analysis
• SIDI Hub Cape Town
• New input from SIDI Berlin

Wishing to spend the morning on technical requirements, SIDI Hub Berlin grounded further discussions in two use cases: Refugees and Opening a Bank Account. In this early session, presenters reviewed the outputs from the deep dive conducted at SIDI Hub Cape Town.

その日の早い段階で、他の情報源や過去のSIDI Hubイベントからのインプットを見直した：

• パリサミットと具体的なユーザーストーリーの作成
• W3Cクレデンシャル・ワーキンググループ
• EU ウォレットのユースケース
• EUと米国のTTP二国間分析
• SIDIハブ・ケープタウン
• SIDI ベルリンからの新しいインプット

SIDIハブ・ベルリンは、午前中を技術的な要件に費やすことを希望し、2つのユースケースでさらなる議論を行った。「難民」と「銀行口座開設」である。この早いセッションで、発表者はSIDI Hub Cape Townで行われたディープダイブからのアウトプットをレビューした。

ベルリンでは先に書いたようにこれまでの取り組みについて確認し、その後、さらなるテーマの深掘りをしていっています。日本にいると難民のユースケースはリアリティがない人も多いと思いますが、これまで移民を受け入れてきたドイツや欧州諸国においては重要なキーワードなんだと思います。

こちら、難民のユースケースですね。

特徴として、自国の法的な身元証明が受けられない状況にあるので、UNHCRが発行する証明書を利用できるか？というのが大きなポイントになります。これはワシントンDCでも話があり、先日のクィックレビューでも書きましたが、どうしても出生からの流れを含め身元を証明することが困難であり、Identity Verificationをする際の照合先がないところから身分を付与していくことになります。その付与プロセス自体がどこまでの保証レベル（IAL/Identity Assurance Level）を持つのか？テロリストが混入している可能性や身元ロンダリングに悪用されていないかを踏まえて、どこまでVerifierが受け入れることができるのか？人権や人道支援の文脈を含めてどのように判断していくのかは非常に難しい話です。ただ、世界的に助けを求めている人々の数がますます増えている昨今、目を背けるべき案件ではありませんね。

こちらは銀行口座の開設のユースケースです。

こちらも移民のケースにも少々関わってきますが、国境を超えて別の国で銀行口座を開設するのは非常に難しい状態です。KYCが難しいのはもちろん、CDDについても元となる実績情報などが取得しにくい状態にあるので、どうしてもリスクベースで考えるとリジェクトもしくはネガティブな判断が下されがちです。こちらもAML/CFTの観点も踏まえて良い落とし所を作っていく必要がありそうです。

今回はここまでです。

この後、ギャップ分析が続きます。

Entra IDを使ったパスワードレスでのオンボーディングシナリオ

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

Entra IDもVerified IDやFIDOなど色々な要素が組み合わさってきているので、それらの機能をどうやって組み合わせて使うのが良いのか？という疑問が湧いてきます。

そんな時にパスワードレスでオンボーディングをするというシナリオに基づくデザイン〜実装ガイドがMicrosoftから発行されていますので、見てみようかと思います。

Phishing-resistant passwordless authentication deployment in Microsoft Entra ID

こちらのドキュメントです。

https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-plan-prerequisites-phishing-resistant-passwordless-authentication

全体像はこんな感じですね。

Onboarding step 1: Identity verification

最初のステップではEntra Verified ID（＋3rdパーティソリューション）を使って政府発行のIDなどで本人確認するところからスタートします。その後、PCのBootstrapではTAP（Temporary Access Pass）を使ってドメイン参加〜認証器のエンロールをする、という流れですね。（もしくは、最近PreviewになったGraph APIで事前にFIDO認証器をプロビジョニングしておく、という方法もありますね）

関連資料）

• Entra Verified ID
• https://learn.microsoft.com/en-us/entra/verified-id/remote-onboarding-new-employees-id-verification
• Temporary Access Pass
• https://learn.microsoft.com/en-us/entra/identity/authentication/howto-authentication-temporary-access-pass#enable-the-temporary-access-pass-policy
• Graph APIでもFIDOクレデンシャルのプロビジョニング
• https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-enable-passkey-fido2#provision-fido2-security-keys-using-microsoft-graph-api-preview

Onboarding step 2: Bootstrap a portable credential

前のフェーズでTAPでBootstrapし、最初のクレデンシャルのエンロールをするタイミングです。ここで重要なのはデバイスにバインドされたクレデンシャルではなくポータブルなクレデンシャルをエンロールすべきである、という点です。当然働き方・デバイスの使い方によって事情は異なりますが、最初のクレデンシャルがデバイスにバインドされてしまうと後々困ることになるからですね。

Onboarding step 3: Bootstrap local credentials on computing devices

ポータブルなクレデンシャルがエンロールされれば、あとは個別のデバイスのセットアップを自由にできるわけです。この段階でデバイスごとのローカルクレデンシャルをエンロールしていきます。典型的にはWindows HelloのPINの生成ですね。要するにローカルの鍵ストアをオープンするための手段を作っていくところです。

まぁ、非常に典型的な話ではありますが、ドキュメントではもっと細かくパターン分けされたデザインが出てきますので、みなさんの仕事の仕方、デバイスの種類を考えて適切なデザインをしていってください。

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

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

粛々とSIDI Hub Tokyoの準備は進んでいるわけですが、始まるまでにちゃんとベルリンのレポートを読み終わっておきましょう。

前回まででPart Oneの概要が終わったので今回からはPart Twoのセッションごとの詳細レポートを見ていきます。

SIDI Summit Introduction - Mark Haine

まずはイントロです。Markがレポートしてくれています。 

Debora Comparin (SIA), one of the founders and organizers of SIDI Hub, opened the day and welcomed participants to the third convening of SIDI Hub before EIC in Berlin. Afforded by its association with EIC, SIDI Hub is pleased to have expertise in the room that spans deep technical knowledge of transnational governance. Further attesting to this, representatives from Germany’s Federal Ministry of the Interior & Community and SPRIN-D, Germany’s Federal Agency for Disruptive Innovation, spoke to the importance of SIDI Hub’s focus on cross-border interoperability and open standards.

SIDIハブの創設者の一人であり、主催者でもあるデボラ・コンパリン（SIA）は、ベルリンのEICの前に開催されたSIDIハブの第3回会合への参加者を歓迎し、開会を宣言した。EICとの提携により、SIDIハブはトランスナショナル・ガバナンスに関する深い技術的知識を持つ専門家を会場に迎えることができた。このことをさらに証明するように、ドイツ連邦内務・地域省およびドイツ連邦破壊的イノベーション機関SPRIN-Dの代表者は、国境を越えた相互運用性とオープンスタンダードに焦点を当てたSIDI Hubの重要性を語った。

私も現地で参加しましたが、ドイツ政府の100％出資の機関であるSPRIN-Dのオフィスでイベントは開催されました。そのため、最初のWelcome keynoteはSPRIN-Dの方が担当しました。

Nick Mothershaw (OIX) reviewed the agenda, which emphasized the following:

1. Identifying Champion Use Cases

2. Identifying Major Barriers to Interoperability

3. Minimum Technical Requirements for Interoperability

4. Deepening our Trust Framework Analysis

5. Critical Research Questions

Nick Mothershaw（OIX）は、以下の点を強調したアジェンダをレビューした。

1 チャンピオンのユースケースの特定

2. 相互運用性に対する主な障壁の特定

3. 相互運用性のための最低技術要件

4. 信頼フレームワーク分析の深化

5. 重要な研究課題

そのあとはNickによるアジェンダの紹介がありました。

SIDI Strategy and Structure - Mark

続いてGailによるSIDI Hubのストラテジーとストラクチャの話です。

Gail Hodges provided an overview of the origins of SIDI Hub, which derived from an ID4Africa presentation and the “Human-Centric Digital Identity” paper. In particular, the problem of cross-border interoperability in the context of national Digital Identity strategies encompassing a wide range of technical architectures and governance models.

Gail Hodges は、ID4Africa のプレゼンテーションと「人間中心のデジタル ID」論文から派生した SIDI ハブの起源について概要を説明した。特に、広範な技術アーキテクチャーとガバナンス・モデルを包含する各国のデジタル ID 戦略の文脈における国境を越えた相互運用性の問題について述べた。

この辺りはいつものGailのセッションなのですが、各国のデジタルID戦略をPublic Governance-Private Governance、Centralized-Decentralizedの２軸で4象限に分類し、現状のばらつきを表現しつつ、この環境のもとで国境を超えた相互運用性を達成することの必要性について話しているわけです。

Despite these challenges - and the ongoing need for domestic sovereignty - can one’s Digital Identity be as easy to present as an email, a phone number, or a passport? SIDI Hub seeks to build a blueprint for how we build Digital Identity ecosystems within and across ecosystems. The goal is for implementers to build interoperable Digital Identity credentials by default. But this, of course, requires measurement and metrics, policies, open standards, open source code (in many jurisdictions), and scientific analysis for best practice security.

このような課題があるにもかかわらず、そして国内主権の継続的な必要性があるにもかか わらず、デジタル ID は電子メール、電話番号、パスポートのように簡単に提示することができるのだろうか？SIDI ハブは、エコシステム内およびエコシステム間でデジタル ID エコシステムを構築する方法の青写真を構築することを目指す。目標は、実装者がデフォルトで相互運用可能なデジタル ID クレデンシャルを構築することである。しかし、これにはもちろん、測定と測定基準、ポリシー、オープン・スタンダード、オープン・ ソース・コード（多くの法域で）、およびベスト・プラクティスのセキュリティのための科学 的分析が必要である。

こんなバラバラな状態の中でもデジタルIDをメールや電話やパスポートのように国境を超えて世界中で相互運用できる状態にするにはやることがたくさんありますね。まさにこれがSIDI Hubがやろうとしていること、というわけです。

SIDI Hub is self-organized into five workstreams:

• Champion Use Cases
• Trust Framework Mapping
• Minimum Requirements for Interoperability
• Metrics of Success
• Governance

As referenced above, SIDI Hub has no governance authority of its own. We therefore discussed where　decisions are made, which remain unchanged as a result of SIDI Hub, and how SIDI aims to support　them.

SIDI Hubは、以下の5つのワークストリームから構成される。

• チャンピオンのユースケース
• トラストフレームワークマッピン
• 相互運用のための最低要件
• 成功の指標
• ガバナンス

上記で言及したように、SIDI Hub はそれ自体のガバナンス権限を持たない。そのため、SIDI Hubの結果として変わることのない意思決定がどこで行われるのか、また、SIDIがどのようにそれをサポートすることを目指しているのかについて議論した。

こちらはいつものSIDI Hubとは何なのか、という話と構成するワークストリームの話ですね。 非常に難しい部分なのですがコミュニティなのでコンセンサスを取りながら意思決定をしていくというのが特徴でもあります。この辺りは今後変わっていくかもしれません。

今回はこのくらいです。ユースケース分析のセッションについて次回解説します。

Kim Cameron Awardの受賞者によるIdentiverseへの参加レポート

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

先日お知らせしたVittorio Bertocciアワードと並行してDIAF（Digital Identity Advancement Foundation）が提供する個人向けの世界２大アイデンティティ・アワードであるKim Cameronアワードの受賞者であるMatthew SpenceがIdentiverse 2024への参加レポートを書いています。

https://digitalidadvancement.org/news/2024-kim-cameron-awardee-reflections-matthew-spence/

DIAFではアワード受賞者にIdentiverseやIIW、EICなどのカンファレンスへの参加をサポートしており、有能でやる気があっても費用面で課題がある若手などへのスポンサーをしています。

ダイバーシティを確保のためにはこのような取り組みは非常に有用ですね。日本でも何かやれないかなぁ、、、と思いますが、まずは日本からもDIAFのアワードにApplyしてみる方が出てくることに期待です。

OpenID Connect for Identity Assuranceの仕様が承認されました

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

Great newsです。

先日より投票が開始されていたOpenID Connect for Identity Assuranceの仕様が最終化、承認されました。

投票のお知らせ）

https://idmlab.eidentity.jp/2024/09/openid-connect-for-identity-assurance.html

最終化に関する公式アナウンス）

https://openid.net/final-openid-connect-for-identity-assurance-specifications-approved/

今回承認された仕様は以下のとおりです。

• OpenID Identity Assurance Schema Definition 1.0 - https://openid.net/specs/openid-ida-verified-claims-1_0-final.html
• OpenID Connect for Identity Assurance Claims Registration 1.0 - https://openid.net/specs/openid-connect-4-ida-claims-1_0-final.html
• OpenID Connect for Identity Assurance 1.0 - https://openid.net/specs/openid-connect-4-identity-assurance-1_0-final.html

皆さん、使っていきましょう。

SIDI Hub東京、前々夜祭を開きます

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

いよいよ今月末はSIDI Hub東京イベントです。

が、小規模でのディスカッション中心、かつ英語イベントということもあり招待者に限りご参加いただくという形となります。

そのため、日本のアイデンティティ関係者の皆さんにも概要を知っていただく場として前々夜祭としてイベントを開くことにしました。

https://openid.connpass.com/event/332975/

こちらは日本語で、かつ実際に活動をしている方からも話をしてもらえるようにしたいと思いますので、ぜひご参加ください。

Death and the Digital Estate（DADE）CGが発足

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

DADE CG（Death and the Digital Estate Community Group）の発足がアナウンスされています。死後のデジタルアイデンティティや遺産について扱うコミュニティグループです。

https://openid.net/announcing-death-and-the-digital-estate-cg/

4月のIIWの前日のOpenID Foundation Workshopで触れられていたコミュニティですね。

https://idmlab.eidentity.jp/2024/04/openid-foundation-workshopgoogle.html

当時AWSにいたDean Saxe（右から二人目。今はBeyond Identityに移籍）がChairを務めるようです。

メーリングリストへの参加なども受け付けていますので参加してみてはいかがでしょうか？

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

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

しばらく別のネタばかりでSIDI Hubについてかけていませんでしたが、10月に入ったので東京開催秒読みということでベルリンレポートの続きを読んでいきます。

前回からしばらく開きましたが、今回は続きです。

Users of a Trust Framework Analysis Tool

A major output of the SIDI Hub 2024 strategy, led by the Open Identity Exchange (OIX), will be a Trust Framework Comparison Tool. This will be bolstered by further analysis and normalization of Trust Frameworks supported by SIDI Hub. At the SIDI Berlin session, breakout groups shaped the value proposition and requirements for such a comparison tool, which will directly influence the final deliverable. Further information is found in the Rapporteur’s notes (next section).

信頼フレームワーク分析ツールのユーザー 

Open Identity Exchange (OIX) が主導する SIDI Hub 2024 戦略の主な成果のひとつは、信頼フレームワーク比較ツールです。これは、SIDI Hub がサポートする信頼フレームワークのさらなる分析と標準化によって強化されます。SIDI Berlin セッションでは、分科会がこのような比較ツールの価値提案と要件を策定し、最終成果物に直接影響を与えることになります。詳細は、ラポータのメモ(次項)をご覧ください。 

トラストフレームワークのマッピングに関して書かれていますね。

現在、各国で制定が進んでいるトラストフレームワークの相互運用が可能な状態にならないと国の間で相互運用性の担保ができなくなるのでここでいうマッピングは非常に重要です。OpenIDファウンデーションジャパンではOIXに協力する形で日本のトラストフレームワークのマッピングを支援しています。

BOLTS: Business, Operational, Legal, Technical, and Social

Given the above take-aways, which span Business, Operational, Legal, Technical, and Social forces that impact the global interoperability effort, the group will use a “BOLTS” framework as a core part of its Champion Use Case analysis.

BOLTS:ビジネス、運用、法律、技術、社会

グローバルな相互運用性への取り組みに影響を与えるビジネス、運用、法律、技術、社会の各分野における上記の要点を踏まえ、当グループは「BOLTS」フレームワークをチャンピオンユースケース分析の中核として使用します。

相互運用性を考える上では技術だけを考えていたは不十分です。ここにあるようにビジネス、運用、法律、社会を含めて考える必要がある、ということです。

Government Participation

A final point of reflection relates to the audience for SIDI Hub events. Given the light attendance from government officials in Berlin, the agenda skewed towards a technical audience that discussed technical possibilities. This is not ideal.

政府の参加

最後に、SIDI Hubのイベントの聴衆について考察したいと思います。ベルリンでの政府関係者の出席が少なかったため、技術的な可能性について議論する技術的な聴衆に偏ったアジェンダとなりました。これは理想的ではありません。

先に記載した通り、法律や社会についても検討が必要です。ベルリンでは政府機関の設備で開催したにもかかわらず確かにあまり多くの政府関係者が参加したわけではありませんでした。この辺りは日本開催をする際のバランスに関する考慮点となるでしょう。

SIDI Hub was founded to unite global audiences to define the users, benefits, and overall business case for globally interoperable digital identity to normalize approaches and define minimum requirements. It was, therefore, somewhat premature to attempt a solution-oriented agenda. With that said, the lessons were valuable, and SIDI Hub has had valuable contributions from European stakeholders through other avenues, e.g., the SIDI Paris Summit, eIDAS 2.0 documentation, etc. Regardless, the SIDI organizers have determined that baseline government participation will be a critical go/no-go criterion for the events planned in Washington, D.C., Tokyo, and Brazil.

SIDI Hubは、世界中のオーディエンスをまとめ、世界規模で相互運用可能なデジタルIDのユーザー、利点、全体的なビジネスケースを定義し、アプローチを標準化し、最低限の要件を定義するために設立されました。そのため、ソリューション志向のアジェンダを試みるには時期尚早でした。とはいえ、そこから得られた教訓は貴重であり、SIDIハブは、SIDIパリサミットやeIDAS 2.0文書など、他の手段を通じて欧州の利害関係者から貴重な貢献を得ることができました。それでも、SIDIの主催者は、ワシントンD.C.、東京、ブラジルで計画されているイベントについては、政府の基本的な参加が実施の可否を決定する重要な基準となると判断しました。

ベルリンでもユースケースの取りまとめ要件整備を行いました。次のワシントンDCや東京・ブラジルでの開催に向けて議論をしていく必要がありそうです。なお、ここに記載がある通りソリューションとして自立させるためのきっかけには早すぎるイメージはありました。しかし読者の皆さんは気にせずにアプライしてくださいね。