信頼できる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で詳しく言及されるのかと思います。楽しみですね。