Re:複数のキャラクターを、場の雰囲気で使い分けるIdentityとかどうだろう
元ネタ: 複数のキャラクターを、場の雰囲気で使い分けるIdentityとかどうだろう - Goodpic
フランクに考えるとIdentityも面白いですねｗ
ちなみに以下、goodpicさんが使ってる単語とOpenID Authentication 2.0で変わった語彙が分からない人の為に変換表を書いておきます。
| 1.1時代の単語 | 2.0の単語 | ||||
| IdP (Identity Provider) | OP (OpenID Provider) | ||||
| Consumer | RP (Relying Party) |
以下、返信とか感想とかー。
日本は、匿名（Anonymous）幻想みたいなものがあって、実は公開されていても、それがおおっぴらになってなければOK的なノリがある。『なんとなくクローズド』な雰囲気が好き。逆に、Amazonの欲しいものリストの件みたいに、実は公開されてました！っていうのは大騒ぎになる。あるあるー。良く分かります。 欧米に比べて日本の観念、文化ってのはIdentityに関しては全然違いますね。
実は『ニックネーム』とかいう概念よりも、『会員番号』でインクリメンタルな数字の方が、一般の人は理解しやすい？ 学籍番号とか、パスポート番号とか、背番号的にナンバリングされている、というのは普通の人にも理解されやすいし、意外と覚えている。これは頻繁に使う数字だからこそ覚えられるんでしょうね。 携帯番号は空で言えるけどメールアドレスは無理みたいな人は多そう。
そこで、なんとなく漠然としたアイデア的なモノを考えてみる。例えば、一つのURLを自分のアイデンティティーとして使うけれども、それが単一のIdpではなく、複数のIdpをインテリジェントに切り替えてくれるProxyのようなものだったら？OpenIDのdelegateを動的に判断して決められる仕組みを作れば可能は可能ですね。 簡単に言えば「RPに応じてopenid2.provider, openid2.local_idを切り替える」って事ですね。 これで単一のIDで、実態であるOP*1にひもづくIdentifierを切り替えられます。 ただ、自分のキャラクターのその場に応じた使い分けは果たしてOPの切り替えによって表現される物なのかどうかは違うと思いますがｗ RPに対して公開されるのは全うに実装すればClaimed Identifierなので、どこのRPに対して認証結果を返そうとも、違いは無いんですよね。 どちらかと言えば属性情報の何を公開するか、によると思います。 仕事絡みの場所でIdentifierにひもづく名前をニックネームとはいかないシーンだってありますからねぇ。
例えば、Identity確認を求めてきたConsumerのサービスの雰囲気に合わせて、自分が持っているアイデンティティーのなかから似たジャンルのサービスのアカウントを返すやべー俄然面白くなってきたｗｗｗｗ とってもソーシャル的ですよね、そういうのって。 これって端的に言ってしまえばtwitter絡みのRPを作るとして、twitterアカウントでログインするってのをOpenIDのような枠組み一つ被せて〜ってのを色んなサービスでも同じような感じで出来るようにしたいって事ですよね。 なるほど、新しい発想だし面白いですね。 RP(Consumer)の雰囲気を機械的に判断するのが現状の枠組みだと非常に難しいですよねぇ。 きっとRP側がEnd UserからClaimed Identifierを受け取ってからdiscoveryしてから、associateする時点で俺のサービスはこんなんだから、このサービスに近いであろうOPにdelegateしてくれと。 そういう枠組みあったら面白そうですねー。 OPが解釈するかどうかは別ですけど、適当なパラメタを渡してassociateなりcheckid_*とかってOpenIDのモードを実行するのは可能なので、その辺りでやり取りすることになるんでしょうね。 Action StreamってのはOpenSocialで言う所のactivityに近いんですかね。
このIdp Proxy的なモノの場所を、XRIで指し示すとか？XRIで指し示す場所が異なるのはちとコンセプトと違う気がします。 それよりはYadis(XRDS)文書でやる方が綺麗なのかもしれませんね。 RPごとに表示するXRDS文書の内容が違えばスマートにバックエンドのOP(IdP)が切り替えられるような気がします。 そういえばdelegateにもXRDS文書って使えるのかなー、試した事ないや。
