How to authorize the identity providers in OpenID
ogawa
小川です。
OpenIDは誰でもidentity providerになれますが、そのidentity providerは誰がどうやってauthorizeす
るのでしょうか。その方法がないとすると、OpenIDアプリは「すべてのidentity providerを信じる」か「予め信頼できるいくつかの
identity providerだけを信じる」ということになると思います。
仮に前者だとすると、それはコメントスパマーがコメントフォームのURL欄にスパムURLを記入することと違いがないわけです。結局OpenIDアプリ
の側でURLごとにアクセスコントロールする必要があって、アプリ制作者側の支持はあまり得られないように思います。後者だとすると、いかにしてそのプ
ロバイダが信頼に足ることを知り得るのかという問題があります。私が関心があるのは特に後者です。
重田さんからもご紹介のあったOpenID.ne.jpのようなプロバイダが複数あることから伺い知れるのは、「ユーザを集めることがそのプロバイダの
信頼性を向上せしめる」という考え方が存在するということです。確かにユーザの多いプロバイダをOpenIDアプリが信用しない限り、かなり多くのユー
ザが認証できないことになるわけですから合理性はあります。
しかし、ユーザが多いということはevilなユーザも多いということです。もしidentity providerがevilなユーザをブロックしなけ
ればならないとしたらそこには明示的なコストが発生します。つまり、既存のidentity providerはもともとそういうコストを払うつもりが
ないか、ユーザからコストに見合う収益を得るつもりがあるかどちらかなのでしょう。
前者ならばやはりOpenIDアプリの側でOpenID URLごとにアクセスコントロールする必要があります。繰り返しになりますがアプリ制作者側の
支持はあまり得られないように思います。後者ならば長期的に見て資金力がありブランディングに成功したプレイヤーにidentity provider
が集約され得るということです。それはプロトコルの策定過程がオープンだったというだけでMicrosoft PassportやGoogle
AuthSub APIと変わりありません。
多分、これはOpenIDの初期に議論が尽くされていることなのかもしれないと思っていますが、皆様はどのようにお考えでしょうか？
Tatsuhiko Miyagawa
が含まれていないのは当然かとおもいます。ただ、その実装が URL であることから、reputation/trust system を
OpenID で claim された URL をベースに構築することも難しくはないでしょう (Google で "OpenID
reputation" あたりを検索)。
アプリ製作者側の支持、というのはスパム対策などの話なのかとおもいますが、そういう意味では OpenID
をアプリに組み込むことによるメリットは、1) アプリ製作者側で User/Password を管理する必要がない 2)
ログインするユーザは新しくアカウントをつくる必要がない、という2点に集約されるのであって、スパム対策などにいますぐ有効になるシステムではないと思います。
ただし繰り返しになりますが、URLをベースにした
reputationサービスをどこかが提供して、サイト製作者は任意にそれを利用する、という展開はありかもしれません。それがプロトコルとして
OpenID の extension になるのかどうかは現時点でわかりません（追ってないという意味で）けど、たとえば Yahoo! が
ID 認証をOpenID で提供し、Yahoo! オークションでの評価ポイントをIDベースで API として提供できるようになれば、
「私は blog.bulknews.net で Yahoo! では id:bulknews です。私が信頼できるかどうかはオークション履歴をみてください」
ということを openid.delegate で Yahoo! OpenID Provider
で認証し、アプリケーション側が問い合わせて自動化する、みたいなこともできるのかなあと。
--
Tatsuhiko Miyagawa
Tatsuhiko Miyagawa
On 2/17/07, ogawa <hirotak...@gmail.com> wrote:
> しかし、ユーザが多いということはevilなユーザも多いということです。もしidentity providerがevilなユーザをブロックしなけ
> ればならないとしたらそこには明示的なコストが発生します。つまり、既存のidentity providerはもともとそういうコストを払うつもりが
> ないか、ユーザからコストに見合う収益を得るつもりがあるかどちらかなのでしょう。
これはその通りで、先ほど Yahoo! の例をはからずも出してしまいましたが、openid.ne.jp のような OpenID
ベースのURLをつくれますというサイトが雨後のたけのこのように出てくるのは黎明期だけであって、最終的にはメジャープレイヤーが ID
provider として残る（現実的に）んだとおもいます。OpenID の仕様策定の中心メンバーが Verisign
であったり、Microsoft, AOL がのってきたところからもそれは明らかにそういう流れかと。
OpenIDプロバイダはIDに対するある程度の管理コストを支払う必要がありますが、それは既存の AOL, MSN
のようなサービサーにとってはすでに既存のコストであると言ってもいいかもしれません。
> 後者ならば長期的に見て資金力がありブランディングに成功したプレイヤーにidentity provider
> が集約され得るということです。それはプロトコルの策定過程がオープンだったというだけでMicrosoft PassportやGoogle
> AuthSub APIと変わりありません。
URLベースで ID を claim
できること、そして仕様策定がオープンでありかつプロプライエタリでないことから1社に依存しないモデル（Google が AuthSub API
の提供をやめたらそれに依存しているアプリは破綻しますが、OpenID
はそうではない）という点において、「～と変わりありません」ということはないかと。
ただし、IDを identify, authenticate するという点において、OpenID
それ自体が既存のIDプロトコルを超えるものでないことはたしかです。みなが同じプロトコルを使うことによって、その上のレイヤを組み立てやすくなるというメリットはあるとおもいますが。
--
Tatsuhiko Miyagawa
Hirotaka Ogawa
オレオレIdentity Providerがいくらでも作れるのにOpenIDが本当にauthenticationになっているのかということなんですけどね。任意のURLごとにIdentity
Providerがあったとすると、結局OpenID
URLとはただのURLに過ぎません。誰も何もtrustしない記号の列です。そうならないためにはProviderがtrustされなくてはなりませんよということです。
reputationシステムについても、つまりそれはあるIdentity
Providerの管理するあるIDに複数のURLが紐付けされて…なんか面白そうではあるのですが、結局その紐付け情報を乱造できるプロバイダが排除されなくてはなりません。そのためにはProviderがuntrustされなくてはなりませんよということです。
じゃあProviderのreputationをコミュニティで管理すればってことになりますが、それは単に既存の枠組みでURLに対するreputationを管理しているのと同じです。うまく行く部分もそうでない部分もあるでしょうね。
--
Hirotaka Ogawa makes no sense.
http://as-is.net/hacks/
http://as-is.net/blog/ (Japanese)
Hirotaka Ogawa
> > が集約され得るということです。それはプロトコルの策定過程がオープンだったというだけでMicrosoft PassportやGoogle
> > AuthSub APIと変わりありません。
>
> URLベースで ID を claim
> できること、そして仕様策定がオープンでありかつプロプライエタリでないことから1社に依存しないモデル（Google が AuthSub API
> の提供をやめたらそれに依存しているアプリは破綻しますが、OpenID
> はそうではない）という点において、「～と変わりありません」ということはないかと。
これはその通りです。言い過ぎました。
Tatsuhiko Miyagawa
オレオレIdentity Provider とはいえ、OpenID 認証を開始するには保持しているURL下にある HTML に
openid.server や openid.delegate
といったタグを書き込んで認証を開始する必要があるわけですから、そのURLを保持しているユーザ以外は認証を通過できない、という点は確認できるかとおもいます。URLはただの文字列ではありますが、そのURL(Identity)を保持しているユーザである(Authentication)、という点は確認できます。
ワイルドカードでどのURLも同一のIDで突破できるようなプロバイダや、ユーザ認証をまったくせず、openid.delegate
を向けるだけでだれでも認証情報をわたせるようなプロバイダも考えられますが、それはおっしゃるとおりプロバイダごとに Untrust
するような対応が現実的に必要になるんでしょう。
--
Tatsuhiko Miyagawa
Tatsuhiko Miyagawa
Free, anonymous, temporary, disposable OpenID
http://www.jkg.in/openid/
http://www.google.com/search?q=anonymous+openid
--
Tatsuhiko Miyagawa
Hirotaka Ogawa
>
> 実際にそういうOpenID provider がありますね。
>
> Free, anonymous, temporary, disposable OpenID
> http://www.jkg.in/openid/
>
> http://www.google.com/search?q=anonymous+openid
やっぱりそうなりますよね。
> On 2/17/07, Tatsuhiko Miyagawa <miya...@gmail.com> wrote:
> > すいません、読み違えてました。
> >
> > オレオレIdentity Provider とはいえ、OpenID 認証を開始するには保持しているURL下にある HTML に
> > openid.server や openid.delegate
> > といったタグを書き込んで認証を開始する必要があるわけですから、そのURLを保持しているユーザ以外は認証を通過できない、という点は確認できるかとおもいます。URLはただの文字列ではありますが、そのURL(Identity)を保持しているユーザである(Authentication)、という点は確認できます。
その通りですね。結局、真のPerson空間よりURL空間の方が圧倒的に広いので、disposal providerのようにPerson
Identityを乱発する装置があると、URLの個数だけ存在する「Identityのようなもの」がauthenticateされることになります。
ちょっとしつこいですが、別の言い方をすると、
「OpenIDは＜Provider, (Provider上の)Person Identity, URL, URL
ownership＞というタプルを認証するものである。もしProviderがreliableならこのタプルはPerson
Identityと同等に機能する。そうでなければ＜URL, URL ownership＞の部分のみ信頼できる。」
ということです。それで、アプリ側からすると本当はOpenIDの仕組みを通して得たかったご利益はPerson
Identityだったのではないか、そのためにはProviderグループをreliableに保つ必要があるのではないか…という具合で私の最初のポストに繋がるのでした。説明不足ですみません。
最もオープンな立場からは宮川さんが挙げられたようにreputationによる方法があり得ます。最も既存権益を重視する立場からはCertificate
Authorityの仕組みで絡めとるとか独占的なプロバイダが登場するとか、そういう方法になる予感がするといったところですか。