9月 18 2008

オープンなコンタクトリスト仕様、Portable Contacts

Published by Eiji at 14:32:31 under DataPortability, OpenSocial, SocialWeb

PlaxoのJoseph Smarr氏が使う言葉に”Open Building Blocks for the Social Web”というものがあります。これはウェブをよりソーシャルにし、サービス相互の連携を深めていくために必要な”要素”を表しています。

この”要素”にはOpenID, OAuth, microformats, OpenSocialと、いずれもこのブログで取り上げてきたこれからのソーシャルウェブを占う重要な規格が挙げられていますが、そんな重要なピースのひとつに、Portable Contactsが加えられました。

Joseph Smarr氏の在籍するPlaxoにて、既に利用可能なAPIが公開されています。

Portable Contactsとは

Portable Contacts, is an easy-to-implement “people data” API that provides secure access to both traditional address book data and to modern social application data (profiles and friends lists).

PortableContactsとは、従来のアドレス帳データと最近のソーシャルアプリケーションデータ(プロフィールと友達リスト)のいずれにも、セキュアなアクセスを提供する、簡単に実装可能な”Peopleデータ”のAPIです。

現時点の仕様の中身を見てみると:

  • ディスカバリの方法(XRDS-Simple)
  • 認証/認可の方法(OAuth, Basic認証)
  • クエリパラメータ(ソート、フィルタ等)
  • 応答フォーマット(JSON, XML)
  • エラーコード
  • Contactのスキーマ

といった内容になっています。vCardやOpenSocial等、既存の仕様から大きく外れないよう意識して設計されているとのこと。

Portable Contactsの使いどころ

Portable Contactsはアドレス帳や友達リストを表すものですので、様々な分野で応用できることが予想されます。

ソーシャルネットワークサービス間の友達リスト交換

既にMySpaceのDataAvailabilityでサービスイメージが示されていますが、MySpaceの友達リストをTwitterにインポートする、なんてことが可能になります。

デスクトップアプリとのアドレス帳交換

例えばMac OS Xのアドレス帳アプリとMicrosoft Outlookのアドレス帳を、ウェブサービスを通じて同期するなんて事も、これまで以上に統一した規格の上で行う事ができるようになります。

携帯電話とSNSのアドレス帳を同期

自分が利用しているSNSの友達リストをそのまま携帯電話に乗せたり、その逆を行う事ができるようになります。ここでRipplexのようなサービスが間に入ると、さらに面白いことができるようになるでしょう。

OpenSocialとの関係

あれ、じゃあOpenSocialとPortable Contactsて同じじゃないの?と思った方もいるのではないでしょうか。そう、基本的にOpenSocialのPeople APIとPortable Contactsの役割は同じです。似た仕様が複数存在する事はあまり好ましくないため、個人的にも疑問に思っていました。

実はJoseph Smarr氏の働きかけにより、Portable ContactsはOpenSocial v0.8.1仕様で統合されました。言い換えると、OpenSocialのPeople APIの仕様とPortable Contactsの仕様は同じです。

OpenSocial v0.8.1の仕様はまもなく公開されると思いますが、内容はPortable Contactsに沿ったものになっていることが確認できます。

まとめ

ソーシャルウェブエコシステム構築の動きは、Portable Contactsのようなピースが揃う事でさらに加速してきています。今後もソーシャルウェブのメインプレイヤーたちの動向から目が離せません。

Comments add to hatena hatena.comment (3) add to del.icio.us (0) add to livedoor.clip (0) add to Yahoo!Bookmark (0) Total: 3

  • kazu
    OpenSocial準拠のサイトが広がりを見せてくると、mixiみたいなクローズなサイトは、間接的にアドレス帳を持ち出されるリスクがあるけど、そこは回避する方法はあるの?
  • そのためにOAuthという仕様が存在します。Social Webのコンセプトは「自分のデータを自分の意思でコントロールできること」にあり、OAuthはプライバシ管理のために使用されます。
    そのため、mixiでPortable Contactsの仕様がオープンなAPIで公開されたとしても、他サービスがごっそりそれをインポートする事はできません。OAuthにより、ユーザーごとに個別に認証を行う必要があります。
    そういう意味で危険なリスクと呼べるものはないかも。
    ただ、誰かが友達リストをインポートする事で、自分のプロフィール写真が他の人の目にさらされた!というクレームはありえると思います。重箱の隅つつきとしか思えませんが。
  • kazu
    なるほど、理解しました。

    REST ful APIをサポートするということと、OAuth認証は対で考えるべきことですか?
    モバイルの場合、JavaScriptが利用できないので、REST ful APIをサポートすることが必然なのでしょうか。
    shindigのいくつのバージョンから本格対応するのかは知りませんが、
    gumiはモバイル対応するべく、REST ful API +OAuth認証に対応しているような言い方です。
  • OpenSocialに限って言えば、OAuth認証は対で考えるべきです。
    ただ、公開はされていませんがmixi station等で使われているmixiのAtomPub APIではWSSI認証が使用されています。他にもBasic認証やDigest認証等、方式はいくつか考えられると思いますが、第三者を介してAPIからデータを取得するという意味では、いずれにしても今はOAuthが最も有力なプロトコルになります。
    ちなみに、JavaScriptでも裏のリクエスト処理はREST/RPCを使って行われています。例えばShindigのガジェット上ではセキュリティトークンというセッションキーのようなものが利用されています。そういう意味では、モバイルであろうとなかろうと、認証は必要です。
    ただ、OAuth(厳密にはOAuth Core)はユーザーのログイン処理というインタラクションが挟まりますので、少し話は複雑です。OAuth Consumer Request(gumiが利用)ですと、ユーザーの認証処理等が挟まりませんので、割と話は単純です。
blog comments powered by Disqus