DISQUS

Eiji > 公開鍵の扱いが中途半端な実装になっているのは、RSA署名方式自体が、署名の潜在的偽造の可能性があるからかもしれないのか？

これは単純に、まだ内輪で話が済んでいるからでしょう。もっと一般的になってくると、厳密に仕様を作り、乗っ取っていなければならなくなると思います。

> HMAC方式はお互いに秘密鍵を保有することで、すでに秘匿性が担保されていると考えてもいいのか。

秘匿性とはなんでしょうか？署名はあくまで自分が名乗っている通りである事を証明するものであり、リクエストの内容を隠すものではありません。リクエストの内容を隠したい場合はSSLなどを利用します。

> コンシューマーがリクエストする際に公開鍵を指定する仕様なら、誰でもなりすましができてしまう。
ハードコーディングは、公開鍵を事前に渡しておくことと捉えるなら、それなりに納得できる気もするが。

公開鍵は誰が見ても、誰が使っても、なりすましには利用できません。
署名の目的は、自分が名乗っている通りの者である事を証明すること。RSA秘密鍵を使って作られた署名は、RSA公開鍵を使ってのみ可逆なので、公開鍵で開けらる署名は秘密鍵の持ち主だと判断できます。また、その公開鍵で開けられる署名は、対となる秘密鍵でしか作る事ができません。

というわけで、秘密鍵が漏洩することさえなければ、公開鍵をハードコーディングする事も、動的に公開鍵を渡す事も特に問題はありません。

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

Eiji そのためにOAuthという仕様が存在します。Social Webのコンセプトは「自分のデータを自分の意思でコントロールできること」にあり、OAuthはプライバシ管理のために使用されます。
そのため、mixiでPortable Contactsの仕様がオープンなAPIで公開されたとしても、他サービスがごっそりそれをインポートする事はできません。OAuthにより、ユーザーごとに個別に認証を行う必要があります。
そういう意味で危険なリスクと呼べるものはないかも。
ただ、誰かが友達リストをインポートする事で、自分のプロフィール写真が他の人の目にさらされた！というクレームはありえると思います。重箱の隅つつきとしか思えませんが。