Identiverse 2024クィックレビュー Day3

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

3日目ともなると少しずつ体力が削られているのを体感し始めますが、引き続き書いていきます。

今日はBreakoutセッションが中心の1日です。

Digital Identity, the G20, and the SIDI Hub Survey - Gail Hodges, Mark Haine, Nick Mothershaw

最初に参加したセッションはGailとMarkとNickによるSIDI Hubの話です。

そもそもSIDI Hubのチャレンジは、グローバルでデジタルアイデンティティが相互運用でキリ状態に持っていくことです。現状、各国や地域が中央集権アイデンティティシステムをバラバラに構築している（Aadhaar、BankID、EU eIDなど）わけですが、これを究極的には相互運用ができる状態に持っていきたい、というわけです。

イメージは電車の車両や貨物コンテナ、メール、電話、パスポートなどグローバルで規格が決まっていてどこにいても通用する世界観ってことです。確かに現状のデジタルアイデンティティはそこまでは言っていませんね。

目的や関係者については以前ポストした通りのことが紹介されましたので省略します。

目玉は5/20にケープタウンでID4Africaと同時開催されたSummitには14の非営利団体、アフリカの国々に加えてインド・ブラジルも参加したことが報告され、また5つのワークストリームの進捗についても触れられました。

特にチャンピオンユースケースでは候補が多く集まってきており、今回のIdentiverseでも参加者から追加するものを募っていましたので、次のEICくらいでは煮詰まってくるのではないかと思いました。ちなみにCross borderでの医療やSIMスワップへの対策など参加者から追加のユースケースに関する意見も出ていました。

また、成功の指標（Metrics of Success）についてGailよりあくまで個人的な意見として「SDGs 16.9のデジタル版を作って実現すること」と話がありました。

さらにOIXのNick Mothershawが中心になって進めているトラストフレームワークマッピングについて、この文脈におけるトラストフレームワークの定義が「デジタルアイデンティティに関するルールとポリシー」を指すことが発表されました。確かにテクノロジーについてはMinimum Requirements側で議論することになりますし、SIDI Hubの性質（標準化団体ではない）ことを鑑みると正しい定義だと思います。

なお、すでに以下の8つのトラストフレームワークの分析を始めており、今後さらに詳細化を進めていくことになると思われます。

• UK / Digital Identity and Attributes Trust Framework（DIATF）
• EU / eIDAS2
• US / NIST SP800-63-4 draft
• Canada / DIACC Pan Canadian Trust Framework
• Sweden / BankID
• Thai / ETDA Trust Framework
• Singapore / Singpass
• India / MOSSIP's Modular Open-Source Identity Platform

日本はないですね。。

なお、分析にあたってのポイントとして「The DNA of Digital ID」を挙げており、例えばプライバシーの考え方が国によって異なることなどを踏まえ、共通点と相違点を洗い出していくというアプローチをとっているようです。

次にMR4I（Minimum Requirements for Interoperability）についてMark Haineからです。フォーカスしているのは、

• Identity Exchange Protocol
• Trust Protocol
• Payload Schemas

で、これらの相互運用性を担保するために、単一のグローバル標準を作るのか複数のプロトコルをサポートするようにスタックを組むのか、プロキシを置くのか、など考えられるアーキテクチャを洗い出しつつ検討を進めています。

今後は、チャンピオンユースケースに向けたサンドボックス〜プロダクションの実装、OSSのテストスイートの提供を行うとのことですが、すでにさまざまな実装面でのギャップはある程度見えており、こちらも洗い出しを行なっているようです。

例えば、Issuing AuthorityのDiscoveryの法人をどうするのか、X.509なのかOpenID Federationなのか、既存のシステム（AadHaarやSingpassなど）がある場合にどのようにするのか、多言語対応をどうするのか、など課題は山積みです。

最後に、来場者アンケートを取りました。

• 一番Fitしそうなユースケースは？：電子パスポートや国を跨いだ銀行口座の開設が上位
• SIDI Hubの活動は続けるべきか？：26/28が続けるべき。残り2もMaybe
• Disinformationに関する懸念はあるか？：22/28があり
• 全ての国民に提供する場合にどのくらいのコストがかかると思うか？：ほとんどの人が$10million以上かかると回答
• 8billionユーザににデプロイしたとしたら？：$8-20million
• ボランティアとしてSIDI Hubコミュニティに貢献したいか？：22/27がポジティブ

Celebrating Ten Years of OpenID Connect - Mike Jones

先日のOpenID Summit Tokyo 2024から始まったOpenID Connect 10周年ですが、今回のIdentiverse、来週のEuropean Identity & Cloud Conferenceと続きます。

2024年２月に仕様フィイナライズされたOpenID Connectについて、どのように仕様策定をしたのか、などの歴史について当時関与した皆さんが話してくれました。

まずはMike Jonesさんから概要の説明がありました。ざっくりですがこんな流れだったという説明がありました。

• 2010年にArtifact Binding for OpenID 2.0がスタートした
• しかし当時の開発者はJSON/REST over XML SOAPを選択した
• その後、JSON/REST protocol over OAuth2.0にピボットした
• 結果、2011年5月のIIWでOpenID Connectにブランディングした
• 2011から2013年で相互運用性テストを実施した

このタイミングで日本の開発者から多くのコントリビューションがあったことが紹介され、novの写真が出てきました（若いw）。

なお、仕様策定にあたってのデザインに関する哲学についても紹介がありました。

• Keep simple things simple
• Make complex things possible

また、同時に過去から学びについても大事にしており、SAMLとOpenID 2.0の経験からメタデータやAuthentication Contextsなどうまく動いているアイデアを取り込んで追加の機能を追加していった、またデザインとして拡張性を持たせた（例えばlogoutとかIDAとか）こと、そしてJWxなどを含めた外部の仕様を含むモジュラー型の設計を行なった、という話でした。

結果として達成したこととして、

• 最も使われているIdentityプロトコル
• 数千の相互運用性のある実装
• 認定プログラムにより相互運用性が進んだ
• ISOによる仕様認定

が挙げられました。

そして、これまでのことから以下の学びがあった、ということです。

• 開発者はシンプルなものを選ぶ
• 相互運用性とセキュリティは厳格なテストが必要
• 拡張性は長い期間の成功に必要
• 簡単に使えることが大事
• 全てが計画通りに行くとは限らない
• 開発者と開発者によるフィードバックが大事

次に、「OpenID and the Enterprise」としてChuck Mortimore@Disney（当時はSalesforce）から話がありました。Cloud Identity Summit 2011のスライドを引用して、当時はEnterpriseでOpenIDは使えない、理由はシンプルさをEnterpriseは求めていないから、というところから始まったという話がありました。

当時のアプローチとして正規化は難しい、だからws-*を入れたくないという意見を梃子に進めた結果、やはり単純さが勝ってws-*は続かず、ということが起きたということでした。

これは某Verifiable Credentials Data Modelの論争にも共通する話ですね。歴史は繰り返すのか？？要注目です。

また、同じくスマートフォンの普及に関するエピソードも紹介があり、アプリとデータアクセスの制御ができるようにしないといけなくなったり、モバイルアプリケーションでもフェデレーションができないといけなくなった、という事情からコンテキストポリシーベースのアプリケーションフレームワークを作ったり、webviewベースでのフェデレーションができるようにした、という話が紹介されました、

そして、ここがOpenID Connectに繋がる話ですが、Artifact Bindingを改めて採用して行ったのか？という話です。当時、クラウド化が進みFirewallは意味をなさなくなり、アイデンティティを含むコアサービスもクラウドへシフトするであろう、という未来予測をしたということです。2010年そこそこの話なので正に先見の明ですね。ちなみに解説すると当時SAML全盛かつクラウドサービス（Google AppsとかOffice365とか）をSPとして利用し始めていたもののIdPはクラウドに出すなんてとんでもない、という文化がありました。そのためAD FSなどをオンプレミスに構築し、クラウドサービスを利用するときも認証だけはオンプレミスで行う、という構成が主流でした。その際にFirewallの外側にあるクラウドサービスからFirewallの内側のサーバへのインバウンド通信の口をFirewallに開ける、なんていうことはとんでもないことだ、という風潮がありました（今でも一定あるとは思いますが）。そこで、SAMLについてもHTTP POST Bindingを使ってSAML Assertionは全てブラウザを介してIdPからSPへ渡される構成が好んで使われるようになりました。それに対してArtifact Binding（いわゆる認可コードフロー）はSPからIdPへの通信が発生する仕組みなので困ってしまったわけです。実はSAMLにもArtifact Bindingは存在していて、本当にイントラ内のSP-IdPでは結構使われていましたが、上記理由でPOST Bindingが主流になってしまったわけです。これがIdPがクラウドに移行することによりArtifact Bindingが復活した、という話です。何しろPOST Bindingではブラウザを通じた通信になるので通信量は増えますし、トークンの中身を見れてしまう、という不利な点もあるので、できるならArtifact Bindingを使いたかったわけです。

さらに、クラウド上のSPは昔Salesforceがそうであったようにジャストインタイムプロビジョニングが中心でした。結果として従来LDAPで実装していた時のようにスキーマの拡張の柔軟性やIDライフサイクル管理の自由度の面で課題が発生します。この課題への対応がOpenID Connectの標準スキーマを定義する動きに繋がったり、SCIMの開発へ繋がって行ったという話もありました。

また、ユーザはOpenID 2.0の頃のように識別子としてURIを使いたくないという話や、ユーザーセントリックな思想の話など現在のDIDやSSIに近い思想は当時からあった、ということも語られました。

次に崎村さんから「25 yesra of OpenID」という話がありました。この話は1月に東京で開催されたOpenID Summit Tokyo 2024でも語られたので記憶にある方もいらっしゃるかもしれませんが、1999年にDrummond Reed（今はEvernymの買収に伴いAVASTにいますね）が中心に立ち上げたXNS.org要するにXRIからスタートしたので実はOpenID Connectは25年の歩みがあるんだよ、という話です。

詳細は省きますが、Hailstorm、Microsoft Passportを覚えてる人〜。3人くらい、、なんて場面もありました。もちろん手を挙げましたよ。はい。

Mikeはその頃は別の仕事をしていたんですね。2005年からアイデンティティをやっていたとのことです。

注目すべき転換点はChuckと同じくiPhoneの登場、もっというと2008年のAppStoreの登場を挙げていらっしゃいました。ストアに個人開発者がアプリを公開できるようになった結果、信頼できないアプリが世界中に溢れかえる事態を招いたわけです。こうなるとIDとパスワードをアプリに埋め込む、という従来のアプローチは怖くてやっていられません。この辺りがOAuthにおけるアクセストークンが必要とされた経緯ですし、OpenID ConnectにおけるIDトークンにも繋がる話です。

その頃に関与していた人たちで決めた仕様デザインを行う上での重要なポイントとして以下が挙げられていました。

• No Canonicalization
• Ascii armoring
• JSON
• REST
• JWx
• Based on OAuth WRAP

やはり正規化が大きな問題として取り上げられていたんですね。長く使われるプロトコルを設計する上ではセキュリティに関しては厳格にチェックする、という思想が生きているわけです。ここでも歴史は繰り返しますね。JSON-LD vs SD-JWT-VCの論争はそろそろ終わればいいのになぁ。。。

当時の人たち。若い・・・（除く猫）

最後に改めて、今ではフェデレーションのメインストリームとなったOpenID Connectはその地位をどのように獲得したのか？について振り返りがありました。

• 開発者フィードバックを聞いた
• 解決できていなかった問題を解いた
• 正規化をしなかった
• 歴史に学んだ
• シンプル導入 for 最小限の価値あるケース
• 開発者を大事にした

他にもJohn BradleyがOpenID Connectは単一の仕様だけじゃなくて色々と組み合わせて作られているよ〜という話から色々と解説してくれましたが割愛します。

Counselors in the Modern Era: Advancing Identity Management - Ian Glazer

Ianから今後のアイデンティティマネジメントはどうなっていくのか？という未来予想について、またその思想について話がありました。

今後アイデンティティマネジメントは個人にとってカウンセラーになる、という予測のもと、必要となるコンポーネントを提示しました。

• Credential Broker
• パスワードやパスキー、VCなどを使いあなたの代わりとして振る舞うために日t受容なコンポーネント
• Data Manager
• 同じくあなたのデータを扱うコンポーネント。真正性検証の観点からVCはこちらもで活用される
• Noodge
• Safeブラウザや仮名生成などプライバシーに係る機能を統括する
• Preference Resolver and Manager
• 同じくプライバシーの観点でSPがあなたのデータを使って何をしようとしているのかを解釈する。この辺りはLLMなども活用されることになるのではないか
• Interface Layer
• 複数のデータを同時に処理するためのMulti-Modalが標準となる
• Participatory Surveillance Manager
• 私たちの代わりに振る舞うには私たちを観測し普段の振る舞いを見ている必要がある。現在でもSiriなどはその一つだが今後はこれがクロスプラットフォームで動けるようになる必要がある

このようにして、デジタルアイデンティティがリアル世界のアウトカムに繋がる世界が到達するのであう。そして、これはコンシューマの話だけではない、もっと広い話なのである。

「Look towards identity management」

痺れますねぇ。さすがでした。

SAML Post-Mortem: Evolution, Challenges, and Future Prospects - Shannon Roddy

カリフォルニア大学バークレー校のIAM管理者の方ですね。SAMLaiとしては聞かざるを得ません。しかし参加者を含め年齢層が高い。あ、SAMLだからか。。。

Post-Mortem、いいですね。SAML is Deadその後、という感じです。

全体を通してのメッセージとしては、Research and Educationの世界ではまだまだSAMLなんですよ。だって2012年にSAMLは死んだのに2020年になってもSAMLのインプリメンテーションが多いんだもん。なぜならSAMLにはdiscovery serviceやmetadata query serviceのように大規模のフェデレーションで使うには重要な機能があるんだから。

事実、UC バークレイのIdPでは640以上の属性を管理し、500以上のSPがつながっているし、InCommonでも6000以上のSPと548のIdPがフェデレーションに参加しているんだよ。

まだまだR&E分野では使われているよ！

という話でした。

Multilateral Federation: The Solution to the Problem that Identity Wallets Don’t Yet Understand They Have - John Bradley

最後はJohnの話です。SAMLの流れから聞くと結構すんなり入ってくるので前にUCバークレーのSAMLの話を聞いておいて良かったです。

全体としては、Federationにおけるトラストモデルの変化とこれがWalletエコシステムにどのように適用されていくのか、ミッシングピースは何なのか？を分析したセッションでした。

まず、Federationの世界ではRPとIdPの間の直接信頼のモデルから始まりました。そこから規模が拡大していくにつれクラウドIdPをハブとするHub and Spokeモデルになり、SAMLにおける大規模Federationでは間接的なトラストを階層的に構成するモデル（EduGainやInCommonにおけるフェデレーション間信頼など）のモデルに成長していきました。

これを分散型と言われる3パーティモデル（Issuer/Holder/Verifier）に当てはめると、

• Wallet Provider
• Wallet Instance
• Issuer
• Verifier

のモデルの中でそれぞれのコンポーネントがFederationの初期のモデルと同じく直接の信頼関係を締結する必要があります。ではこれをグローバルでスケールさせるにはどうするべきなのか？

こうなるとTrust Managerのようなものが必要となり、結果USではAAMVA、EUでは欧州協議会が認定機関のように振る舞うこととなってしまいます。しかしこれはTrust Managerの乱立によるサイロができてしまうことになります。

実際は、

• Walletは複数のIssuerによって信頼されている必要がある
• IssuerはどんなVerifierによっても信頼される必要がある
• VerifierはIssuerから信頼される必要がある

ということになります。

そしてサイロを防ぐためにはこの信頼は地理的な要件ではなく、ポリシーによって構成されるべきであり、クレデンシャルタイプ毎にポリシーを構成することができるようになるべきだ、というわけです。そのことによりスケーラビリティのために必要なマルチラテラルな信頼モデルが構成されることになる、という話でした。

さて、明日は最終日なのであまりセッションはありませんが最後まで走り切りたいと思います。