先日の『リアル』に関するtwitについて

web

こないだtwitter上で『リアル』の話になった時のことを備忘録。このあたりの話していた時のつぶやきがtwitter側の障害で歯抜けになってしまっているので思い出しながらまとめておく。


発端はログとかアーカイブ、などの話が周縁でされていた模様で(今現在、twitterのやり取りを半分思い出しながらエントリ書いている時点で実に皮肉的w)、その中で

  • 「一般人(ITリテラシ的な意味で)はログの担保が必要な人はそんなにいない」
  • 「(例えば一般人の代表のような)女子高生はケータイのメールがコミュニケーションのインターフェース(ケータイにおける電子メール文化というアーキテクチャの特性上、自動的にログがローカル端末に残る)なので、意外とログは自前でとれているよ」

というような話が見えてきたところで

  • 「流行の『リアル』に関して,統計とか知ってる訳ではないけどおそらく、大半の更新はメールでされているのでは？特に写真貼付でUPしたい時とか。なのでログ効果はさらに強まっているんじゃないかな。」

というような話を付け加えた。


その次に、ITmediaかCNETか、どっちだったか忘れたのだけど、この辺のはてブが付きまくっている『リアル』に関する記事を上げて、

  • 「リアル、がリアルタイムの略語だって言われてるけど、それがメールよりもリアルタイムではないのは何故なんだぜ？」

的なtwitをしたら

  • 「リアルは、リアルタイムのリアルじゃなくて、真実的な意味のリアルじゃないの？それが、 1 つのアカウントで複数リアルが作成できて、それぞれに真実がある、みたいな。」

という反論を貰う。なる。それはそーかもしれないなと思った。


とはいいながらもまぁWebのIT記事に『リアル』は『リアルタイム』の略だなんて書いているのでその論で話を進めた自分が

  • 「これまで即時性のある(あり過ぎる)メールというツールで彼女達は内容のないコミュニケーションを延々取って来たけど、それは即レスしないと友人ではないよ、ような同調圧力が自然発生するような文化であり、彼女達自身の首をしめるような高コストなコミュニケーションだった。現在流行っている『リアル』というツールはその言葉とは裏腹にメールよりもコストの低い存在であり、彼女達の無意識的な工夫の結果ではないか」

的な意味のコメントをして(140文字以内で)、

  • 「いや、リアルはメールの代替ではなく、授業中にまわすノートの切れ端なツールではないか(そこには単純に彼女達が年頃になった時に目の前に出現しているツールが変化しているだけでしょ)」

という話があったり、一方で

という声を頂いたりした。


・・・というのがだいたいの流れで、この時は『リアル』に夢中だったのだけど昨日あたりから急激にPokenに心奪われてしまい彼らと共同購入の約束して、届いたらcafeなんぞ借りて『ハイタッチ』しようぜ、なんて言ってるのだからWebの流れは早すぎるぜふぅ。。

[ポーケン / Poken] - Mix Set (4+1 free pieces)

[ポーケン / Poken] - Mix Set (4+1 free pieces)

Relying Party Best Practices　ななめよみ

Relying Party(OpenID認証利用サイト)のベストプラクティス、というタイトルのエントリが
http://wiki.openid.net/というところで公開されていました。


目次はこんな感じ。

1. Basic
　　　1. Site allows user to authenticate using an OpenID identifier
　　　2. Site allows creation of new user account by simply signing in using an OpenID identifier
　　　3. One Site Account per OpenID, unless the site enables manual account selection
　　　4. Site unambiguously indicates authenticated users
　　　5. Treat extensions as optional, not mandatory
　　　6. Clearly inform the user if their OpenID will be published
2. Would Be Nice
　　　1. OpenID-authenticated users have full access to all provided services
　　　2. Allow users to upgrade from a local username/password account to an OpenID account
　　　3. Allow users to change the OpenID Identifier associated with their account
3. Brilliant
　　　1. Provide Lost Identifier functionality to switch to a new identifier without access to the old one
　　　2. Provide the ability to merge accounts
　　　3. Many-to-one relationship between Identity URLs and user accounts
　　　4. Don't require users to choose locally-unique usernames
　　　5. Allow, but do not require, users to attach a handle or name to their identity
　　　6. Store primary OpenID in a cookie and check_immediate at next session

Relying Party Best Practices

正確な和訳はとてもできない頭なので、目次と説明文をあわせて雰囲気で読んでみた"感想"を書いていく。


本題に入る前にまずは用語の整理を。わかってる人はここ飛ばすよねJKなところ。

ユーザがRelying Partyサイト上でログインをするために、(一般的なIDとPasswordによるログインではなく)
自身の持つOpenIDを指定してOpenID Providerサイトに移動し、Providerサイト上で
(ここでは一般的にはID/Password認証が多い)認証を行う。ここでのログインが認められた場合に、その
認証OKな結果がRelying Partyサイトに通知され、自サイトでの認証行為相当が行われた、とみなすこと

  • Relying Party

OpenIDログインができるサイト。例えばiKnow(http://www.iknow.co.jp/)とか。

Relying Partyサイトで「○○でログインする」ボタンが付いているような
「OpenIDを利用した時に認証を行ってくれる」ID提供サイト。
例えばmixi,yahoo,google,livedoor とかのこと。


では雰囲気読み開始。

1. Basic

1. 基本

1. Site allows user to authenticate using an OpenID identifier

（当たり前）Relying PartyはOpenID認証ができるよ

2. Site allows creation of new user account by simply signing in using an OpenID identifier

Relying Partyサイト側のユーザアカウントを持っていないユーザが
OpenID認証結果を利用したら、アカウントの新規作成をするようにして。
その際、SREGやAXを利用した登録支援ができればいいね。

3. One Site Account per OpenID, unless the site enables manual account selection

基本的には一つのOpenIDは一つのRelying Party側のアカウントと紐付けるべきだぜ、
但しRelying Partyサイト上でアカウント管理機能があれば話は別だけどな。

4. Site unambiguously indicates authenticated users

Relying Partyサイトは、OpenID認証されたユーザID(※)を明確にサイト上で示すべき。
※(Verifiedされた)Claimed Identifierのことだろう

5. Treat extensions as optional, not mandatory

拡張は扱える(例えばSREGなど)べし
またProvider側がSREG対応していない場合にも(UI、UX的に)適切な処理をして。

6. Clearly inform the user if their OpenID will be published

Relying PartyサイトによってユーザのOpenIDが公表されるかどうかについては、
Relying Partyサイトは明確にユーザに知らせるべきでしょ


※正直、阿呆すぎてでこの意味がわからなかった。
RPがユーザの利用しているOpenID(Claimed Identifier)を
表に出すかどうかは基本的にRPの勝手だから、
そのことをユーザにわからせろよ、てこと？かな。

2. Would Be Nice

2.いい感じ

1. OpenID-authenticated users have full access to all provided services

OpenID認証を利用するユーザと、Relying PartyサイトでのUsername/Password認証を利用していた
ユーザの間で、提供できるサービスに差がないようにするのが望ましいなぁ

2. Allow users to upgrade from a local username/password account to an OpenID account

Relying Partyサイトで元々Username/Password認証を利用していたユーザを
OpenID認証でもログインできるようにする(アップグレードできる)のがいいよ

3. Allow users to change the OpenID Identifier associated with their account

Relying Partyサイト上のアカウントに紐づいているOpenIDをユーザが変更・管理できること


※2.は全体的に既存のWebサイトがOpenID対応する場合のプラクティスですね

3. Brilliant

3. ちょーちょーちょーいい感じ。

1. Provide Lost Identifier functionality to switch to a new identifier without access to the old one

(例えばユーザが利用していたOpenID Providerが無効になったなど)古いOpenIDと紐づいた状態の
Relying Party上のアカウントに対して新しいOpenIDにユーザが紐付けることができる機能を提供すること
※もしRelying PartyがユーザのEmailアドレスを知っているなら「パスワード忘れた場合は」機能と
似た機能を実装すればいいかもしれない、とのこと。

2. Provide the ability to merge accounts

一人のユーザが持つRelying Partyサイト上の複数のアカウントをマージできること
OpenID認証を提供することで、ユーザが複数のID作成をしてしまうケースは増えてしまう
だろうから、「人に紐づく単位でIDを束ねる」機能は必要になるはず。


※どのOpenID ProviderでこのRelying Partyサイトを利用したか忘れてしまう問題って、あると思います。

3. Many-to-one relationship between Identity URLs and user accounts

ユーザが利用するOpenID((Verified)Claimed Identifier)とRelying Partyサイト
のIDが"他対１"の関係であること


※上のマージ機能を提案している時点で当たり前な気がするけど。

4. Don't require users to choose locally-unique usernames

Relying Partyサイト上でユーザを一意にするための名前は、ユーザに要求するのではなく
OpenID識別子(Verified Claimed Identifier)を利用すること。
（ユーザにとっても混乱の元になるでしょ？）


※これも基本、な気が。。いわゆるOpenID再利用問題にも絡む問題となるし。

5. Allow, but do not require, users to attach a handle or name to their identity

(でも)ユーザが任意のハンドルネームを作成する機能があれば好ましいかもしれません
一意性という観点では、ハンドルネームはユニークでなくても構いません
ブログのコメントユーザ名などで好まれるでしょう。とのこと

6. Store primary OpenID in a cookie and check_immediate at next session

OpenID認証を簡略にするため、そのユーザにとってプライマリなOpenID情報をもつ
Relying PartyサイトのCookieをセットするようにし、check_immediateを実行するべし

感想まとめ

断然リアリティがあり素晴らしいです。

続・twtr2srcで簡単日記

web 日記

以前書いたエントリ『twtr2srcで簡単日記』にて作者さんからコメント頂いていた。再度twtr2srcで新機能の時系列ソートを利用してのお手軽日記。


Sun, Feb 22

  • 12:27  さっきこれ見てて旨そうだったから今晩は酢豚作ろうhttp://www.tv-tokyo.co.jp/danshigohan/
  • 14:12  どうやらLX３のキャップを無くしていたらしい。。という訳でこれを買おうかどうか悩む http://tinyurl.com/d74qph
  • 18:07  池袋亀でLX3純正の本革カバー実物見てきたけどあんまり格好良くなかった。あれに一万弱払うのはないな、でもケースが欲しいからどうしたものか
  • 18:10  @tkm そうだマイスペ手芸部でわたしのカメラケース作ってよ。報酬はずむから
  • 19:15  モテになるためには夜景観賞士検定持ってるといいとのこと http://www.yakeikentei.jp/
  • 22:22  2月22日22時22分22秒をお知らせします
  • 22:33  くるりの岸田が「シングルは捲き餌」と言い放ってるこの記事はなかなか深い http://natalie.mu/pp/quruli


Sat, Feb 21

  • 01:06  空耳アワーの投稿に杉並区在住のチン中村さんがwww
  • 12:31  劇団銅鑼の芝居を観にいきますよ。yomeは例によって役者ではなく売り子。。
  • 13:50  近所のスーパーなんだけどこれが春日にしか見えなくていつも吹いてしまう - Photo: http://bkite.com/04PiB
  • 16:28  面白かったなぁ、今回の芝居。また芝居を観ること、という経験そのものをデザインしてみせたイスラエル人演出家が凄かった。
  • 21:16  安ワインでリーズナブルに酔えて満足

あ、@tkmr宛へのreplyがタイポしている、とか朝は酢豚作るつもりだったけど結局作らなかったなとか色々ふりかえりが出来て便利です。
ちょくちょく使わせてもらいます。id:ogaogaさん、ありがとうございました。

鮭のちゃんちゃんチーズ焼き

料理 web

http://cookpad.com/recipe/483773
こちらのcookpadでチェックしていた鮭のちゃんちゃんチーズ焼きが美味しくできました。作者さんにはこの場で伝わらない感謝を。


P1010354.JPG


超絶便利なレシピサイトであるcookpadさんところのコンテンツはちょくちょく利用させて貰っているのですが、私の場合は気になるレシピのリンクURLをはてブかタンブラで残しておいて暇な週末に料理するというやり方がはまっています。


でも本来であればcookpadのIDでログインして、提供されているMyフォルダ機能でお気に入りのレシピ集を作成したり、上の写真も「つくれぽ」としてcookpad内で公開するのが「筋」だと思っていますが、そうしていないのは申し訳ないですが、そのやりかたは私にとって若干の不便があり、なのでそうしていなく、その辺は個人の自由なのだと思ってます。


ただそれでは申し訳なさすぎるので、なんでcookpadの機能についてもある程度わかっていて（実際にアカウントだけは持っています）cookpadサイトを利用していないのかということを自分なりに分析した結果をお話しますと、自分がはてブとタンブラのリンク集をホームグランドとして（それをfriendfeedのmyfeedとして確認することが自然な生活パターンとして身に付いてしまって）いる中でcookpadをログインしてまで利用すること(MyフォルダにRSSが出るならまた違ったかもしれないのですが)は、少しだけイレギュラーな行為、相対的にコスト高な行為であるからです。あくまでも私みたいな人間にとって、の話ですが。（ここは強調しておくべきです）


いまいち実感わかないOpenSocialですが、例えばこういう時なんでしょうねそれが便利だなと感じるときって。と思いました。cookpadのコンテンツを利用しているはてなユーザの私が何らかの形でcookpadに対してフィードバックしたい。という気持ちが少し発生した時に、それを低コストで実現できるような基盤技術があれば、それは嬉しいなと思うので。


やはりキーワードは「恩返し」です。おもてなし、されたら、恩返し、しなきゃな。です。インターネットって、特にCGMなんて呼ばれているものはそういうもの。少し脱線するけど投げ銭とかのマイクロペイメントの必要が叫ばれていますけどあれも一種の「恩返し」。その体験をどーにかデザインできないものか、ということですね。
とか思いつつ、晩酌は続くよどこまでもほろほろと。

デブサミ2009一日目。温故知新

日記

楽しみにしていたデブサミ2009に出撃。デベロッパーの祭典だったのだけど今日は意外にも技術の話ではないところでグッと来る示唆があったのでメモ。
今回色々なセッションで聞いたのは、パラダイム、という言葉。そしてそこから喚起されたのは温故知新。


午前最初のセッションで出て来たのはクラウド、というテーマ。最近ではバズワードと揶揄されることが多くなったこの言葉はSOAからのパラダイムシフトという概念が根底にある、一貫性よりも可用性。SOAでは到達できないスケールレベルを扱うためにはは従来のN-tierを捨てないといけないほど根本からの変革が必要という話で、、というこの説明だけではまぁ陳腐なバズに聞こえてしまう人がいるのは仕方なく私の表現力のなさのせいなのだけど、デブサミでのMSのアーキテクトの方のセッション内容はかなり多岐に掘り下げられており非常に興味深く気づけばノート４ページくらいのメモを取っていた。ここらへんは今日の主題にそれるのでまぁ今度。


次のMatz（まつもとゆきひろ）の大盛況な言語よもやま史なセッションでは、これ自体は割と一般的なテーマながらも話上手でまったく飽きない凄い、という全般的な印象。示唆的なフレーズがたびたびあったのは流石だなぁと感心していた中でひとつ上げたいのは、言語の進化というものはハードウェアの進化、ソフトウェアの進化と一方で変わらない人間の能力の限界から来る要請があるという論旨で、ここでもパラダイムという言葉がキーワードされていた。パラダイムの変換の中で必要とされるのは温故知新的な技術。具体例ではGC（ガーベジコレクション）なんて概念はいつからあった？というもので、でも使われるようになったのは９０年代のjava(Ruby)からでしょ。と。
これが温故知新の例。


さてここからが今日何と言ってもな話、で、午後一のセッションだった睡眠覚悟で向かったのを非常にいい意味で裏切ってくれた、「テクノロジーは世界をインターフェースする」というセッション。発表されたのは１０年以上前からメディアアーティストを発表されているデザインな方で、多摩美でも教壇に立たれている方らしい。今ここはデブサミなのになんだか懐かしい大学の講義を聞いている感覚になれたのは同級生と一緒に話を聞いていたから、という訳ではなさそう。
セッションでは、その方なりのメディアとはどういうものか、デザインとはどういうものか、について明確な考えを示していく。メディアとは何のためにあるのか？それは人がそれまで見ることができなかったものを先人の知恵によりデザインされ可視化することができるようになった手段、と話されていたと私は理解。インターネットというメディアは、一般人がこれまでリーチできなかった一時情報に暴力的にリーチすることができる、という特性、また分散的、WWW、という特性がありそこで表現者は何を新たにデザインして（恩返し的な）ポジティブな創造を行ってゆけばいいのか、というある意味基本的なことなのだけどビジネスの世界に浸かっているとと忘れがちになってしまうことに対しての気づきを改めて与えてくれたことに感謝していて、これは本気で取り組んで行きたいのだよなぁと思っている次第。


少し考えたのは、今いま個人的興味のつきないアイデンティティ、デジタルなそれに対して我々が、子供達が、親達が、ポストインターネットなこの世の中でどうつきあって行けばいいのか。Web上に置かれているmixiやtwitterの私と私の関係の集合であるアイデンティティは現在のところ最適にデザインされているとは私自身は思っていなく、どんな姿がよりよい未来なのか。という興味がつきない。できることならそのことに対して先人の創造の恩返しができるような、デザインができないものかな、ということを憚りながらも夢想してしまう。で、そのデザインというのは過去からの決別的な何かではなくて（人間社会をデザインする、というなのだから）温故知新的なものが出てくるのかなという気がしている。こういうのは考えて、作って、利用してみて、のサイクルをまわさねば、なんだ。


実際に今流行ってるのは昔流行らなかったあれ、というのが年とってきたからというのもあり色々と遭遇してくるようになった訳だけども、アイデンティティ自体は今の時代の要請というものに乗るかどうか、マッチするものは何かということを整理することはできないのだけど、見直すべきものはいくらでもあるな、と１０年前のメディアアートに触れて思った一日目でした。

twtr2srcで簡単日記

日記


Tue, Feb 10


Mon, Feb 09

  • 09:21 @tkmr 2/10発売、キリンの淡麗Wは世界初プリン体を99%カットしたらしいよ。マジお薦め #
  • 09:01 本日二度目の出勤開始、一度目は会社前まできて忘れ物に気づきました #

Sun, Feb 08


http://www.ogaoga.org/lab/twtr2src/index.php?u=komatak#sourceより

http://www.ogaoga.org/lab/twtr2src/index.phpというサービスでお手軽日記。
無意識的なつぶやきが自動的に日記になるのは素晴らしいですね。
ひとつ欲しいのは時系列順で読みたい時に下から読まないといけないという。まぁtacコマンド流せばいいだけという話もありますが。

『ブログのコメント認証にOpenIDが使える』ことは本当に便利なのか

web

ずっと言われ続けている気がするこんなOpenIDのステロタイプな利用例ですけど、
実際のところは大きなブログサービスでほぼ利用されてない*1という件についてです。


掲題の括弧内がもし本当に便利だったのならOpenID Providerが出揃ったような雰囲気が醸し出された昨年末あたりで各社ブログサービスが対応しているのだと思うのだけど、少なくともOpenIDという技術に明るいユーザが多いだろうはてなダイアリーは対応しても良さそうなのだけど、現状そうなっていない。これに対応しているのはGoogleのBloggerやMovable Typeがあるけれど、このユーザ層は日本のブログ人口の比率でいくと大変に少ない。てことは、一見便利そうなこの仮定は僕らにとっては実は微妙なアレなんだろうなということで、誰にとって便利なのか？なぜ便利なのか？デメリットは？あたりを整理して、問題の本質は何なのかとどうすれば便利になるのかを考えたいのです。

■便利そうな理由

ブログコメント、にまつわる登場人物は

  • ブログ主
  • ブログサービス提供者（個人運営なら=ブログ主）
  • コメントする人
  • 記事を読んでる人

です。


ブログ主には匿名で誰彼構わずコメントされるのは嫌だけど、身元がある程度わかるような人ならオッケーという微妙な乙女心を持つ方は割といて、ソリューションとしては同じブログサービスのIDを持った人のコメントを受け付けるという仕組みをブログサービス側が提供しています。そんなブログ主の記事をたまたま読んでいた人が何らかコメントしたくなった時にブログ主が利用しているサービスのIDを持っていないがためにコメントすることができなく、コメントするためだけに新規ID取得をするなんてことは面倒なので結構な確率で機会損失が起こってしまいますが、コメント認証にOpenIDがサポートされていれば自分が持っている他のサービスプロバイダのIDでログイン後にコメントが書けるので便利だな、というのが直観的にあります。
直接的にはブログ主、コメント者双方にとって有意義なシステムですが、有益なエントリに対して貴重なコメント、しかもコメント者の「本来の身元(はてな村の○○がXXXのブログにコメントを付けたんだよ、という意味でのトレーサビリティがプラスされる)」が付くことで他に読んでる人にとっても魅力あるコンテンツにもなりえますし、ユーザのブログが盛り上がっている状況はサービス事業者側にとっても好ましいことのはずです。

■便利でない理由

これだけ聞くと良さそうな気がしますが、今日のお題はダメな理由について考えることでした。

  • 新規IDの機会損失

これは上の例の反対として起こることですが、サービス提供側にとってはOpenIDの導入が新規ID取得率の低下になるかもしれない、と考える人がいるかもしれません。ただ上記の通りOpenIDの導入は事業者側にとってもプラスとなる点もあるとは思いますが。

  • 携帯でコメントがつけられない

OpenIDは携帯からは利用できません*2。例えばアメブロなどは携帯でのみブログをやっているユーザが大半ですってのはまあいいのですが、じゃあPCからはOpenID認証も受けつけて携帯からはサービス事業者のIDでのみ受け付ける、というシステム方式じゃなんだか煩雑な印象を受けてそこまでして対応する意味あるの？という気持ちにさせてくれますし、OpenIDなんてよく知らないブログ主も混乱させてしまう原因になりそうです。


とかない頭を絞って考えていたのですが、結局のところはこうですかね。ぶっちゃけ。

  • 「他の誰でもない私」がコメントしたことを他者に知らせたいなんて人はまず、いないから

つまり「便利そうな理由」で上げた理由を便利だと感じてくれる人の割合が絶対的に少ない、というのが本質なような。

■問題の本質は

ここからは視点が定まっていないですが。
「他の誰でもない私」がコメントしたことをわりかし大きな（例えば継続的にはてブされるような）ブログのコメント欄で他者に知らせたいなんて人は「ほどほど」にしかいない。そんなのはマニアックで、ネット利用ユーザのピラミッドの頂点に君臨するギークのような方々が住む世界で、それは１０年たってもアメブロユーザには伝わらない話ではないのか。
例えばこれをたまたま読んでくださったあなたを、今特別にブログは書いて無くてはてなについてはよくわからずidは持ってない、Mixiのアカウントは持っている、あと最近はじめたTwitterで有名人のフォローはしている、ようなペルソナに仮定します。そんなあなたがこのエントリにOpenID認証で(実際にははてなダイアリーはOpenID認証をもっていないけど、あくまで仮定)ブログにコメントつけるだろうか。その時あなたはTwitterやMixiのIDで (TwitterはOPではないけれど)ログインして、あなたであることをブログ主に伝えたいでしょうか。という問題だと思うのです。*3


つまり利用者の感情とか、ノリとか、そういうところが問題の本質なんだと思ってます。


ただミクシィやアメブロを見てみると、普通のネットユーザレベルでも十分に馴れ合いは発生しています。彼らは物凄い勢いでコメントをしあってます。じゃああれは何だ？という話になるとクローズドな世界だということだと思います。
ちなみにはてな村の人は、そのクローズドが村レベルにまでは拡張されている人達だと思ってて、OpenIDはさらにその意識をゆるくソーシャルに、ウェブのさらに広い範囲まで村を拡張することができるアーキテクチャになる可能性がある気がしているので、こんな話を書いているのですね。
今のウェブの「トレンド*4」は、「オープン」とか「ソーシャル」を志向していますしね（苦笑）。

■どうあって欲しいのか

散々アメブロアメブロ言ってて悪気がある訳ではないのですが、このまま行きます。
そのアメブロユーザにとってもOpenIDのことを知っているとかどうかはおいておいて、似たような趣味嗜好の持ち主同士がネット上のアメブロの外にいた場合に、その人とアメンバーと馴れ合いするのと同じ感覚で馴れ合いができれば、嬉しいのではないのでしょうか。
どこのサービスを利用している、とかはあまり関係なく、いかにフレキシブルにユーザ同士がふれ合えるかどうかじゃないの？という意味で、ひいてはウェブの世界を広い意味での「セカンド・ライフ」として利用できるような世界にするためのアーキテクチャの一つとして、僕はOpenIDはイケるのではないかと思ってるのですが。うぬ。抽象的すぎますね。


今回「ブログのコメント」という狭い視点から始めましたが、そういった実現の一歩として各ブログサービスはにOpenID認証をはじめて欲しいし、OpenID Provider側は皆SREG対応はして欲しい（個人的には要求されたらMUSTで答えなければいけない、という制約があって欲しい）という風に思います。

■まとめ

はてなさん、よろしくお願いします。

    • -

*1:livedoor Blogが「mixi OpenID」対応しているけど、プロバイダ限定のOpenIDはここではあえて無視

*2:今のところ

*3:正確な話をするとOpenID2.0の拡張仕様を利用しない認証をするだけであればあなたがTwitterの誰、とかMixiの誰とかまでわかりえる訳ではないのですが(認証されたURLがあなただ、といえれば別ですが)、「便利」の項であげた「トレーサビリティ」を活用することを考えた場合、少なくともSREGでのニックネームの流通は必須でしょう

*4:土曜日にdankogaiのセミナーを聴いた時にトレンドを追っかけるのだけはやめよう、という話をしていてそれはその通りだと思ってて、苦笑