草の根型認証システムとLiberty
世の中にやっとIdentity Federationという言葉を認識してもらいつつあるのに（しかも認識だけで、理解とはちょっと遠い）、いきなりUser Centric Identityのような新しい言葉が出てくると、それだけで憂鬱になるエンジニアも多いのではないでしょうか。
まあUser Centric Identityはちょっとおいておくとしても、さらに世の中に目を広げてみると、最近、草の根的に様々な分散型個人識別システム、認証APIが跋扈しているのが見て取れます。
(実はこれらの全部の内容を知ってるわけじゃないんですけど＾＾；)
これらはエンタープライズで利用されるフェデレーションプロトコルなどと比べて、対象とする問題領域がそれぞれ異なっている（特定領域にフォーカスしている）、ある特定サービスに紐づいているという点に特徴があります。
で、エンタープライズのフェデレーションプロトコルの代表選手であるLibertyはどうかというと、さすがエンタープライズレベルで必要とされている要求をちゃんと網羅しています。すなわち、一般的なサイト間アイデンティティ連携にまつわる問題（個人識別から信頼関係に基づく属性共有まで）の解決にふさわしい標準を定義してくれているわけです。
それなのに、なぜ上に挙げたものたちがわざわざ登場し、実際のサービスで使われだしているのでしょう。ただ単にみんな不勉強で、車輪の発明を繰り返しているだけなのでしょうか？
なんとなく、Libertyはあまりに問題解決を網羅しすぎてしまった印象があります。それがために、たとえばブログのコメントを書くときの認証に応用しようとしても、ちょっと重すぎて使えない。Libertyの本当のうまみとされるサービス間でのアイデンティティ属性共有にしても、サービスサイトが独自に行う仕組みに負けてしまう。ちょっとこれは残念な気がします。Libertyのエバンジェリングでなんとかなるものならなんとかしたいのですが。
で、Oracleがそれに対してどう思っているかというのは、実のところはよく知りません。ただ、Oracle COREid Federation では WS-Federation、Liberty ID-FF、SAML2.0と主要なフェデレーションプロトコルをサポートします（マルチフェデレーションプロトコルへの対応）。ということで、これは本当に個人的な期待でしかないのですが、今後Web 2.0世界？でドミナントをとるかもしれない草の根認証APIに対してもうまく対応できるはずです。もちろんそれがLibertyである可能性もありますし、そうであってくれればかっこいいですね。
ちなみにOracle Application Server 10g R3 (OC4J 10.1.3)ではWebサービスとしてSOAPだけでなくREST XMLも受け付けます*1。RESTはAmazonやYahooのWebサービスでも使用されているコンシューマ向けサービスで特に人気のあるWebサービスプロトコルです。Oracleの主戦場がエンタープライズだからといって、LightWeight化の流れを無視しているわけではない、ということが読み取れます。
