[4] auth-scheme
は、 HTTP や派生プロトコルにおいて認証に用いる仕組み、あるいは仕組みを表す文字列です。
[9] auth-scheme
は HTTP の token
とされています >>7, >>11, >>13, >>15。
[10] auth-scheme
は大文字・小文字不区別です >>7, >>11, >>13, >>15。
[53] 現実には、特定の大文字・小文字の組み合わせしか受け付けない杜撰な実装もあります。
[25] auth-scheme
が使われる challenge や credentials
では、 auth-param
のリスト (#
)
または token68
を添えて指定できます。これらは
chalenge や credentials における auth-scheme
依存の追加情報を表しています。
[27] 各 auth-scheme
におけるこれらの値の構文と処理方法については、
それぞれの項および auth-param
を参照してください。
[8] auth-scheme
の値は、 HTTP の challenge、
credentials の中で認証の方式を表すために使われます。
[5] auth-scheme
の値は、 CGI のメタ変数
AUTH_TYPE
の値としても使われます。
[28] 認証方式は一般に起源鯖での認証にも串での認証にも使えます。 各認証方式はそれぞれの場面で使えるかを明記する必要がある >>19 とされています。
[29] HTTP では認証方式は特に限定されておらず、 IANA登録簿に新規に登録もできるようになっています。
[32] RTSP は HTTP に定義を委ねていますが、 Basic
と Digest
の実装を推奨しています >>31。
[30] SIP はIANA登録簿がなかった時代の HTTP から派生したためか、
そのようには明記されていません。また Digest
には対応することが求められていますが、 Basic
の実装は禁止されています。旧版では pgp
が定義されていましたが、後に削除されています。
[51] auth-scheme
の値は、 Authentication-Control:
ヘッダーでも使われます。
[20] HTTP認証は状態を持ちません。 認証に必要な情報は、すべて要求に含めなければなりません。 >>19
[21] HTTP接続に基いていたり、束縛されていたりする認証は、 HTTP の仕様の範囲外とされており、認証された利用者以外が当該 HTTP接続を使えないことを保証できない限り、欠陥を持っています。 >>19
[39] JSON 形式の auth-scheme
および
auth-param
の一覧が >>40 にあります。
[49] RFC 7804 は SCRAM-
から始まる命名規則を定義していますが、
特にこの名前を予約しているわけではなく、命名規則に従っていても
IANA登録簿に通常の規則により登録することを求めています。
[42] Webブラウザーは、Web互換性のため、次の認証方式に対応する必要があります。
[41] OAuth 2.0 では、要求におけるアクセストークンの送信や応答における認証エラーの通知に、 専用または兼用の HTTP認証方式を使うことができるとしています。そのような認証方式に対して若干の制約も課しています。 アクセストークン型と認証方式名は揃えることが推奨されています。
[3] HTTP/1.1 WWW-Authenticate header ( 版) http://www.http-stats.com/WWW-Authenticate
[16] auth-param
も参照。
[14] draft-stecher-icap-subid-00 - ICAP Extensions ( ( 版)) http://tools.ietf.org/html/draft-stecher-icap-subid-00#section-3.4
[36] >>35 は類似した一連の認証方式について RA-
から始まる auth-scheme
の命名規則を提案していました。
また >>38 は SCRAM-
から始まる命名規則を提案していました。
しかしいずれも支持を集められなかったようです。
[55] RFC 3050 - Common Gateway Interface for SIP, , https://tools.ietf.org/html/rfc3050#section-5.5.1.1