たけまる / openid

_ Identity Conference #01 [openid][idcon]

Identity Conference #01 に参加してきました．ホスト役の ZIGOROu さ
んありがとうございました．また，mizzy さんには PC を貸していただい
て助かりました．

詳しい内容は ZIGOROu さんがまとめてくれると思うので，雑駁な感想を
書き留めておきます．

(追記) まとめてくれました．
Identity Conference #01を開催しました - Yet Another Hackadelic

メインは YADIS/XRI, OAuth の解説と，OpenID/SAML の比較についての発
表でした．ぼやっと理解していたところに詳しい説明を聞けたので，知識
が深まったような気がします．個人的には，YADIS の使い方や，OAuth の
詳細な部分について確認できたのがよかったです．

複数のサービスでバラバラになっている ID を統一するという発表もあり，
最近似たような話を耳にしたこともあって興味深かったですね．

最後に，僕の発表スライドを置いときます．

OpenID and AtomPub
20080316-openid_atompub.pdf

《続きを読む》

_ 免責事項(DISCLAIMER) [openid]

# id:shinichitomita さんのマネです．

ええと、id:ZIGOROuさんの@ITの記事でこのブログが紹介されているのですが、

OpenID Authentication 2.0時代の幕開け − ＠IT

このブログの内容は、Atom : その他 = 7:3 くらいです、感覚的に。後者
のうちOpenID関連となるとさらに半分くらい。どちらかというとニッチな
ところを書く事が多いので、本流は他のサイトをどうぞ。なにせv2.0になっ
てからはまともに仕様を読んでいない＜おぃ

一応、あまり役に立たないカテゴリ検索へのリンク：

たけまる / openid

_ OpenID は「ブラウザにIDをセットする」イメージ? [openid]

アイデンティティ飲み会では，OpenID のユーザビリティが話題になりまし
た．「いまのままでは一般ユーザに受け入れられない」という意見をたく
さん耳にしました．その点について，少し考えてみました．

# 結果的には Sxipperの解説みたいになってるかも．．

《続きを読む》

_ 第1回アイデンティティ飲み会 (と信じられないようなミス) [openid]

「にわかなやつほど語りたがる」の法則よろしく，最近 OpenID について
書き散らしていた流れで，豪華メンバーのアイデンティティ飲み会に紛れ
てきました．

「アイデンティティ飲み会」 は来週金曜 - tkudo's weblog about identity management

内容うんぬんより先に，信じられないようなミスをしてしまったのでここ
で懺悔します．

終電が早かったので先に帰ったのですが，
支払いを忘れてしまいました ＞＜

ホントに申し訳ありません．特に幹事の工藤様，早急に支払いますので連
絡くださいませ．

... 内容については書く元気がなくなったので，ZIGOROu さんや machu さ
んのブログを見てください．まぁ，支払いを忘れるくらい盛り上がったっ
てことで．．

第1回アイデンティティ飲み会 - Yet Another Hackadelic
第1回アイデンティティ飲み会 (エンタープライズとWebの素敵な出会い) - まちゅダイアリー (2008-01-18)

_ OpenID に向いている認証と向いてない認証 [openid]

ZIGOROu さんのとこで，OpenID の使い道について面白い議論がされてい
ました．

Re:本当は怖いOpenIDによる認証 - Yet Another Hackadelic

まず大前提として個人情報等、センシティブなデータを取り扱うサイトは
必ず会員登録は行うべきで、認証、認可はRPのIdentifierに対して与えら
れるべきです。

RP (Consumer) のユーザID で認証するのであれば，OpenID を無理に使わ
なくても良さそうな気がします．この後，ZIGOROu さんのエントリではい
くつかの解決策が提案されているのですが，一歩戻って OpenID の使いど
ころについて考えてみることにしました．

# これから書くことって当たり前のことな気がするけど，そういうことで
# も書いて確認できるのがブログのいいとこでもあるので，ちょっと書い
# てみます．

認証を行うと言ったとき，その目的は二つに分けられると思ってます．

1. ユーザと現実の人間との照合 (認証側にリスクあり)
2. ユーザのトラッキング (認証側にリスクなし)

《続きを読む》

_ Re：OpenID をどう扱うかは, それを扱うサイトの考え次第 [openid]

# このエントリは工藤さんへの返答で，新しい話題はありません．

OpenID をどう扱うかは, それを扱うサイトの考え次第 - tkudo's weblog about identity management

ひとつ前のエントリに関して, ネタ元のたけまるさんからたくさんのツッ
コミをいただいた.

込み入った話を淡々と書いたら，結果的にキツイ文章になってしまいすみ
ませんでした ＞＜

丁寧に説明していただいたので，OpenID.sun.com で何が起こっていたかよ
くわかりました (^^;

また，あとで user-experience ML に投げてみます．

いずれにせよ OpenID うんぬんというよりは (もっと言えば, OpenID に
限らず SAML とかであっても), 各サイトがアイデンティティをどう扱う
かというポリシー決めがまずは重要かと.

OpenID はプロトコルとしては一応の完成を見たわけですが，こういった技
術を僕らが使いこなしていくには時間がかかるかもしれないですね．

_ OpenID は「ログアウトしない」のかなぁ [openid]

工藤さん，返答エントリありがとうございました．
「ユーザが OpenID を使って RP にログイン → RP だけからログアウト → OpenID を使って RP に再ログイン」 のときに, 同一の IdP にある複数の OpenID を使いわけるというユースケース - tkudo's weblog about identity management

このエントリを読んで，調べて考えてみたんですが，極端に言えば
「OpenID はログアウトしない (ブラウザ終了時を除く)」と考えるべきな
のだろうと思うようになりました．そのような用途に使っていくのだろう
と．

以下，OpenID のログアウト処理がいい加減である理由を考えています．
また，工藤さんから提案いただいた解決策についても検討します．

# 内容が込み入っているため，論文調になっていて読みにくいかもしれません

《続きを読む》

_ 複数の OpenID を切り替えて使うときの振る舞い [openid]

細かいことですが，ひとつの IdP が提供する複数の OpenID を切り替えて
使うような状況では，IdP の振る舞いが定められてないかもしれません
(仕様バグ?)．

たとえば，仕事とプライベートで異なる OpenID を使い分けるような状況
です．いくつかの IdP でテストしてみたところ，エラーや不自然な振る
舞いが見られました．

原因を分析して，解決方法を考えてみました．

# まだ Open Problem なら，open-id ML に投げてみようかなぁ．

(2008-01-05追記) machu さんから，シングルログアウトとの関係について
コメントいただきました．ありがとうございます．

シングルログアウトがないよって話かな？

確かに，シングルログアウト (Consumer と IdP で同期を取ってログアウ
トすること) との関係から説明した方がいいですね．違いがわかりにくかっ
たので，補足します．

このエントリで書いている問題は，シングルログアウトが完全に実現され
れば自動的に解決します．しかし，シングルログアウトを実現するのは
現在の仕様では難しいです．というのは，ユーザがConsumerからログアウ
トしたときに，そのことをIdPに通知するプロトコルが存在しないためで
す (参考↓)．
OpenID におけるセッション管理 - tkudo's weblog about identity management

そこで今回は，「シングルログアウト」ではなく，「再ログインの同期」
のみに状況を絞って，簡単に実現する方法を提案しています．

今回取り上げている問題では，ユーザはConsumerからログアウトした後に，
異なるユーザ名でIdPに再アクセスします．この場合，IdPは，ユーザが
Consumerからログアウトしたことを知ることができます (たとえば，
Cookie と openid.identitiy= の不一致でわかる)．であれば，IdPの実装
を少し工夫するだけで，Consumer側のログアウトをIdP側にも反映させるこ
とができます．
(追記ここまで)

《続きを読む》

_ OpenID v1.1 の IdP と Consumer を Catalyst で動かした [openid][catalyst]

IdP (Identity Provider) と Consumer を Catalyst で動かしてみました．

といっても，IdP はNet::OpenID::Server を Catalyst に組み込むだけだ
し，Consumer にいたっては Catalyst::Plugin::Authentication::Credential::OpenID
というプラグインがあるから簡単だろうと思っていました．ところが，そ
うでもなかったので，メモとソースを残しておきます．

ダウンロードすれば，実際に動く IdP と Consumer が手に入ります．手っ
取り早く手元で OpenID を動かしてみたい人はダウンロードしてみてくだ
さい．なお，Catalyst v5.7011, Catalyst::Plugin::Authentication v0.10004
でテストしました．

OpenID v2.0 仕様がリリースされているのに，v1.1 というのが弱いです
が，Net::OpenID の対応待ちと言うことで．

余談ですが，Catalyst::Plugin::Authentication::Credential::OpenID は
CodeRepos にあげてもいいかもと思いました．id:ikasam_a みたいにが熱
心に見てる人もいるみたいだし．

《続きを読む》

_ 僕が OpenSocial や OpenID, OAuth を無視できない理由 [opensocial][openid][oauth]

machu さんを皮切りに，shinichitomita さんや kazuhooku さんがとても
面白い議論を繰り広げてます．

クロスドメインのセキュリティ問題を OAuth で解決する - まちゅダイアリー (2007-12-07)
Re: クロスドメインのセキュリティ問題を OAuth で解決する - id:kazuhookuのメモ置き場
クロスドメイン通信とアクセスコントロール - snippets from shinichitomita’s journal

ちょっと切り口を変えて，「この議論がどうして重要なのか，どうして革
新的なのか」ということを考えてみます．うまく説明できるかわかんない
けど，挑戦してみようかなと．

イノベーションってのは，それまでうまく使えなかったリソースを活用で
きるようになったときに起こる．蒸気であれ，電気であれ，資本であれ．

先に結論を言うと，OpenSocial や OpenID, OAuth (クロスドメイン関連の
技術) は，今はうまく使えていないリソースを活用して，イノベーション
を起こす可能性を持っているってこと．

# 似たようなこと書いてるページがありましたら教えてくださいませ m(_ _)m

《続きを読む》

_ OAuth - リソースへのアクセスを代行するプロトコル [oauth][openid]

[2007-09-23-1] で AtomPub の認証について書いたからというわけではな
いのですが，OAuth というプロトコルの仕様を斜め読みしたのでメモして
おきます．間違いがあったら教えていただけると嬉しいです m(_ _)m

(追記) OAuth の「背景」みたいのについては，miyagawa さんからもらっ
たコメントと，まちゅさんのエントリが参考になります．
- miyagawa さん

oAuthはFlickr,GoogleAuthSub,Y!BBAuth,AOL openAuth,TypeKeyなんかの
統合プロトコルという位置づけ。例では401->WWW-Authenitcateが
handshake になってるけど実際はもっと他の方法で運用されるんじゃない
かなぁ

- まちゅさん
WebAPI のアクセス制御に使える OAuth という仕様 - まちゅダイアリー (2007-09-25)

さて，OAuth は，第三者に対して，認証を要求するリソースへのアクセス
を一時的に許可するためのプロトコルです．

たとえば，写真印刷サービスがあるとします．そして，あなたは flickr
に保存してある非公開写真の印刷を依頼しようとしています．このとき，
写真を "公開" 状態にすることなく，また flickr へのログイン情報を教
えることもなく，印刷を依頼することができます．

OpenID が "authentication (認証) の分散" だとすると，OAuth は
authorization (許可) になります．

(参考) 仕様から学ぶOpenIDのキホン − ＠IT

処理フローは OpenID とほぼ同じようです．OpenID の拡張にしてもよさ
そうに思いましたが，OpenID 以外の認証方法と組み合わせるために独立
したプロトコルにしたのでしょう．

いくつか気になった点がありました．

現在の仕様では，アクセスを許可するリソースを限定できないように思い
ました．つまり，写真印刷サービスは，印刷する写真だけでなくすべての
写真にアクセスできてしまいそうです．最終的には修正されると思います
が (詳しくは後述)．

さらに，HTTP メソッドを限定できるとよさそうです．GET は許可するけ
ど，PUT, DELETE は不許可という状況はありそうなので．

簡単なメモを残しておきますので，よかったら参考にしてください．詳し
い説明は ZIGOROu さんあたりがしてくれそうな気がするので，待つこと
にしましょう ;-)

《続きを読む》