5. IANA の考慮事項 (IANA Considerations)

5.1 認証スキームレジストリ (Authentication Scheme Registry)

"Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry" は、チャレンジおよび資格情報における認証スキームの名前空間を定義する。これは作成済みであり、現在 http://www.iana.org/assignments/http-authschemes で維持されている。

5.1.1 手続き (Procedure)

登録には以下のフィールドを含めなければならない (MUST):

• 認証スキーム名 (Authentication Scheme Name)
• 仕様テキストへのポインター (Pointer to specification text)
• 注記 (任意) (Notes (optional))

この名前空間に追加される値には IETF Review が必要である ([RFC5226] の 4.1 節を参照)。

5.1.2 新しい認証スキームに関する考慮事項 (Considerations for New Authentication Schemes)

HTTP 認証フレームワークには、新しい認証スキームがどのように機能できるかに制約を課すいくつかの側面がある:

• HTTP 認証はステートレスであると推定される。リクエストを認証するために必要なすべての情報は、サーバーが以前のリクエストを記憶していることに依存するのではなく、リクエスト内で提供されなければならない (MUST)。基盤となる接続に基づく、またはそれに束縛された認証は本仕様の範囲外であり、認証されたユーザー以外のいかなる当事者もその接続を使用できないようにする措置が取られない限り、本質的に欠陥がある ([RFC7230] の 2.3 節を参照)。

• 認証パラメーター "realm" は、2.2 節で説明されている保護空間を定義するために予約されている。新しいスキームは、その定義と互換性のない方法でこれを使用してはならない (MUST NOT)。

• "token68" 記法は既存の認証スキームとの互換性のために導入されたものであり、1 つのチャレンジまたは資格情報につき 1 回しか使用できない。したがって、新しいスキームは代わりに auth-param 構文を使用することが望ましい。そうでなければ、将来の拡張が不可能になるからである。

• チャレンジと資格情報の解析は本仕様によって定義されており、新しい認証スキームによって変更することはできない。auth-param 構文を使用する場合、すべてのパラメーターは token と quoted-string の両方の構文をサポートすることが望ましく、構文上の制約は解析後 (すなわち quoted-string 処理後) のフィールド値に対して定義することが望ましい。これは、受信者がすべての認証スキームに適用できる汎用のパーサーを使用できるようにするために必要である。

注記: "realm" パラメーターの値の構文が quoted-string に制限されているという事実は、新しいパラメーターでは繰り返されるべきではない設計上の悪い選択であった。

• 新しいスキームの定義では、未知の拡張パラメーターの扱いを定義することが望ましい。一般に、"must-ignore" 規則は "must-understand" 規則よりも好ましい。そうでなければ、レガシーな受信者が存在する状況で新しいパラメーターを導入するのが難しくなるからである。さらに、新しいパラメーターを定義するためのポリシー (「仕様を更新する」や「このレジストリを使用する」など) を記述することが望ましい。

• 認証スキームは、オリジンサーバー認証 (すなわち WWW-Authenticate の使用) および/またはプロキシ認証 (すなわち Proxy-Authenticate の使用) で使用可能かどうかを文書化する必要がある。

• Authorization ヘッダーフィールドで運ばれる資格情報はユーザーエージェントに固有であるため、それらが出現するリクエストの範囲内で、"private" Cache-Control 応答ディレクティブ ([RFC7234] の 5.2.2.6 節) と同じ効果を HTTP キャッシュに与える。

したがって、Authorization ヘッダーフィールドで資格情報を運ばないことを選択する新しい認証スキーム (例えば新しく定義されたヘッダーフィールドを使用するもの) は、Cache-Control リクエストディレクティブ (例えば "no-store"、[RFC7234] の 5.2.1.5 節) または応答ディレクティブ (例えば "private") のいずれかの使用を義務付けることにより、キャッシュを明示的に禁止する必要がある。

5.2 ステータスコードの登録 (Status Code Registration)

http://www.iana.org/assignments/http-status-codes にある "Hypertext Transfer Protocol (HTTP) Status Code Registry" は、以下の登録で更新されている:

値	説明	参照
401	Unauthorized	3.1 節
407	Proxy Authentication Required	3.2 節

5.3 ヘッダフィールドの登録 (Header Field Registration)

HTTP ヘッダーフィールドは、http://www.iana.org/assignments/message-headers/ で維持されている "Message Headers" レジストリに登録される。

本文書は以下の HTTP ヘッダーフィールドを定義するため、"Permanent Message Header Field Names" レジストリがそれに応じて更新されている ([BCP90] を参照)。

ヘッダーフィールド名	プロトコル	ステータス	参照
Authorization	http	standard	4.2 節
Proxy-Authenticate	http	standard	4.3 節
Proxy-Authorization	http	standard	4.4 節
WWW-Authenticate	http	standard	4.1 節

変更管理者 (change controller) は、"IETF ([email protected]) - Internet Engineering Task Force" である。

---