久々にOP駆動のOpenID利用フローを考えました。
OP駆動のAssertionについてはこちらのエントリを参考してください。
- OP initiated の認証に関するメモ - Yet Another Hackadelic
- OpenID Unsolicited Positive Assertion - =kthrtty/(+blog)
簡単に言い切るところから始めましょう。
こんなしくみを今回考えます。
OPからRPへシームレスに識別子+属性を提供
現実的に使われそうな例を出したいので、ネットショッピングのフローにOpenIDをねじ込んでいきます。
以下のようなユースケースを考えました。
- 価格.comみたいな価格比較サイトでほしい商品を探す
- 気に入った商品を扱う複数のショッピングサイトのなかから一番安いショッピングサイトを選択
- レビューなどもまぁまぁなので、購入するためにショッピングサイトに移動
- ショッピングサイト内で決済処理
今回、価格.comがOP,各ショッピングサイトがRPになります。
書いていて価格.comがOPっていう説明は微妙かなと思ってきました。
Yahoo! JAPANだともっと説明しやすいのかも!!!
1,2あたりの画面がこちらです。
画面下の取扱ショップ一覧、OpenIDのRP一覧と考えます。
ここで、ショップのいずれかをクリックすると、各ショップの説明画面に移動します。
評価や口コミを見て、問題なかったらそのショップのページに移動するわけです。
通常、価格.comのヘビーユーザーだとしてもここで各ショップに遷移し、決済処理の際に住所情報を入れたり必要に応じてログインしてポイントつかったり、という流れになるでしょう。
ここで、OP駆動のアサーションを送りつけてやるのはどうでしょうか。
きっと「外部サイトに情報を渡すんだから利用規約に同意させて(ry」的な指摘を受けると思いますが、このRP確認画面的なものに含んでおけばいいでしょう。
今までよりは、各ショッピングサイト(RP)に遷移するときにはシームレスなログインもしくは新規ユーザー登録が実現できるかもしれません。
- 決済完了までのステップを減らすことでユーザビリティUP
- さらに決済システムをOPが持っているならCXで決済まで連携
シーケンスはこんな感じだと思います。
Yahoo! ショッピングや楽天などの大手が共通でOpenIDでユーザーを送りつける仕組みを採用すれば、ショッピングサイト側は開発工数がおさえられてメリットありありなのかなと。OpenSocialのアプリ開発みたいなイメージですね。
あと、id:ZIGOROuさんもおっしゃっているとおり、欲しい属性情報をRP側で定義しておいたりなんかするとOP側も便利かもしれませんね。
欲を言えば、ここに SREG やら AX などで RP のその return_to ではこういう属性が欲しい〜なんて提示も出来れば OP 駆動の認証開始がより便利になるかもしれない。
http://d.hatena.ne.jp/ZIGOROu/20081214/1229268753/