Mixi内部でのOpenID利用法を応用すれば独自IDシステム構築のASPサービスができる

ちょっと前に、Mixiが内部で異ドメイン間の認証情報持ち回りにOpenIDを使っている　という記事がありましたが。
それって、ConsumerとIdPを同じ主体が管理している必要は全然ないので、独自IDサービスが欲しいけど処々の事情で内部ではIDサービスを用意できないというような企業に対し、ID機能をASPするようなサービスに応用できるよね、と思った。

図で説明すると、一般のOpenIDの認証シーケンスは以下のような感じ。
（注：すみません、以下の図、CNETだったかITmediaだったかのOpenID記事中の図をベースに作っています。が、図を作ったのがずいぶん前であったため、図の出典を忘れてしまいました。すみません、盗用の意図はないので、どこの図かご存知の方がおられましたら、ご一報いただければ幸いです。）

でも、Mixiの場合、完全なOpenIDだと最初にConsumer側からユーザに入力されたClaimed Identifier送って、とかの手順があるはずだけど、それがない。
なので、OpenIDのシーケンス利用してると言っても完全に同じではないよね、と思って追ってみると、以下のような感じだった。

でも上の絵で、MixiはConsumerもIdPも社内で持っているけど、別にIdPは他社が持っていても話は成り立つんじゃないの？と思った。
自分で独自IDを構築できないConsumer社のために、ASPでIdPを用意して、ドメインだけConsumer社のドメインを割り当ててもらって外部からはConsumer社が運営しているID機能のように見えるけど、実はアウトソースしてます、みたいなのはアリじゃないかと思った。

「自分で独自IDを構築できないってどんな場合よ」とかツッコミありそうだけど、「ID機能作りたいけど親会社がコンプライアンスにうるさくて、お客様の個人情報を預かるようなサービスを作るならプライバシーマークを取ってないと構築を許してくれない、でもID導入は火急なので悠長にプライバシーマークなんて取ってられない」みたいなケースだってあるのではないかと思います。
また、「それならはてな認証とかそれこそOpenIDとか、外部認証使えよ」というツッコミもあると思うのですが、ユーザ利便性と技術面だけ考えればそれで万々歳なのですが、企画やマーケティングをする人の立場からは、同じID機能導入するならば、IDの導入により単なるユーザへの利便供与ではなく、ユーザ属性による行動分析等で次のサービス検討等に結び付けたい、というニーズもやはり存在します。

なので、「独自のID機能を設けたいけど、設けられる状況にない」というようなサービスを抱える企業のために、プライバシーマークや障害・災害時対応等も十分信頼されるレベルでのIdPサーバを構築して、それを外部にASPするというようなサービスも、有り得るのではないかと思いました。