この記事は新歓ブログリレーではありません。
こんにちは、24Mの@hijiki51です。先日（1/19）@kyosu とOpenID Summit Tokyo 2024に参加してきました。そこで、今回はそこで聞いたセッションなどについて気になった・印象に残ったところをピックアップしながら記事にしたいと思います。（traQの会話ログと写真とにらめっこしながら）
今は四月ですよ？なにしてたんですか？
先日録画が公開されたようです（復習します）
OIDF Strategic Outlook for 2024 and Briefing on the Sustainable Interoperable Digital Identity (SIDI) Summit in Paris
まずはOIDF(OpenID Foundation)における 2024年の活動計画です。こうしてみると様々なWG(Working Group)が動いているのがわかります。調べてみたら現在(2024/4) 12のWG が動いているらしいです。ミーティングのURLや議事録も公開されているので後で見てみようと思います。
続いてSIDI(Sustainable Interoperable Digital Identity)の話です。国境を越えて相互運用可能なデジタルアイデンティティを作ろうという試みです。これを実現するために上に示したような様々な国(日本を含む)や標準化団体、企業が参加しています。
これらの国：団体がSIDIに対して何を求めているか(Champion Use Case)についてSIDI Summit中に調査をしたらしく、その結果が載っていました。
票数を見ると、やはり資格や金融関係は正確な本人確認が要求されることから、需要が高いことが見て取れます。一方、実現難易度に関しては需要が高いものでも半分ぐらいに割れていて、認識や実装コストに対するギャップがあることもわかります。このギャップをどう埋めていくかが持続可能性、相互運用性を担保するために重要なのかなと思いました。
OpenID ファウンデーション・ジャパン ワーキンググループ活動報告
個人的に今最も熱い仕様である OIDC4IA(OpenID Connect for Identity Assurance) の話が出てきました。OIDC4IAが何かというのは、その仕様書のIntroから引用すると、
for providing Relying Parties with identity information, i.e., Verified Claims, along with an explicit statement about the verification status of these Claims (what, how, when, according to what rules, using what evidence).
RPに Identity 、すなわち検証されたClaims を提供し、そのクレームの検証状況（なにを、いつ、どうやって、どのような手段で、どの証拠に基づいて）を明示するためのものである。(by DEEPL)
となっています。例えば、ある人の名前がOP(OpenID Provider)から取得できたとき、その名前が手で入力したものなのか、免許証から取得したものか、また登録時に本人確認を実行しているのか否かのような情報を一緒に返してくれます。これを用いれば、得られた情報に対する信頼性の保証を行うことができるというメリットがあります。
ちなみにOIDC4IAには日本の Trusted Framework として jp_aml (犯罪収益移転防止法) 、Documents(情報源) として jp_drivers_license (運転免許証)などがpre-defined valueとして登録されていたりします。
Panel: Celebrating Ten Years of OpenID Connect
こんな話がさらっとされてた記憶があるんですが、調べてもわかりませんでした。詳しい人見てたら教えてほしいです。
25 years of OpenID
前夜祭と称して 時間切れ対策のため？ 同じ内容が前日夜にYoutube Liveで配信されていたのでそれを貼っておきます。
昼食
下の階にあったカフェでラザニアを食べました。おいしかった～
EU Digital Identity Wallets (eIDAS 2) - status and way forward
ここからは Identity Wallet が中心となるセッションでした。Identity Walletはその名前の通り各個人の個人情報(Personal Identity Data, PID)を集約し、各RP(Relying Party)に提供するものです。いままでのResource Server とは違って各個人にデータの所有権が移るあたりが違うらしいですが、まだちゃんと理解してないです・・・（まだeIDAS (2014) のほうもちゃんと読めてない）気になる人は eIDAS 2.0 とかを読むといいらしい？
上の図はEUDI Wallet(EU Digital Identity Wallet) の概観図です。青い四角がWalletで、そこからRPにPIDを提示しているのがわかります。このPIDはその上流にあるPID Provider (国、機関など)によって発行されます。
これらのデータをどのように提供するか、保証するかについても検討が進んでいて、OIDC が強く関連するものとしては OpenID for Verifiable Credentials が提供のプロトコルとして、そのフォーマットとしては Selective Disclosure JWTs (SD-JWTs, これに関してはあとのセッションで詳しいのがあったので後述します) とかが採用されようとしています。（まだDraftの仕様も多い）
Waiting for the EUDI Wallet: Securing the transition from SAML 2.0 to OpenID Connect
イタリアでのEUDI Wallet の実装状況とその技術背景の説明がありました。
が、新しめの仕様が多く出てきて、ほとんど理解できていないです・・・。
Passkeys and Identity Federation
パスキーとID連携に関するritouさんのセッションです。主要なブラウザ・OSベンダーがパスキーに対応したことで、続々と各サービスがパスキーに対応し始めています。ここ1年は「○○がパスキーに対応」といったニュース記事をたくさん見かけた記憶です。
発表ではパスキーとID連携についてそれぞれのセキュリティ特性とUX、そしてそれらを組み合わせることによる効果を解説されました。
パスキー認証とID連携を認証方式として組み合わせることで、高いUXをパスキーによって実現したり、パスキー非対応の環境においてもID連携による認証手段が使えるなど、お互いの弱点を補完しあうことができます。
また後半にはパスキー認証とID連携の組み合わせに関連する仕様の紹介がありました。
セキュリティ要件の高いアプリケーションでは、OP側でのユーザー認証強度が低い場合に利用不可に or (RPがOPに)再認証を要求したいことがあります。その実現の手段として acr 等のクレームや acr_values 等のパラメータを使う方法が紹介されました。
ここらで登場するパラメータは仕様においてはOPTIONALで、最初に仕様を読んだ時にはその重要性をあまり実感できていませんでしたが、今回の説明を受けて理解がとても深まりました。
acr について、OIDC Core 1.0では具体的な値は定義されていないのですが、パスキーに関連する値は OpenID Connect Extended Authentication Profile (EAP) ACR Values 1.0 - draft 01 で定義されています。
最後に RFC 9470: OAuth 2.0 Step Up Authentication Challenge Protocol の仕様の紹介が行われました。
パスキーとID連携は普段アプリケーションを作る上でも認証方式として検討する部分でもあり、今後の開発の参考になるようなセッションでした。また、個人的にパスキーやOIDC関連のritouさんの記事をよく読んでいたので、対面でお話を聴けて良かったです。
実際の発表内容は以下のritouさんの記事で公開されています。(画像を一部引用させていただいています。)
ritou
OIDFシェアードシグナルフレームワーク（ID2）を利用してリアルタイムでセキュリティシグナルを共有するための最新情報
ここから二つはBreakout roomによるセッションです。
まずはShared Signal Frameworkの話です。これはOIDCの認証がログイン時のみに行われ、継続したモニタリングが行われていないという問題点に対する解決策の一つです。
シグナルの種類としては、ユーザーの状態（セッション、認証レベル）の変更を通知するCASP(Continuous Access Evaluation Profile)やパスワード漏洩、アカウント停止などのセキュリティリスクを通知するRISC(Risk Incident Sharing and Coordination) が挙げられていました。
このあたりの状態通知周りは私が知っているものだと、現状 OIDC Front-Channel/Back-Channel/RP-Initiated Logout 1.0 程度しかなく、その実装としても微妙に使いにくかったりしたのでこの仕様の登場はとてもありがたいです。今後の仕様の策定に期待＆注視していきたいです。
Verifiable Credential Demo ~ SD-JWT VC & mdoc/mDL issuance using OpenID for Verifiable Credential Issuance
Authlete社の川崎さんによるセッションです。このセッションではVC(Verifiable Credential)フォーマットとして指定されているSD-JWT VC フォーマットとmdoc/mDLフォーマットのVCをOID4VCIの仕様に基づいて二つ同時に発行するデモが行われました。
SD-JWTはSelective Disclosure(選択的開示)を実現するためのフォーマットの一つです。また、mdocは、ISO/IEC 18013-5:2021 で定義されているデータ構造で、 CBORというバイナリフォーマットに基づくものです。mDLはmdocの一種で、同 ISO 文書内で定義されており、モバイル運転免許証を表します。そして、OID4VCIはVCの発行手順を定義する仕様です。
SD-JWT, mdoc/mDL といったフォーマットや、OID4VCIの仕様は事前知識がほとんどない状態でしたが、丁寧な解説と実際のデモによって理解を一歩進めることが出来ました。
発表内容は以下の記事でも公開されています。(川崎さんの記事にはいつもお世話になっています。)
TakahikoKawasaki
また、OID4VCI 仕様の詳細な解説がAuthleteの公式サイトから出ています。ここら辺の仕様は今後しっかりと読みこんでキャッチアップしていきたいです。
分散の誤謬
最後は崎村さんによるクロージングです。「分散の誤謬」というインパクトのあるタイトルですが、内容も非常に印象に残るものでした。
話はWeb1.0、Web2.0の流れの解説から始まり、そしてWeb3(と言われているもの)の世界が本当に分散を実現するものなのか？というものでした。
Web2.0の特徴はAPIエコノミーで、各サイトがAPIを提供し、それを組み合わせることでサービスを実現するものでした。これは中央に集中的なデータベースを構える必要なく、分散されたデータをAPIを通じて必要に応じ取得します。このような分散の特徴を持つWeb2.0にも関わらず、現在はGAFAのような巨大企業が支配的になっています。
ではWeb3(分散ID/Walletの世界)はどうでしょうか。分散の度合いは集中と分散の二択ではなく、グラデーションを持ちます。
IdPの実行インスタンスの数の観点だとWalletモデルでは個人のデバイスの数以上になると考えられ、このことから分散と言われています。
一方で分散ID/Walletモデルは、データの保持場所の観点では個人のデータはWalletに超集中されることが想定されます。
また、IdP提供者の観点でも、最終的にWalletはプラットフォームへの集中が行われるのではないかと指摘されています。
このように皆で分散を目指していたはずが、結果として集中が発生してしまうという話でした。
Web3のマーケティング用語として「分散」や「自己主権」といった単語が使われているのを度々見かけますが、ある種の幻想のような話が多いです。Justinさんのと合わせて最後のセクションはそのような幻想に対し現実を教え、そしてDigital Identityのあり方を考えさせられるものでした。
発表と同様の内容のものが崎村さんのYoutubeで公開されています。
感想
- 英語の同時文字起こしはとても助かった
- 唐突なKanaria
- 最初のセッションにもあったが相互運用可能性は重要になりそう
- WG入りたい
- 今回知った様々な仕様・技術を今後追っていきたい
- あらためてDigital Identityの分野は面白いと思った
おまけ
夕食（破産）
参考文献
