SAML: 悪いデザインのフラクタル

… 署名が実際に何をサインしてるのかを確認しなきゃいけない。つまり…署名をどうやって確認するつもりなの？署名を検証するためのデータが必要だよね。

よくテストされていて、きちんと書かれたライブラリで、（良い）SAMLのサブセットだけをサポートしている例って何かある？

それが元々のOpenID（LiveJournalの時代のやつ）でしょ？「自分のアイデンティティをホストする」ってやつ。

OpenID Connectは、フェデレーテッドログインをサポートするための仕組みを、動的発見や動的登録の仕様の一部として持ってるんだ。でも、誰もそれを使ったり実装したりしないのが問題。小さなテック企業はフェデレーテッドログインを望んでないし、基本的にSSO税に頼ってエンタープライズ顧客をアップセルするのが好きなんだ。大手認証企業もフェデレーテッドログインが進むのを望んでない。競争相手が増えて、彼らの異常な利益率が脅かされるからね。ビジネス面が解決されるまでは、どんなに技術が改善されても何も変わらないと思う。OpenID Connectのいくつかの小さな相互運用性のギャップは、関係者が本気で取り組めば数ヶ月で修正できるはずだよ。

自分が管理するバックエンドを使って、どこでもアカウントを作ってログインできるべきだ。実現可能だけど、今のやり方では無理だね。IndieAuthは存在してるけど、広くサポートされてないんだよね。

記事が指摘してるように、SAMLがJSONを使ってないことを批判するのはちょっと不公平だよね。だって当時、JSONなんてほとんど存在してなかったし。構造化データのシリアライズされた表現が必要だったら、必要以上に機能が豊富でもXMLを使うのがエンジニア的には理にかなってたと思う。代替案はASN.1か、自分でゼロからフォーマットを作ることだったけど、それが本当に良いとは言えないよね。（自分でフォーマットを作るのがXML特有のセキュリティ問題に対して脆弱じゃないって理由で賛成することもできるけど、その問題が当時は十分に理解されてなかったと思う。もし理解されてたら、特定の問題を引き起こす機能を無効にした準標準的な安全なXMLのバリアントが考案されてたかも。）XMLは、セキュリティに関わるミス機能がなくても、マークアップ言語が必要ない大多数のユースケースにはJSONや他の非マークアップ言語のシリアライズフォーマットより劣ってると思うけど、これは大した問題じゃない、基本的にはただの構文の問題だよね。

本当の問題は、eXtensible Markup Languageを使っておきながら、すでにその言語のコア機能である内側の拡張性の構文を自分たちで作り出したことだよ！名前の最初の単語なんだから！「JSONを使う」みたいなもので、実際には自分たちが作ったオブジェクト表記を通じて間接的にオブジェクトをエンコードしてる感じ…それが構造化されてるんだ。

原則的にはそれができるよ。ほとんどの非エンタープライズツールはそれをサポートしてないけど、単にIdPが欲しいわけじゃなくて、アンチスパムや評判管理、アカウント回復のアウトソーシング、大量ユーザー作成の制限を行うIdPが欲しいんだよね。誰でもいつでも自分が誰かを証明できるなら、ユーザー名とパスワードだけで済ませられるのに。

認証って、ただの文書やデータストリームじゃないんだよね。ここでちょっと混乱しちゃった。KerberosやOAuth（特にJWT）を使った経験からだけど、JSONのことを言ってるんだ。もし「マークアップ」って言うのが「XMLはダメ」って意味なら、それには同意するよ。Kerberosには「マークアップ」みたいなものがあって、主題に関する便利なメタデータを運ぶための型付きの穴があるんだ。特に「authorization-data」って呼ばれるものね。でも、a) KDCに便利なサイトローカルの情報を含めさせるのは本当に面倒くさいし、b) Kerberizedサービスがその認可データにアクセスできるようにするのは驚くほど難しい！(b)は意外だよ。しばらくその問題に取り組んでたけど、Kerberosに関してはたくさんの作業をしてきた。でもAPIはたくさんの作業が必要で、CだけじゃなくてJavaやPythonなど、いろんなことが絡んでくるから、最後の部分は橋渡しに大量の作業が必要なんだ。結局、アプリケーションがデコードしなきゃいけない{何らかのデータ型ID, それに応じてエンコードされたデータ}の山ができちゃう。だから、次のことをしなきゃいけない： - サイトローカルのauthzデータの構文/エンコーディングを指定する - KDC側のコードを書く（できればプラグインだけで） - RFC 6680を実装する - いろんな言語のバインディングを含める - アプリで使うためのauthzデータデコーダーを実装する - そのアプリでデコーダーを使う これが終わらないんだ。で、JSONと比べてみると、署名やMACの検証、トークンの復号が終わったら、今度はクレーム用のJSONテキストが手に入る。トークン発行者にサイトローカルのクレームを注入するのは簡単だし、アプリで使うのももっと簡単（JWTバリデーターがあればね、そうじゃなきゃ署名の検証を忘れると簡単すぎるけど！）。JWTはこれをうまくやった。Kerberosは間違えた。Kerberosを擁護するなら、これは80年代中頃から後半にかけてのもので、GSS-APIは90年代初頭から中頃にかけてのものだから、30年以上、40年以上前の話なんだ。すべてJSONやXMLが登場する前のことだけど、2026年の今、Kerberosは擁護できない。Kerberosはまだ必要だけど、便利なアプリケーションプロトコルやその実装のための仕様がたくさんあるし、Active Directoryのためにも必要なんだ。このことから学んだのは、GSS-APIが00年代中頃にはgss_accept_sec_context()のバージョンを成長させて、JSONテキストを出力する必要があったってこと。あの頃に戻ってそれを作りたかったな。だから、認証コンテキストのメタデータ、特に認可に役立つメタデータは「マークアップ」言語、特にJSONで表現できるし、すべきだと思う。