ここ数日OAuthのことばっかり調べてますが、TwitpicがOAuth Echoというものを採用していたのでさらに調べてみました。

ググってみると一番最初にOAuth Echo - delegation in identity verificationという記事が出てきたので、まずこの記事を読んでみることにしました。次のセクションはこの記事の和訳になりますので、概要のみをご覧になりたい方は次のセクションを飛ばしてください。

割と長い文章をそのままオレオレ直訳しているので、原文をご覧になりたい方は元記事をご覧ください。

OAuth Echo - delegation in identity verification

OAuth Echo - 私が今、身元証明の委任ワークフローと呼んでいるもの（@joestump、名前をつけてくれてありがとう）の図例を添付しました。これはtake 1とtake 2から進化した最新の図です。

身元証明の委任とは？ 以下のように言い換えましょう:

あなたは、OAuthを使用できるTwitter Clientです。そして、あなたはすでにあなたのユーザを認可しています。あなたのユーザはTwitpicのようなメディア提供サービスを使いたがっています。Twitpicは現在、あなたのユーザのユーザーネームとパスワードを尋ね、そのツイッターユーザの代わりに写真を保存することができます。あなたは、そのユーザネームとパスワードを持っていません。それでは、どのようにしてTwitpicにあなたのユーザの身元認証を可能にさせることができるのでしょうか？

私が今までに受け取った全てのコメントから、この問題を２つに分けました：

• OAuth Echo - シンプルで簡単な身元証明の委譲 - これは、ツイッターが実装し推奨する可能性が最も高い意見です。そして
• OAuth Echo Restricted - 身元証明の委譲リクエストが、特定のDelegatorと名前をつけられたものを通してのみ発生することを保証するため、何らかのセキュリティの制限を追加することです

OAuth Echoの詳細はページ１です。これはとてもエレガントでシンプルです。コンシューマとしてのあなたは、保護されたリソースを訪ねます。この一環として、あなたはユーザの身元確認をするため、Twitter上のaccount/verify_credentialsに対しOAuthコールができるよう、Delegator the Authorization headerを与える必要があります。

The Restricted versionはConsumerの"名前"を持っています。the Delegator he or sheはリクエストの一部として使っています。その"名前"をConsumerが伝えた署名付きのAuthorization headerに含んでいます。Delegatorはそのデータを取得し、署名しなおし、Twitterにそれを伝えます。TwitterはDelegatorの確認、（Consumerを使っている）ユーザによって署名されたAuthorization headerの確認、そしてユーザ（とConsumer）がその特定のDelegatorを通してそれを送ったかどうかの確認をし、すべての裏づけを行います。 OAuth Echo - Identity Verification Delegation (Draft

この件が落ち着いたと感じたら、また正式な形でこの件について書いて、OAuth WRAP/2.0に移植します。今までコメントしてくれた方ありがとう！

適当な日本語に訳すのって難しいですね。全く意味が違っているようなところがあればご指摘くだされば幸いです。

で、OAuth Echoって何？

Consumerがウェブサービス（これも厳密にはConsumer）の機能を使いたいけど、認証しようにもそのウェブサービスはConsumerを利用しているユーザのService Provider上の証明情報（ユーザネームやパスワード）を持っていません。そんな時に利用するのがOAuth Echoという認証プロトコルです。OAuth EchoではConsumer、Service Providerに加えDelegatorという新しいファクターが登場します。

Delegatorって何？

Delegatorは認証作業を委譲するものです。ユーザがConsumerを使い始めた時点で、ConsumerではService Providerでの認証を終えていますが、Delegatorでは終えていません。つまり、この時点ではDelegatorはConsumerを利用しているユーザの情報を何も持っていません。Delegatorは、Consumerから証明情報を受け取り、Service Providerに代わりに認証を行ってもらいます。

認証フロー

DelegatorとService Provider間で具体的にどのようにデータをやり取りしどう処理するかの詳細まで把握しきれていませんが、ここまでで分かったことをひとまず図に起こしてみました。今のところOAuth Echoを採用しているのはTwitpicだけみたいですが、近いうちに全容を把握したいと思います。

所感

『リソースへのアクセス権限の委譲を行うOAuth認証が既に行われているConsumerに対して、Delegatorでの認証をService Providerに委譲する』というのがOAuth Echo。この一文を書いて、読んでみたら自分でも少し混乱してしまいます。OAuthについての記事を数日書いてみて、文章で多数の要素がからむ物を説明する難しさを改めて実感しました。お気づきの点がありましたらコメント欄やTwitterでご指摘いただければと思います。