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

仕様書

意味

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

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

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

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

構文

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

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

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

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

[19] credentials >>12 と Authentication-Info: >>21 や Proxy-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 2617 は ABNF 構文で一応規定していました >>1。

文脈

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

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

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

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

処理

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

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

歴史

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