auth-int

qop 引数 (HTTP)

[23] qop 引数は、 ダイジェスト認証が単なる認証のみを提供するのか、 一貫性の検査も行うのかを表します。

仕様書

意味

[8] challenge では、 「保護の品質 (quality of protection) 」を示す字句のリストです >>4

[14] credentials では、クライアントメッセージに適用した 「保護の品質」を示します >>12

[24] Authentication-Info: ヘッダー >>21Proxy-Authentication-Info: ヘッダー >>26 では、 サーバー応答に適用した「保護の品質」を示します。

[25] サーバークライアント要求で指定したのと同じ値を使うべきです >>21

構文

[16] challenge では、 auth-param引用文字列構文を使わなければなりません >>4

[7] challenge では、 1つ以上の字句の列です >>4

[15] 不明確ですが、空白区切りと思われます。

[17] credentials では、サーバーchallenge で示した値のいずれかでなければなりません >>12

[19] credentials >>12Authentication-Info: >>21Proxy-Authentication-Info: ヘッダー >>26 では、 引用文字列でなく字句生成しなければなりません

[18] 1つしか指定できません。

[9] auth は、認証を示します >>4, >>21

[10] auth-int は、 一貫性 (integrity) 保護付き認証を示します >>4, >>21

[27] auth-int を指定すると、A2 の計算で payload body が考慮されるようになります。 この機能が開発された当時は (無いよりまし程度の) 意味があったのかもしれませんが、現在となっては無意味です。 payload body の改竄は検知できますが、ヘッダーは改竄し放題です。 auth-int でなく TLS を使うべきです。

[28] 値は大文字・小文字不区別です。

[29] RFC 7616 はそれをまったく説明していません。1つ前の RFC 2617ABNF 構文で一応規定していました >>1

文脈

[5] ダイジェスト認証challenge >>4credentials >>12 で指定できます。

[6] challenge では、すべての実装が使わなければなりません >>4

[13] 「使う」とは具体的に何を言っているのかは謎です。 RFC 2617 は「省略可能だが RFC 2069 との互換性のためなので、 すべての実装が使うべき」と言っていたので、 サーバーqop 引数を明示するべき、 という意味だと思われます。

[22] ダイジェスト認証に成功したら、応答Authentication-Info: ヘッダー >>21Proxy-Authentication-Info: ヘッダー >>26auth-param として指定できます。

処理

[11] challenge では、未知の指定は無視しなければなりません >>4

[20] response 引数rspauth 引数の値の計算に使われます。

歴史

[2] この引数RFC 2069 にはなく、 RFC 2617 で追加されました。