idnits 2.17.00 (12 Aug 2021) /tmp/idnits27998/draft-ietf-httpauth-extension-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 17, 2016) is 2067 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5987 (Obsoleted by RFC 8187) -- Obsolete informational reference (is this intentional?): RFC 7564 (Obsoleted by RFC 8264) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTPAUTH Working Group Y. Oiwa 3 Internet-Draft H. Watanabe 4 Intended status: Experimental H. Takagi 5 Expires: March 21, 2017 ITRI, AIST 6 K. Maeda 7 T. Hayashi 8 Lepidum 9 Y. Ioku 10 Individual 11 September 17, 2016 13 HTTP Authentication Extensions for Interactive Clients 14 draft-ietf-httpauth-extension-09 16 Abstract 18 This document specifies extensions for the HTTP authentication 19 framework for interactive clients. Currently, fundamental features 20 of HTTP-level authentication are insufficient for complex 21 requirements of various Web-based applications. This forces these 22 applications to implement their own authentication frameworks by 23 means like HTML forms, which becomes one of the hurdles against 24 introducing secure authentication mechanisms handled jointly by 25 servers and user-agent. The extended framework fills gaps between 26 Web application requirements and HTTP authentication provisions to 27 solve the above problems, while maintaining compatibility with 28 existing Web and non-Web uses of HTTP authentication. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on March 21, 2017. 47 Copyright Notice 48 Copyright (c) 2016 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 65 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 2.1. Terms for describing authentication protocol flow . . . . 4 67 2.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7 68 3. Optional Authentication . . . . . . . . . . . . . . . . . . . 8 69 3.1. Note on Optional-WWW-Authenticate and use of 70 WWW-Authenticate header with non-401 status . . . . . . . 10 71 4. Authentication-Control header . . . . . . . . . . . . . . . . 11 72 4.1. Non-ASCII extended header parameters . . . . . . . . . . . 12 73 4.2. Auth-style parameter . . . . . . . . . . . . . . . . . . . 13 74 4.3. Location-when-unauthenticated parameter . . . . . . . . . 14 75 4.4. No-auth parameter . . . . . . . . . . . . . . . . . . . . 15 76 4.5. Location-when-logout parameter . . . . . . . . . . . . . . 15 77 4.6. Logout-timeout parameter . . . . . . . . . . . . . . . . . 16 78 4.7. Username parameter . . . . . . . . . . . . . . . . . . . . 17 79 5. Usage examples . . . . . . . . . . . . . . . . . . . . . . . . 18 80 5.1. Example 1: a portal site . . . . . . . . . . . . . . . . . 18 81 5.1.1. Case 1: a simple application . . . . . . . . . . . . . 19 82 5.1.2. Case 2: specific action required on log-out . . . . . 19 83 5.1.3. Case 3: specific page displayed before log-in . . . . 19 84 5.2. Example 2: authenticated user-only sites . . . . . . . . . 20 85 5.3. When to use Cookies . . . . . . . . . . . . . . . . . . . 20 86 5.4. Parallel deployment with Form/Cookie authentication . . . 21 87 6. Methods to extend this protocol . . . . . . . . . . . . . . . 22 88 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 89 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 90 8.1. Security implication of the username parameter . . . . . . 24 91 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 92 9.1. Normative References . . . . . . . . . . . . . . . . . . . 24 93 9.2. Informative References . . . . . . . . . . . . . . . . . . 25 94 Appendix A. (Informative) Applicability of features for each 95 messages . . . . . . . . . . . . . . . . . . . . . . 25 96 Appendix B. (Informative) Draft Change Log . . . . . . . . . . . 26 97 B.1. Changes in Httpauth WG Revision 09 . . . . . . . . . . . . 26 98 B.2. Changes in Httpauth WG Revision 08 . . . . . . . . . . . . 26 99 B.3. Changes in Httpauth WG Revision 07 . . . . . . . . . . . . 26 100 B.4. Changes in Httpauth WG Revision 06 . . . . . . . . . . . . 26 101 B.5. Changes in Httpauth WG Revision 05 . . . . . . . . . . . . 26 102 B.6. Changes in Httpauth WG revision 04 . . . . . . . . . . . . 27 103 B.7. Changes in Httpauth WG revision 03 . . . . . . . . . . . . 27 104 B.8. Changes in Httpauth WG revision 02 . . . . . . . . . . . . 27 105 B.9. Changes in Httpauth WG revision 01 . . . . . . . . . . . . 27 106 B.10. Changes in Httpauth revision 00 and HttpBis revision 00 . 27 107 B.11. Changes in revision 02 . . . . . . . . . . . . . . . . . . 27 108 B.12. Changes in revision 01 . . . . . . . . . . . . . . . . . . 27 109 B.13. Changes in revision 00 . . . . . . . . . . . . . . . . . . 27 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 112 1. Introduction 114 This document defines several extensions to the current HTTP 115 authentication framework, to provide functionality comparable with 116 current widely-used form-based Web authentication. A majority of the 117 recent websites on the Internet use custom application-layer 118 authentication implementations using Web forms. The reasons for 119 these may vary, but many people believe that the current HTTP Basic 120 and Digest authentication methods do not have enough functionality 121 (including good user interfaces) to support most realistic Web-based 122 applications. However, such use of form-based Web authentication has 123 several weakness against attacks like phishing, because all behavior 124 of the authentication is controlled from the server-side application. 125 This makes it really hard to implement any cryptographically strong 126 authentication mechanisms into Web systems. To overcome this 127 problem, we need to "modernize" the HTTP authentication framework so 128 that better client-controlled secure methods can be used with Web 129 applications. The extensions proposed in this document include: 131 o optional authentication on HTTP (Section 3), 133 o log out from both server and client side (Section 4), and 135 o finer control for redirection depending on authentication status 136 (Section 4). 138 1.1. Terminology 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 142 "OPTIONAL" in this document are to be interpreted as described in 143 [RFC2119]. 145 This document distinguishes the terms "client" and "user" in the 146 following way: A "client" is an entity understanding and talking HTTP 147 and the specified authentication protocol, usually computer software; 148 a "user" is a (usually natural) person who wants to access data 149 resources using "a client". 151 2. Definitions 153 2.1. Terms for describing authentication protocol flow 155 HTTP Authentication defined in [RFC7235] can involve several pairs of 156 HTTP requests/responses. Throughout this document, the following 157 terms are used to categorize those messages: for requests, 158 1) A non-authenticating request is a request not attempting any 159 authentication: a request without any Authorization header field. 161 2) An authenticating request is the opposite: a request with an 162 Authorization header field. 164 For responses, 166 1) A non-authenticated response is a response which does not involve 167 any HTTP authentication. It does not contain any WWW-Authenticate 168 ([RFC7235]) or Authentication-Info header field ([RFC7615]). 170 Servers send this response when the requested resource is not 171 protected by an HTTP authentication mechanism. In context of this 172 specification, non-authentication-related negative responses (e.g. 173 403 and 404) are also considered non-authenticated responses. 175 (See note on successfully-authenticated responses below for some 176 ambiguous cases.) 178 2) An authentication-initializing response is a response which 179 requires or allows clients to start authentication attempts. 180 Servers send this response when the requested resource is 181 protected by HTTP authentication mechanism, and the request meets 182 one of the following cases: 184 * The request is a non-authenticating request, or 186 * The request contained an authentication trial directed to a 187 protection space (realm) other than the one the server 188 expected. 190 The server will specify the protection space for authentication in 191 this response. 193 Upon receiving this response, the client's behavior is further 194 divided to two possible cases. 196 * If the client has no prior knowledge on authentication 197 credentials (e.g. a user-name and a password) related to the 198 requested protection space, the protocol flow terminates and 199 the client will ask the user to provide authentication 200 credentials, 202 * On the other hand, if client already has enough authentication 203 credentials to the requested protection space, the client will 204 automatically send an authenticating request. Such cases often 205 occur when the client did not know beforehand that the current 206 request-URL requires authentication. 208 3) A successfully-authenticated response is a response for an 209 authenticating request meaning that the authentication attempt was 210 granted. (Note: if the authentication scheme used does not use an 211 Authentication-Info header field, it can't be distinguished from a 212 non-authenticated response.) 214 4) An intermediate authenticating response is a response for an 215 authenticating request which requires more reaction by the client 216 software without involving users. Such a response is required 217 when an authentication scheme requires two or more round-trip 218 messages to perform authentication, or when an authentication 219 scheme uses some speculative short-cut method (such as uses of 220 cached shared secrets) and it failed. 222 5) A negatively-authenticated response is a response for an 223 authenticating request which means that the authentication attempt 224 was declined and can not continue without a different set of 225 authentication credentials. Clients typically erase memory of the 226 active credentials and ask the user for other ones. 228 Usually the format of these responses are as same as the one for 229 authentication-initializing responses. Clients can distinguish 230 negatively-authenticated responses from authentication- 231 initializing responses by comparing the protection spaces 232 contained in the request and in the response. 234 Figure 1 shows a state diagram of generic HTTP authentication with 235 the above message categorization. Note that many authentication 236 schemes use only a subset of the transitions described on the 237 diagram. Labels in the figure show the abbreviated names of response 238 types. 240 =========== ----------------- 241 NEW REQUEST ( UNAUTHENTICATED ) 242 =========== ----------------- 243 | ^ non-auth. 244 v | response 245 +----------------------+ NO +-------------+ 246 | The requested URI |--------------------------->| send normal | 247 | known to be auth'ed? | ---------------->| request | 248 +----------------------+ / +-------------+ 249 YES | / initializing| 250 v / | 251 +------------------+ NO / | 252 | Can auth-req.(*1)|--------- | 253 | be constructed? | | 254 +------------------+ | 255 YES | initializing | 256 | ---------------------------------------. | 257 | / v v 258 | | ---------------- NO +-----------+ 259 | | ( AUTH-REQUESTED )<------| passwords | 260 | | ---------------- |etc. known?| 261 v | +-----------+ 262 +-----------+ negative ------------- negative |YES 263 | send |---------->( AUTH-FAILED )<---------, | 264 /| auth-req | ------------- | | 265 / +-----------+\ | v 266 | \ \ intermediate +-----------+ 267 | \ -------------------------------->| send | 268 | \ | auth-req | 269 | non-auth. \successful successful +-----------+ 270 | response (*2) \ / | ^ 271 v \ / | | 272 ----------------- \ -------------- / `----' 273 ( UNAUTHENTICATED ) ----->( AUTH-SUCCEED )<---- intermediate 274 ----------------- -------------- 276 Figure 1: Generic state diagram for HTTP authentication 278 Note: (*1) For example, "Digest" scheme requires server-provided 279 nonce to construct client-side challenges. 280 (*2) In "Basic" and some others, this cannot be distinguished from a 281 successfully-authenticated response. 283 2.2. Syntax Notation 285 This specification uses an extended ABNF syntax defined in [RFC7230] 286 and [RFC5234]. The following syntax definitions are quoted from 288 [RFC7230] and [RFC7235]: auth-scheme, quoted-string, auth-param, SP, 289 BWS, header-field, and challenge. It also uses the convention of 290 using header field names for specifying the syntax of values for the 291 header field. 293 Additionally, this specification uses the following syntax 294 definitions as a refinement for token and the right-hand-side of 295 auth-param in [RFC7235]. 297 bare-token = bare-token-lead-char *bare-token-char 298 bare-token-lead-char = %x30-39 / %x41-5A / %x61-7A 299 bare-token-char = %x30-39 / %x41-5A / %x61-7A / "-" / "_" 300 extension-token = "-" bare-token 1*("." bare-token) 301 extensive-token = bare-token / extension-token 302 integer = "0" / (%x31-39 *%x30-39) ; no leading zeros 304 Figure 2: the BNF syntax for common notations 306 Extensive-tokens are used in this protocol where the set of 307 acceptable tokens includes private extensions. Any extensions of 308 this protocol MAY use either bare-tokens allocated by IANA (under the 309 procedure described in Section 7), or extension-tokens with the 310 format "-.", where is a valid 311 (sub-)domain name on the Internet owned by the party who defines the 312 extension. 314 3. Optional Authentication 316 The Optional-WWW-Authenticate header enables a non-mandatory 317 authentication, which is not possible under the current HTTP 318 authentication mechanism. 320 In several Web applications, users can access the same contents as 321 both a guest user and an authenticated user. In most Web 322 applications, this functionality is implemented using HTTP cookies 323 [RFC6265] and custom form-based authentication. The new 324 authentication method using this message will provide a replacement 325 for these authentication systems. 327 Servers MAY send HTTP non-interim responses containing the 328 Optional-WWW-Authenticate header as a replacement of a 401 response 329 when it is authentication-initializing. The 330 Optional-WWW-Authenticate header MUST NOT be sent on 401 responses 331 (i.e. a usual WWW-Authenticate header MUST be used on 401 responses). 333 Optional-WWW-Authenticate = 1#challenge 334 Figure 3: BNF syntax for Optional-WWW-Authenticate header 336 Example: 337 HTTP/1.1 200 OK 338 Optional-WWW-Authenticate: Basic realm="xxxx" 340 The challenges contained in the Optional-WWW-Authenticate header are 341 the same as those for a 401 responses corresponding to the same 342 request. For authentication-related matters, an optional 343 authentication request will have the same meaning as a 401 message 344 with a corresponding WWW-Authenticate header (as an authentication- 345 initializing response). (The behavior for other matters MAY be 346 different between the optional authentication and 401 messages. For 347 example, clients MAY choose to cache the 200 messages with 348 Optional-WWW-Authenticate header field but not the 401 messages by 349 default.) 351 A response with an Optional-WWW-Authenticate header SHOULD be 352 returned from the server only when the request is either non- 353 authenticated or authenticating to a wrong (not the server's 354 expected) protection space. If a response is either an intermediate 355 or a negative response to a client's authentication attempt, the 356 server MUST respond with a 401 status response with a 357 WWW-Authenticate header instead. Failure to comply with this rule 358 will render clients unable to distinguish authentication successes 359 and failures. 361 The server is NOT RECOMMENDED to include an Optional-WWW-Authenticate 362 header in a positive response when a client's authentication attempt 363 succeeds. 365 Whenever an authentication scheme supports servers sending some 366 parameter which gives a hint of the URL space for the corresponding 367 protection space for the same realm (e.g. "path" or "domain"), 368 servers requesting non-mandatory authentication SHOULD send such 369 parameter with the response. Clients supporting non-mandatory 370 authentication MUST recognize the parameter, and MUST send a request 371 with an appropriate authentication credential in an Authorization 372 header for any URI inside the specified paths. 374 Implementations are not required to support this header for all of 375 their supported authentication schemes (i.e., they may choose to 376 implement it only for a subset of their supported schemes). New 377 authentication schemes can require support of the optional 378 authentication as a prerequisite, though. 380 3.1. Note on Optional-WWW-Authenticate and use of WWW-Authenticate 381 header with non-401 status 383 In the current specification of HTTP/1.1, it is clarified that the 384 WWW-Authenticate header can be used with messages with status codes 385 other than 401 (Authentication Required). Especially, the use of 386 WWW-Authenticate header with the 200 status messages implies a very 387 similar meaning to the above-defined Optional-WWW-Authenticate 388 header. 390 The design of Optional-WWW-Authenticate header expects that the use 391 of a new header guarantees that clients which are unaware of this 392 extension will ignore the header, and that Web developers can rely on 393 that behavior to implement a secondary fallback method of 394 authentication. Several behavioral requirements written in the above 395 section also assumes this property, and defines a necessary 396 functionality to implement an HTTP optional authentication reliably 397 and consistently. 399 On the other hand, some experiments and discussions on the IETF 400 mailing list revealed that most of (but not necessarily all of) the 401 existing HTTP clients, at the time of writing, just ignore the WWW- 402 Authenticate headers in non-401 messages, giving the similar behavior 403 with the Optional-WWW-Authenticate. However, every corner case of 404 behavior was not fully tested, nor well-defined in the existing 405 specifications. 407 Considering these situations, the authors of this document chose to 408 use a new header for a new feature "experiment". This is to avoid 409 defining every corner-case behavior for the existing standard WWW- 410 Authentication header in this experimental document, which could be 411 considered by some implementers as an "incompatible changes to 412 existing specification". 414 Experimentally, the authors propose implementers of the standard 415 HTTP/1.1 specification (especially implementers of this extension) to 416 implement undefined (implementation-dependant) detailed handling of 417 WWW-Authenticate header with non-401 status messages as similar as 418 those defined above for the Optional-WWW-Authenticate header. For 419 example, we propose for servers to return 401 status for failed 420 authentication attempts, even when the unauthenticated request to the 421 same resource will result in the 200 status. This can realize how 422 (whether) we can implement non-mandatory authentication using the 423 standard header fields and status codes. If this experiment is 424 successful, the future revision of this experimental document may 425 "bless" and recommend the use of standard WWW-Authenticate header, 426 with some "standard-level" requirements on some corner case behavior. 428 4. Authentication-Control header 430 Authentication-Control = 1#auth-control-entry 431 auth-control-entry = auth-scheme 1*SP 1#auth-control-param 432 auth-control-param = extensive-token BWS "=" BWS token 433 / extensive-token "*" BWS "=" BWS ext-value 434 ext-value = 436 Figure 4: the BNF syntax for the Authentication-Control header 438 The Authentication-Control header provides a more precise control of 439 the client behavior for Web applications using an HTTP authentication 440 protocol. This header is supposed to be generated in the application 441 layer, as opposed to WWW-Authenticate headers which will usually be 442 generated by the Web servers. 444 Clients MAY freely choose any subset of these parameters to be 445 supported. Also, these are not required to support any of these 446 parameters for all of their supported authentication schemes. 447 However, authentication schemes can require/recommend support for 448 some of these parameters as a prerequisite. 450 The Authentication-Control header contains one or more 451 "authentication control entries" each of which corresponds to a 452 single realm for a specific authentication scheme. If the 453 auth-scheme specified for an entry supports the HTTP "realm" feature, 454 that entry MUST contain the "realm" parameter. If not, the entry 455 MUST NOT contain the "realm" parameter. 457 Among the multiple entries in the header, the relevant entries in the 458 header are those corresponding to an auth-scheme and a realm (if 459 any), for which "the authentication process is being performed, or 460 going to be performed". In more detail, 462 (1) If the response is either an authentication-initializing 463 response or a negatively-authenticated response, there can be 464 multiple challenges in the WWW-Authenticate header (or the 465 Optional-WWW-Authenticate header defined in this extension), 466 each of which corresponds to a different scheme and realm. In 467 this case, the client has a choice on the scheme and realm they 468 will use to authenticate. Only the entry in the 469 Authentication-Control header corresponding to that scheme and 470 realm are relevant. 472 (2) If the response is either an intermediate authenticating 473 response or a successfully-authenticated response, the scheme 474 and realm given in the Authorization header of the HTTP request 475 will determine the currently-ongoing authentication process. 477 Only the entry corresponding to that scheme and realm are 478 relevant. 480 The server MAY send an Authentication-Control header containing non- 481 relevant entries. The client MUST ignore all non-relevant entries it 482 received. 484 Each entry contains one or more parameters, each of which is a name- 485 value pair. The name of each parameter MUST be an extensive-token. 486 Clients MUST ignore any unknown parameters contained in this header. 487 The entries for the same auth-scheme and the realm MUST NOT contain 488 duplicated parameters for the same name. Clients MAY either take any 489 one of those duplicated entries or ignore all of them. 491 The type of parameter value depends on the parameter name as defined 492 in the following subsections. Regardless of the type, however, the 493 recipients MUST accept both quoted and unquoted representations of 494 values as defined in HTTP. If the parameter is defined to have a 495 string value, implementations MUST send any value outside of the 496 "token" ABNF syntax in either a quoted form or an an ext-value form 497 (see Section 4.1). If the parameter is defined as a token (or 498 similar) or an integer, the value SHOULD follow the corresponding 499 ABNF syntax after possible unquoting of the quoted-string value (as 500 defined in HTTP), and MUST be sent in a plain (not an ext-value) 501 form. (Note: the rest of this document will show all string-value 502 parameters in quoted forms, and others in unquoted forms.) 504 Any parameters contained in this header MAY be ignored by clients. 505 Also, even when a client accepts this header, users are able to 506 circumvent the semantics of this header. Therefore, if this header 507 is used for security purposes, its use MUST be limited to providing 508 some non-fundamental additional security measures valuable for end- 509 users (such as client-side log-out for protecting against console 510 takeover). Server-side applications MUST NOT rely on the use of this 511 header for protecting server-side resources. 513 Note: The header syntax allows servers to specify Authentication- 514 Control for multiple authentication schemes, either as multiple 515 occurrences of this header or as a combined single header (see 516 Section 3.2.2 of [RFC7230] for rationale). The same care as for 517 parsing multiple authentication challenges needs to be taken. 519 4.1. Non-ASCII extended header parameters 521 Parameters contained in the Authentication-Control header MAY be 522 extended to non-ASCII values using the framework described in 523 [RFC5987]. All servers and clients MUST be capable of receiving and 524 sending values encoded in [RFC5987] syntax. 526 If a value to be sent contains only ASCII characters, the field MUST 527 be sent using plain RFC 7235 syntax. The syntax as extended by ext- 528 value MUST NOT be used in this case. 530 If a value (except the "realm" header) contains one or more non-ASCII 531 characters, the parameter SHOULD be sent using the ext-value syntax 532 defined in Section 3.2 of [RFC5987]. Such a parameter MUST have a 533 charset value of "UTF-8", and the language value MUST always be 534 omitted (have an empty value). The same parameter MUST NOT be sent 535 more than once, regardless of the used syntax. 537 For example, a parameter "username" with value "Renee of France" 538 SHOULD be sent as < username="Renee of France" >. If the value is 539 "Rene of France", it SHOULD be sent as 540 < username*=UTF-8''Ren%C3%89e%20of%20France > instead. 542 Interoperability note: [RFC7235], Section 2.2, defines the "realm" 543 authentication parameter which cannot be replaced by the "realm*" 544 extend parameter. It means that the use of non-ASCII values for an 545 authentication realm is not the defined behavior in HTTP. 546 Unfortunately, some people currently use a non-ASCII realm parameter 547 in reality, but even its encoding scheme is not well-defined. 548 Given this background, this document does not specify how to handle a 549 non-ASCII "realm" parameter in the extended header fields. If 550 needed, the authors propose to use a non-extended "realm" parameter 551 form, with a wish for maximum interoperability. 553 4.2. Auth-style parameter 555 Example: 556 Authentication-Control: Digest realm="protected space", 557 auth-style=modal 559 The parameter "auth-style" specifies the server's preference for user 560 interface behavior for user authentication. This parameter can be 561 included in any kind of response, however, it is only meaningful for 562 either authentication-initializing or negatively-authenticated 563 responses. The value of this parameter MUST be one of the bare- 564 tokens "modal" or "non-modal". When the Optional-WWW-Authenticate 565 header is used, the value of this parameter MUST be disregarded and 566 the value "non-modal" is implied. 568 The value "modal" means that the server thinks the content of the 569 response (body and other content-related headers) is valuable only 570 for users refusing the authentication request. The clients are 571 expected to ask the user for a password before processing the 572 content. This behavior is common for most of the current 573 implementations of Basic and Digest authentication schemes. 575 The value "non-modal" means that the server thinks the content of the 576 response (body and other content-related headers) is valuable for 577 users before processing an authentication request. The clients are 578 expected to first process the content and then provide users the 579 opportunity to perform authentication. 581 The default behavior for clients is implementation-dependent, and it 582 may also depend on authentication schemes. The proposed default 583 behavior is "modal" for all authentication schemes unless otherwise 584 specified. 586 The above two different methods of authentication possibly introduce 587 a observable difference of semantics when the response contains 588 state-changing side effects; for example, it can affect how Cookie 589 headers [RFC6265] in 401 responses are processed. However, the 590 server applications SHOULD NOT depend on existence of such side 591 effects. 593 4.3. Location-when-unauthenticated parameter 595 Example: 596 Authentication-Control: Mutual realm="auth-space-1", 597 location-when-unauthenticated="http://www.example.com/login.html" 599 The parameter "location-when-unauthenticated" specifies a location 600 where any unauthenticated clients should be redirected to. This 601 header can be used, for example, when there is a central login page 602 for the entire Web application. The value of this parameter is a 603 string that contains an URL location. If a received URL is not 604 absolute, the clients SHOULD consider it a relative URL from the 605 current location. 607 This parameter MAY be used with a 401 response for an authentication- 608 initializing response. It can also be contained, although this is 609 NOT RECOMMENDED, in a positive response with an 610 Optional-WWW-Authenticate header. The clients MUST ignore this 611 parameter when a response is either successfully-authenticated or 612 intermediately-authenticated. 614 When a client receives an authentication-initiating response with 615 this parameter, and if the client has to ask users for authentication 616 credentials, the client will treat the entire response as if it were 617 a 303 "See Other" response with a Location header that contains the 618 value of this parameter (i.e., client will be redirected to the 619 specified location with a GET request). Unlike a normal 303 620 response, if the client can process authentication without the user's 621 interaction, this parameter MUST be ignored. 623 4.4. No-auth parameter 625 Example: 626 Authentication-Control: Basic realm="entrance", no-auth=true 628 The parameter "no-auth" is a variant of the 629 location-when-unauthenticated parameter; it specifies that new 630 authentication attempts are not to be performed on this location in 631 order to improve the user experience, without specifying the 632 redirection on the HTTP level. This header can be used, for example, 633 when there is a central login page for the entire Web application, 634 and when an explicit user interaction with the Web content is desired 635 before authentication. The value of this parameter MUST be a token 636 "true". If the value is incorrect, client MAY ignore this parameter. 638 This parameter MAY be used with authentication-initiating responses. 639 It can also be contained, although this is NOT RECOMMENDED, in a 640 positive response with an Optional-WWW-Authenticate header. The 641 clients MUST ignore this parameter when a response is either 642 successfully-authenticated or intermediately-authenticated. 644 When a client receives an authentication-initiating response with 645 this parameter, if the client has to ask users for authentication 646 credentials, the client will ignore the WWW-Authenticate header 647 contained in the response and treat the whole response as a normal 648 negative 4xx-class response instead of giving the user an opportunity 649 to start authentication. If the client can process authentication 650 without the user's interaction, this parameter MUST be ignored. 652 Using this parameter along with location-when-unauthenticated 653 parameter is meaningless. If both were supplied, clients SHOULD 654 ignore the location-when-unauthenticated parameter. 656 This parameter SHOULD NOT be used as a security measure to prevent 657 authentication attempts, as it is easily circumvented by users. This 658 parameter SHOULD be used solely for improving user experience of Web 659 applications. 661 4.5. Location-when-logout parameter 663 Example: 664 Authentication-Control: Digest realm="protected space", 665 location-when-logout="http://www.example.com/byebye.html" 667 The parameter "location-when-logout" specifies a location where the 668 client is to be redirected when the user explicitly requests a 669 logout. The value of this parameter MUST be a string that contains 670 an URL location. If a given URL is not absolute, the clients MUST 671 consider it a relative URL from the current location. 673 This parameter MAY be used with successfully-authenticated responses. 674 If this parameter is contained in other kinds of responses, the 675 clients MUST ignore this parameter. 677 When the user tells the client to terminate the current 678 authentication period, if the client currently displays a page 679 supplied by a response with this parameter, the client will 680 automatically change current location to the location specified in 681 this parameter, using a new GET request, as if it has received a 303 682 response. Any operations related to logging-out (e.g. erasing 683 memories of user name, authentication credential and all related one- 684 time credentials such as nonce or keys) SHOULD occur before 685 processing a page transition. 687 When the user requests the client for the termination of an 688 authentication period, if the client supports this parameter but the 689 server response does not contain this parameter, the client's 690 RECOMMENDED behavior is as follows: if the request corresponding to 691 the current content was GET method, reload the page without the 692 authentication credential. Otherwise, keep the current content as-is 693 and simply forget the authentication status. The client SHOULD NOT 694 replay a non-idempotent request without the user's explicit approval. 696 Web applications are encouraged to send this parameter with an 697 appropriate value for any responses (except those with redirection 698 (3XX) statuses) for non-GET requests. 700 See Section 5 for some examples for possible deployment of this 701 parameter. 703 4.6. Logout-timeout parameter 705 Example: 706 Authentication-Control: Basic realm="entrance", logout-timeout=300 708 The parameter "logout-timeout", when contained in a successfully- 709 authenticated response, means that any authentication credentials and 710 state related to the current protection space are to be discarded if 711 a time specified in this header (in seconds) has passed since the 712 time this header was received. The value MUST be an integer. As a 713 special case, the value 0 means that the server is logging the client 714 out immediately from the current authentication space and that the 715 client is now returns to unauthenticated state. This does not, 716 however, mean that the long-term memories for the passwords and 717 passwords-related details (such as password reminders and auto fill- 718 ins) should be removed. If a new timeout value is received for the 719 same authentication space, it cancels the previous timeout and sets a 720 new timeout. 722 4.7. Username parameter 724 Example: 725 Authentication-Control: Basic realm="configuration", username="admin" 727 The parameter "username" tells that the only "user name" to be 728 accepted by the server is the value given in this parameter. 730 This parameter is particularly useful, for example, for routers and 731 other network appliances with a Web configuration interface. Many of 732 those use a HTTP Basic authentication with one predefined user name, 733 with many varieties such as "admin", "root", "user" etc. In current 734 situation, users have almost no hint about the valid user name upon 735 the authentication request. Some shows the valid value in a "realm" 736 string, some in the 401-status response page, shown _after_ the user 737 giving up the authentication and cancelled the authentication dialog. 738 If this parameter is given, the client Web browser can auto-fill the 739 user-name field in the authentication dialog before the users attempt 740 to authenticate themselves. 742 This parameter MAY be used with authentication-initiating responses 743 or negatively-authenticated responses requiring another attempt of 744 authentication. The clients MUST ignore this parameter when a 745 response is either successfully-authenticated or intermediately- 746 authenticated. 748 If the authentication scheme to be used has a syntax limitation on 749 the allowed user names (e.g. Basic and Digest do not allow colons in 750 user names), the specified value MUST follow that limitation. 751 Clients SHOULD ignore any values which do not conform to such 752 limitations. 754 Also, if the used authentication scheme requires a specific style of 755 text preparation for the user name (e.g., PRECIS [RFC7564] string 756 preparation or Unicode normalization), the server SHOULD send the 757 values satisfying such requirements (so that clients can use the 758 given user name as is). 760 Clients MAY still send any authentication requests with other user 761 names, possibly in vain. Clients are not required (also not 762 forbidden) to give users opportunities for supplying a user name 763 different from the server-specified one. Servers are also not 764 strictly required to reject user names other than specified, but 765 doing so will usually give bad user experiences and may confuse users 766 and clients. 768 Although this parameter is useful in a specific class of use cases, 769 using it in a general use cases has many security implications and 770 possible pit-falls. Please consult Section 8.1 before deciding to 771 use this parameter. 773 5. Usage examples 775 This section shows some examples for applying this extension to 776 typical websites which are using Forms and cookies for managing 777 authentication and authorization. The content of this section is not 778 normative and for illustrative purposes only. 780 In these examples, we assume that there are two kinds of clients (Web 781 browsers). One kind of these implements all features described in 782 the previous sections. We also assume that browsers will have a user 783 interface which allows users to deactivate (log-out from) current 784 authentication sessions. The other kind are the "existing" 785 implementations which do not support any of these features. 787 When not explicitly specified, all settings described below are to be 788 applied with Authentication-Control headers, and these can be sent to 789 clients regardless of the authentication status (these will be 790 silently ignored whenever not effective). 792 5.1. Example 1: a portal site 794 This subsection provides an example application for a site whose 795 structure is somewhat similar to conventional portal sites. In 796 particular, most web pages are available for guest (unauthenticated) 797 users, and if authentication is performed, the content of these pages 798 is customized for each user. We assume the site has the following 799 kinds of pages currently: 801 o Content pages. 803 o Pages/mechanism for performing authentication: 805 * There is one page which asks a user name and a password using a 806 HTML POST form. 808 * After the authentication attempt, the user will be redirected 809 to either the page which is previously displayed before the 810 authentication, or some specific page. 812 o A de-authentication (log-out) page. 814 5.1.1. Case 1: a simple application 816 When such a site does not require specific actions upon log-in and 817 log-out, the following simple settings can be used. 819 o Set up an optional authentication to all pages available to 820 guests. Set up an Authentication-Control header with "auth- 821 style=non-modal" setting. 823 o If there are pages only available to authenticated users, set up a 824 mandatory authentication with "auth-style=non-modal" setting. 826 o No specific pages for authentication are needed. It will be 827 performed automatically, directed by the above setting. 829 o A de-authentication page is also not needed. If the site has one, 830 put "logout-timeout=0" there. 832 o For all pages for POST requests, it is advisable to have 833 "location-when-logout=". 835 5.1.2. Case 2: specific action required on log-out 837 If the site requires specific actions upon log-out, the following 838 settings can be used. 840 o All settings in the Case 1 are applied. 842 o For all pages, set up the Authentication-Control header "location- 843 when-logout=". 845 o In the de-authentication page, no specific set-up is needed. If 846 there are any direct links to the de-authentication page, put 847 "logout-timeout=0". 849 5.1.3. Case 3: specific page displayed before log-in 851 If the site needs to display a specific page before log-in actions 852 (some announcements, user notices, or even advertisements), the 853 following settings can be applied. 855 o Set up an optional authentication to all pages available to 856 guests. Set up an Authentication-Control header with "no- 857 auth=true". Put a link to a specific log-in page in contents. 859 o If there are pages only available to authenticated users, set up a 860 mandatory authentication with "location-when-unauthenticated=". 863 o For the specific log-in page, set up a mandatory authentication. 865 o For all pages for POST requests, it is advisable to have 866 "location-when-logout=", too. 868 o De-authentication pages are not needed. If the site has one, put 869 "logout-timeout=0". 871 5.2. Example 2: authenticated user-only sites 873 If almost all pages in the target site require authentication (e.g., 874 an Internet banking site), or if there are no needs to support both 875 unauthenticated and authenticated users on the same resource, the 876 settings will become simpler. The following are an example for such 877 a site: 879 o Set up a mandatory authentication to all pages available to 880 authenticated users. Set up an Authentication-Control header with 881 "auth-style=non-modal" setting. 883 o Set up a handler for the 401-status which requests users to 884 authenticate. 886 o For all pages for POST requests, it is advisable to have 887 "location-when-logout=", too. 889 o De-authentication pages are not needed. If the site will have 890 one, put "logout-timeout=0" there. 892 5.3. When to use Cookies 894 In current Web sites using form-based authentication, Cookies 895 [RFC6265] are used for managing both authorization and application 896 sessions. Using the extensions in this document, the former features 897 will be provided by using (extended) HTTP authentication/ 898 authorization mechanisms. In some cases, there will be ambiguity on 899 whether some functions are for authorization management or for 900 session management. The following hints will be helpful for deciding 901 which features to use. 903 o If there is a need to serve multiple sessions for a single user 904 using multiple browsers concurrently, use a Cookie for 905 distinguishing between sessions for the same user. (C.f. if there 906 is a need to distinguish sessions in the same browser, HTML5 Web 907 Storage [W3C.REC-webstorage-20130730] features can be used instead 908 of Cookies.) 910 o If a web site is currently deploying a session time-out feature, 911 consider who benefits from the feature. In most cases, the main 912 requirement for such a feature is to protect users from having 913 their consoles and browsers hijacked (i.e. benefits are on the 914 users' side). In such cases, the time-out features provided in 915 this extension can be used. On the other hand, the requirement is 916 to protect server's privilege (e.g. when some regulations require 917 to limit the time difference between user's two-factor 918 authentication and financial transaction commitment; the 919 requirement is strictly on the servers' side), that should be 920 managed on the server side using Cookies or other session 921 management mechanisms. 923 5.4. Parallel deployment with Form/Cookie authentication 925 In some transition periods, sites can need to support both HTTP-layer 926 and form-based authentication. The following example shows one way 927 to achieve that. 929 o If Cookies are used even for HTTP-authenticated users, each 930 session determined by Cookies SHOULD identify which authentication 931 has been used for the session. 933 o First, set up any of the above settings for enabling HTTP-layer 934 authentication. 936 o For unauthenticated users, add the following things to the Web 937 pages, unless the client supports this extension and HTTP-level 938 authentication. 940 * For non-mandatory authenticated pages, put a link to Form-based 941 authenticated pages. 943 * For mandatory authenticated pages, either put a link to Form- 944 based authenticated pages, or put a HTML-level redirection 945 (using element) to such pages. 947 o In Form-based authenticated pages, if users are not authenticated, 948 the page can provide a redirection for HTTP-level authentication 949 by "location-when-unauthenticated" setting. 951 o Users are identified to authorization and content customization by 952 the following logic. 954 * First, check the result of the HTTP-level authentication. If 955 there is a Cookie session tied to a specific user, both should 956 match. 958 * If the user is not authenticated on the HTTP-level, use the 959 conventional Form-based method to determine the user. 961 * If there is a Cookie tied to HTTP authentication, but there is 962 no corresponding HTTP authentication result, that session will 963 be discarded (because it means that authentication is 964 deactivated by the corresponding user). 966 6. Methods to extend this protocol 968 If a private extension to this protocol is implemented, it MUST use 969 the extension-param to avoid conflicts with this protocol and any 970 other extensions. (Standardized or being-standardized extensions MAY 971 use either bare-tokens or extension-tokens.) 973 When bare-tokens are used in this protocol, these MUST be allocated 974 by IANA. Any tokens used for non-private, non-experimental 975 parameters are RECOMMENDED to be registered to IANA, regardless of 976 the kind of tokens used. 978 Extension-tokens MAY be freely used for any non-standard, private, 979 and/or experimental uses. An extension-tokens MUST use the format 980 "-.", where is a validly 981 registered (sub-)domain name on the Internet owned by the party who 982 defines the extensions. Any unknown parameter name is to be ignored 983 regardless of whether it is an extension-token or a bare-token. 985 7. IANA Considerations 987 This document defines two new entries for the "Permanent Message 988 Header Field Names" registry. 990 +-------------+---------------------------+-------------------------+ 991 | | Entry 1: | Entry 2: | 992 +-------------+---------------------------+-------------------------+ 993 | Header | Optional-WWW-Authenticate | Authentication-Control | 994 | Field Name | | | 995 | Protocol | http | http | 996 | Status | experimental | experimental | 997 | Change | IETF | IETF | 998 | Control | | | 999 | Spec. | Section 3 of this | Section 4 of this | 1000 | Document | document | document | 1001 +-------------+---------------------------+-------------------------+ 1003 This document also establishes a registry for HTTP authentication 1004 control parameters. The registry manages case-insensitive ASCII 1005 strings. The string MUST follow the extensive-token syntax defined 1006 in Section 2.2. 1008 To acquire registered tokens, a specification for the use of such 1009 tokens MUST be available as a publicly-accessible document, as 1010 outlined as "Specification Required" level in [RFC5226]. 1012 Registrations for authentication control parameters are required to 1013 include a description of the control extension. New registrations 1014 are advised to provide the following information: 1016 o Token: a token used in HTTP headers for identifying the algorithm. 1018 o Specification: A reference for a specification defining the 1019 algorithm. 1021 The initial content of this registry is as follows: 1023 +-------------------------------+------------------------------+ 1024 | Token | Specification | 1025 +-------------------------------+------------------------------+ 1026 | auth-style | Section 4.2 of this document | 1027 | location-when-unauthenticated | Section 4.3 of this document | 1028 | no-auth | Section 4.4 of this document | 1029 | location-when-logout | Section 4.5 of this document | 1030 | logout-timeout | Section 4.6 of this document | 1031 | username | Section 4.7 of this document | 1032 +-------------------------------+------------------------------+ 1034 8. Security Considerations 1036 The purpose of the log-out timeout feature in the Authentication- 1037 control header is to protect users of clients from impersonation 1038 caused by an attacker having access to the same console. The server 1039 application implementers SHOULD be aware that the directive may 1040 always be ignored by either malicious clients or clients not 1041 supporting this extension. If the purpose of introducing a timeout 1042 for an authentication period is to protect server-side resources, 1043 this protection MUST be implemented by other means such as HTTP 1044 Cookies [RFC6265]. 1046 All parameters in the Authentication-Control header SHOULD NOT be 1047 used for any security-enforcement purposes. Server-side applications 1048 MUST NOT assume that the header will be honored by clients and users. 1050 8.1. Security implication of the username parameter 1052 The "username" parameter sometimes reveals sensitive information 1053 about the HTTP server and its configurations, useful for security 1054 attacks. In general, security common practice suggests that any kind 1055 of information on the existence/non-existence of specific user-name 1056 shall not be disclosed before the successful authentication. 1057 Obviously, the "username" parameter contradicts with this practice. 1059 Given this background, the use of the "username" parameter SHOULD be 1060 strictly limited to cases where the all of the following conditions 1061 are met: 1063 (1) the valid user name is pre-configured and not modifiable (such 1064 as root, admin or similar ones); 1066 (2) the valid user name for such an appliance is publicly known (for 1067 example, written in a manual document); and 1069 (3) either the valid user name for the server is easily guessable by 1070 other means (for example, from the model number shown in an 1071 unauthenticated page), or the server is accessible only from 1072 limited networks. 1074 Most importantly, the "username" parameter SHOULD NOT be used in any 1075 case when the valid user names can be changed/configured by users or 1076 administrators. 1078 9. References 1080 9.1. Normative References 1082 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1083 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 1084 RFC2119, March 1997, 1085 . 1087 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1088 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1089 DOI 10.17487/RFC5226, May 2008, 1090 . 1092 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1093 Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ 1094 RFC5234, January 2008, 1095 . 1097 [RFC5987] Reschke, J., "Character Set and Language Encoding for 1098 Hypertext Transfer Protocol (HTTP) Header Field 1099 Parameters", RFC 5987, DOI 10.17487/RFC5987, August 2010, 1100 . 1102 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1103 Protocol (HTTP/1.1): Message Syntax and Routing", 1104 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1105 . 1107 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1108 Protocol (HTTP/1.1): Authentication", RFC 7235, 1109 DOI 10.17487/RFC7235, June 2014, 1110 . 1112 9.2. Informative References 1114 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 1115 DOI 10.17487/RFC6265, April 2011, 1116 . 1118 [RFC7564] Saint-Andre, P. and M. Blanchet, "PRECIS Framework: 1119 Preparation, Enforcement, and Comparison of 1120 Internationalized Strings in Application Protocols", 1121 RFC 7564, DOI 10.17487/RFC7564, May 2015, 1122 . 1124 [RFC7615] Reschke, J., "HTTP Authentication-Info and Proxy- 1125 Authentication-Info Response Header Fields", RFC 7615, 1126 DOI 10.17487/RFC7615, September 2015, 1127 . 1129 [W3C.REC-webstorage-20130730] 1130 Hickson, I., "Web Storage", World Wide Web Consortium 1131 Recommendation REC-webstorage-20130730, July 2013, 1132 . 1134 Appendix A. (Informative) Applicability of features for each messages 1136 This section provides a cross-reference table showing the 1137 applicability of the features provided in this specification to each 1138 kind of responses described in Section 2.1. The table provided in 1139 this section is for informative purposes only. 1141 +-------------------+-------+----------+-----------+------+ 1142 | | init. | success. | intermed. | neg. | 1143 +-------------------+-------+----------+-----------+------+ 1144 | Optional auth. | O | n | N | N | 1145 | auth-style | O | - | - | O | 1146 | loc.-when-unauth. | O | I | I | i | 1147 | no-auth | O | I | I | i | 1148 | loc.-when-logout | - | O | - | - | 1149 | logout-timeout | - | O | - | - | 1150 | username | O | - | - | O | 1151 +-------------------+-------+----------+-----------+------+ 1153 Legends: 1154 O = MAY contain; n = SHOULD NOT contain; N = MUST NOT contain 1155 i = SHOULD be ignored; I = MUST be ignored; 1156 - = meaningless (to be ignored) 1158 Appendix B. (Informative) Draft Change Log 1160 [To be removed on final publication] 1162 B.1. Changes in Httpauth WG Revision 09 1164 o More comments are reflected to the text. 1166 B.2. Changes in Httpauth WG Revision 08 1168 o Typo fixed. 1170 o Authors' addresses updated. 1172 B.3. Changes in Httpauth WG Revision 07 1174 o WGLC comments are reflected to the text. 1176 B.4. Changes in Httpauth WG Revision 06 1178 o Several comments from reviewers are reflected to the text. 1180 B.5. Changes in Httpauth WG Revision 05 1182 o Authors' addresses updated. 1184 B.6. Changes in Httpauth WG revision 04 1186 o IANA consideration section added. 1188 B.7. Changes in Httpauth WG revision 03 1190 o Adopting RFC 5987 extended syntax for non-ASCII parameter values. 1192 B.8. Changes in Httpauth WG revision 02 1194 o Added realm parameter. 1196 o Added username parameter. We acknowledge Michael Sweet's proposal 1197 for including this to the Basic authentication. 1199 B.9. Changes in Httpauth WG revision 01 1201 o Clarification on peers' responsibility about handling of relative 1202 URLs. 1204 o Automatic reloading should be allowed only on safe methods, not 1205 always on idempotent methods. 1207 B.10. Changes in Httpauth revision 00 and HttpBis revision 00 1209 None. 1211 B.11. Changes in revision 02 1213 o Added usage examples. 1215 B.12. Changes in revision 01 1217 o Syntax notations and parsing semantics changed to match httpbis 1218 style. 1220 B.13. Changes in revision 00 1222 o Separated from HTTP Mutual authentication proposal (-09). 1224 o Adopting httpbis works as a referencing point to HTTP. 1226 o Generalized, now applicable for all HTTP authentication schemes. 1228 o Added "no-auth" and "auth-style" parameters. 1230 o Loosened standardization requirements for parameter-name tokens 1231 registration. 1233 Authors' Addresses 1235 Yutaka Oiwa 1236 National Institute of Advanced Industrial Science and Technology 1237 Information Technology Research Institute 1238 Tsukuba Central 1 1239 1-1-1 Umezono 1240 Tsukuba-shi, Ibaraki 1241 JP 1243 Email: y.oiwa@aist.go.jp 1245 Hajime Watanabe 1246 National Institute of Advanced Industrial Science and Technology 1247 Information Technology Research Institute 1248 Tsukuba Central 1 1249 1-1-1 Umezono 1250 Tsukuba-shi, Ibaraki 1251 JP 1253 Email: h-watanabe@aist.go.jp 1255 Hiromitsu Takagi 1256 National Institute of Advanced Industrial Science and Technology 1257 Information Technology Research Institute 1258 Tsukuba Central 1 1259 1-1-1 Umezono 1260 Tsukuba-shi, Ibaraki 1261 JP 1263 Email: takagi.hiromitsu@aist.go.jp 1265 Kaoru Maeda 1266 Lepidum Co. Ltd. 1267 Village Sasazuka 3, Suite #602 1268 1-30-3 Sasazuka 1269 Shibuya-ku, Tokyo 1270 JP 1272 Email: maeda@lepidum.co.jp 1273 Tatsuya Hayashi 1274 Lepidum Co. Ltd. 1275 Village Sasazuka 3, Suite #602 1276 1-30-3 Sasazuka 1277 Shibuya-ku, Tokyo 1278 JP 1280 Email: hayashi@lepidum.co.jp 1282 Yuichi Ioku 1283 Individual 1285 Email: mutual-work@ioku.org