2024年10月18日金曜日

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

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

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


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

2024年10月17日木曜日

Credential Exchange Format/Protocolの新Working draft

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

Authenticate 2024が10/14-16で開催されましたね。
各社イベントに向けて色々と実装をして発表にこぎつける、というのは世の常ですが、これはもちろんスペックライターについても同じようです。



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

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

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

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

2024年10月16日水曜日

信頼できる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と子供のプライバシーに関する動画はなかなかショッキングなところもありますので、しっかりと議論をしていってもらいたいところです。



2024年10月15日火曜日

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でした。



2024年10月14日月曜日

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

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

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

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


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

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


まぁしかしOAuth2.0の周辺仕様が多くなりすぎたのでシンプルにしましょう、というのは良かったのですが、フレームワークとプロファイルという意味でマイクロ化された仕様が組み合わさるOAuth2.0は複雑化する一方で柔軟性を提供して来たわけで、歴史の長さも含め広く浸透して来ているわけです。
そこをシンプルではあるものの新しい仕組みで置き換えるのは、正しいかもしれませんが実際の普及という観点では非常に難しい話になりそうです。

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

2024年10月13日日曜日

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


ぜひ読んでみましょう!

2024年10月12日土曜日

SIDI Hub - ベルリンレポートを読む(7)

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

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