スパイスラボ神部です。

前回のエントリ（OpenID で OP Identifier をつかって楽々ログイン(２) ( ラボブログ ) ）で調べた資料を見ていて、ちょっとオチが見えてきました。しかも壮大な。

何か壮大な見落としをしていたかもしれません。

-壮大なオチが好きだ！ - Favorites!

実は既に OpenID Authentication 2.0 Ready な RP になっていたかも

上記記事で参考にした 10分で作るYahoo! OpenID RP (Yahoo! JAPAN Tech Blog) という記事によると、http://openidenabled.com/ にある OpenID Library を導入せよとあります。

一方、もともと参考にしていた「【CakePHP】OpenIDをAuthComponentにトッピングしてみる | ねねとまつの小部屋 」を見ると、こちらでも PHP OpenID Library を導入せよとあり、実際に自分の環境でも導入が完了しています。

ということは、既に OpenID Authentication 2.0 Ready な Relay Partner になっており、Identifier の渡し方が間違っているだけなのでは？

と言うことで実験

いままでは OpenID に対応させたログインフォームはこんなコードでした。

echo $form->create('User', array('action' => 'login'));
echo $form->input('username"));
echo $form->input('password"));
echo $form->input('OpenidUrl.openid');
echo $form->submit('');
echo $form->end();

これを、こんな風に変更。

echo $form->create('User', array('action' => 'login'));
echo $form->input('OpenidUrl.openid', array("label"=>"", "type"=>"hidden", "value"=>"yahoo.co.jp"));
echo $form->submit('http://i.yimg.jp/images/login/btn/Ymark.gif');
echo $form->end();

これで Yahoi! のロゴをクリックすると・・・

無事 Yahoo! の認証ページに転送されました！！！

ということで・・・

大変間抜けなオチですが、OP Identifier をつかって簡単にログインするための準備はとっくに整っていたようです。ただ、 OP Identifier についてより知ることが出来たということと、具体的な渡し方が類推できたことはよかったように思います。

結論としては、

-【CakePHP】OpenIDをAuthComponentにトッピングしてみる | ねねとまつの小部屋 に従うとユーザに OpenID を入力させずにボタンクリックでログインさせる OpenID 2.0 Authorization ための準備はととのっている！

-渡し方は簡単で、具体的には OpenidUrl.openid に Op Identiier（yahoo.co.jp や mixi.jp という文字列）を渡してあげるだけ！

という感じでしょうか。

この経験を活かしていろいろなサイトをがしがし OpenID 対応にしてみたいと思います！

-半落ち (講談社文庫)が好き！ - ILOVEIT(β)

スパイスラボ神部です。

OP Identifier を使って、OpenID Authentication 2.0 ライクなユーザインターフェースを提供するかどうかを調べています。これがけっこう手がかりがなくて困っています。まずは、ここが参考にはなりそうなのですが・・・

-OpenID Authentication 2.0時代の幕開け － ＠IT

なにが必要か

まず、OpenID 1.1 での認証は出来る状態になっているとして、その先のことを考えてみます。

-OpenID Provider (OP)にどうやって OP Identifier を渡すか（まさか GET で渡すでもないだろうし）

-認証が取れた状態を、どうやって手元のシステムに戻すか

-Claimed Identifier の扱いは？（渡してあげるとか、しなくていいのか？）

-その他何か見落としがないかなど

引き続き調べてみます。

ログインボタンのリンク集を集めてみる

-Yahoo!デベロッパーネットワーク - Yahoo! JAPAN IDログインボタン

-mixi Developer Center (ミクシィ デベロッパーセンター) » ログインボタン

-OpenID導入をご検討のサイト様へ - BIGLOBE OpenID

RP になるには

いろいろ調べてみて、今やろうとしていることをテキストで表すと、

-自分のサービスをOpenIDでログインできるサイト、すなわちRPとは（Relying Party）にすること

-利用するOPを入力させることで認証させる

ということになるようです。

-10分で作るYahoo! OpenID RP (Yahoo! JAPAN Tech Blog)

が参考になりました。

-OpenIDでログインできるサイトを作成する2 - DoboWiki

こちらも参考になるかも。

スパイスラボ神部です。

（7/28 修正）id:ZIGOROu さんより 2009-07-27 - Yet Another Hackadelic といった感じのあたたかいかいご指摘をいただきました。今回使用を意図しているものは「OP EndPoint URL 」ではなく、「OP Identifier 」になるということで、各所用語を「エンドポイント」から「OP Identifier 」に修正しています。あしからずご了承ください。

今日はちょっとだけ CakePHP をさわれています。CakePHP で OpenID を使うとき、いつも参考にさせていただいているのが 【CakePHP】OpenIDをAuthComponentにトッピングしてみる | ねねとまつの小部屋 というエントリなのですが、このサンプルの場合、ユーザに OpenID を入れてもらわないといけないという問題があります。例えば mixi の場合は https://id.mixi.jp/xxxxx といったものが OpenID になるのですが、これをユーザに調べて自分で入れてもらうのは面倒ですよね。

そこで OpenID には OP Identifier というユーザ誘導のためのすばらしい仕組みがあるため、このステップをパスさせることができます。上記エントリの続き的に、OpenID Component をトッピングした状態で、CakePHP でこのエンドポイントを処理するにはどうしたらいいのか、といいうのを考えてみましょう。

とかいいつつ今回は予告編。次回で具体的な実装について書いてみたいと思います。

-OP Identifier が好きだ！ - Favorites!

追記

ご指摘いただいたエントリの中で呈示されているこちらの資料 Introduction OpenID Authentication 2.0 Revival によると、OP Identifier のほかに Claimed Identifier というものも使えるそうで、これらはまとめて「User-Supplied Identifier」と呼ばれるそうです。

関連資料

-速報、1500万人が使える mixi OpenID の技術面を解説するでござるの巻 - Yet Another Hackadelic

こうして今振り返ると、mixi の　OpenID 対応はソーシャル化に向けたひそかな一歩だったんだよ！

OpenID の OP Identifier を使ってユーザーを誘導しているサービスほか

-リグレト

-イベント開催支援ツール アテンド : ATND

-タグ「OpenID」を含む新着エントリー - はてなブックマーク

スパイスラボ神部です。

「OpenPNE 3」は、OpenSocial に対応し、誰もが OpenSocial Container となることができる可能性を秘めているオープンソースの SNS ソフトウェアです。しかし、OpenStack に準拠するには一歩一歩技術的手順を踏む必要があり、まだ完全にそういったレベルに達しているわけではありません。それでも一歩一歩前進を続けているようですので、少し現状のまとめをしてみたいと思います。

-見通しが好きだ！ - Favorites!

OpenPNE 3 の歩んでいる道のりのまとめ

当初 OpenPNE 3 が OpenSocial に対応したさい、よういちろうさんから OpenPNE3がOpenSocial対応になりました - OpenSocial-Japan | Google グループ という記事で問題点が指摘されていました）。

この問題は、3.0.1 で修正されたようです。

-OpenPNE3.0.1をリリースしました｜OpenPNE

OpenSocial Restful API への完全対応は近日中？

しかし、OpenSocial Restful API の利用については、まだ問題点が残っていたもよう。名付けるならば「トークンハイジャック（？）」でもいう問題でしょうか。

※これについては記事の最後でもう一度触れます。

-opOpenSocialPlugin 0.8.1beta リリース｜OpenPNE

によると、これが利用できるようになって OpenSocial Container としてのスペックをより満たすためには、OpenPNE3 CoreがOAuthに対応したあとになるようです。これはすなわち、OAuth や OpenSocial Restful API に関連する部分を司ることになる opWebAPIPlugin のバージョンが十分な機能をもった段階に達することが必要になるのではないでしょうか。

しかし少しずつ開発は前進しており、最新版は opWebAPIPlugin 0.3.4 になるようです。

-opWebAPIPlugin 0.3.4 をリリースしました｜OpenPNE

今後の見通し（推測）

外部から見た場合の今後の流れをまとめてみます。手嶋屋さんに取材したわけではないのであくまで推測になりますが、

１．opWebAPIPlugin の機能が十分な状態になってリリースされる

２．OAuth ready な状態の opWebAPIPlugin が OpenPNE 3 の最新版に組み込まれる

３．最新の　opOpenSocialPlugin、および opWebAPIPlugin が同梱された OpenPNE 3 がリリースされる

→ OpenPNE 3 を適切にセットアップすれば誰でも OpenSocial Container になれる時代が到来！

ということになるかと思います。こうなると、So-net SNS のような SNS 立ち上げサービスにも広がって行くことになり、OpenSocial アプリケーション開発者にとってはより活躍の場が広がるかもしれません。

特に So-net SNS は短期間のみ利用される SNS があったりするかもしれませんので、その需要を満たす OpenSocial アプリケーションを有料で開発したりとか、そういった柔軟なアプリケーション開発もあるかしれません。

モバイル版？

（そういえば、Restful API が整備されるとなると、OpenSocial アプリのモバイル版への対応も広がりますよね・・・ボソッ）

参考その他

-OAuthで気持ちのいいアクセス制御を

手嶋屋さんでの社内情報共有の時の資料だそうです。しかし、最後の方に出てくる「トークンハイジャック（？）」のようなものに対する対応はまだ OAuth プロトコル側には反映されていないようです。対策アイディア募集中だとか。

-見積りや見通しの力を生かす指導 (新しい算数科授業研究・教材研究シリーズ)が好き！ - ILOVEIT(β)

スパイスラボ神部です。

OpenSocial をやってるとちょこちょこ顔を出す OpenID と Auth。これについてちゃんと理解するためのいろいろを調べてみたいと思います。

-シングル・サインオンが好きだ！ - Favorites!

OpenID まわりについて

-OpenID や OAuth の役割と、既存のシングル・サインオンとの違い：Goodpic

これは目から鱗。シングルサインオンとシステムの類似性があるわけだから、そこから理解するのがいいのかもね。

となると、要は OpenID は「本人確認を取り除いた低コストな認証システム、ということなのかなあ。

とりあえずは、Web に特化されたシングルサインオン、と認識しておこう。

その他の参考エントリ：

-OpenIDの使いどころ - Yet Another Hackadelic

-たけまる / OpenID に向いている認証と向いてない認証

-ID管理と OpenID について - まちゅダイアリー(2008-01-11)

-Young risk taker.: OpenID動向 - Trusted Data Exchangeがユーザ属性ポータビリティの切り札になるか？

ここにあるのはまだ難しすぎる。だけど、ユーザのアイデンティティを =foobar と表記しているのが、数年後には当たり前になるのかな（どうやら OpenID 的表記！？）

-認証APIとOpenIDの違いを説明して、OpenID導入を説得する - tzmtkのブログ

OAuth について

-APIアクセス権を委譲するプロトコル、OAuthを知る － ＠IT

この記事によると：

困りごと１：サービス間でマッシュアップするとユーザアイデンティティがないがしろになる

困りごと２：サイトごとのアカウント発行が面倒

解決すること１：ユーザーにとってOAuthを利用するメリットはIDとパスワードをOAuthコンシューマに預けなくてもよいこと（サービス提供者による不正アクセス対策になる）

解決すること２：OAuthコンシューマに与える権限を事前に確認できる（どうやらこれは OpenID ではできない？）

※OAuthは「オース」と読むらしい。

その他の関連エントリ：

-OAuthで気持ちのいいアクセス制御を

OAuth 登場以前、Twitter の投稿 API を叩くための認証は Basic 認証しかありませんでした

例えば Twitter でいえば、「こっからここまでやっていいよ」と言うのを、Twitter にログインした状態において手動で設定画面を開かせることなく許可することができる、ってことなのかな。そこのプロセスが自動なのなら確かにすばらしいですね。

うん、なんかわかってきたぞ。そうなると、認可している権限一覧も確認したくなりますね。

（例えば、自分の Twitter アカウントにアクセスしてきている外部サービスの一覧とか）

-ゼロから学ぶOAuth：第1回　OAuthとは？―OAuthの概念とOAuthでできること｜gihyo.jp … 技術評論社

よかった、書いてあることと理解していることが大分近いぞ。

OpenID・OAuth 双方について述べているもの

-OpenID + OAuth：おいしい物同志のおいしい組み合わせ

-Think and Win » Blog Archive » OpenID、OAuthを個人が複数所有して、必要なAuthorizationを独自に構築する

-入門 LDAP／OpenLDAP―ディレクトリサービス導入・運用ガイドが好き！ - ILOVEIT(β)

まとめ

自分なりに解釈した、OpenID と OAuth のもっとも簡単で最小限のまとめ。

間違っているかもしれませんが、こんなところでどうでしょうか。

OpenID とは？

-Web に特化されたシングルサインオンのしくみ

OAuth とは？

-（使っているサービスに対する別サービスからの）APIアクセス権を効率よく認可させられる仕組み

理解に自信があるわけではないので、よりよい解釈があればアドバイスお待ちしております。

スパイスラボ神部です。

先週のニュースですが、先週「EDGE co.Lab」が始動したというニュースが掲載されていました。

これは開発者の悩みを解決するというとりくみということで、その悩みとして次のようなものが挙げられています。

「せっかく面白いものを作ったのに、注目が集まらない」

「サーバが貧弱でいつもサイトが重い」

「一般層への宣伝ができない」

「サイト１つでは稼げない」

なんだかこのリストを見ていると、私が以前から勝手に提唱している ガラパゴスネットワーク の構成要素とも共通する点を感じます。

拙案ガラパゴスネットワーク（仮）の再まとめと共通点

こちらの構成要素、書いたままのものでは長いので短くまとめ治すとこのような感じでしょうか。

１．Web サービス・アプリを最小単位としてネットワークが構成される

２．アクセスがサービス間を循環するようにリコメンデーションシステムが機能する

３．一般層も利用しやすい検索・誘導のしくみを備えている。

４．ネットワークに参加することで、通常よりトラフィックを増やしたり減らしたり出来る（※二酸化炭素の排出権のようにトラフィックを売買できるとよいはず）

５．データベースがよい状態で保たれるようシステムの維持につとめる。

６．参加・脱退は自由（Google のようにクローラによる強制参加ではない）

ついでに、この続きのエントリのまとめを要約すると、

１．Web サービスのオープンネットワークをつくりたい

２．Web サービス（携帯サイト含む）をつくれば作るほど儲けにつながるしくみをつくりたい

３．一般層に訴えたい

みたいな感じです。まとめなおせばまとめ治すほど、「EDGE co.Lab」にも通じるところがあうような気がします。これはぜひ参加してみたい！

ただ大きく違うのは、サービス自体が livedoor というもののブランド構築に貢献するであろうこと、またホスティングの部分も livedoor に組み込まれていくとのこと。このあたりは、「Google App Engine」や、「Amazon EC2＆Amazon S3」のようなクラウドなサービスに倣ったものなのかも知れません。

では、参加出来そうなアプリケーションは？

どうやら EDGE.co.Lab に参加するには、OpenID に対応しているほうがやりやすいようです。このあたりは、OpenID ファウンデーション・ジャパンに参加している流れもあるのでしょう。

ラボにもOpenID 対応のサービス、いくつかあります。

１．Ckr!（ちぇけら！）～ マイミクとペア占い☆

mixi OpenID に用途を絞ってしまいましたが、もっと一般化すれば ID 同士の占い、なんてことができるかもしれません。ただ、マイミクという要素があるので移植は結構難しいかも。

２．Clone me ! ～ お題のサービスをクローンしよう！

こちらははてなの OpenID にのみ対応。これははてなに開発者が多そうだから、ということではてな専用にしてみましたが、livedoor もそういう属性あってもいいでしょうから、これは移植可能かな。

３．みんなの相性診断

これは実は非公開サービスなのですが、男女複数をエントリーすると相性診断がまとめて出来る、というものです。認証対応もしていないですが、再利用はしてみたい。

ということで・・・内容が偏っていてあまり色合いはよくないのですが、まずはそのコンセプトに触れるためにコンタクトをとるところからはじめて見ようと思います。

最期に関連リンク

EDGE co.Lab 始まったな！Livedoor++過ぎる件 - Yet Another Hackadelic

livedoor ニュース - 来たれ腕に自信のエンジニア！一般開発者と共に作るプロジェクト「EDGE co.Lab」がスタート

もう少しニュースや関連エントリを探してみようと思います。

スパイスラボ神部です。

ちょっと前からこちらのエントリーライブ更新：CakePHP で mixi OpenID に対応したサイトを作成する (ラボブログ)で作っていたサービスが遂に完成しました。

Ckr!（ちぇけら！）～ マイミクとペア占い☆

mixi OpenID はいろいろ使ってもらいにくさもありますが、今回は簡単に使ってもらえるように、マイミクのプロフィールの ＵＲＬ、例えば http://mixi.jp/show_friend.pl?id=○○○○○ という URL を入れるだけで、あとは自動的に進むようにしてみました。

ログインすれば、自分の占いはもちろん、にプロフィールＵＲＬを指定したマイミクの占いも見ることが出来ます。自分の占いにはコメントが付けられるので、相手には自分のプロフィール URL を案内すれば、自分のコメントを読んだり相手にもコメントを読んでもらったり出来ます。あっ、GET で自分のプロフィール ID 入力済みのページに案内するようにもしたほうがよさそうですね。

今回ページ遷移を続けながら認証を続けるにあたり、mixi OpenID だけでは難しい部分は、OpenID component for CakePHP や PHP OpenID Library をを導入しながら CakePHP のモデルと組み合わせたりして対処しています。あと、OpenID アプリにあるまじきことに、mixi OpenID 専用アプリです（笑）これはちょっとひどいかもしれませんが、mixi ユーザ専用ウェブアプリと見てもらうことも出来ると思います。

とりあえずは mixi OpenID の実験作ですので、まずはいろいろ遊んでもらえたらと思います。mixi OpenID に対応した他のサイトと併せて使いどころなど比較してもらえればと思います。また今回は制作が遅れ、Mashup Award 4 に間に合わなかったのがちょっと残念です。

（追記）

-マイミクとペア占い - らくがきちょう・・・紹介されました！公認タレント・アーティストへのマイミク申請は、自動的にOK出るみたいなので心配ご不要です。

ラボ神部です。

なんだか昨日は知らないうちに GINZA TECH LOUNGE feat. OpenID というとても興味惹かれるイベントがあったらしいのですが、参加出来ず残念です。

こちらにあるレポート やListPod での OpenID 利用について LT してきたを読んで会場の模様を思い浮かべながらいろいろ考えていたのですが、その中で続報的に上がっていた次の記事

-増えすぎた OpenID をどう管理するか - まちゅダイアリー (2008-09-11)

に書かれていることがちょっと気になりました。

希望

* 信頼できるサイトが「OpenIDおまとめサービス」とかで提供してほしい。URLも短く

これはしかにそうだと思います。OpenID 対応アプリケーションを作ってみると感じるのですが、ユーザからはいろいろなサービスがひとつの ID で利用出来て便利なのですが、アプリケーション側からは同じ人でも別の OpenID プロバイダ経由で認証に来た場合は別のユーザ扱いになっちゃうんですよね。

たとえばはてなみたいに一人一ID（サブアカウントを除く）のを基本にしているサービスがありますが、そういうポリシーのもとに一IDあたりの重みを強く持たせたいときは OpenID は少し採用しにくくなってくるのです。

OpenID の仕組みはお店とポイントカードに仕組みに似ていて、お客さんが例えばDVDレンタル店舗 T 社のポイントカードを持っていたとしたら、まず T 社のお店に行けば特典サービスが得られるとします。次に T 社のポイントカードがコンビニ F 社のポイントカードシステムと提携し、T 社のポイントカードを持って行くと F 社でも特典サービスが得られるようになったとします。

このとき、ユーザは T 社のポイントカードを使っても F 社のポイントカードを使っても特典サービスが得られますが、お店側からすればそれは別々のお客さんに見えるわけです。カードを持っている人は同一人物なのに、持っているカードによって ID が変わってしまい、見ようによっては同一人物を複数のお客さんとして取り扱わなければ鳴りません。これではお店側も利用者の実情がつかみにくくなってしまい、実際に有効な利用者母数がわかりにくくなってしまうだけではなく、ユーザから預かるデータの管理もより複雑になってしまいます（もちろん現状ではユーザデータは ID ごとに別々に管理するよ、という軽さを持たざるを得ないわけですが）。

当面の対処方法としては、例えば手元の Open ID のアプリケーション側で複数の Open ID の「おまとめサービス」を提供することです。こうすると、いち利用者が複数の ID でログインしてくるという複雑なことは多少解決に向けられるような気がします。しかし同時に元エントリでも指摘されているような、アプリケーション運営者側による利用者の ID 統合情報掌握につながり、これはユーザにとって嬉しいことではありません。だからこそ、元エントリで述べられているような「OpenID おまとめサービス」が必要になってくるのではないかと思います。

この問題は OpenID が普及するにつれ、将来必ずぶち当たる壁なのではないでしょうか。本当はこういうのは保険証番号とか住基ネットIDとかがインフラになってくれればいいのかもしれませんが、国のIT施策に期待するのも難しいところなので、どこか意表をついたところがこういう認証サービスをはじめたら面白いかなーと思います。以前 IIJ4u とかをやっていた IIJ とかがやりはじめたら、ブランド面も含め結構面白いんじゃないでしょうか？