昨日は夜新橋まで
OpenID技術セミナーを受講しに行く。
とりあえずOpenIDの存在は知ってたものの、実際にどうこれを使うかという点で、今のビジネスといまいち結びつかない部分があったので、ちょっと一度おさらいが必要かと思ったので。
んで受講した感想ですが、今の新宿の会社でメインに扱ってるような求人系サイトだと、まだOpenIDは使いづらいかなぁ、と。
求人系サイトでユーザ登録させる理由って、結局は「新着求人のメール配信」だったり、「求人に応募するときにいちいちプロフィールを入力しなくてもいい」とかだったりするので、前者だったらE-Mailが必要になるし、後者なら氏名・住所・電話番号とかが必要。それに対し、今のOpenIDだと単なるユーザ認証機能しかないところが多い（というか日本国内だとほぼそれしかない）ようなので、少なくとも他社のOpenIDでログインできるようにする（＝OpenIDのRPになる）メリットがあまり見出せず。
mixiが将来的にOpenIDのsreg・AX（どっちもOpenIDで個人情報とかを受け渡しできるようにする機能）対応を拡張する方針らしいので、それが広がってきた段階で対応を検討しようかな、と。
自社で運営している人材紹介会社向けASPのユーザ認証にOpenIDを使うってのも考えたんですが、実際運用してると異なる企業で採用担当者が同じ人（グループ会社で一括採用してるケースとか、採用業務そのものをアウトソーシングしてる場合などにありがち）ってケースがあって、そこにOpenIDを入れてしまうと「どの企業の情報を表示すればよいか」が区別できない、ということが判明したため（今は1つのユーザID（＝E-Mailアドレス）に複数パスワードを設定できて、パスワードによってどの会社の情報を表示するかを判断してる）、これも現段階では難しいという結論に。
＃まあやってやれないことはないんでしょうが、どっちにしろUIの変更が必要なので。
結局今のOpenIDって、現時点でユーザ認証系のシステムを持たないところが新たに認証系を持ちたいとか、ちょっとしたSpam避けをやりたいという場合には有効だけど、サイト内に個人情報を持たないとどーしよーもないところには向きじゃない、という感じ。
むしろそういう意味では、今管理してるサイトがOpenIDのOPになって（＝OpenIDを発行し、RPからの認証要求を受け付ける）、既にサイト内で保有してる個人の職歴情報なんかをAXで提供できるようにするほうがむしろビジネスとしてはありかも。
まあうちは開発会社なので、あくまでクライアントからの要望がないとそういうことは勝手にはできないわけですが。
