[要約] RFC 8053は、インタラクティブクライアント向けのHTTP認証拡張に関する仕様です。このRFCの目的は、ユーザーがHTTP認証をより簡単かつ安全に行えるようにすることです。
Internet Engineering Task Force (IETF) Y. Oiwa
Request for Comments: 8053 H. Watanabe
Category: Experimental H. Takagi
ISSN: 2070-1721 ITRI, AIST
K. Maeda
T. Hayashi
Lepidum
Y. Ioku
Individual Contributor
January 2017
HTTP Authentication Extensions for Interactive Clients
インタラクティブクライアント用のHTTP認証拡張機能
Abstract
概要
This document specifies extensions for the HTTP authentication framework for interactive clients. Currently, fundamental features of HTTP-level authentication are insufficient for complex requirements of various Web-based applications. This forces these applications to implement their own authentication frameworks by means such as HTML forms, which becomes one of the hurdles against introducing secure authentication mechanisms handled jointly by servers and user agents. The extended framework fills gaps between Web application requirements and HTTP authentication provisions to solve the above problems, while maintaining compatibility with existing Web and non-Web uses of HTTP authentication.
このドキュメントでは、インタラクティブクライアント用のHTTP認証フレームワークの拡張について説明します。現在、HTTPレベル認証の基本的な機能は、さまざまなWebベースのアプリケーションの複雑な要件には不十分です。これにより、これらのアプリケーションはHTMLフォームなどの手段で独自の認証フレームワークを実装する必要があり、サーバーとユーザーエージェントによって共同で処理される安全な認証メカニズムを導入することに対するハードルの1つになります。拡張フレームワークは、既存のWebおよびWeb以外のHTTP認証の使用との互換性を維持しながら、Webアプリケーションの要件とHTTP認証の準備の間のギャップを埋め、上記の問題を解決します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントでは、インターネットコミュニティの実験プロトコルを定義します。このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8053.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8053で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Terms for Describing Authentication Protocol Flow . . . . 5
2.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 8
3. Optional Authentication . . . . . . . . . . . . . . . . . . . 8
3.1. Note on Optional-WWW-Authenticate and Use of
WWW-Authenticate Header with Non-401 Status . . . . . . . 10
4. Authentication-Control Header . . . . . . . . . . . . . . . . 11
4.1. Non-ASCII Extended Header Parameters . . . . . . . . . . 13
4.2. Auth-Style Parameter . . . . . . . . . . . . . . . . . . 13
4.3. Location-When-Unauthenticated Parameter . . . . . . . . . 14
4.4. No-Auth Parameter . . . . . . . . . . . . . . . . . . . . 15
4.5. Location-When-Logout Parameter . . . . . . . . . . . . . 16
4.6. Logout-Timeout Parameter . . . . . . . . . . . . . . . . 17
4.7. Username Parameter . . . . . . . . . . . . . . . . . . . 17
5. Usage Examples . . . . . . . . . . . . . . . . . . . . . . . 18
5.1. Example 1: A Portal Site . . . . . . . . . . . . . . . . 19
5.1.1. Case 1: A Simple Application . . . . . . . . . . . . 19
5.1.2. Case 2: Specific Action Required on Logout . . . . . 20
5.1.3. Case 3: Specific Page Displayed before Login . . . . 20
5.2. Example 2: Authenticated User-Only Sites . . . . . . . . 20
5.3. When to Use Cookies . . . . . . . . . . . . . . . . . . . 21
5.4. Parallel Deployment with Form/Cookie Authentication . . . 22
6. Methods to Extend This Protocol . . . . . . . . . . . . . . . 23
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
8. Security Considerations . . . . . . . . . . . . . . . . . . . 24
8.1. Security Implication of the Username Parameter . . . . . 24
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
9.1. Normative References . . . . . . . . . . . . . . . . . . 25
9.2. Informative References . . . . . . . . . . . . . . . . . 26
Appendix A. (Informative) Applicability of Features for Each
Message . . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
This document defines several extensions to the current HTTP authentication framework, to provide functionality comparable with current, widely used, form-based Web authentication. A majority of the recent websites on the Internet use custom application-layer authentication implementations using Web forms. The reasons for these may vary, but many people believe that the current HTTP Basic and Digest authentication methods do not have enough functionality (including good user interfaces) to support most realistic Web-based applications. However, such use of form-based Web authentication has several weaknesses against attacks like phishing, because all behavior of the authentication is controlled from the server-side application. This makes it really hard to implement any cryptographically strong authentication mechanisms into Web systems. To overcome this problem, we need to "modernize" the HTTP authentication framework so that better client-controlled secure methods can be used with Web applications. The extensions proposed in this document include:
このドキュメントでは、現在のHTTP認証フレームワークに対するいくつかの拡張機能を定義し、現在広く使用されているフォームベースのWeb認証と同等の機能を提供します。最近のインターネット上のWebサイトの大部分は、Webフォームを使用したカスタムアプリケーション層認証実装を使用しています。これらの理由はさまざまですが、多くの人々は、現在のHTTP BasicおよびDigest認証方法には、最も現実的なWebベースのアプリケーションをサポートするための十分な機能（優れたユーザーインターフェイスを含む）がないと考えています。ただし、このようなフォームベースのWeb認証の使用には、認証のすべての動作がサーバー側アプリケーションから制御されるため、フィッシングなどの攻撃に対していくつかの弱点があります。これにより、暗号化された強力な認証メカニズムをWebシステムに実装することが非常に困難になります。この問題を克服するには、HTTP認証フレームワークを「近代化」して、クライアント制御の安全な方法をWebアプリケーションで使用できるようにする必要があります。このドキュメントで提案されている拡張機能は次のとおりです。
o optional authentication on HTTP (Section 3),
o HTTPでのオプションの認証（セクション3）、
o log out from both the server and client side (Section 4), and
o サーバー側とクライアント側の両方からログアウトします（セクション4）。
o finer control for redirection depending on the authentication status (Section 4)
o 認証ステータスに応じたリダイレクトの詳細な制御（セクション4）
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこの文書の "は、[RFC2119]で説明されているように解釈されます。
This document distinguishes the terms "client" and "user" in the following way: a "client" is an entity understanding and talking HTTP and the specified authentication protocol, usually computer software; a "user" is a (usually natural) person who wants to access data resources using "a client".
このドキュメントでは、「クライアント」と「ユーザー」という用語を次のように区別しています。「クライアント」とは、HTTPおよび指定された認証プロトコル（通常はコンピュータソフトウェア）を理解し、話し合うエンティティです。 「ユーザー」は、「クライアント」を使用してデータリソースにアクセスすることを希望する（通常は自然な）人です。
HTTP Authentication defined in [RFC7235] can involve several pairs of HTTP requests/responses. Throughout this document, the following terms are used to categorize those messages.
[RFC7235]で定義されたHTTP認証には、HTTP要求/応答の複数のペアが含まれる場合があります。このドキュメントでは、次の用語を使用してこれらのメッセージを分類しています。
For requests:
リクエストの場合：
1) A non-authenticating request is a request not attempting any authentication: a request without any Authorization header field.
1）非認証要求は、認証を試みない要求です。Authorizationヘッダーフィールドのない要求です。
2) An authenticating request is the opposite: a request with an Authorization header field.
2）認証要求はその逆です：Authorizationヘッダーフィールドを持つ要求。
For responses:
回答の場合：
1) A non-authenticated response is a response that does not involve any HTTP authentication. It does not contain any WWW-Authenticate ([RFC7235]) or Authentication-Info header field ([RFC7615]).
1）非認証応答は、HTTP認証を含まない応答です。 WWW-Authenticate（[RFC7235]）またはAuthentication-Infoヘッダーフィールド（[RFC7615]）は含まれていません。
Servers send this response when the requested resource is not protected by an HTTP authentication mechanism. In the context of this specification, non-authentication-related negative responses (e.g., 403 and 404) are also considered non-authenticated responses.
要求されたリソースがHTTP認証メカニズムによって保護されていない場合、サーバーはこの応答を送信します。この仕様の文脈では、非認証関連の否定応答（403や404など）も非認証応答と見なされます。
(See the note on successfully authenticated responses below for some ambiguous cases.)
（あいまいなケースについては、以下の正常に認証された応答に関する注記を参照してください。）
2) An authentication-initializing response is a response that requires or allows clients to start authentication attempts. Servers send this response when the requested resource is protected by an HTTP authentication mechanism, and the request meets one of the following cases:
2）認証初期化応答は、クライアントが認証試行を開始することを要求または許可する応答です。サーバーは、要求されたリソースがHTTP認証メカニズムによって保護されており、要求が次のいずれかの場合にこの応答を送信します。
* The request is a non-authenticating request, or
* リクエストが非認証リクエストである、または
* The request contained an authentication trial directed to a protection space (realm) other than the one that the server expected.
* リクエストには、サーバーが予期したもの以外の保護スペース（レルム）に向けられた認証トライアルが含まれていました。
The server will specify the protection space for authentication in this response.
サーバーは、この応答で認証用の保護スペースを指定します。
Upon receiving this response, the client's behavior is further divided to two possible cases:
この応答を受け取ると、クライアントの動作はさらに次の2つの場合に分けられます。
* If the client has no prior knowledge on authentication credentials (e.g., a username and a password) related to the requested protection space, the protocol flow terminates and the client will ask the user to provide authentication credentials.
* クライアントが、要求された保護スペースに関連する認証資格情報（ユーザー名やパスワードなど）を事前に認識していない場合、プロトコルフローは終了し、クライアントはユーザーに認証資格情報を提供するように求めます。
* On the other hand, if the client already has enough authentication credentials to the requested protection space, the client will automatically send an authenticating request. Such cases often occur when the client does not know beforehand that the current request-URL requires authentication.
* 一方、要求された保護スペースに対して十分な認証資格情報がクライアントに既にある場合、クライアントは自動的に認証要求を送信します。このようなケースは、現在のリクエストURLに認証が必要であることをクライアントが事前に知らない場合によく発生します。
3) A successfully authenticated response is a response for an authenticating request meaning that the authentication attempt was granted. (Note: if the authentication scheme used does not use an Authentication-Info header field, it can't be distinguished from a non-authenticated response.)
3）正常に認証された応答は、認証要求に対する応答であり、認証の試行が許可されたことを意味します。 （注：使用する認証方式がAuthentication-Infoヘッダーフィールドを使用しない場合、認証されていない応答と区別できません。）
4) An intermediate authenticating response is a response for an authenticating request that requires more reaction by the client software without involving users. Such a response is required when an authentication scheme requires two or more round-trip messages to perform authentication, or when an authentication scheme uses some speculative short-cut method (such as uses of cached shared secrets) and it fails.
4）中間認証応答は、ユーザーを関与させることなくクライアントソフトウェアによるより多くの反応を必要とする認証要求に対する応答です。このような応答は、認証スキームが認証を実行するために2つ以上の往復メッセージを必要とする場合、または認証スキームが投機的ショートカット方法（キャッシュされた共有シークレットの使用など）を使用して失敗した場合に必要です。
5) A negatively authenticated response is a response for an authenticating request, which means that the authentication attempt was declined and cannot continue without a different set of authentication credentials. Clients typically erase the memory of the active credentials and ask the user for other ones.
5）否定的に認証された応答は、認証要求に対する応答です。これは、認証の試行が拒否され、別の一連の認証資格情報がないと続行できないことを意味します。クライアントは通常、アクティブな資格情報のメモリを消去し、ユーザーに他の資格情報を要求します。
Usually the format of these responses is the same as the one for authentication-initializing responses. Clients can distinguish negatively authenticated responses from authentication-initializing responses by comparing the protection spaces contained in the request and in the response.
通常、これらの応答の形式は、認証初期化応答の形式と同じです。クライアントは、要求と応答に含まれる保護スペースを比較することにより、否定的に認証された応答と認証初期化応答を区別できます。
Figure 1 shows a state diagram of generic HTTP authentication with the above message categorization. Note that many authentication schemes use only a subset of the transitions described in the diagram. Labels in the figure show the abbreviated names of response types.
図1は、上記のメッセージ分類による一般的なHTTP認証の状態図を示しています。多くの認証スキームは、図に示されている遷移のサブセットのみを使用することに注意してください。図のラベルは、応答タイプの省略名を示しています。
=========== -----------------
NEW REQUEST ( UNAUTHENTICATED )
=========== -----------------
| ^ non-auth.
v | response
+----------------------+ NO +-------------+
| The requested URI |--------------------------->| send normal |
| known to be auth'ed? | ---------------->| request |
+----------------------+ / +-------------+
YES | / initializing|
v / |
+------------------+ NO / |
| Can auth-req.(*1)|--------- |
| be constructed? | |
+------------------+ |
YES | initializing |
| ---------------------------------------. |
| / v v
| | ---------------- NO +-----------+
| | ( AUTH-REQUESTED )<------| passwords |
| | ---------------- |etc. known?|
v | +-----------+
+-----------+ negative ------------- negative |YES
| send |---------->( AUTH-FAILED )<---------, |
/| auth-req | ------------- | |
/ +-----------+\ | v
| \ \ intermediate +-----------+
| \ -------------------------------->| send |
| \ | auth-req |
| non-auth. \successful successful +-----------+
| response (*2) \ / | ^
v \ / | |
----------------- \ -------------- / `----'
( UNAUTHENTICATED ) ----->( AUTH-SUCCEED )<---- intermediate
----------------- --------------
Figure 1: Generic State Diagram for HTTP Authentication
図1：HTTP認証の一般的な状態図
Notes: (*1) For example, the "Digest" scheme requires a server-provided nonce to construct client-side challenges. (*2) In "Basic" and some others, this cannot be distinguished from a successfully authenticated response.
注：（* 1）たとえば、「ダイジェスト」スキームでは、クライアント側のチャレンジを構築するためにサーバー提供のナンスが必要です。 （* 2）「ベーシック」などでは、認証成功と区別できません。
This specification uses an extended ABNF syntax defined in [RFC7230] and [RFC5234]. The following syntax definitions are quoted from [RFC7230] and [RFC7235]: auth-scheme, quoted-string, auth-param, SP, BWS, header-field, and challenge. It also uses the convention of using header field names for specifying the syntax of values for the header field.
この仕様は、[RFC7230]と[RFC5234]で定義されている拡張ABNF構文を使用します。次の構文定義は、[RFC7230]および[RFC7235]から引用されています：auth-scheme、quoted-string、auth-param、SP、BWS、header-field、およびchallenge。また、ヘッダーフィールドの値の構文を指定するためにヘッダーフィールド名を使用する規則を使用します。
Additionally, this specification uses the following syntax definitions as a refinement for token and the right-hand-side of auth-param in [RFC7235].
さらに、この仕様では、[RFC7235]のトークンとauth-paramの右側の改良として、次の構文定義を使用しています。
bare-token = bare-token-lead-char *bare-token-char
bare-token-lead-char = %x30-39 / %x41-5A / %x61-7A
bare-token-char = %x30-39 / %x41-5A / %x61-7A / "-" / "_"
extension-token = "-" bare-token 1*("." bare-token)
extensive-token = bare-token / extension-token
integer = "0" / (%x31-39 *%x30-39) ; no leading zeros
Figure 2: The BNF Syntax for Common Notations
図2：一般的な表記のBNF構文
Extensive-tokens are used in this protocol where the set of acceptable tokens includes private extensions. Any extensions of this protocol MAY use either bare-tokens allocated by IANA (under the procedure described in Section 7), or extension-tokens with the format "-<token>.<domain-name>", where <domain-name> is a valid (sub-)domain name on the Internet owned by the party who defines the extension.
このプロトコルでは拡張トークンが使用され、受け入れ可能なトークンのセットにプライベート拡張が含まれます。このプロトコルのすべての拡張は、IANAによって割り当てられたベアトークン（セクション7で説明されている手順の下）、または "-<token>。<domain-name>"という形式の拡張トークンを使用できます（ただし、<domain-name>）。拡張機能を定義する当事者が所有するインターネット上の有効な（サブ）ドメイン名です。
The Optional-WWW-Authenticate header enables a non-mandatory authentication, which is not possible under the current HTTP authentication mechanism.
Optional-WWW-Authenticateヘッダーは、必須の認証を有効にします。これは、現在のHTTP認証メカニズムでは不可能です。
In several Web applications, users can access the same contents as both a guest user and an authenticated user. In most Web applications, this functionality is implemented using HTTP cookies [RFC6265] and custom form-based authentication. The new authentication method using this message will provide a replacement for these authentication systems.
いくつかのWebアプリケーションでは、ユーザーはゲストユーザーと認証済みユーザーの両方として同じコンテンツにアクセスできます。ほとんどのWebアプリケーションでは、この機能はHTTP Cookie [RFC6265]とカスタムフォームベース認証を使用して実装されています。このメッセージを使用する新しい認証方法は、これらの認証システムの代わりを提供します。
Servers MAY send HTTP non-interim responses containing the Optional-WWW-Authenticate header as a replacement for a 401 response when it is authentication-initializing. The Optional-WWW-Authenticate header MUST NOT be sent on 401 responses (i.e., a usual WWW-Authenticate header MUST be used on 401 responses).
サーバーは、Authentication-initializingのときに、401応答の代わりにOptional-WWW-Authenticateヘッダーを含むHTTP非中間応答を送信する場合があります。 Optional-WWW-Authenticateヘッダーを401応答で送信してはなりません（つまり、通常のWWW-Authenticateヘッダーを401応答で使用する必要があります）。
Optional-WWW-Authenticate = 1#challenge
オプション-WWW-Authenticate = 1＃challenge
Figure 3: BNF Syntax for Optional-WWW-Authenticate Header
図3：Optional-WWW-AuthenticateヘッダーのBNF構文
Example: HTTP/1.1 200 OK Optional-WWW-Authenticate: Basic realm="xxxx"
例：HTTP / 1.1 200 OKオプション-WWW-Authenticate：Basic realm = "xxxx"
The challenges contained in the Optional-WWW-Authenticate header are the same as those for a 401 response corresponding to the same request. For authentication-related matters, an optional authentication request will have the same meaning as a 401 message with a corresponding WWW-Authenticate header (as an authentication-initializing response). (The behavior for other matters MAY be different between the optional authentication and 401 messages. For example, clients MAY choose to cache the 200 messages with the Optional-WWW-Authenticate header field but not the 401 messages by default.)
Optional-WWW-Authenticateヘッダーに含まれるチャレンジは、同じ要求に対応する401応答のチャレンジと同じです。認証関連の問題の場合、オプションの認証要求は、対応するWWW-Authenticateヘッダーが付いた401メッセージと同じ意味になります（認証初期化応答として）。 （他の問題の動作は、オプションの認証と401メッセージでは異なる場合があります。たとえば、クライアントは、オプションのWWW-Authenticateヘッダーフィールドで200メッセージをキャッシュすることを選択できますが、デフォルトでは401メッセージをキャッシュできません。）
A response with an Optional-WWW-Authenticate header SHOULD be returned from the server only when the request is either non-authenticated or authenticating to a wrong (not the server's expected) protection space. If a response is either an intermediate or a negative response to a client's authentication attempt, the server MUST respond with a 401 status response with a WWW-Authenticate header instead. Failure to comply with this rule will render clients unable to distinguish between authentication successes and failures.
Optional-WWW-Authenticateヘッダーを含む応答は、リクエストが認証されていないか、間違った（サーバーの予期しない）保護スペースに対して認証されている場合にのみサーバーから返される必要があります（SHOULD）。応答がクライアントの認証試行に対する中間応答または否定応答のいずれかである場合、サーバーは、代わりにWWW-Authenticateヘッダーを含む401ステータス応答で応答する必要があります。このルールに従わない場合、クライアントは認証の成功と失敗を区別できなくなります。
The server is NOT RECOMMENDED to include an Optional-WWW-Authenticate header in a positive response when a client's authentication attempt succeeds.
サーバーは、クライアントの認証試行が成功したときに、肯定応答にOptional-WWW-Authenticateヘッダーを含めることはお勧めしません。
Whenever an authentication scheme supports servers sending some parameter that gives a hint about the URL space for the corresponding protection space for the same realm (e.g., "path" or "domain"), servers requesting non-mandatory authentication SHOULD send such a parameter with the response. Clients supporting non-mandatory authentication MUST recognize the parameter and MUST send a request with an appropriate authentication credential in an Authorization header for any URI inside the specified paths.
認証スキームが、同じレルム（たとえば、「パス」または「ドメイン」）に対応する保護スペースのURLスペースについてのヒントを提供するパラメーターを送信するサーバーをサポートする場合は常に、非必須認証を要求するサーバーは、そのようなパラメーターを送信する必要があります（SHOULD）。応答。非必須認証をサポートするクライアントは、パラメータを認識しなければならず、指定されたパス内の任意のURIの承認ヘッダーに適切な認証資格情報を含むリクエストを送信する必要があります。
Implementations are not required to support this header for all of their supported authentication schemes (i.e., they may choose to implement it only for a subset of their supported schemes). New authentication schemes can require support of the optional authentication as a prerequisite, though.
実装は、サポートされているすべての認証スキームでこのヘッダーをサポートする必要はありません（つまり、サポートされているスキームのサブセットに対してのみ実装することを選択できます）。ただし、新しい認証スキームでは、前提条件としてオプションの認証のサポートが必要になる場合があります。
3.1. Note on Optional-WWW-Authenticate and Use of WWW-Authenticate Header with Non-401 Status
3.1. Optional-WWW-Authenticateと、401以外のステータスでのWWW-Authenticateヘッダーの使用に関する注意
In the current specification of HTTP/1.1, it is clarified that the WWW-Authenticate header can be used with messages with status codes other than 401 (Authentication Required). In particular, the use of the WWW-Authenticate header with the 200 status messages implies a very similar meaning to the above-defined Optional-WWW-Authenticate header.
現在のHTTP / 1.1の仕様では、WWW-Authenticateヘッダーを、401（認証が必要）以外のステータスコードのメッセージで使用できることが明記されています。特に、200ステータスメッセージでWWW-Authenticateヘッダーを使用することは、上記で定義されたOptional-WWW-Authenticateヘッダーと非常に類似した意味を意味します。
The design of Optional-WWW-Authenticate header expects that the use of a new header guarantees that clients that are unaware of this extension will ignore the header, and that Web developers can rely on that behavior to implement a secondary fallback method of authentication. Several behavioral requirements written in the above section also assume this property and define a necessary functionality to implement an optional authentication reliably and consistently.
Optional-WWW-Authenticateヘッダーの設計では、新しいヘッダーを使用すると、この拡張機能を認識していないクライアントがヘッダーを無視することが保証され、Web開発者はその動作に依存して認証のセカンダリフォールバック方法を実装できることが期待されます。上記のセクションで記述されたいくつかの動作要件もこのプロパティを想定し、オプションの認証を確実かつ一貫して実装するために必要な機能を定義します。
On the other hand, some experiments and discussions on the IETF mailing list revealed that most of (but not necessarily all of) the existing HTTP clients, at the time of writing, just ignore the WWW-Authenticate headers in non-401 messages, giving similar behavior with the Optional-WWW-Authenticate. However, every corner case of behavior was not fully tested or well-defined in the existing specifications.
一方、IETFメーリングリストでのいくつかの実験と議論により、既存のHTTPクライアントのほとんど（必ずしもすべてではない）は、執筆時点では、非401メッセージのWWW-Authenticateヘッダーを無視し、 Optional-WWW-Authenticateでの同様の動作。ただし、既存の仕様では、動作の隅々まで完全にテストされていないか、明確に定義されていません。
Considering these situations, the authors of this document chose to use a new header for a new feature "experiment". This is to avoid defining every corner-case behavior for the existing standard WWW-Authentication header in this experimental document, which could be considered by some implementers as an incompatible changes to existing specification.
これらの状況を考慮して、このドキュメントの作成者は、新しい機能「実験」に新しいヘッダーを使用することを選択しました。これは、この実験的なドキュメントで既存の標準のWWW-Authenticationヘッダーのあらゆるケースの動作を定義することを避けるためです。これは、一部の実装者が既存の仕様に対する互換性のない変更と見なす可能性があります。
Experimentally, the authors propose that implementers of the standard HTTP/1.1 specification (especially implementers of this extension) implement undefined (implementation-dependent) detailed handling of the WWW-Authenticate header with non-401 status messages similar as those defined above for the Optional-WWW-Authenticate header. For example, we propose that servers return the 401 status for failed authentication attempts, even when the unauthenticated request to the same resource will result in the 200 status. This can determine how (whether) non-mandatory authentication using the standard header fields and status codes can be implemented. If this experiment is successful, a future revision of this experimental document may "bless" and recommend the use of a standard WWW-Authenticate header, with some stricter requirements on some corner-case behavior.
実験的に、著者らは、標準のHTTP / 1.1仕様の実装者（特にこの拡張機能の実装者）が、オプションとして上記で定義したものと同様の非401ステータスメッセージを含むWWW-Authenticateヘッダーの未定義（実装依存）の詳細な処理を実装することを提案しています。 -WWW-Authenticateヘッダー。たとえば、同じリソースへの非認証リクエストが200ステータスになる場合でも、サーバーは認証試行の失敗に対して401ステータスを返すことを提案します。これにより、標準のヘッダーフィールドとステータスコードを使用した必須でない認証を実装する方法（かどうか）を決定できます。この実験が成功した場合、この実験的なドキュメントの将来の改訂版は「祝福」され、標準的なWWW-Authenticateヘッダーの使用を推奨する可能性があります。
Authentication-Control = 1#auth-control-entry
auth-control-entry = auth-scheme 1*SP 1#auth-control-param
auth-control-param = extensive-token BWS "=" BWS token
/ extensive-token "*" BWS "=" BWS ext-value
ext-value = <see RFC 5987, Section 3.2>
Figure 4: The BNF Syntax for the Authentication-Control Header
図4：Authentication-ControlヘッダーのBNF構文
The Authentication-Control header provides more precise control of the client behavior for Web applications using an HTTP authentication protocol. This header is supposed to be generated in the application layer, as opposed to the WWW-Authenticate headers, which will usually be generated by the Web servers.
Authentication-Controlヘッダーは、HTTP認証プロトコルを使用して、Webアプリケーションのクライアント動作をより正確に制御します。このヘッダーは、通常はWebサーバーによって生成されるWWW-Authenticateヘッダーとは対照的に、アプリケーション層で生成されることになっています。
Clients MAY freely choose any subset of these parameters to be supported. Also, these may choose to support any of the parameters for only a subset of their supported authentication schemes. However, authentication schemes can require/recommend support for some of these parameters as a prerequisite.
クライアントは、サポートされるこれらのパラメーターのサブセットを自由に選択できます（MAY）。また、これらは、サポートされている認証スキームのサブセットのみのパラメータをサポートすることを選択できます。ただし、認証スキームは、前提条件としてこれらのパラメータの一部のサポートを要求/推奨できます。
The Authentication-Control header contains one or more "authentication control entries", each of which corresponds to a single realm for a specific authentication scheme. If the auth-scheme specified for an entry supports the HTTP "realm" feature, that entry MUST contain the "realm" parameter. If not, the entry MUST NOT contain the "realm" parameter.
Authentication-Controlヘッダーには、1つ以上の「認証制御エントリ」が含まれています。各エントリは、特定の認証スキームの単一のレルムに対応しています。エントリに指定されたauth-schemeがHTTPの「レルム」機能をサポートしている場合、そのエントリには「レルム」パラメータが含まれている必要があります。そうでない場合、エントリに「レルム」パラメータを含めてはなりません（MUST NOT）。
Among the multiple entries in the header, the relevant entries in the header are those corresponding to an auth-scheme and a realm (if any) for which "the authentication process is being performed or going to be performed". In more detail:
ヘッダー内の複数のエントリの中で、ヘッダー内の関連するエントリは、「認証プロセスが実行されている、または実行されようとしている」auth-schemeおよびレルム（存在する場合）に対応するエントリです。さらに詳細に：
(1) If the response is either an authentication-initializing response or a negatively authenticated response, there can be multiple challenges in the WWW-Authenticate header (or the Optional-WWW-Authenticate header defined in this extension), each of which corresponds to a different scheme and realm. In this case, the client has a choice about the scheme and realm they will use to authenticate. Only the entry in the Authentication-Control header corresponding to that scheme and realm are relevant.
（1）応答が認証初期化応答または否定的に認証された応答のいずれかである場合、WWW-Authenticateヘッダー（またはこの拡張で定義されたOptional-WWW-Authenticateヘッダー）に複数のチャレンジが存在する可能性があります。別のスキームと領域。この場合、クライアントは認証に使用するスキームとレルムについて選択できます。そのスキームとレルムに対応するAuthentication-Controlヘッダーのエントリのみが関連します。
(2) If the response is either an intermediate authenticating response or a successfully authenticated response, the scheme and realm given in the Authorization header of the HTTP request will determine the currently ongoing authentication process. Only the entry corresponding to that scheme and realm are relevant.
（2）応答が中間認証応答または正常に認証された応答のいずれかである場合、HTTP要求のAuthorizationヘッダーで指定されたスキームとレルムが、現在進行中の認証プロセスを決定します。そのスキームとレルムに対応するエントリのみが関連します。
The server MAY send an Authentication-Control header containing non-relevant entries. The client MUST ignore all non-relevant entries it received.
サーバーは、無関係なエントリを含むAuthentication-Controlヘッダーを送信してもよい（MAY）。クライアントは、受信した無関係なエントリをすべて無視する必要があります。
Every entry contains one or more parameters, each of which is a name-value pair. The name of each parameter MUST be an extensive-token. Clients MUST ignore any unknown parameters contained in this header. The entries for the same auth-scheme and the realm MUST NOT contain duplicated parameters for the same name. Clients MAY either take any one of those duplicated entries or ignore all of them.
すべてのエントリには1つ以上のパラメータが含まれており、各パラメータは名前と値のペアです。各パラメーターの名前は、広範なトークンでなければなりません。クライアントは、このヘッダーに含まれる不明なパラメーターを無視する必要があります。同じauth-schemeとレルムのエントリには、同じ名前の重複したパラメーターを含めてはなりません（MUST NOT）。クライアントは、これらの重複したエントリのいずれか1つを取るか、それらのすべてを無視することができます。
The type of parameter value depends on the parameter name as defined in the following subsections. Regardless of the type, however, the recipients MUST accept both quoted and unquoted representations of values as defined in HTTP. If the parameter is defined to have a string value, implementations MUST send any value outside of the "token" ABNF syntax in either a quoted form or an ext-value form (see Section 4.1). If the parameter is defined as a token (or similar) or an integer, the value SHOULD follow the corresponding ABNF syntax after possible unquoting of the quoted-string value (as defined in HTTP) and MUST be sent in a plain (not an ext-value) form. (Note: the rest of this document will show all string-value parameters in quoted forms, and it will show others in unquoted forms.)
パラメーター値のタイプは、以下のサブセクションで定義されているパラメーター名によって異なります。ただし、タイプに関係なく、受信者は、HTTPで定義されているように、引用符付きと引用符なしの両方の値の表現を受け入れる必要があります。パラメータが文字列値を持つように定義されている場合、実装は、 "トークン" ABNF構文の外側にある値を、引用符付きの形式またはext-value形式で送信する必要があります（セクション4.1を参照）。パラメータがトークン（または類似のもの）または整数として定義されている場合、値は（HTTPで定義されているように）引用符付き文字列値の可能な引用符を外した後に対応するABNF構文に従い、プレーン（extではなく）で送信する必要があります（SHOULD）。 -value）フォーム。 （注：このドキュメントの残りの部分では、引用符付きの形式ですべての文字列値パラメーターを示し、引用符なしの形式で他のパラメーターを示します。）
Any parameters contained in this header MAY be ignored by clients. Also, even when a client accepts this header, users are able to circumvent the semantics of this header. Therefore, if this header is used for security purposes, its use MUST be limited to providing some non-fundamental additional security measures valuable for end-users (such as client-side logout for protection against console takeover). Server-side applications MUST NOT rely on the use of this header for protecting server-side resources.
このヘッダーに含まれるパラメータは、クライアントによって無視される場合があります。また、クライアントがこのヘッダーを受け入れる場合でも、ユーザーはこのヘッダーのセマンティクスを回避できます。したがって、このヘッダーをセキュリティの目的で使用する場合、その使用は、エンドユーザーにとって価値のあるいくつかの非基本的な追加のセキュリティ対策（コンソールの乗っ取りから保護するためのクライアント側のログアウトなど）の提供に限定する必要があります。サーバー側アプリケーションは、サーバー側リソースを保護するためにこのヘッダーの使用に依存してはなりません（MUST NOT）。
Note: The header syntax allows servers to specify Authentication-Control for multiple authentication schemes, either as multiple occurrences of this header or as a combined single header (see Section 3.2.2 of [RFC7230] for rationale). The same care as for parsing multiple authentication challenges needs to be taken.
注：ヘッダー構文を使用すると、サーバーは、このヘッダーの複数のオカレンスとして、または単一のヘッダーの組み合わせとして、複数の認証スキームのAuthentication-Controlを指定できます（根拠については、[RFC7230]のセクション3.2.2を参照してください）。複数の認証チャレンジを解析する場合と同じ注意を払う必要があります。
Parameters contained in the Authentication-Control header MAY be extended to non-ASCII values using the framework described in [RFC5987]. All servers and clients MUST be capable of receiving and sending values encoded in [RFC5987] syntax.
[RFC5987]で説明されているフレームワークを使用して、Authentication-Controlヘッダーに含まれるパラメーターを非ASCII値に拡張できます（MAY）。すべてのサーバーとクライアントは、[RFC5987]構文でエンコードされた値を送受信できる必要があります。
If a value to be sent contains only ASCII characters, the field MUST be sent using plain RFC 7235 syntax. The syntax as extended by ext-value MUST NOT be used in this case.
送信する値にASCII文字のみが含まれる場合、フィールドはプレーンなRFC 7235構文を使用して送信する必要があります。この場合、ext-valueによって拡張された構文を使用してはなりません（MUST NOT）。
If a value (except the "realm" header) contains one or more non-ASCII characters, the parameter SHOULD be sent using the ext-value syntax defined in Section 3.2 of [RFC5987]. Such a parameter MUST have a charset value of "UTF-8", and the language value MUST always be omitted (have an empty value). The same parameter MUST NOT be sent more than once, regardless of the syntax used.
値（「レルム」ヘッダーを除く）に1つ以上の非ASCII文字が含まれている場合、[RFC5987]のセクション3.2で定義されているext-value構文を使用してパラメーターを送信する必要があります（SHOULD）。そのようなパラメーターは「UTF-8」の文字セット値を持たなければならず（MUST）、言語値は常に省略されなければなりません（空の値を持っています）。使用される構文に関係なく、同じパラメーターを複数回送信してはなりません（MUST NOT）。
For example, a parameter "username" with the value "Renee of France" SHOULD be sent as < username="Renee of France" >. If the value is "Ren<e acute>e of France", it SHOULD be sent as < username*=UTF-8''Ren%C3%89e%20of%20France > instead.
たとえば、値が「Renee of France」のパラメータ「username」は、<username = "Renee of France">として送信する必要があります。値が「Ren <e急性> e of France」の場合、代わりに<username * = UTF-8''Ren％C3％89e％20of％20France>として送信する必要があります。
Interoperability note: [RFC7235], Section 2.2, defines the "realm" authentication parameter that cannot be replaced by the "realm*" extend parameter. This means that the use of non-ASCII values for an authentication realm is not the defined behavior in HTTP. Unfortunately, some people currently use a non-ASCII realm parameter in reality, but even its encoding scheme is not well defined. Given this background, this document does not specify how to handle a non-ASCII "realm" parameter in the extended header fields. If needed, the authors propose using a non-extended "realm" parameter form, with a wish for maximum interoperability.
相互運用性に関する注記：[RFC7235]のセクション2.2では、「realm *」拡張パラメーターで置き換えることができない「realm」認証パラメーターを定義しています。つまり、認証レルムに非ASCII値を使用することは、HTTPで定義されている動作ではありません。残念ながら、一部の人々は現在、非ASCIIレルムパラメータを実際に使用していますが、そのエンコーディングスキームでさえも明確に定義されていません。このような背景があるため、このドキュメントでは、拡張ヘッダーフィールドで非ASCIIの「レルム」パラメータを処理する方法を指定していません。必要に応じて、最大の相互運用性を望んで、拡張されていない「レルム」パラメーター形式の使用を提案します。
Example: Authentication-Control: Digest realm="protected space", auth-style=modal
例：Authentication-Control：Digest realm = "protected space"、auth-style = modal
The parameter "auth-style" specifies the server's preference for user interface behavior for user authentication. This parameter can be included in any kind of response; however, it is only meaningful for either authentication-initializing or negatively authenticated responses. The value of this parameter MUST be one of the bare-tokens, "modal" or "non-modal". When the Optional-WWW-Authenticate header is used, the value of this parameter MUST be disregarded and the value "non-modal" is implied.
パラメータ「auth-style」は、ユーザー認証のユーザーインターフェース動作に対するサーバーの設定を指定します。このパラメーターは、あらゆる種類の応答に含めることができます。ただし、これは、認証初期化応答または否定的に認証された応答のいずれかに対してのみ意味があります。このパラメーターの値は、「モーダル」または「非モーダル」のベアトークンのいずれかである必要があります。 Optional-WWW-Authenticateヘッダーを使用する場合、このパラメーターの値は無視する必要があり、値 "non-modal"が暗黙指定されます。
The value "modal" means that the server thinks the content of the response (body and other content-related headers) is valuable only for users refusing the authentication request. The clients are expected to ask the user for a password before processing the content. This behavior is common for most of the current implementations of Basic and Digest authentication schemes.
値「モーダル」は、サーバーが応答のコンテンツ（本文およびその他のコンテンツ関連のヘッダー）は、ユーザーが認証要求を拒否する場合にのみ価値があると考えることを意味します。クライアントは、コンテンツを処理する前にユーザーにパスワードを要求する必要があります。この動作は、基本認証方式とダイジェスト認証方式の現在の実装のほとんどに共通しています。
The value "non-modal" means that the server thinks that the content of the response (body and other content-related headers) is valuable for users before processing an authentication request. The clients are expected to first process the content and then provide users with the opportunity to perform authentication.
「non-modal」という値は、サーバーが、認証要求を処理する前に、応答のコンテンツ（本文およびその他のコンテンツ関連ヘッダー）がユーザーにとって価値があると考えていることを意味します。クライアントは最初にコンテンツを処理し、次にユーザーに認証を実行する機会を提供することが期待されています。
The default behavior for clients is implementation dependent, and it may also depend on authentication schemes. The proposed default behavior is "modal" for all authentication schemes unless otherwise specified.
クライアントのデフォルトの動作は実装に依存し、認証スキームにも依存する場合があります。提案されたデフォルトの動作は、特に指定がない限り、すべての認証スキームで「モーダル」です。
The above two different methods of authentication possibly introduce an observable difference of semantics when the response contains state-changing side effects; for example, it can affect how Cookie headers [RFC6265] in 401 responses are processed. However, the server applications SHOULD NOT depend on the existence of such side effects.
上記の2つの異なる認証方法では、応答に状態変化の副作用が含まれている場合に、セマンティクスに観察可能な違いが生じる可能性があります。たとえば、401応答のCookieヘッダー[RFC6265]の処理方法に影響を与える可能性があります。ただし、サーバーアプリケーションは、そのような副作用の存在に依存するべきではありません。
Example:
Authentication-Control: Mutual realm="auth-space-1",
location-when-unauthenticated="http://www.example.com/login.html"
The parameter "location-when-unauthenticated" specifies a location to which any unauthenticated clients should be redirected. This header can be used, for example, when there is a central login page for the entire Web application. The value of this parameter is a string that contains a URL location. If a received URL is not absolute, the clients SHOULD consider it a relative URL from the current location.
パラメータ「location-when-unauthenticated」は、認証されていないクライアントをリダイレクトする場所を指定します。このヘッダーは、たとえば、Webアプリケーション全体の中央ログインページがある場合に使用できます。このパラメーターの値は、URLロケーションを含むストリングです。受信したURLが絶対ではない場合、クライアントはそれを現在の場所からの相対URLと見なすべきです。
This parameter MAY be used with a 401 response for an authentication-initializing response. It can also be contained, although this is NOT RECOMMENDED, in a positive response with an Optional-WWW-Authenticate header. The clients MUST ignore this parameter when a response is either successfully authenticated or intermediately authenticated.
このパラメータは、認証初期化応答の401応答で使用される場合があります。これは推奨できませんが、Optional-WWW-Authenticateヘッダーを含む肯定応答に含めることもできます。応答の認証が成功したか、中間的に認証された場合、クライアントはこのパラメーターを無視する必要があります。
When a client receives an authentication-initiating response with this parameter, and if the client has to ask users for authentication credentials, the client will treat the entire response as if it were a 303 "See Other" response with a Location header that contains the value of this parameter (i.e., the client will be redirected to the specified location with a GET request). Unlike a normal 303 response, if the client can process authentication without the user's interaction, this parameter MUST be ignored.
クライアントがこのパラメーターで認証開始応答を受信し、クライアントがユーザーに認証資格情報を要求する必要がある場合、クライアントは応答全体を、それを含むLocationヘッダーを持つ303 "See Other"応答であるかのように扱います。このパラメータの値（つまり、クライアントはGETリクエストで指定された場所にリダイレクトされます）。通常の303応答とは異なり、クライアントがユーザーの操作なしで認証を処理できる場合、このパラメーターは無視する必要があります。
Example:
Authentication-Control: Basic realm="entrance", no-auth=true
The parameter "no-auth" is a variant of the location-when-unauthenticated parameter; it specifies that new authentication attempts are not to be performed on this location in order to improve the user experience, without specifying the redirection on the HTTP level. This header can be used, for example, when there is a central login page for the entire Web application and when an explicit user interaction with the Web content is desired before authentication. The value of this parameter MUST be a token "true". If the value is incorrect, the client MAY ignore this parameter.
パラメータ「no-auth」は、location-when-authenticatedパラメータのバリアントです。これは、HTTPレベルでリダイレクトを指定せずに、ユーザーエクスペリエンスを向上させるために、この場所で新しい認証試行を実行しないことを指定します。このヘッダーは、たとえば、Webアプリケーション全体の中央ログインページがあり、認証の前にWebコンテンツとの明示的なユーザーインタラクションが必要な場合に使用できます。このパラメーターの値は、トークン「true」でなければなりません。値が正しくない場合、クライアントはこのパラメーターを無視してもよい（MAY）。
This parameter MAY be used with authentication-initiating responses. It can also be contained, although this is NOT RECOMMENDED, in a positive response with an Optional-WWW-Authenticate header. The clients MUST ignore this parameter when a response is either successfully authenticated or intermediately authenticated.
このパラメータは、認証開始応答で使用される場合があります。これは推奨できませんが、Optional-WWW-Authenticateヘッダーを含む肯定応答に含めることもできます。応答の認証が成功したか、中間的に認証された場合、クライアントはこのパラメーターを無視する必要があります。
When a client receives an authentication-initiating response with this parameter, if the client has to ask users for authentication credentials, the client will ignore the WWW-Authenticate header contained in the response and treat the whole response as a normal negative 4xx-class response instead of giving the user an opportunity to start authentication. If the client can process authentication without the user's interaction, this parameter MUST be ignored.
クライアントがこのパラメーターを使用して認証開始応答を受信すると、クライアントがユーザーに認証資格情報を要求する必要がある場合、クライアントは応答に含まれるWWW-Authenticateヘッダーを無視し、応答全体を通常の負の4xxクラス応答として扱います。ユーザーに認証を開始する機会を与える代わりに。クライアントがユーザーの操作なしで認証を処理できる場合、このパラメーターは無視する必要があります。
Using this parameter along with the location-when-unauthenticated parameter is meaningless. If both were supplied, clients SHOULD ignore the location-when-unauthenticated parameter.
このパラメーターをlocation-when-authenticatedパラメーターと一緒に使用しても意味がありません。両方が提供された場合、クライアントはlocation-when-unauthenticatedパラメーターを無視する必要があります（SHOULD）。
This parameter SHOULD NOT be used as a security measure to prevent authentication attempts, as it is easily circumvented by users. This parameter SHOULD be used solely for improving the user experience of Web applications.
このパラメーターは、ユーザーが簡単に回避できるため、認証の試みを防ぐためのセキュリティ対策として使用してはなりません（SHOULD NOT）。このパラメーターは、Webアプリケーションのユーザーエクスペリエンスを向上させるためにのみ使用する必要があります（SHOULD）。
Example:
Authentication-Control: Digest realm="protected space",
location-when-logout="http://www.example.com/byebye.html"
The parameter "location-when-logout" specifies a location where the client is to be redirected when the user explicitly requests a logout. The value of this parameter MUST be a string that contains a URL location. If a given URL is not absolute, the clients MUST consider it a relative URL from the current location.
「location-when-logout」パラメーターは、ユーザーが明示的にログアウトを要求したときにクライアントがリダイレクトされる場所を指定します。このパラメーターの値は、URLの場所を含む文字列でなければなりません。指定されたURLが絶対URLではない場合、クライアントはそれを現在の場所からの相対URLと見なす必要があります。
This parameter MAY be used with successfully authenticated responses. If this parameter is contained in other kinds of responses, the clients MUST ignore this parameter.
このパラメータは、認証に成功した応答で使用される場合があります。このパラメーターが他の種類の応答に含まれている場合、クライアントはこのパラメーターを無視する必要があります。
When the user tells the client to terminate the current authentication period, if the client currently displays a page supplied by a response with this parameter, the client will automatically change the current location to the location specified in this parameter using a new GET request, as if it has received a 303 response. Any operations related to logout (e.g., erasing memories of username, authentication credential, and all related one-time credentials such as nonce or keys) SHOULD occur before processing a page transition.
ユーザーがクライアントに現在の認証期間を終了するように指示すると、クライアントが現在このパラメーターを使用した応答によって提供されるページを表示している場合、クライアントは新しいGET要求を使用して現在の場所をこのパラメーターで指定された場所に自動的に変更します。 303応答を受け取った場合。ログアウトに関連する操作（たとえば、ユーザー名、認証資格情報、およびnonceやキーなどの関連するすべてのワンタイム資格情報のメモリの消去）は、ページ遷移を処理する前に発生する必要があります。
When the user requests the client for the termination of an authentication period, if the client supports this parameter but the server response does not contain this parameter, the client's RECOMMENDED behavior is as follows: if the request corresponding to the current content was the GET method, reload the page without the authentication credential. Otherwise, keep the current content as-is and simply forget the authentication status. The client SHOULD NOT replay a non-idempotent request without the user's explicit approval.
ユーザーがクライアントに認証期間の終了を要求したときに、クライアントがこのパラメーターをサポートしているが、サーバーの応答にこのパラメーターが含まれていない場合、クライアントの推奨される動作は次のとおりです。現在のコンテンツに対応する要求がGETメソッドの場合、認証情報なしでページをリロードします。それ以外の場合は、現在のコンテンツをそのままにして、認証ステータスを忘れてください。クライアントは、ユーザーの明示的な承認なしに、べき等ではないリクエストを再生すべきではありません。
Web applications are encouraged to send this parameter with an appropriate value for any responses (except those with redirection (3XX) statuses) for non-GET requests.
Webアプリケーションでは、GET以外の要求の応答（リダイレクト（3XX）ステータスの応答を除く）に適切な値を指定して、このパラメーターを送信することをお勧めします。
See Section 5 for some examples for possible deployment of this parameter.
このパラメーターの可能な展開の例については、セクション5を参照してください。
Example:
Authentication-Control: Basic realm="entrance", logout-timeout=300
The parameter "logout-timeout", when contained in a successfully authenticated response, means that any authentication credentials and state related to the current protection space are to be discarded if the time specified in this header (in seconds) has passed since the time this header was received. The value MUST be an integer. As a special case, the value 0 means that the server is logging the client out immediately from the current authentication space and that the client is now returned to the unauthenticated state. This does not, however, mean that the long-term memories for the passwords and passwords-related details (such as password reminders and auto fill-ins) should be removed. If a new timeout value is received for the same authentication space, it cancels the previous timeout and sets a new timeout.
「logout-timeout」パラメーターは、正常に認証された応答に含まれる場合、このヘッダーで指定された時間が（秒単位で）指定された時間が経過してから現在の保護スペースに関連する認証資格情報と状態が破棄されることを意味しますヘッダーを受信しました。値は整数でなければなりません。特殊なケースとして、値0は、サーバーがクライアントを現在の認証スペースからすぐにログアウトし、クライアントが未認証の状態に戻ることを意味します。ただし、これは、パスワードおよびパスワード関連の詳細（パスワードのリマインダーや自動入力など）の長期的な記憶を削除する必要があることを意味するものではありません。同じ認証スペースに対して新しいタイムアウト値が受信されると、以前のタイムアウトがキャンセルされ、新しいタイムアウトが設定されます。
Example:
Authentication-Control: Basic realm="configuration", username="admin"
The parameter "username" tells us that the only "username" to be accepted by the server is the value given in this parameter.
パラメータ「username」は、サーバーが受け入れる唯一の「username」がこのパラメータで指定された値であることを示しています。
This parameter is particularly useful, for example, for routers and other network appliances with a Web configuration interface. Many of those use an HTTP Basic authentication with one predefined username, with many varieties such as "admin", "root", "user", etc. In the current situation, users have almost no hint about the valid username upon the authentication request. Some show the valid value in a "realm" string, some in the 401-status response page, shown _after_ the user gave up the authentication and canceled the authentication dialog. If this parameter is given, the client Web browser can auto-fill the username field in the authentication dialog before the users attempt to authenticate themselves.
このパラメーターは、例えば、Web構成インターフェースを備えたルーターやその他のネットワーク装置などで特に役立ちます。それらの多くは、「admin」、「root」、「user」など、さまざまな種類の1つの事前定義されたユーザー名でHTTP基本認証を使用します。現在の状況では、ユーザーは認証リクエストで有効なユーザー名についてほとんどヒントを知りません。一部は「レルム」文字列で有効な値を示し、一部は401ステータス応答ページで、ユーザーが認証をあきらめて認証ダイアログをキャンセルした後に表示されます。このパラメーターが指定されている場合、クライアントWebブラウザーは、ユーザーが自分自身を認証しようとする前に、認証ダイアログのユーザー名フィールドに自動入力できます。
This parameter MAY be used with authentication-initiating responses or negatively authenticated responses requiring another attempt at authentication. The clients MUST ignore this parameter when a response is either successfully authenticated or intermediately authenticated.
このパラメータは、認証を開始する応答、または認証の再試行を必要とする否定的に認証された応答で使用される場合があります。応答の認証が成功したか、中間的に認証された場合、クライアントはこのパラメーターを無視する必要があります。
If the authentication scheme to be used has a syntax limitation on the allowed usernames (e.g., Basic and Digest do not allow colons in usernames); the specified value MUST follow that limitation. Clients SHOULD ignore any values that do not conform to such limitations.
使用する認証スキームに許可されたユーザー名の構文制限がある場合（たとえば、BasicおよびDigestではユーザー名にコロンを使用できません）;指定された値はその制限に従う必要があります。クライアントは、そのような制限に適合しない値をすべて無視する必要があります（SHOULD）。
Also, if the used authentication scheme requires a specific style of text preparation for the username (e.g., PRECIS [RFC7564] string preparation or Unicode normalization), the server SHOULD send the values satisfying such requirements (so that clients can use the given username as is).
また、使用する認証方式でユーザー名に特定のスタイルのテキスト準備が必要な場合（たとえば、PRECIS [RFC7564]文字列準備またはUnicode正規化）、サーバーはそのような要件を満たす値を送信する必要があります（クライアントが指定のユーザー名をです）。
Clients MAY still send any authentication requests with other usernames, possibly in vain. Clients are not required (also not forbidden) to give users opportunities for supplying a username different from the server-specified one. Servers are also not strictly required to reject usernames other than specified, but doing so will usually result in bad user experiences and may confuse users and clients.
クライアントは、他のユーザー名を使用して認証要求を送信することができますが（おそらく無駄です）。クライアントは、サーバー指定のユーザー名とは異なるユーザー名を提供する機会をユーザーに提供する必要はありません（これも禁止されていません）。サーバーは、指定された以外のユーザー名を拒否することも厳密には必要ありませんが、拒否すると、通常、ユーザーエクスペリエンスが低下し、ユーザーとクライアントが混乱する可能性があります。
Although this parameter is useful in a specific class of use cases, using it in a general use case has many security implications and possible pitfalls. Please consult Section 8.1 before deciding to use this parameter.
このパラメーターは特定のクラスのユースケースで役立ちますが、一般的なユースケースでこのパラメーターを使用すると、セキュリティに多くの影響があり、問題が発生する可能性があります。このパラメーターの使用を決定する前に、セクション8.1を参照してください。
This section shows some examples for applying this extension to typical websites that use forms and cookies for managing authentication and authorization. The content of this section is not normative and is for illustrative purposes only.
このセクションでは、フォームとCookieを使用して認証と承認を管理する一般的なWebサイトにこの拡張機能を適用する例をいくつか示します。このセクションの内容は規範的ではなく、説明のみを目的としています。
In these examples, we assume that there are two kinds of clients (Web browsers). One kind of these implements all features described in the previous sections. We also assume that browsers will have a user interface that allows users to deactivate (log out from) current authentication sessions. The other kind are the "existing" implementations that do not support any of these features.
これらの例では、2種類のクライアント（Webブラウザー）があると想定しています。これらの1つの種類は、前のセクションで説明したすべての機能を実装します。また、ブラウザーには、ユーザーが現在の認証セッションを非アクティブ化（ログアウト）できるユーザーインターフェイスがあることも想定しています。もう1つの種類は、これらの機能のいずれもサポートしない「既存の」実装です。
When not explicitly specified, all settings described below are to be applied with Authentication-Control headers, and these can be sent to clients regardless of the authentication status (these will be silently ignored whenever not effective).
明示的に指定されていない場合、以下で説明するすべての設定はAuthentication-Controlヘッダーを使用して適用され、認証ステータスに関係なくクライアントに送信できます（これらは有効でない場合は通知なく無視されます）。
This subsection provides an example application for a site whose structure is somewhat similar to conventional portal sites. In particular, most Web pages are available for guest (unauthenticated) users, and, if authentication is performed, the content of these pages is customized for each user. We assume that the site has the following kinds of pages currently:
このサブセクションでは、構造が従来のポータルサイトにいくらか似ているサイトのサンプルアプリケーションを示します。特に、ほとんどのWebページはゲスト（認証されていない）ユーザーが使用でき、認証が実行されると、これらのページのコンテンツはユーザーごとにカスタマイズされます。現在、サイトには次の種類のページがあると想定しています。
o Content pages
o コンテンツページ
o Pages/mechanism for performing authentication:
o 認証を実行するためのページ/メカニズム：
* There is one page that asks for a username and a password using a HTML POST form.
* HTML POSTフォームを使用してユーザー名とパスワードを要求するページが1つあります。
* After the authentication attempt, the user will be redirected to either the page that was previously displayed before the authentication or some specific page.
* 認証の試行後、ユーザーは認証前に表示されていたページまたは特定のページにリダイレクトされます。
o A de-authentication (logout) page.
o 認証解除（ログアウト）ページ。
When such a site does not require specific actions upon login and logout, the following simple settings can be used:
このようなサイトがログインおよびログアウト時に特定のアクションを必要としない場合は、次の簡単な設定を使用できます。
o Set up an optional authentication to all pages available to guests. Set up an Authentication-Control header with the "auth-style=non-modal" setting.
o ゲストが利用できるすべてのページにオプションの認証を設定します。 「auth-style = non-modal」設定でAuthentication-Controlヘッダーを設定します。
o If there are pages only available to authenticated users, set up a mandatory authentication with the "auth-style=non-modal" setting.
o 認証されたユーザーのみが利用できるページがある場合は、「auth-style = non-modal」設定で必須認証を設定します。
o No specific pages for authentication are needed. It will be performed automatically, directed by the above setting.
o 認証のための特定のページは必要ありません。上記の設定により、自動的に実行されます。
o A de-authentication page is also not needed. If the site has one, put "logout-timeout=0" there.
o 認証解除ページも必要ありません。サイトにある場合は、そこに「logout-timeout = 0」と入力します。
o For all pages for POST requests, it is advisable to have a "location-when-logout=<some page>".
o POSTリクエストのすべてのページで、「location-when-logout = <some page>」を使用することをお勧めします。
If the site requires specific actions upon logout, the following settings can be used:
サイトでログアウト時に特定のアクションが必要な場合は、次の設定を使用できます。
o All settings in Case 1 are applied.
o ケース1のすべての設定が適用されます。
o For all pages, set up the Authentication-Control header "location-when-logout=<de-authentication page>".
o すべてのページで、Authentication-Controlヘッダー「location-when-logout = <de-authentication page>」を設定します。
o In the de-authentication page, no specific setup is needed. If there are any direct links to the de-authentication page, put "logout-timeout=0".
o 認証解除ページでは、特別な設定は必要ありません。認証解除ページへの直接リンクがある場合は、「logout-timeout = 0」と入力します。
If the site needs to display a specific page before login actions (some announcements, user notices, or even advertisements), the following settings can be applied:
ログインアクションの前にサイトが特定のページを表示する必要がある場合（アナウンス、ユーザー通知、さらには広告）、以下の設定を適用できます。
o Set up an optional authentication to all pages available to guests. Set up an Authentication-Control header with "no-auth=true". Put a link to a specific login page in contents.
o ゲストが利用できるすべてのページにオプションの認証を設定します。 "no-auth = true"を使用してAuthentication-Controlヘッダーを設定します。コンテンツに特定のログインページへのリンクを挿入します。
o If there are pages only available to authenticated users, set up a mandatory authentication with the "location-when-unauthenticated=<the login page>".
o 認証されたユーザーのみが使用できるページがある場合は、「location-when-unauthenticated = <ログインページ>」を使用して必須認証を設定します。
o For the specific login page, set up a mandatory authentication.
o 特定のログインページで、必須の認証を設定します。
o For all pages for POST requests, it is advisable to have "location-when-logout=<some page>", too.
o POSTリクエストのすべてのページで、 "location-when-logout = <some page>"も設定することをお勧めします。
o De-authentication pages are not needed. If the site has one, put "logout-timeout=0".
o 認証解除ページは必要ありません。サイトにある場合は、「logout-timeout = 0」と入力します。
If almost all pages in the target site require authentication (e.g., an Internet banking site), or if there is no need to support both unauthenticated and authenticated users on the same resource, the settings will become simpler. The following are examples for such a site:
ターゲットサイトのほとんどすべてのページで認証が必要な場合（インターネットバンキングサイトなど）、または同じリソースで認証されていないユーザーと認証されたユーザーの両方をサポートする必要がない場合は、設定が簡単になります。以下は、そのようなサイトの例です。
o Set up a mandatory authentication to all pages available to authenticated users. Set up an Authentication-Control header with the "auth-style=non-modal" setting.
o 認証されたユーザーが利用できるすべてのページに必須認証を設定します。 「auth-style = non-modal」設定でAuthentication-Controlヘッダーを設定します。
o Set up a handler for the 401-status that requests users to authenticate.
o ユーザーに認証を要求する401ステータスのハンドラを設定します。
o For all pages for POST requests, it is advisable to have a "location-when-logout=<some page>", too.
o POSTリクエストのすべてのページで、「location-when-logout = <some page>」も用意することをお勧めします。
o De-authentication pages are not needed. If the site will have one, put "logout-timeout=0" there.
o 認証解除ページは必要ありません。サイトにある場合は、そこに「logout-timeout = 0」を配置します。
In current websites using form-based authentication, Cookies [RFC6265] are used for managing both authorization and application sessions. Using the extensions in this document, the former features will be provided by using (extended) HTTP authentication/ authorization mechanisms. In some cases, there will be ambiguity on whether some functions are for authorization management or for session management. The following hints will be helpful for deciding which features to use.
フォームベースの認証を使用する現在のWebサイトでは、承認とアプリケーションセッションの両方を管理するためにCookie [RFC6265]が使用されています。このドキュメントの拡張機能を使用すると、以前の機能は（拡張された）HTTP認証/承認メカニズムを使用して提供されます。場合によっては、一部の機能が承認管理用かセッション管理用かが曖昧になります。次のヒントは、使用する機能を決定するのに役立ちます。
o If there is a need to serve multiple sessions for a single user using multiple browsers concurrently, use a Cookie for distinguishing between sessions for the same user. (C.f. if there is a need to distinguish between sessions in the same browser, HTML5 Web Storage [W3C.REC-webstorage-20130730] features can be used instead of Cookies.)
o 複数のブラウザを同時に使用して1人のユーザーに複数のセッションを提供する必要がある場合は、Cookieを使用して同じユーザーのセッションを区別します。 （C.f.同じブラウザーでセッションを区別する必要がある場合は、Cookieの代わりにHTML5 Webストレージ[W3C.REC-webstorage-20130730]機能を使用できます。）
o If a website is currently deploying a session time-out feature, consider who benefits from the feature. In most cases, the main requirement for such a feature is to protect users from having their consoles and browsers hijacked (i.e., benefits are on the users' side). In such cases, the time-out features provided in this extension can be used. On the other hand, the requirement is to protect the server's privilege (e.g., when some regulations require limiting the time difference between a user's two-factor authentication and financial transaction commitment; the requirement is strictly on the servers' side), that should be managed on the server side using Cookies or other session-management mechanisms.
o Webサイトが現在セッションタイムアウト機能を展開している場合は、その機能のメリットを検討してください。ほとんどの場合、このような機能の主な要件は、ユーザーがコンソールとブラウザを乗っ取られるのを防ぐことです（つまり、ユーザー側にメリットがあります）。このような場合、この拡張機能で提供されるタイムアウト機能を使用できます。一方、要件はサーバーの特権を保護することです（たとえば、一部の規制ではユーザーの2要素認証と金融トランザクションコミットメントの時間差を制限する必要がある場合、要件は厳密にサーバー側にあります）。 Cookieまたはその他のセッション管理メカニズムを使用してサーバー側で管理されます。
In some transition periods, sites may need to support both HTTP-layer and form-based authentication. The following example shows one way to achieve that.
一部の移行期間では、サイトがHTTPレイヤー認証とフォームベース認証の両方をサポートする必要がある場合があります。次の例は、これを実現する1つの方法を示しています。
o If Cookies are used even for HTTP-authenticated users, each session determined by Cookies SHOULD identify which authentication has been used for the session.
o HTTP認証されたユーザーに対してもCookieが使用される場合、Cookieによって決定される各セッションは、そのセッションに使用された認証を識別する必要があります（SHOULD）。
o First, set up any of the above settings for enabling HTTP-layer authentication.
o 最初に、HTTP層認証を有効にするための上記の設定をセットアップします。
o For unauthenticated users, add the following things to the Web pages, unless the client supports this extension and HTTP-level authentication:
o 認証されていないユーザーの場合、クライアントがこの拡張機能とHTTPレベルの認証をサポートしていない限り、Webページに次のものを追加します。
* For non-mandatory authenticated pages, add a link to the form-based authenticated pages.
* 必須ではない認証済みページの場合は、フォームベースの認証済みページへのリンクを追加します。
* For mandatory authenticated pages, either put a link to form-based authenticated pages or put an HTML-level redirection (using <META http-equiv="refresh" ...> element) to such pages.
* 必須の認証済みページの場合、フォームベースの認証済みページへのリンクを配置するか、そのようなページにHTMLレベルのリダイレクト（<META http-equiv = "refresh" ...>要素を使用）を配置します。
o In the form-based authenticated pages, if users are not authenticated, the page can provide a redirection for HTTP-level authentication by the "location-when-unauthenticated" setting.
o フォームベースの認証済みページでは、ユーザーが認証されていない場合、「location-when-unauthenticated」設定により、ページがHTTPレベル認証のリダイレクトを提供できます。
o Users are identified for authorization and content customization by the following logic:
o ユーザーは、次のロジックによって承認とコンテンツのカスタマイズが識別されます。
* First, check the result of the HTTP-level authentication. If there is a Cookie session tied to a specific user, both should match.
* まず、HTTPレベルの認証の結果を確認します。特定のユーザーに関連付けられたCookieセッションがある場合、両方が一致する必要があります。
* If the user is not authenticated on the HTTP-level, use the conventional form-based method to determine the user.
* ユーザーがHTTPレベルで認証されていない場合は、従来のフォームベースの方法を使用してユーザーを決定します。
* If there is a Cookie tied to HTTP authentication but there is no corresponding HTTP authentication result, that session will be discarded (because it means that authentication is deactivated by the corresponding user).
* HTTP認証に関連付けられたCookieがあり、対応するHTTP認証結果がない場合、そのセッションは破棄されます（対応するユーザーによって認証が非アクティブ化されていることを意味するため）。
If a private extension to this protocol is implemented, it MUST use the extension-param to avoid conflicts with this protocol and any other extensions. (Standardized extensions or extensions that are being standardized MAY use either bare-tokens or extension-tokens.)
このプロトコルのプライベート拡張が実装されている場合、このプロトコルと他の拡張との競合を回避するために、extension-paramを使用する必要があります。 （標準化された拡張機能または標準化されている拡張機能は、ベアトークンまたは拡張トークンのいずれかを使用できます。）
When bare-tokens are used in this protocol, these MUST be allocated by IANA. Any tokens used for non-private, non-experimental parameters are RECOMMENDED to be registered with IANA, regardless of the kind of tokens used.
このプロトコルでベアトークンが使用される場合、これらはIANAによって割り当てられる必要があります。非プライベートで非実験的なパラメーターに使用されるトークンは、使用されるトークンの種類に関係なく、IANAに登録することをお勧めします。
Extension-tokens MAY be freely used for any non-standard, private, and/or experimental uses. An extension-token MUST use the format "-<bare-token>.<domain-name>", where <domain-name> is a validly registered (sub-)domain name on the Internet owned by the party that defines the extensions. Any unknown parameter name is to be ignored regardless of whether it is an extension-token or a bare-token.
拡張トークンは、非標準、プライベート、および/または実験的な用途に自由に使用できます（MAY）。拡張トークンは、「-<bare-token>。<domain-name>」という形式を使用する必要があります。ここで、<domain-name>は、拡張を定義する当事者が所有するインターネット上に有効に登録された（サブ）ドメイン名です。不明なパラメーター名は、拡張トークンかベアトークンかに関係なく無視されます。
This document defines two new entries for the "Permanent Message Header Field Names" registry.
このドキュメントでは、「Permanent Message Header Field Names」レジストリに2つの新しいエントリを定義しています。
+-------------+---------------------------+-------------------------+
| | Entry 1: | Entry 2: |
+-------------+---------------------------+-------------------------+
| Header | Optional-WWW-Authenticate | Authentication-Control |
| Field Name | | |
| Protocol | http | http |
| Status | experimental | experimental |
| Change | IETF | IETF |
| Control | | |
| Spec. | Section 3 of this | Section 4 of this |
| Document | document | document |
+-------------+---------------------------+-------------------------+
This document also establishes the "HTTP Authentication Control Parameters" registry. The registry manages case-insensitive ASCII strings. The string MUST follow the extensive-token syntax defined in Section 2.2.
このドキュメントでは、「HTTP認証制御パラメータ」レジストリも確立しています。レジストリは大文字と小文字を区別しないASCII文字列を管理します。文字列は、セクション2.2で定義された拡張トークン構文に従う必要があります。
To acquire registered tokens, a specification for the use of such tokens MUST be available as a publicly accessible document (see "Specification Required" in [RFC5226]).
登録されたトークンを取得するには、そのようなトークンの使用に関する仕様が、公にアクセス可能なドキュメントとして利用可能でなければなりません（[RFC5226]の「必要な仕様」を参照）。
Registrations for authentication control parameters are required to include a description of the control extension. New registrations are advised to provide the following information:
認証制御パラメーターの登録には、制御拡張の説明を含める必要があります。新規登録は、次の情報を提供することをお勧めします。
o Token: A token used in HTTP headers for identifying the algorithm.
o トークン：アルゴリズムを識別するためにHTTPヘッダーで使用されるトークン。
o Specification: A reference for the specification defining the algorithm.
o 仕様：アルゴリズムを定義する仕様のリファレンス。
The initial content of this registry is as follows:
このレジストリの初期内容は次のとおりです。
+-------------------------------+------------------------------+
| Token | Specification |
+-------------------------------+------------------------------+
| auth-style | Section 4.2 of this document |
| location-when-unauthenticated | Section 4.3 of this document |
| no-auth | Section 4.4 of this document |
| location-when-logout | Section 4.5 of this document |
| logout-timeout | Section 4.6 of this document |
| username | Section 4.7 of this document |
+-------------------------------+------------------------------+
The purpose of the logout timeout feature in the Authentication-control header is to protect users of clients from impersonation caused by an attacker having access to the same console. The server application implementers SHOULD be aware that the directive may always be ignored by either malicious clients or clients not supporting this extension. If the purpose of introducing a timeout for an authentication period is to protect server-side resources, this protection MUST be implemented by other means such as HTTP Cookies [RFC6265].
Authentication-controlヘッダーのログアウトタイムアウト機能の目的は、攻撃者が同じコンソールにアクセスすることによって引き起こされる偽装からクライアントのユーザーを保護することです。サーバーアプリケーションの実装者は、悪意のあるクライアントまたはこの拡張機能をサポートしていないクライアントのいずれかがこのディレクティブを常に無視する可能性があることに注意してください。認証期間のタイムアウトを導入する目的がサーバー側のリソースを保護することである場合、この保護はHTTP Cookie [RFC6265]などの他の手段で実装する必要があります。
All parameters in the Authentication-Control header SHOULD NOT be used for any security-enforcement purposes. Server-side applications MUST NOT assume that the header will be honored by clients and users.
Authentication-Controlヘッダー内のすべてのパラメーターは、セキュリティを強化する目的で使用してはなりません（SHOULD NOT）。サーバー側のアプリケーションは、ヘッダーがクライアントとユーザーによって尊重されると想定してはなりません。
The "username" parameter sometimes reveals sensitive information about the HTTP server and its configurations that are useful for security attacks. In general, common security practice suggests that any kind of information on the existence/non-existence of a specific username shall not be disclosed before successful authentication. Obviously, the "username" parameter contradicts this practice.
「username」パラメータは、セキュリティ攻撃に役立つHTTPサーバーとその構成に関する機密情報を明らかにする場合があります。一般に、一般的なセキュリティ慣行では、特定のユーザー名の存在/非存在に関するあらゆる種類の情報は、認証が成功する前に開示されるべきではないことを示唆しています。明らかに、「username」パラメータはこの方法と矛盾します。
Given this background, the use of the "username" parameter SHOULD be strictly limited to cases where all of the following conditions are met:
このような背景があるため、「username」パラメータの使用は、以下の条件がすべて満たされている場合に厳密に制限する必要があります（SHOULD）。
(1) the valid username is pre-configured and not modifiable (such as root, admin, or similar ones);
（1）有効なユーザー名は事前設定されており、変更できません（root、admin、または類似のユーザーなど）。
(2) the valid username for such an appliance is publicly known (for example, written in a manual document); and
（2）そのようなアプライアンスの有効なユーザー名が公に知られている（たとえば、マニュアルに書かれている）。そして
(3) either the valid username for the server is easily guessable by other means (for example, from the model number shown in an unauthenticated page), or the server is accessible only from limited networks.
（3）サーバーの有効なユーザー名が他の方法（たとえば、認証されていないページに表示されるモデル番号から）で簡単に推測できるか、サーバーが限られたネットワークからのみアクセス可能である。
Most importantly, the "username" parameter SHOULD NOT be used in any case when the valid usernames can be changed/configured by users or administrators.
最も重要なのは、ユーザー名または管理者が有効なユーザー名を変更/構成できる場合は、 "username"パラメータを使用しないでください。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、DOI 10.17487 / RFC5226、2008年5月、<http://www.rfc-editor.org / info / rfc5226>。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234]クロッカー、D。、エド。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、DOI 10.17487 / RFC5234、2008年1月、<http://www.rfc-editor.org/info/rfc5234>。
[RFC5987] Reschke, J., "Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters", RFC 5987, DOI 10.17487/RFC5987, August 2010, <http://www.rfc-editor.org/info/rfc5987>.
[RFC5987] Reschke、J。、「ハイパーテキスト転送プロトコル（HTTP）ヘッダーフィールドパラメーターの文字セットと言語エンコード」、RFC 5987、DOI 10.17487 / RFC5987、2010年8月、<http://www.rfc-editor.org/ info / rfc5987>。
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.
[RFC7230]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Message Syntax and Routing」、RFC 7230、DOI 10.17487 / RFC7230、2014年6月、<http://www.rfc-editor.org/info/ rfc7230>。
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, DOI 10.17487/RFC7235, June 2014, <http://www.rfc-editor.org/info/rfc7235>.
[RFC7235]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Authentication」、RFC 7235、DOI 10.17487 / RFC7235、2014年6月、<http://www.rfc-editor.org/info/rfc7235>。
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, DOI 10.17487/RFC6265, April 2011, <http://www.rfc-editor.org/info/rfc6265>.
[RFC6265] Barth、A。、「HTTP State Management Mechanism」、RFC 6265、DOI 10.17487 / RFC6265、2011年4月、<http://www.rfc-editor.org/info/rfc6265>。
[RFC7564] Saint-Andre, P. and M. Blanchet, "PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols", RFC 7564, DOI 10.17487/RFC7564, May 2015, <http://www.rfc-editor.org/info/rfc7564>.
[RFC7564] Saint-Andre、P。およびM. Blanchet、「PRECIS Framework：Preparation、Enforcement、and Comparison of Internationalized Strings in Application Protocols」、RFC 7564、DOI 10.17487 / RFC7564、2015年5月、<http：// www。 rfc-editor.org/info/rfc7564>。
[RFC7615] Reschke, J., "HTTP Authentication-Info and Proxy-Authentication-Info Response Header Fields", RFC 7615, DOI 10.17487/RFC7615, September 2015, <http://www.rfc-editor.org/info/rfc7615>.
[RFC7615] Reschke、J。、「HTTP Authentication-Info and Proxy-Authentication-Info Response Header Fields」、RFC 7615、DOI 10.17487 / RFC7615、2015年9月、<http://www.rfc-editor.org/info/ rfc7615>。
[W3C.REC-webstorage-20130730] Hickson, I., "Web Storage", World Wide Web Consortium Recommendation REC-webstorage-20130730, July 2013, <http://www.w3.org/TR/2013/REC-webstorage-20130730>.
[W3C.REC-webstorage-20130730] Hickson、I。、「Web Storage」、World Wide Web Consortium Recommendation REC-webstorage-20130730、2013年7月、<http://www.w3.org/TR/2013/REC- webstorage-20130730>。
Appendix A. (Informative) Applicability of Features for Each Message
付録A.（参考）各メッセージの機能の適用性
This section provides a cross-reference table showing the applicability of the features provided in this specification to each kind of response described in Section 2.1. The table provided in this section is for informative purposes only.
このセクションでは、セクション2.1で説明した各種類の応答に対する、この仕様で提供される機能の適用可能性を示す相互参照表を提供します。このセクションで提供される表は、情報提供のみを目的としています。
+-------------------+-------+----------+-----------+------+
| | init. | success. | intermed. | neg. |
+-------------------+-------+----------+-----------+------+
| Optional auth. | O | n | N | N |
| auth-style | O | - | - | O |
| loc.-when-unauth. | O | I | I | i |
| no-auth | O | I | I | i |
| loc.-when-logout | - | O | - | - |
| logout-timeout | - | O | - | - |
| username | O | - | - | O |
+-------------------+-------+----------+-----------+------+
Legends:
O = MAY contain; n = SHOULD NOT contain; N = MUST NOT contain
i = SHOULD be ignored; I = MUST be ignored;
- = meaningless (to be ignored)
Authors' Addresses
著者のアドレス
Yutaka Oiwa National Institute of Advanced Industrial Science and Technology Information Technology Research Institute Tsukuba Central 1 1-1-1 Umezono Tsukuba-shi, Ibaraki Japan
Yutaka Oiwa National Institute of Advanced Industrial Science and Technology Information Technology Research Institute Tsukuba Central 1 1-1-1 Umezono Tsukuba-shi, Ibaraki Japan
Email: y.oiwa@aist.go.jp
Hajime Watanabe National Institute of Advanced Industrial Science and Technology Information Technology Research Institute Tsukuba Central 1 1-1-1 Umezono Tsukuba-shi, Ibaraki Japan
Hajime Watanabe National Institute of Advanced Industrial Science and Technology Information Technology Research Institute Tsukuba Central 1 1-1-1 Umezono Tsukuba-shi, Ibaraki Japan
Email: h-watanabe@aist.go.jp Hiromitsu Takagi National Institute of Advanced Industrial Science and Technology Information Technology Research Institute Tsukuba Central 1 1-1-1 Umezono Tsukuba-shi, Ibaraki Japan
Email: h-watanabe@aist.go.jp Hiromitsu Takagi National Institute of Advanced Industrial Science and Technology Information Technology Research Institute Tsukuba Central 1 1-1-1 Umezono Tsukuba-shi, Ibaraki Japan
Email: takagi.hiromitsu@aist.go.jp
Kaoru Maeda Lepidum Co. Ltd. Village Sasazuka 3, Suite #602 1-30-3 Sasazuka Shibuya-ku, Tokyo Japan
かおる まえだ ぇぴづｍ こ。 Ｌｔｄ。 ゔぃっぁげ ささずか ３、 すいて ＃６０２ １ー３０ー３ ささずか しぶやーく、 ときょ じゃぱん
Email: maeda@lepidum.co.jp
Tatsuya Hayashi Lepidum Co. Ltd. Village Sasazuka 3, Suite #602 1-30-3 Sasazuka Shibuya-ku, Tokyo Japan
たつや はやし ぇぴづｍ こ。 Ｌｔｄ。 ゔぃっぁげ ささずか ３、 すいて ＃６０２ １ー３０ー３ ささずか しぶやーく、 ときょ じゃぱん
Email: hayashi@lepidum.co.jp
Yuichi Ioku Individual Contributor
ゆいち いおく いんぢゔぃづあｌ こんｔりぶとｒ
Email: mutual-work@ioku.org