題して「もしm○xiがOpenID Providerになったら」です。 5分くらいでOpenID 2.0の新しくなった点について分かる内容にしました。 そんときのスライド OpenID 2.0 Quick Note まぁ良かったら見て下さい。 当日の様子 なんか前に座ってる人たちの行儀が悪過ぎてDNBK 特に眼鏡掛けてたちっちゃい人、id:lopnorにそっくりな人の自重出来なさっぷりにDNBK =natさんニコニコしてた tmaesakaさんが英語ペラペラで遠い存在に感じた id:lyokatoと僕は仲間だと思った(英語的に) norahmodelさん来てた。今度三国志トークする id:TAKESAKOより早く会社出たのに現地に着いたのは僕の方が遅かった＞＜ Mac勢がほぼ全滅してた と言う訳で、中々素敵な会でした。 CNETさん、本当にありがとうございました。
啓蒙活動も兼ねて最近は面白いOpenID関連の話題には積極的に絡んで行こうと思ってます。 で、早速面白い記事を発見しました。 元ネタはid:IwamotoTakashiさんの、 結論―RP(Consumer)はアカウント情報にどのIDを紐づけるべきなのか なんですけど、過去記事を遡らないと分からないので、簡単にどういう問題なのか説明しておきます。 RPはエンドユーザーのどのIdentityに対して一意なユーザーと認識するべきか まずは1.1時代の話 1.1時代はClaimed Identifierと言うのは下記の二通りしかありません。 実際にIdPで発行されているIdentifier 自分が所有しているURLにdelegate設定がある 前者に関してはClaimed Identifier = Verified Identifierですが、後者は厄介です。 Claimed Identifie
OpenIDの仕様を改めて復習してみよう 本連載ではPHPによるOpenIDのサンプルを使って、実際に「Consumer」や「Identity Provider（以下、IdP）」を動かしながら、その仕組みについて解説してきました。かなり駆け足で紹介してきたため、今回はこれまでの解説を踏まえながら改めてOpenIDについておさらいします。 OpenIDでIdPが受け付けるアクセスには「associate」と「checkid_immediate」「checkid_setup」「check_authentication」の4つのモードがあります。これらは認証のたびにすべてが呼び出されるのではなく、状況によって選択されます。 まず「associate」では、アソシエーションハンドルとその有効期限、共通暗号鍵がIdPからConsumerに渡されます。アソシエーションハンドルは有効期限の間は再利用可能
_ 僕が OpenSocial や OpenID, OAuth を無視できない理由 [opensocial][openid][oauth] machu さんを皮切りに，shinichitomita さんや kazuhooku さんがとても 面白い議論を繰り広げてます． クロスドメインのセキュリティ問題を OAuth で解決する - まちゅダイアリー (2007-12-07) Re: クロスドメインのセキュリティ問題を OAuth で解決する - id:kazuhookuのメモ置き場 クロスドメイン通信とアクセスコントロール - snippets from shinichitomita’s journal ちょっと切り口を変えて，「この議論がどうして重要なのか，どうして革 新的なのか」ということを考えてみます．うまく説明できるかわかんない けど，挑戦してみようかなと． イノベーションってのは
長らくOpenID 2.0関連のspecの議論が行われていましたが、やっと出ました。 OpenID 2.0…Final(ly)! – OpenID で具体的に何が出たかと言うと以下の二つのspecです。 Final: OpenID Authentication 2.0 - Final Final: OpenID Attribute Exchange 1.0 - Final OpenID Authentication 2.0 1.1から変わった点で、今の所僕が知ってる内容をかいつまんで紹介すると、 用語が変わった Consumer -> RP(Relying Party) IdP -> OP(OpenID Provider)など 後方互換性がある。(openid.ns) XRIの導入 XRDSの導入*1 Association Typeの追加 Discovering OpenID Relyi
While its certainly been a long process in the making, we're now quite excited to announce OpenID Authentication 2.0 and OpenID Attribute Exchange 1.0 as final specifications ("OpenID 2.0"). This morning was the closing day of the Internet Identity Workshop and David Recordon, Dick Hardt, and Josh Hoyt (three of the authors and editors) made the announcement during the first session. Both specific
前回はConsumerサイトを実際に作る際のプログラミングに関してお話ししましたが、今回はOpenIDに関するセキュリティについて考えてみます。 今回取り上げるトピックとしては、 などを段階的に説明していきます。IdPの構築方法を知る前にOpenIDプロトコルのセキュリティに関して熟知しておきましょう。 OpenIDプロトコルにおける通信経路のセキュリティ ここまで詳細に解説してきませんでしたがOpenID認証プロトコルのフェイズにおいて、どのようにセキュリティ上の安全性を担保しているかを解説しましょう。 まずはassociateモードを正常に実行するSmartモードの場合です。 ConsumerはユーザーからのClaimed Identifierを受け取ると、associateのキャッシュが存在しない場合は新規にIdPに対してassociateモードのリクエストを行います。第3回で「as
OpenIDでテキストを共有できるWebサービス LIMILIC つくりました URLがIDっていうのはキャッチーじゃないのでOpenIDは使えないと言い続けていましたが、ここ最近の盛り上がりについカッとなってサービスをつくりました LIMILIC - OpenIDでテキストを共有できるWebサービス OpenIDをつかってLIMILICにログインすると、はてな記法を用いてWikiライクなページを作成できます。そのページに対して閲覧と編集それぞれにアクセス制御をかけるできます。 閲覧はすべてのユーザに、編集は一部の方にというようにアクセス制御することでお知らせページを作ったりと、writeboard風に使えます。メールアドレスや共有のパスワードなどよりもずっと安全じゃないかと思います。 あと、おまけ的にanonymous機能も付いていますので、匿名日記も書けます OpenIDって何？って方
追記: OpenID対応サービスまとめを作りました。 たぶん、2008年のインターネット（Webサービス)業界はOpenIDによるWebサービスのID体系の統一の荒波に揉まれることになると思う。日本のサービスプロバイダは、OpenIDの襲来に備えるべき。 海の向こうではすでにDigg, Wikipedia, Yahoo, Microsoftなどが導入や支持を発表しているほか、多くの小さなネットサービスはOpenIDに頼ったアーリーアダプタの取り込みに積極的になってる。日本国内ではどうかと言えば、niftyのaboutmeなどを除いて大手のWebサービスは未だ様子を見ている状態。リサーチレベルでは重要性が把握されつつある一方、経営レベルでは「なにそれ」的な状態が多そう。いかん、いかんよ。 2008年、YahooかAmazonかGoogleかわからないけれど、ほぼ間違いなくどこかの日本の大手の
はじめに 僕自身がセキュリティに対する暗号化の知識が足りなさ過ぎたので、ここで思い切ってまとめてみようと思います。 HMAC-SHA1 Diffie-Hellman鍵共有 について主に述べます。 現代の暗号化技術について (via: wikipedia) 現代の暗号ってのは概ね２パターンしか無くて、 共通鍵*1 公開鍵・秘密鍵 って奴です。 共通鍵ってのは代表的なのはパスワード認証なんかはそうで、データを送信する側(概ねサーバーとか)とデータを受信する側(ユーザー)は共に同じ共通鍵であるパスワードを知ってるってケ−スがそれ。DESとかAESが使われます。 公開鍵・秘密鍵ってのはsshでの公開鍵認証でも使われているように、データの暗号化に公開鍵を使い、データの複合化に秘密鍵を使う。従って特定のデータを複合出来るのは秘密鍵を所持している人のみ可能だって事になります。RSAだとかDSAが使われて
久しぶりに真面目にエントリを書いて見ます。OpenIDのreputation問題に関して、AOLがちょっと前に打ち出した一つの方針について思うところを書いてみます。 reputationとは OpenIDに関するreputation問題とは、Claimed Identifierが指し示すIdP/OP*1が信頼するに値するかどうかと言う評価・評判の事です。 と言うのもIdP/OPと言うのは誰でもでっち上げる事が出来るので、どこの馬の骨とも分からないIdP/OPでも何も対策しなければ許可してしまうのがOpenIDの仕様です。 そのIdPを提供するwebサイトに脆弱性があり、アカウントがクラックされでもしたら、そのようなアカウントをもって認証されたユーザーを信頼できるでしょうか。 よって何らかの指針を持ってして、OpenIDのIdP/OPを評価しなければならないのでは無いか…と言うお話です。 A
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く