OpenID Connect仕様がISO標準として発表
(self-issued.info)- OpenID Connect の仕様9件がISO/IEC標準として発行され、Core 1.0、Discovery、Dynamic Client Registration、ログアウト仕様、OAuth 2.0レスポンスモードまで国際標準体系に組み込まれた
- OpenID Foundationは2023年12月に PAS(Publicly Available Specifications) 方式でISOに提出し、その後のISO承認投票を経て発行まで完了した
- ISO標準化により、国際条約上認められた標準化機関の仕様を求める法域でも OpenID Connectの導入 が容易になる可能性がある
- 提出前にOpenID Connect working groupは、ISO版に既知の修正事項が入るよう errata corrections を適用する手続きを進めた
- OpenID Foundationは今回のPAS手続きの経験をもとに、FAPI 1.0、最終化後のeKYC-IDAとFAPI 2.0仕様群もISO発行の対象として提出する計画である
ISO/IEC標準として発行された仕様
- 今回ISO/IEC標準として発行された OpenID Connect 関連仕様は9件
- ISO/IEC 26131:2024 — Information technology — OpenID connect — OpenID connect core 1.0 incorporating errata set 2
- ISO/IEC 26132:2024 — Information technology — OpenID connect — OpenID connect discovery 1.0 incorporating errata set 2
- ISO/IEC 26133:2024 — Information technology — OpenID connect — OpenID connect dynamic client registration 1.0 incorporating errata set 2
- ISO/IEC 26134:2024 — Information technology — OpenID connect — OpenID connect RP-initiated logout 1.0
- ISO/IEC 26135:2024 — Information technology — OpenID connect — OpenID connect session management 1.0
- ISO/IEC 26136:2024 — Information technology — OpenID connect — OpenID connect front-channel logout 1.0
- ISO/IEC 26137:2024 — Information technology — OpenID connect — OpenID connect back-channel logout 1.0 incorporating errata set 1
- ISO/IEC 26138:2024 — Information technology — OpenID connect — OAuth 2.0 multiple response type encoding practices
- ISO/IEC 26139:2024 — Information technology — OpenID connect — OAuth 2.0 form post response mode
PAS提出とISO承認
- OpenID FoundationによるOpenID Connect仕様の提出は、2023年12月に PAS(Publicly Available Specifications) の形で行われた
- ISO承認投票を経て、該当仕様はISO/IEC標準として発行された
- ISOは国際条約上認められる標準化機関の一つであるため、このような機関の標準利用を法的に求める法域では、OpenID Connect導入の可能性が広がるとみられる
ISO版に含まれた修正事項
- 提出前に OpenID Connect working group は、仕様にerrata correctionsを適用する手続きを進めた
- その結果、ISO版には既知の修正事項が反映された
1件のコメント
Hacker News のコメント
約17年前に OpenID にかなり深く関わっていたにもかかわらず（https://simonwillison.net/search/?tag=openid&year=2007）、OpenID Connect が「識別子は URL であり、その URL の所有権を証明する」という元々の OpenID のアイデアとはほとんど無関係だと理解するまで、恥ずかしいほど長くかかった。
OpenID Connect は実質的には OAuth の進化形に近い
OpenID Connect は OAuth の進化というより、ビジョンや精神の面では OpenID の進化に近いと思う。OIDC は OpenID と同様にユーザー識別と認証に焦点を当てているが、OpenID と違ってまったく新しい認証フローを作り直したわけではなく、すでに認証用途に誤用されていた OAuth 仕様の上に認証フローを載せることで主目的を達成した
そのため、OIDC 準拠を目標にしていないシステムでも、部分的には OIDC に従っていることが多い。OIDC 標準の一部がすでに必要なものを提供しているなら、わざわざ車輪を再発明する理由はない
OpenID Connect は OAuth2（RFC 6749）に認証レイヤーを追加した拡張であり、OAuth2 は権限を付与する認可フレームワーク。
一方で OAuth 1.0/1.0a と OpenID 1/2 は名前が似ているだけで、互いに関係も互換性もないプロトコルなので、2024年時点ではほとんど無関係。検索するときは注意が必要
これはどの面から見ても良いことではない。まず、お金を払わないと見られない 有料標準は本当に悪い。
次に、必要になったときに際限なく時間を浪費しなくて済む標準と実装を設計するために、もっと努力が注がれるとよい
ただし、ISO 標準番号を得ることが、インターネット上に HTML 文書を置くことよりどんな利点があるのかはよく分からない
標準は良いものだが、ISO のような大きな標準化団体が標準を見るのにお金を取るのは腹立たしい。
おそらく一部の企業や業界では、IETF や汚いオープンソースのヒッピー集団が作ったものより、そうした組織の 「本物の」標準を要求するからなのだろう
そのため OpenID Connect が ISO 番号で発行されると、一部のプロジェクトでは導入が容易になる。もちろん OpenID Connect 自体は引き続き無料で閲覧・利用できるが、上記のような状況にある人々にとって、より選びやすい選択肢が生まれる
ISO は自由でないゴミであり、ソフトウェアエコシステムの役に立たない。
ISO 8601 を見ると、過度に複雑で、メンテナーが無料の草案を使ったせいで正しく実装されないことが多く、実際には何かをきちんと解決しているわけでもない。たとえば壁時計時刻を表現できないため、タイムゾーンが変わり得る将来の日付で問題が生じる。
以前 mp4 も扱ったことがあるが、Apple スタックに変更点があり、ISO だけでは十分でないことが分かった
批判はたいてい夏時間変更のような仮定へ流れていく。「4年後のアブサーディスタン現地時刻14:00を、UTC との関係が何であれ指定したいができない」といった批判がよくある。だが仮定をもう少し進めると、アブサーディスタンが海外領土を追加したり、同盟に加入したり、タイムゾーンや夏時間を変えたりする可能性もある。
問題を考えると、現地時刻の定義そのものが変わり得るので、あり得るすべての変更を漏れなく定義しない限り、将来の現地時刻を指定することは不可能だ。結局、将来の 原子時計のティック数（TAI） を決めて使用時点で現地時刻に解釈するか、何らかの固定時刻を指定したうえで使用時点に現地時刻として解釈するしかない
新しい JS Temporal API がこれを扱うのかも気になる。かなり深く踏み込んでいるようだったが
ISO のような 読むのに有料の標準は、人類の進歩を積極的に妨げている。こうした行為を奨励しないでほしい
最終草案と公式標準は、実質的な内容の面ではほぼ同じだと理解している。OIDC 標準の草案もどこかで公開されていると思う
そのエンジニアたちが人類の進歩を生み出しながら、同時に人類の進歩を積極的に害していると言うのは変だ
アイデンティティ・プロビジョニングは、発明されるべきではなかった怪物だ
2000年代半ばには自分で OpenID サーバーを運用するほどのファンだったが、この概念全体が根本的にどれほど欠陥を抱えているのか分かっていなかった
アイデンティティは個人に内在する譲渡不能な属性であって、他の個人、企業/ウェブサイト、政府などが「提供」できるものではない。彼らにできるのは、パスポートを発行するようにクレデンシャルを提供して証明することだけだ
少なくとも WebAuthn はこの点を正しく捉えている
あるアイデンティティは十分に多くの場所で使っているため、一部の主体に対してはそれが自分のものだと否認しにくいかもしれないが、その場合でも、そのアイデンティティを見た主体のうち、私であることを証明できるところは小さな部分集合にすぎない
Google、MS、Apple 以外でアカウントを作れる独立系 OIDC 発行者はまだ残っているのか？
少し前に GitHub アカウントを使わずに Tailscale アカウントを作りたかったが、できなかった
以前は openid.net と Ubuntu One がこうしたサービスを提供していたように思うが、停止したと理解している
ただ、この種のサービスに必要なセキュリティとサポートのコストは大きく、特に無料で提供するのは小規模な組織には現実的ではない。これを可能にする規模の経済は大きく、企業向け製品に大企業が支払う場合は特にうまくはまる
OpenID Connect はかなり単純なプロトコルだ。仕様（https://openid.net/specs/openid-connect-core-1_0.html）を読んで、1日ほどで大部分を理解できた
仕様を読みたくない人のために、単純な HTTP リクエストで OpenID クライアントを実装する総合チュートリアルも書いた（[https://spapas.github.io/2023/11/29/openid-connect-tutorial/](https://spapas.github.io/2023/11/29/openid-connect-tutorial/））
例は Python を使っているが、好きな言語で実装するのは難しくないはずだ。複雑な部分の大半は JWT トークンをデコードして検証するところにある
この手書きのクライアントを実際の本番プロジェクトで Keycloak 認証に1年ほど使っており、すべて完璧に動作している
追伸: 自分のサイトに広告が多すぎるのは分かっている。残念ながら Google Ads をきちんと設定する時間がなく、より良い代替案も見つけられなかった。読むときは広告ブロッカーを使えばよい
ただし、単純だのような主観的な表現には注意したほうがよい。読者が難しいと感じているのに筆者が単純だと言うと、かなり萎縮してしまうことがある
それでも OIDC が簡単だという点にはまだ確信が持てない。Keycloak は途方もない複雑さを隠しており、開発者たちが退屈しのぎにそう作ったわけではない。例えば SSO タイムアウト、クライアントタイムアウト、複数のトークンタイムアウトなど、さまざまなタイムアウト設定が非常に多い
ISO 標準をめぐる収益化と組織運営は、全体として非常に怪しく感じる
あまり知られていないコツとして、親切なエストニアのサイト https://evs.ee で、より安い版の標準を探せる。彼らはしばしば、原本とほぼ同じ内容を含む独自版を作っている。残念ながら今回の場合は、実際の標準を同程度の価格で提供しているだけのようだ https://www.evs.ee/en/search?OnlySuggestedProducts=false&que...
後でより良い価格の独自版が出るか、サイトを見守る価値はある。通常、価格は原本の約10%程度だ。エストニアが素晴らしいことをしている、もう一つのデータポイントだ
医療機器のコンプライアンス業務をしているので、かなり怪しい標準化団体をよく相手にしている https://openregulatory.com/accessing-standards/
「標準化にはお金がかかる」「こうした組織は良い仕事をしている」といったよくある論理はすべて聞いたが、まったく同意しない。何かが標準であるなら、それは法律に近いものになると思う。人々はそれに従えるべきであり、そのためには自由にアクセスできなければならない。EU の法務官も同意しているようだ https://openregulatory.com/maybe-eu-standards-are-becoming-f...
PDF を怪しげに有料で売らなくてもよい標準化はたくさんある。ECMAScript と ANSI C が思い浮かぶし、ほかにもまだ続く
ISO 出版物にすると、調達部門にとっては責任回避用の盾になる
何にせよ、ISO 標準一式への準拠を求めたという理由で解雇された人はいないのだから