NTTは2月19日、計算機科学の未解決問題を解決したと発表した。同社が解決したのは、著名なデータ構造として知られる「二分決定グラフ」に関する未解決問題。今回示した理論は、計算機科学の著名な教科書にあった記述の誤りを指摘しており、研究チームの修正案が承諾され、内容が改訂されるという。
また、計算機科学の著名な教科書「The Art of Computer Programming」（TAOCP）には“一部の演算については多項式時間（多項式で表現できる時間のこと）で実行可能である”と記載があった。しかし実際には、多項式時間で実行可能であることに関する証明は、これまで存在していなかった。
今回研究チームでは、集合族の積（Join）の計算量が不明だった演算に着目。一度の演算の実行が複数回の共通部分・和集合演算と等価となり得ることを発見した。これを基に、一度の演算で二分決定グラフのサイズが指数的に増加する事例を示し、多項式時間で演算を実行することが不可能だと初めて証明した。
また今回の理論は、TAOCPの誤った記述を指摘している。NTTの提案は、TAOCPの著者であるドナルド・クヌース博士も承認し、教科書の記載を改訂する予定。
⇧ 計算機科学の著名な教科書に誤りがあったとか、衝撃的ですな...
かなり影響範囲が大きそうな気はしますな...
OpenID Connect（OIDC）とは
公式のドキュメントによると、
What is OpenID Connect
OpenID Connect is an interoperable authentication protocol based on the OAuth 2.0 framework of specifications (IETF RFC 6749 and 6750). It simplifies the way to verify the identity of users based on the authentication performed by an Authorization Server and to obtain user profile information in an interoperable and REST-like manner.
⇧ とあり、
『an interoperable authentication protocol based on the OAuth 2.0 framework of specifications (IETF RFC 6749 and 6750)』
認証プロトコルとあるのですが、
⇧ 登場人物の関係が分り辛いという...
そして、
⇧ アプリケーションの実装によっても登場人物が変わってくるという...
そもそも、人手によるログイン画面の無いアプリケーションもあるんでね...
GitHub ActionsにおけるAzureとのOpenID Connect（OIDC）について整理してみる
「GitHub Actions」のドキュメントを確認すると、
GitHubの OIDC プロバイダーは、Azure のワークロード ID フェデレーションと連携します。 概要については、「ワークロード ID フェデレーション」の Microsoft のドキュメントを参照してください。
Azure で OIDC ID プロバイダーを構成するには、次の構成を実行する必要があります。 これらの変更を行う手順については、Azure のドキュメントを参照してください。
⇧ とあり、
| No | OIDC登場人物 | クラウドプロバイダー | |
|---|---|---|---|
| クライアント | サーバー | ||
| GitHub | Microsoft Azure | ||
| 1 | OIDC プロバイダー | ✅ | |
| 2 | OIDC ID プロバイダー | ✅ | |
⇧ とりあえず、名前が紛らわしいのだが、2つのリソースが「OpenID Connect（OIDC）」の登場人物として出てきますと。
別のページを確認すると、
⇧ 上図のような感じになっている。
で、「GitHub Actions」のドキュメントのリンクから「Azure」のドキュメントのページに遷移して内容を確認すると、
⇧ とあり、GitHub側からAzure環境に接続するということから、「GitHub-hosted runners」における話になりますと。
ワークロード ID フェデレーションを使用して、Microsoft Entra ID のユーザー割り当てマネージド IDまたはアプリ登録を構成し、GitHub や Google などの外部 ID プロバイダー (IdP) からのトークンを信頼します。
https://learn.microsoft.com/en-us/entra/workload-id/workload-identity-federation
⇧ まさかの「GitHub Actions」のドキュメントと反対になっている...
■GitHub Actionsのドキュメント
■Microsoft Azureのドキュメント
言っていることが、真逆であると...
とりあえず、
⇧「Azure」のドキュメントでは、一貫して、「GitHub」側を「IdP（ID Provider）」としているのだが、「GitHub Actions」のドキュメントでは、「Azure」側を「IdP（ID Provider）」としているという...
「Azure」のドキュメントによると「信頼関係」の構築手順でも「external identity provider」に対して、とあるので、どちらかが間違っているとは思うんだが、公式のドキュメントでこの状態は辛過ぎる...
■Configure an app to trust an external identity provider
■Configure a user-assigned managed identity to trust an external identity provider
■Sign in with a managed identity configured on an Azure virtual machine (Only available for self-hosted GitHub runners)
⇧ Azure Loginで認証する場合は、
- a federated identity credential on an application in Microsoft Entra ID
- a federated identity credential on a user-assigned managed identity in Microsoft Entra ID
- a managed identity configured on an Azure virtual machine (Only available for self-hosted GitHub runners)
の3択になってくるということなんかね？
ログイン画面の無いようなアプリケーションにおいて、ユーザーに紐付く認証情報になるのは芳しくないと思われるので、
- a federated identity credential on an application in Microsoft Entra ID
- a managed identity configured on an Azure virtual machine (Only available for self-hosted GitHub runners)
のどちらかを採用していく形になるってことですかね？
で、「GitHub Actions」側の対応は、
⇧ を行う必要がありますと。
のどちらで、どんな作業が必要なのかが、非常に分り辛い...
とりあえず、公式のドキュメントの整合性を何とかして欲しい...
用語の定義や使い方が錯綜し過ぎなんよね...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
