doc: Add RFC documents

1 files changed, 1571 insertions, 0 deletions

diff --git a/doc/rfc/rfc8053.txt b/doc/rfc/rfc8053.txt
new file mode 100644
index 0000000..9fbe468
--- /dev/null
+++ b/doc/rfc/rfc8053.txt
@@ -0,0 +1,1571 @@
+
+
+
+
+
+
+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
+
+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.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for examination, experimental implementation, and
+   evaluation.
+
+   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.
+
+   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.
+
+
+
+
+
+
+Oiwa, et al.                  Experimental                      [Page 1]
+
+RFC 8053         HTTP Auth. Ext. for Interactive Clients    January 2017
+
+
+Copyright Notice
+
+   Copyright (c) 2017 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Oiwa, et al.                  Experimental                      [Page 2]
+
+RFC 8053         HTTP Auth. Ext. for Interactive Clients    January 2017
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Oiwa, et al.                  Experimental                      [Page 3]
+
+RFC 8053         HTTP Auth. Ext. for Interactive Clients    January 2017
+
+
+1.  Introduction
+
+   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:
+
+   o  optional authentication on HTTP (Section 3),
+
+   o  log out from both the server and client side (Section 4), and
+
+   o  finer control for redirection depending on the authentication
+      status (Section 4)
+
+1.1.  Terminology
+
+   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].
+
+   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".
+
+
+
+
+
+
+
+
+
+
+
+
+Oiwa, et al.                  Experimental                      [Page 4]
+
+RFC 8053         HTTP Auth. Ext. for Interactive Clients    January 2017
+
+
+2.  Definitions
+
+2.1.  Terms for Describing Authentication Protocol Flow
+
+   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.
+
+   For requests:
+
+   1) A non-authenticating request is a request not attempting any
+      authentication: a request without any Authorization header field.
+
+   2) An authenticating request is the opposite: a request with an
+      Authorization header field.
+
+   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]).
+
+      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.
+
+      (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:
+
+      *  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.
+
+
+
+
+
+
+Oiwa, et al.                  Experimental                      [Page 5]
+
+RFC 8053         HTTP Auth. Ext. for Interactive Clients    January 2017
+
+
+      Upon receiving this response, the client's behavior is further
+      divided to two possible cases:
+
+      *  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.
+
+   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.)
+
+   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.
+
+   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.
+
+      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.
+
+
+
+
+
+Oiwa, et al.                  Experimental                      [Page 6]
+
+RFC 8053         HTTP Auth. Ext. for Interactive Clients    January 2017
+
+
+         ===========                                -----------------
+         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
+
+   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.
+
+
+
+
+
+
+
+Oiwa, et al.                  Experimental                      [Page 7]
+
+RFC 8053         HTTP Auth. Ext. for Interactive Clients    January 2017
+
+
+2.2.  Syntax Notation
+
+   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.
+
+   Additionally, this specification uses the following syntax
+   definitions as a refinement for token and the right-hand-side of
+   auth-param in [RFC7235].
+
+    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
+
+   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.
+
+3.  Optional Authentication
+
+   The Optional-WWW-Authenticate header enables a non-mandatory
+   authentication, which is not possible under the current HTTP
+   authentication mechanism.
+
+   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.
+
+
+
+
+
+
+
+
+
+Oiwa, et al.                  Experimental                      [Page 8]
+
+RFC 8053         HTTP Auth. Ext. for Interactive Clients    January 2017
+
+
+   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).
+
+    Optional-WWW-Authenticate = 1#challenge
+
+         Figure 3: BNF Syntax for Optional-WWW-Authenticate Header
+
+      Example:
+      HTTP/1.1 200 OK
+      Optional-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.)
+
+   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.
+
+   The server is NOT RECOMMENDED to include an Optional-WWW-Authenticate
+   header in a positive response when a client's authentication attempt
+   succeeds.
+
+   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.
+
+
+
+Oiwa, et al.                  Experimental                      [Page 9]
+
+RFC 8053         HTTP Auth. Ext. for Interactive Clients    January 2017
+
+
+   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
+
+   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.
+
+   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.
+
+   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.
+
+   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.
+
+   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
+
+
+
+Oiwa, et al.                  Experimental                     [Page 10]
+
+RFC 8053         HTTP Auth. Ext. for Interactive Clients    January 2017
+
+
+   (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.
+
+4.  Authentication-Control Header
+
+    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
+
+   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.
+
+   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.
+
+   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.
+
+   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:
+
+   (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
+
+
+
+
+Oiwa, et al.                  Experimental                     [Page 11]
+
+RFC 8053         HTTP Auth. Ext. for Interactive Clients    January 2017
+
+
+        Authentication-Control header corresponding to that scheme and
+        realm are relevant.
+
+   (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.
+
+   The server MAY send an Authentication-Control header containing non-
+   relevant entries.  The client MUST ignore all non-relevant entries it
+   received.
+
+   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.
+
+   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.)
+
+   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.
+
+   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.
+
+
+
+Oiwa, et al.                  Experimental                     [Page 12]
+
+RFC 8053         HTTP Auth. Ext. for Interactive Clients    January 2017
+
+
+4.1.  Non-ASCII Extended Header Parameters
+
+   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.
+
+   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.
+
+   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.
+
+   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.
+
+   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.
+
+4.2.  Auth-Style Parameter
+
+   Example:
+   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.
+
+
+
+Oiwa, et al.                  Experimental                     [Page 13]
+
+RFC 8053         HTTP Auth. Ext. for Interactive Clients    January 2017
+
+
+   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.
+
+   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.
+
+4.3.  Location-When-Unauthenticated Parameter
+
+   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.
+
+   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.
+
+
+
+
+
+
+
+Oiwa, et al.                  Experimental                     [Page 14]
+
+RFC 8053         HTTP Auth. Ext. for Interactive Clients    January 2017
+
+
+   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.
+
+4.4.  No-Auth Parameter
+
+   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.
+
+   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.
+
+   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.
+
+   Using this parameter along with the location-when-unauthenticated
+   parameter is meaningless.  If both were supplied, clients SHOULD
+   ignore the location-when-unauthenticated parameter.
+
+   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.
+
+
+
+
+Oiwa, et al.                  Experimental                     [Page 15]
+
+RFC 8053         HTTP Auth. Ext. for Interactive Clients    January 2017
+
+
+4.5.  Location-When-Logout Parameter
+
+   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.
+
+   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.
+
+   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.
+
+   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.
+
+   See Section 5 for some examples for possible deployment of this
+   parameter.
+
+
+
+
+
+
+
+
+
+
+Oiwa, et al.                  Experimental                     [Page 16]
+
+RFC 8053         HTTP Auth. Ext. for Interactive Clients    January 2017
+
+
+4.6.  Logout-Timeout Parameter
+
+   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.
+
+4.7.  Username Parameter
+
+   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.
+
+   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.
+
+   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.
+
+
+
+
+
+
+
+Oiwa, et al.                  Experimental                     [Page 17]
+
+RFC 8053         HTTP Auth. Ext. for Interactive Clients    January 2017
+
+
+   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.
+
+   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).
+
+   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.
+
+5.  Usage Examples
+
+   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.
+
+   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.
+
+   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).
+
+
+
+
+
+
+
+
+
+Oiwa, et al.                  Experimental                     [Page 18]
+
+RFC 8053         HTTP Auth. Ext. for Interactive Clients    January 2017
+
+
+5.1.  Example 1: A Portal Site
+
+   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:
+
+   o  Content pages
+
+   o  Pages/mechanism for performing authentication:
+
+      *  There is one page that asks for a username and a password using
+         a HTML POST form.
+
+      *  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.
+
+5.1.1.  Case 1: A Simple Application
+
+   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  If there are pages only available to authenticated users, set up a
+      mandatory authentication with the "auth-style=non-modal" setting.
+
+   o  No specific pages for authentication are needed.  It will be
+      performed automatically, directed by the above setting.
+
+   o  A de-authentication page is also not needed.  If the site has one,
+      put "logout-timeout=0" there.
+
+   o  For all pages for POST requests, it is advisable to have a
+      "location-when-logout=<some page>".
+
+
+
+
+
+
+
+
+
+Oiwa, et al.                  Experimental                     [Page 19]
+
+RFC 8053         HTTP Auth. Ext. for Interactive Clients    January 2017
+
+
+5.1.2.  Case 2: Specific Action Required on Logout
+
+   If the site requires specific actions upon logout, the following
+   settings can be used:
+
+   o  All settings in Case 1 are applied.
+
+   o  For all pages, set up the Authentication-Control header "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".
+
+5.1.3.  Case 3: Specific Page Displayed before Login
+
+   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  If there are pages only available to authenticated users, set up a
+      mandatory authentication with the
+      "location-when-unauthenticated=<the login page>".
+
+   o  For the specific login page, set up a mandatory authentication.
+
+   o  For all pages for POST requests, it is advisable to have
+      "location-when-logout=<some page>", too.
+
+   o  De-authentication pages are not needed.  If the site has one, put
+      "logout-timeout=0".
+
+5.2.  Example 2: Authenticated User-Only Sites
+
+   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.
+
+
+
+
+Oiwa, et al.                  Experimental                     [Page 20]
+
+RFC 8053         HTTP Auth. Ext. for Interactive Clients    January 2017
+
+
+   o  Set up a handler for the 401-status that requests users to
+      authenticate.
+
+   o  For all pages for POST requests, it is advisable to have a
+      "location-when-logout=<some page>", too.
+
+   o  De-authentication pages are not needed.  If the site will have
+      one, put "logout-timeout=0" there.
+
+5.3.  When to Use Cookies
+
+   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.
+
+   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  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.
+
+
+
+
+
+
+
+
+
+
+
+
+Oiwa, et al.                  Experimental                     [Page 21]
+
+RFC 8053         HTTP Auth. Ext. for Interactive Clients    January 2017
+
+
+5.4.  Parallel Deployment with Form/Cookie Authentication
+
+   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.
+
+   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  First, set up any of the above settings for enabling HTTP-layer
+      authentication.
+
+   o  For unauthenticated users, add the following things to the Web
+      pages, unless the client supports this extension and HTTP-level
+      authentication:
+
+      *  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.
+
+   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  Users are identified for authorization and content customization
+      by the following logic:
+
+      *  First, check the result of the HTTP-level authentication.  If
+         there is a Cookie session tied to a specific user, both should
+         match.
+
+      *  If the user is not authenticated on the HTTP-level, use the
+         conventional form-based method to determine the user.
+
+      *  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).
+
+
+
+
+
+
+
+
+
+Oiwa, et al.                  Experimental                     [Page 22]
+
+RFC 8053         HTTP Auth. Ext. for Interactive Clients    January 2017
+
+
+6.  Methods to Extend This Protocol
+
+   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.)
+
+   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.
+
+   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.
+
+7.  IANA Considerations
+
+   This document defines two new entries for the "Permanent Message
+   Header Field Names" registry.
+
+   +-------------+---------------------------+-------------------------+
+   |             | 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.
+
+   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]).
+
+
+
+
+
+
+Oiwa, et al.                  Experimental                     [Page 23]
+
+RFC 8053         HTTP Auth. Ext. for Interactive Clients    January 2017
+
+
+   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  Specification: A reference for the specification defining the
+      algorithm.
+
+   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 |
+     +-------------------------------+------------------------------+
+
+8.  Security Considerations
+
+   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].
+
+   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.
+
+8.1.  Security Implication of the Username Parameter
+
+   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.
+
+
+
+
+
+Oiwa, et al.                  Experimental                     [Page 24]
+
+RFC 8053         HTTP Auth. Ext. for Interactive Clients    January 2017
+
+
+   Given this background, the use of the "username" parameter SHOULD be
+   strictly limited to cases where all of the following conditions are
+   met:
+
+   (1)  the valid username is pre-configured and not modifiable (such as
+        root, admin, or similar ones);
+
+   (2)  the valid username for such an appliance is publicly known (for
+        example, written in a manual document); and
+
+   (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.
+
+   Most importantly, the "username" parameter SHOULD NOT be used in any
+   case when the valid usernames can be changed/configured by users or
+   administrators.
+
+9.  References
+
+9.1.  Normative References
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+
+
+
+Oiwa, et al.                  Experimental                     [Page 25]
+
+RFC 8053         HTTP Auth. Ext. for Interactive Clients    January 2017
+
+
+   [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>.
+
+9.2.  Informative References
+
+   [RFC6265]  Barth, A., "HTTP State Management Mechanism", RFC 6265,
+              DOI 10.17487/RFC6265, April 2011,
+              <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>.
+
+   [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>.
+
+   [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>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Oiwa, et al.                  Experimental                     [Page 26]
+
+RFC 8053         HTTP Auth. Ext. for Interactive Clients    January 2017
+
+
+Appendix A.  (Informative) Applicability of Features for Each Message
+
+   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.
+
+        +-------------------+-------+----------+-----------+------+
+        |                   | 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
+
+   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
+
+   Email: h-watanabe@aist.go.jp
+
+
+
+
+
+Oiwa, et al.                  Experimental                     [Page 27]
+
+RFC 8053         HTTP Auth. Ext. for Interactive Clients    January 2017
+
+
+   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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Oiwa, et al.                  Experimental                     [Page 28]
+