2010年12月26日

Google Buzz で使われているドラフト標準

James Clark の A tour of the open standards used by Google Buzz (2010-02-12, James Clark's Random Thoughts) の日本語訳です。 XRD, WebFinger 辺りの概略が分かりそうだったので日本語にしました。

日本語訳

Google Buzz について最も魅力的だと思ったのが、彼らが オープンな標準に準拠する と宣言したことです。

ソーシャル Web は従来の Web (シンプルでオープンな標準によってつながっている多くのサイト) のように機能すると一番うまくいく、と私たちは信じています。

ということで、関係する標準技術をひと巡りする時間をちょっととりました。 ここでは、私にとって目新しいものに焦点を当てるようにします。

Google Buzz における設計上の重要な決定のひとつは、ソーシャル Web における個人は E メールアドレス (もしくは少なくとも似たような文字列) によって識別されるべきだ、ということです。 どちらかと言うと、私はこれに賛成です。 純粋な Web アーキテクチャという観点からは URI を使う方が望ましいかもしれませんが、ユーザーインターフェイスの観点からは E メールアドレスの方がはるかにうまくいくと考えています。

このため、Google Buzz はディスカバリの問題に対処するいくつかの標準を持ちます。 ディスカバリの問題とは、E メールアドレスのように見えるものとメタデータをどのようにして関係付けるか、ということです。 次のふたつがキーとなる標準です。

XRD:XRD は OASIS XRI TC によって作られたシンプルな XML フォーマットです。 汎用的な方法でリソースに関するメタデータを表現するためのものです。 とても妥当な感じで、不正な XRI とは関係ないのは嬉しいですね。 RDDL にとても似ています。
WebFinger:WebFinger は E メールアドレスから XRD ファイルを取得する仕組みを提供します。 HTTP に基づくふたつのステップから成ります。 まず始めに、E メールアドレスのドメイン部分を使って構築された、よく知られた URI から XRD ファイルを HTTP で取得します (よく知られた URL は "the Defining Well-Known URIs" と "host-meta" というインターネット標準に準拠します)。 このドメイン単位の XRD ファイルはいくつかの機能を提供してくれますが、とりわけ強調したいのは、 そのドメインにおける E メールアドレスのための URI 構築方法を教えてくれる URI テンプレートを提供してくれることです。 この URI が違うことにより、ある E メールアドレスに関連するメタデータの XRD 表現が分かります。 JSON シリアライゼーションに関することが雑音に感じられるかもしれませんが、これは意味があります。JSON はこの問題にとてもうまく合いそうなのです。

ディスカバリーメカニズムなどと組み合わせられるたくさんの興味深いことのひとつとして、公開鍵と個人を関連付けることがあります。 これを定義する Magic Signatures という仕様があります。 Magic Signatures は全ての普通の X.509 製品 を正しく避けてくれます。 ここでは完全に必要ないことです。簡単な RSA 公開鍵さえあれば良いのです。 ひとつの粗探しになってしまいますが、すでに完璧に良い標準フォーマットがあるにも関わらず、公開鍵のために独自フォーマットを発明していることが気になります。 たとえば OpenSSL で使われているように、RSAPublicKey ASN.1 構造 (RFC 3477/PKCS#1 で定義されています) の DER エンコーディングのことです。

WebFinger は XRD ファイルを安全な方法で取得する必要があり、このことは、SSL を使うか XML-DSig を使って XRD ファイルに署名するかを意味します。 これを安全な状態にするためには気をつけましょう。 どちらの方法でも、既存の X.509 基盤を活用します。 ここでキーとなるアーキテクチャ上の決定は、ドメインレベルで証明書を発行するために X.509 基盤を使うことです。 そしてドメインから個人まで信頼の連鎖 (chain of trust) を拡げるために Web の技術を使います。 配備の観点からは、私は Gmail や Facebook がやっているように、あるドメインに大勢のユーザーがいるような場所ではうまくいくと考えています。 課題となるのは、あなたのドメイン用に Google Apps などでもうまく動かすことです。 そこではドメイン当たりのユーザー数はわずかです。 今のところ Google Apps はドメイン管理者にいくつかの DNS レコードの設定だけを要求します。 DNS が安全ではないことが問題なのです (少なくとも DNSSEC が広く普及するまでは)。 とはいえ、ひとつの解決方法があります。 ユーザーのドメイン (たとえば jclark.com) はプロバイダーのドメイン (たとえば foo.google.com) におけるホストを示す SRV レコードを持つでしょう。 XRD は HTTP を使って取得されますが、ユーザーのドメインのために XML-DSig と X.509 証明書を使って署名されています。 WebFinger のサービスプロバイダー (たとえば Google) は、おそらく WebFinger への利用を制限するフラグを持たせるなどして、 これらの証明書を発行することに気をつけてくれるでしょう (Google はすでに Google Apps の設定作業の一部としてドメイン制御を検証しています)。 ここでの信頼されたルートはブラウザーベンダーが決めた HTTPS のルートとは違うかもしれません。

Magic Signatures のもうひとつの部分は、XML-DSig より簡単で JSON でも動作するような代替方法だと宣伝されています。 ここでのキーアイデアは、XML における情報のアイテムにまで署名するというコンセプト全体を避けて、それゆえに正規化の必要性を避けることです。 その代わり、バイト列に署名します。このバイト列は XML 要素の中身 (もしくは JSON 文字列) として base64 でエンコードされます。 私は、コンテンツを base64 でエンコードしたものがいつも署名されているようにする、という考えには賛成していません。 テキスト形式の利点の多くを必要もなく投げ捨てているかにみえるからです。 そうではなく、署名したバイト列が Unicode 文字列を表しているなら、XML や JSON の組み込みクォート機構 (XML なら文字参照や CDATA セクション) を使って、 XML 要素の中身または JSON 文字列として Unicode 文字列を直接表現できるのです。 XML や JSON を解析した結果のユニコード文字列は、標準の署名アルゴリズムが適用される前に UTF-8 でエンコードされるでしょう。 Magic Signatures を使う上でもっと根本的な問題は、XML-DSig の重要な特性 (中でも enveloped 署名) を損なってしまうことです。 重要な特性とは、単に署名を無視することによって、署名について知らないか気をつけないアプリケーションでも署名されたデータを理解できることです。 私も、XML-DSig の複雑さを避けたい、という点については全くもって同意します。しかし、Magic Signatures がそのための正しい方法だとは納得していません。 XRD は XML-DSig に依存していることに注意しましょう。 とはいえ、XML-DSig の非常に限定的なプロファイルしか指定していませんので、XML-DSig を処理する複雑さを劇的に小さくしてくれます。 JSON が。(訳注：原文は For JSON, I think i となっている。何かの間違いか慣用表現？)

Atom を拡張する標準もあります。 もっとも簡単なものは、content を拡張することです。

Atom Activity Extensions:
Atom Activity Extensions はソーシャルネットワーク上の活動 (何かにリンクしたことや何かを投稿したことなどです) のための意味的なマークアップを提供します。 これは分かりやすくて良いですね。
Media RSS Module:
Media RSS Module はマルチメディアコンテンツを扱う拡張を提供します。 元々は Yahoo によって RSS のために設計されました。 マルチメディア (content/@src, link) のための既存の Atom/AtomPub の機構とこれらがどうやって共存するのかをまだ理解していません。

プロトコルを拡張したものもあります。

PubSubHubbub:PubSubHubbub は Atom フィードからほぼリアルタイムに更新を取得するスケーラブルな方法を提供します。 Atom フィードは "hub" へのリンクを含むようにします。 アグリゲータは、フィードが更新されたときに通知してもらうように、hub に登録できます。 パブリッシャーがフィードを更新すると、hub に通知 (ping) し、hub は自分に登録されている全てのアグリゲータを更新します。 hub がアグリゲータに知らせるためには HTTP POST を使いますので、サーバベースのアグリゲータを意図しています。
Salmon:Salmon はフィードアグリゲーションを双方向にします。 ユーザ A はソーシャルネットワーキングサイト X だけを使っていて、ユーザ B はソーシャルネットワーキングサイト Y だけを使っていると仮定してください。 ユーザ A がユーザ B とつながりたい場合、典型的には A が Y に参加するか B が X に参加しなければなりません。 この方法は、世の中がひとつの支配的なソーシャルネットワーク (Facebook など) を持つ方向に進めます。 長期的に考えるとこれが良いことだとは思えません。 Salmon 拡張はこの問題の一部を解決します。 X は A のために Atom フィードにリンクするプロフィールを外からも見えるようにでき、Y は A に関する情報を B に提供するためにそれを使えます。 しかし問題があります。 B が A のエントリーのひとつにコメントしたいとしたらどうでしょう。 B のコメントを X に戻し、それを A が見えるようにすることを Y はどうやって保証できるでしょうか？ もうひとつのソーシャルネットワーキングサイト Z には、A のエントリーに対する B のコメントを見たがっているユーザ C がいるかもしれません。 基本的な考え方は単純です。 X によって外から見えるようになっている A の Atom フィードを、コメントが投稿される URI にリンクするのです。 Salmon の大きな進展は Magic Signatures によって成されます。 Atom エントリーに署名することは、サイトがコメントを受け付けるかどうかを決めるキーとなります。

Google はこれらの標準のいくつかのために Open Web Foundation を使うようにも見えます。 OWF のメンバー一覧には私が知っていて尊敬できる人たちの名前がたくさんありますが、正直なところ OWF の必然性を理解できません。 IETF と非常によく似ています。 IETF には不足だと感じて OWF を形成する動機は何だったのでしょうか？

XML か他の表現か

ということでざっくりと日本語にしてみました。 しかし、ここに出てきたことが絶対に XML でなければならないのか言うと、たぶんそんなことはありません。 個別の設計や組み合わせは XML で定式化した方が良いかもしれません (XML Schema などは嫌われている感じがありますが...) が、 実際に利用する場合は、通信データ量とプログラムでの扱い方などの関係により JSON のような表現形式の方が歓迎されるかもしれませんね。

その関係で... かどうかは分かりませんが、最近では XML と JSON に関して色々あるなーと思うのでした。

あと、URL をユーザの識別として使うことに関してはこの辺りもメモ。

  • URL as UI (Jakob Nielsen's Alertbox, March 21, 1999)
ラベル: ,

0 件のコメント:

コメントを投稿

登録: コメントの投稿 (Atom)