[7] HTTP認証の challenge や credentials における引数は auth-param
>>3
や authentication parameter >>3 と呼ばれています。
[83] Authentication-Control:
ヘッダーでは、
auth-param
と似て非なる auth-control-param
>>82 が使われています。
[5] auth-param
は、名前と値の組を =
で連結したものです。 =
の前後には BWS が挟まります。 >>3
[33] 名前は字句です。大文字・小文字不区別です。 >>3
[2] RFC 1945 と RFC 2068 では値は引用文字列とされていました。 RFC 2617 以後字句も認められています。
[22] RFC 1945 と RFC 2068 の定義では必ず引用文字列とすることになっていましたが、 RFC 2069 ではそうなっていない構文が定義されており、矛盾していました。
[36] 更に、各引数について個別の値の構文が定義されています。
[68] RFC 2616 世代までは、例によって引数ごとの個別の ABNF 構文は quoted-string の引用符まで含めて特定の構文を決める形になっていました。 現実にはまず token または quoted-string として構文解析した後にその値の部分を取り出して処理するのが一般的だと思われます。 RFC 723x 世代からはそのような形に改められています。 RFC 7235 もそのように定義することを求めています >>67。
[69] realm
引数の値は字句ではなく引用文字列としなければならないとされています。ただしこのような制限は新しい引数には設けるべきではないとされています
>>67。
[80] Authentication-Info:
/Proxy-Authentication-Info:
については、原則として字句と引用文字列の両方の送受信に対応するべきこと、
後方互換性のためどちらで送信するべきか規定できることが RFC
で説明されています。
[64] RFC 2616 まではヘッダーの文字コードは ISO-8859-1
とされていましたが、 RFC 723x では US-ASCII
になっており、8ビットのオクテットの解釈は不明となっています。
[65] 実際には利用者名や合言葉などで非ASCII文字が使われることがあります。
その扱いは auth-scheme
に依りますが、明確に規定されているものもあれば、
されていないものもあります。
[66] OAuth 1.0 ではパーセント符号化を使っています (>>55)。
[81] ダイジェスト認証の username
/username*
引数では、 RFC 5987 の拡張が使われています。
[86] Mutual
では、 credentials, challenge,
Authentication-Info:
/Proxy-Authentication-Info:
で RFC 5987 の拡張が使われています。ただし realm
引数では禁止されています。
>>85
auth-param
のリスト#✎[13] auth-param
は引数の1対ですが、実際にはリスト
(#
) として用いられます。
[6] MIME や HTTP の他のヘッダーでは引数は ;
で区切るのが普通ですが、 auth-param
のリストでは
,
で区切ります。
,
でしたが、
MIME に揃えるため RFC 1945 時代より前に ;
に変更されました。
なぜ auth-param
だけ ,
のまま残ったのかは不明ですが、
他の引数を値とするヘッダーは理論上存在しても実際には使われていなかった一方、
認証は早くからしばしば用いられていたため変更できなかったのかもしれません。[15] challenge では >>3 同じ名前の引数を複数回使うことは認められていません。
[12] credentials では順序は特に規定されていないようです。
realm
引数は唯一、 auth-scheme
に関わらず必須で構文的にも最初に定義されている特殊な引数でした。
ただ最初の引数でなければならないのが ABNF 構文の定義上のものなのか、
現実にそうでなければならない要件なのかははっきりしませんでした。[84] auth-control-param
は似ていますが、少し違います。
RFC 5987 の拡張構文にも対応しています。
[51] OAuth 1.0 ではプロトコル引数を Authorization:
ヘッダーで auth-param
として指定することができ、
その場合の構文が HTTP 本体よりも厳密に規定されています。 >>50
[75] 解釈の方法はなぜか規定されていません。記号や非ASCII文字の値が含まれることがあり得るので、 それをどう処理するか規定がないと相互運用性に影響しそうですが・・・。
[20] auth-param
はリスト (#
)
として用いられます。
[17] challenge (誰何) では、 auth-scheme
に続けて指定し、必要な認証についての追加情報を表します。
[18] credentials では、 auth-scheme
に続けて指定し、認証に必要な情報を表します。
[77] Authentication-Info:
, Proxy-Authentication-Info:
両ヘッダーでも使われています。
[70] 未知の引数についての共通の処理の方法はありません。 認証方式を定義する際はどのように扱うか決めるべきとされています >>67。その際、「理解しなければならない」ではなく「無視しなければならない」 とするのが好ましいとされています >>67。 また新しい引数を規定する方法 (仕様書の改訂や登録簿など) も定めるべきとされています >>67。
[78] challenge や credentials では、次のような引数が用いられます。
Challenge
(Remote-Passphrase
challenge, credentials)Credential
(AWS4-HMAC-SHA256
誰何)SignedHeaders
(AWS4-HMAC-SHA256
誰何)Signature
(AWS4-HMAC-SHA256
誰何)algorithm
(Digest 誰何, credentials)apikey
(AdobeAuth
challenge)auth
(GoogleLogin credentials)authorization_uri
(Bearer
誰何)charset
challenge
(HOBA
challenge)cnonce
(Digest credentials)data
date
digest
(Digest credentials)domain
(Digest 誰何)entity
(PEM
credentials)error
(Bearer
challenge)error_description
(Bearer
challenge)error_uri
(Bearer
challenge)k
key
keyuri
max-age
(HOBA
challenge)nc
(Digest credentials)nonce
(Digest 誰何)oauth_acceptable_versions
(OAuth
challenge)oauth_acceptable_timestamps
(OAuth
challenge)oauth_consumer_key
(OAuth credentials)oauth_error_in_response_body
(OAuth
credentials)oauth_nonce
(OAuth credentials)oauth_parameters_absent
(OAuth
challenge)oauth_parameters_rejected
(OAuth
challenge)oauth_problem
(OAuth
challenge)oauth_problem_advice
(OAuth
challenge)oauth_scope
(OAuth
credentials)oauth_session_handle
(OAuth
credentials)oauth_signature_method
(OAuth credentials)oauth_signature
(OAuth credentials)oauth_timestamp
(OAuth credentials)oauth_token
(OAuth credentials)oauth_token_attributes
(OAuth
credentials)oauth_version
(OAuth credentials)opaque
(Digest 誰何, credentials)qop
(Digest 誰何, credentials)resource_id
(Bearer
誰何)response
(Digest credentials)result
(HOBA
credentials)scope
(Bearer
challenge)sessionid
(AdobeAuth
challenge)sig
(AdobeAuth
challenge)signature
source
stale
realm
(challenge, Remote-Passphrase
credentials)Realms
(Remote-Passphrase
challenge)Response
(Remote-Passphrase
challenge, credentials)Security-Context
(Remote-Passphrase
challenge, credentials)Session-Key
(Remote-Passphrase
challenge)sid
sr
State
(Remote-Passphrase
challenge, credentials)t
ticket
(AdobeAuth
challenge)Timestamp
(Remote-Passphrase
challenge)token
(Token
credentials)ttl
uri
(Digest credentials)user-auth
(SFLY
credentials)userhash
username
(Digest credentials, Remote-Passphrase
credentials)[8] RFC 1945 と RFC 2068 では ABNF 構文上 realm
引数は
auth-param
に含まれないことになっていました。 RFC 2069 と
RFC 2617 と RFC 7235 では realm
も auth-param
の部分に含まれています。
[74] >>73 に SIP に関する IANA登録簿があります。
[88] >>87 に vapid
に関するIANA登録簿があります。
[72] JSON 形式の一覧データファイルが >>71 にあります。
[79] Authentication-Info:
や Proxy-Authentication-Info:
で用いられるものについては、そちらの項を参照。