まちゅダイアリー
過去の日記 タグ Categories
まちゅダイアリー
at posts/single.html

Identity Conference #2

machu included in 2008 200806
   3464 words   7 minutes 

Identity Conference #2に参加させてもらった。 幹事の水野さん、講演者の皆さん、ありがとうございます。

(1) XRI, Reputation, Trust (=natさん)

僕は、OpenIDの課題のひとつに、URLをIDとして使うことによる敷居があると思っている。 それを解決するための方法の一つがXRIということで、この基調講演はとても興味深かった。

XRIについて
  • XRIはOASIS Openで標準化している。
  • XRIは識別子、XRDS、検索の三本柱になっている
  • 人が理解するi-name（再利用可）と機械が理解するi-number（再利用不可）をペアで管理する
    • 再利用不可のIDには「!」が含まれる
    • i-numberと対にすることで、i-nameを再利用できる → OpenIDの再利用問題を解決する
    • i-nameが同じでも、i-numberが異なれば別のユーザと判断する。i-numberがURIのフラグメントと同じ役割を果たしている。

XRI は DNS にちょっと似ていて、階層の概念がある。 トップレベルの名前を取得するには、それなりに厳しい審査が必要とのこと。 第２レベルは比較的自由。

@free*username

なんかは第２レベルの例。 @free がトップレベルで、その後に * を付けてユーザ名を連結している。 ちなみに、先頭が = なのは個人で、 @ なのは組織らしい。

XRDSについて
  • XRDSを使うとXRIからURLやメールアドレスを引くことができる

これは実際に試してみると分かりやすい。 XRIを使うと、 =nat さんのブログは =nat/(+blog) で、連絡先は =nat/(+contact) と表現される。 XRIからブログのURLや連絡先を調べる方法はいくつかある。

  1. inamesのプロキシに手動で入力する
  2. XRIをURIにマッピングする

後者は、以下のようなURLになる。

いずれの方法にしても、XRIをブログのURLやメールアドレスへと変換している。 なので、DNSサーバがFQDNとIPアドレスを結びつけているように、XRIとURLやメールアドレスを結びつけるものが必要になる。 それがXRDSというXMLファイルになる。

=nat さんの XRDS は以下のようにして取得できる。

$ curl 'http://xri.net/=nat?_xrd_r=application/xrds+xml'

XRIの後に _xrd_r というクエリストリングを付けている。 これは、zigorouさんのYAPCプレゼンを参考にした。

レスポンスとしてXRDSが返ってきて、そのなかに (+contact) に対応するメールアドレスが書かれているのが分かる。

それ以外の場合 (+blogの場合) は linksafe-forward.ezibroker.net というサイトにリダイレクトしているっぽい。 このサイトに接続すると、さらに以下のように =nat さんのブログ (www.sakimura.org) へのリダイレクトが返ってくる。 （この関連付けに XRDS を使っているのかどうかは分からなかった）

$ curl -I 'http://linksafe-forward.ezibroker.net/forwarding/=nat/(+blog)'
HTTP/1.1 302 Moved Temporarily
Date: Thu, 26 Jun 2008 15:20:37 GMT
Server: Apache
Set-Cookie: JSESSIONID=28370DD0FADF74F8B943D8B97A4E9740; Path=/forwarding
Location: http://www.sakimura.org/en/
Connection: close
Content-Type: text/html;charset=UTF-8
X-Pad: avoid browser bug

こんな風に、 XRI を使うとブログの URL やメールアドレスをシンプルに表現できるよってことみたい。

ちなみに、 @freeXRIが提供している XRI Resolution を使うと、 curl を使わなくても XRI に関連づけられた XRDS を調べることができる。

XRI と URI

さっきの例では XRI を以下のように URI で表現できた。

http://xri.net/=nat

それで、 URI で表現できるのなら、わざわざ

xri://=nat

みたいな新しいスキーマを用意する必要があるの？という意見がでていて、議論になっているみたい。 この辺の話題はXRI vs URI - Yet Another Hackadelicや、そこのコメント欄が参考になる。 この議論には、

「Webは世界の一部」 vs 「世界はWebの一部」

という考え方の相違があるようで、これはなるほどと思った。 もう少し具体的なことを話されていたけど、ここではパス。

OpenID の課題

このペースで書いていると終わる気がしないので、箇条書きに戻す。

  • OpenIDはTrustメカニズムが不足している。
  • 信憑性 Reputation が必要
  • 認証手段はIdPが主張しているだけ。それを客観的にどうやって信じるか。
    • ORMS TCで議論している。
  • 非否認性
    • 契約の概念。事後否認。署名の世界。
    • Trusted Data Exchange
    • ID-WSFに近い。
    • Reputation Serviceと公開鍵の取得。

「否認防止」は PKI のデジタル署名でよく登場する話。 OpenID の場合、発行サイト (OP) から対応サイト (RP) へと送られる認証結果 (OpenID Response) は、 OP の署名がついている。 でもその実体は OP と RP で共有している鍵なので、OPが後で「そんなユーザを認証した覚えは無い」とRPへ言うこともできる。

今の OpenID の利用レベルだと、（RP は OP を信頼している前提なので） OP にそこまで求めなくても良いと思う。 けど、より重要度の高いトランザクションに使いたい場合はこういうことも考えないといけないのかな。

OpenID の利用例

JALと旅行代理店でのOpenID利用例について。

このサービスによって、JMB会員は、ミキのサイトで新たに個人情報などを入力しなくても、JMB番号でログインして、宿泊予約や代金決済などが自由にできるようになった。

ということで、 OpenID をベースにして、属性情報を取得するという話。 限定された環境での OpenID の利用ということで、少し Liberty の ID-WSF の世界っぽかった。

まとめ

特に、最後の事例がとても興味深かった。 飛行機の予約とホテルの予約の例は、まさに Liberty Alliance のユースケース。 それが OpenID で実装されているというところが、衝撃的だなぁ。

(2) Apache2::AuthenOpenID

id:lopnorによるプレゼン。 Apache2::AuthenOpenIDは Apache の OpenID 対応認証モジュール。 これを導入すれば、 .htaccess を書くだけで簡単に OpenID のクライアントになることができる。 前から面白いなぁと思って気になっていたので、開発の背景を聞くことができたのが嬉しい。

  • OpenIDっていつ使うのさ。
    • 例えば、知り合いに写真を見せたい。
  • 「ひと」と「ひと」をOpenIDでつなげる。
    • .htaccessを書くだけでOpenIDが使える。
  • 認証はPerlのモジュールを任せる。
  • 認可はApacheのauthz_userに任せている。
    • 認可の応用。AuthzHatenaPoint
    • 認可の応用: livedoor blogのプライベートモード
  • サーバ管理者が組み込めば、ユーザが簡単に使える。
  • 「認識可能な識別子」が重要。
    • Yahoo!のOpenIDアカウント名は、長過ぎて利用者が .htaccess に書けるとは思えない。
    • (そこでXRI？とか思ったりした）
  • 「理解可能な画面遷移」が重要
    • なんでこのページにいるの？フィッシングじゃないの？
    • (これは結構重要な指摘)
  • メールアドレスのToのほうが分かりやすいじゃん。
    • 誰のための仕組み？
Q&A
  • SREGと連携すれば面白そう。
  • xriは通らない
  • フラグメント付きのIDを書かせるのは厳しい。
    • Claimed Identifierベース。
  • OpenID は認証には使えるが認可には使えない？
  • コンピュータが管理するのか、人が管理するのかの違い。
    • （OpenIDはi-numberに近い？）

利用者視点での使い勝手をしっかりと考えられているなぁ…と思った。 理論がしっかりしていても使い勝手が悪いと普及しないので、このプレゼンの順番は GJ 。

あと、忘れてた。

認証＝あんただれ、認可＝あんただめ

これはすごく分かりやすい。もっと流行るべき。

(3) Attribute Exchange (AX)

id:zigorou さんによる AX の解説。

AX は現時点で対応している OP が myopenid, sxipper しか無く、また仕様上もかなり gdgd で罠も多いと。余り現時点で使える代物ではありません。

という話だった。 以下は自分の思ったことを含めてのメモ。

  • AXは特定の人が進めているだけ
  • OAuthに行って帰ってこない人も。足並みがそろってない。
  • 草の根の人はフォーマルな仕様策定が苦手。
    • GIF裁判の教訓。ちゃんとやらないとダメ。
    • (参加者が特許を行使しないことが前提？)
  • SxipperのAXはCardSpaceに似ている。

(4) ID-WSF の紹介

NTT伊藤さんによる ID-WSF の紹介。 資料は slideshare にアップされている。 ネット上で入手できる ID-WSF に関する資料の中では、一番詳しく書かれていると思う。

個人的には DS (Discovery Service) が Web Service の UDDI を連想してしまって、こういうサービスはどれくらい流行るんだろうな…と思った。 仕様策定の時にも、 DS と IdP は一つにするという議論があったみたい。

ともあれ、時間をかけて仕様を決めているだけあって、かなりよく考えられている感じ。 AX や SREG などの OpenID の属性交換での課題も、 ID-WSF での議論が参考になるんだろうなと思った。 7月18日に第三回Liberty Alliance 技術セミナーが開催されるようなので、そこでもう少し詳しく聞いてこよう。

なんだか、ずいぶんと感想が長くなってしまった。 まだ書き足りないこともあるけど、ちょっと気力が尽きちゃった。 懇親会は１次会までの参加だったけど、２次会がメインだったらしい。 残念。

次回はプレゼンの場を与えていただいたので、自分なりのネタを考えてみようと思う（プレゼン駆動開発）。

関連する日記

Updated on 2008-08-21
 OpenID
Back | Home