1. Introduction (はじめに)

1. Introduction (はじめに)

Proof of Possession (DPoP) は、OAuth [RFC6749] アクセストークンおよびリフレッシュトークンをアプリケーションレベルで送信者制約 (sender-constraining) するためのメカニズムです。これにより、クライアントは HTTP リクエストに DPoP ヘッダーを含めることで、公開鍵/秘密鍵のペアの所有を証明できます。ヘッダーの値は JSON Web Token (JWT) [RFC7519] であり、認可サーバーは発行されたトークンをクライアントの鍵ペアの公開部分にバインドすることができます。その後、そのようなトークンの受信者は、トークンと、クライアントが DPoP ヘッダーの存在によって保持していることを証明した鍵ペアとの間のバインディングを検証できるため、トークンを提示しているクライアントも秘密鍵を所持しているという保証が得られます。言い換えれば、トークンの正当な保有者は、鍵ペアの秘密部分を保持し所有を証明する送信者に制約されます。

ここで指定されるメカニズムは、基盤となるセキュアなトランスポート層の要素を利用する他の送信者制約トークンメソッド（[RFC8705] や [TOKEN-BINDING] など）が利用できない、または望ましくない場合に使用できます。たとえば、ユーザーエージェントでの TLS クライアント認証のユーザーエクスペリエンスが低く、HTTP トークンバインディングのサポートが不足しているため、OAuth クライアントが Web ブラウザで動的にダウンロードされて実行されるアプリケーション（「シングルページアプリケーション」と呼ばれることもあります）である場合、これらのメカニズムはどちらも使用できません。さらに、ユーザーのデバイスに直接インストールされて実行されるアプリケーションは、侵害された、または悪意のあるリソースによってトークンが悪用されるのを防ぐために、DPoP バインディングの恩恵を受けるトークンに適しています。このようなアプリケーションは通常、暗号化鍵専用の安全なストレージを持っています。

DPoP は、使用されるクライアント認証方法に関係なく、アクセストークンを送信者制約するために使用できますが、DPoP 自体はクライアント認証には使用されません。DPoP はまた、パブリッククライアント（つまり、client_id に関連付けられた認証資格情報を持たないクライアント）に発行されたリフレッシュトークンを送信者制約するためにも使用できます。

1.1. 表記規則と用語

この文書内のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", および "OPTIONAL" は、BCP 14 [RFC2119] [RFC8174] で説明されているように、すべて大文字で表示される場合にのみ解釈されます。

この仕様では、[RFC5234] の拡張バッカス・ナウア記法 (ABNF) 表記を使用しています。

この仕様では、「OAuth 2.0 認可フレームワーク」[RFC6749] で定義されている用語「アクセストークン」、「リフレッシュトークン」、「認可サーバー」、「リソースサーバー」、「認可エンドポイント」、「認可リクエスト」、「認可レスポンス」、「トークンエンドポイント」、「グラントタイプ」、「アクセストークンリクエスト」、「アクセストークンレスポンス」、「クライアント」、「パブリッククライアント」、および「コンフィデンシャルクライアント」を使用しています。

用語「リクエスト」、「レスポンス」、「ヘッダーフィールド」、および「ターゲット URI」は [RFC9110] から引用されています。

用語 "JOSE" および "JOSE Header" は [RFC7515] から引用されています。

この文書には、部分的および完全な HTTP メッセージの非規範的な例が含まれています。いくつかの例では、[RFC8792] に従って、長い値の行末に単一のバックスラッシュを使用して行の折り返しを示しています。折り返しのバックスラッシュとその後の改行および先頭のスペースは、値の一部ではありません。