draft-ietf-httpauth-extension-03.txt   draft-ietf-httpauth-extension-04.txt 
HTTPAUTH Working Group Y. Oiwa HTTPAUTH Working Group Y. Oiwa
Internet-Draft H. Watanabe Internet-Draft H. Watanabe
Intended status: Experimental H. Takagi Intended status: Experimental H. Takagi
Expires: August 23, 2015 RISEC, AIST Expires: January 7, 2016 ITRI, AIST
T. Hayashi T. Hayashi
Lepidum Lepidum
Y. Ioku Y. Ioku
Individual Individual
February 19, 2015 July 6, 2015
HTTP Authentication Extensions for Interactive Clients HTTP Authentication Extensions for Interactive Clients
draft-ietf-httpauth-extension-03 draft-ietf-httpauth-extension-04
Abstract Abstract
This document specifies a few extensions of HTTP authentication This document specifies a few extensions of HTTP authentication
framework for interactive clients. Recently, fundamental features of framework for interactive clients. Recently, fundamental features of
HTTP-level authentication is not enough for complex requirements of HTTP-level authentication is not enough for complex requirements of
various Web-based applications. This makes these applications to various Web-based applications. This makes these applications to
implement their own authentication frameworks using HTML Forms and implement their own authentication frameworks using HTML Forms and
other means, which becomes one of the hurdles against introducing other means, which becomes one of the hurdles against introducing
secure authentication mechanisms handled jointly by servers and user- secure authentication mechanisms handled jointly by servers and user-
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 23, 2015. This Internet-Draft will expire on January 7, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 32 skipping to change at page 3, line 32
5.1. Example 1: a portal site . . . . . . . . . . . . . . . . . 16 5.1. Example 1: a portal site . . . . . . . . . . . . . . . . . 16
5.1.1. Case 1: a simple application . . . . . . . . . . . . . 17 5.1.1. Case 1: a simple application . . . . . . . . . . . . . 17
5.1.2. Case 2: specific action required on log-out . . . . . 17 5.1.2. Case 2: specific action required on log-out . . . . . 17
5.1.3. Case 3: specific page displayed before log-in . . . . 17 5.1.3. Case 3: specific page displayed before log-in . . . . 17
5.2. Example 2: authenticated user-only sites . . . . . . . . . 18 5.2. Example 2: authenticated user-only sites . . . . . . . . . 18
5.3. When to use Cookies . . . . . . . . . . . . . . . . . . . 18 5.3. When to use Cookies . . . . . . . . . . . . . . . . . . . 18
5.4. Parallel deployment with Form/Cookie authentications . . . 19 5.4. Parallel deployment with Form/Cookie authentications . . . 19
6. Methods to extend this protocol . . . . . . . . . . . . . . . 20 6. Methods to extend this protocol . . . . . . . . . . . . . . . 20
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Normative References . . . . . . . . . . . . . . . . . . . 21 9.1. Normative References . . . . . . . . . . . . . . . . . . . 22
9.2. Informative References . . . . . . . . . . . . . . . . . . 22 9.2. Informative References . . . . . . . . . . . . . . . . . . 22
Appendix A. (Informative) Applicability of features for each Appendix A. (Informative) Applicability of features for each
messages . . . . . . . . . . . . . . . . . . . . . . 22 messages . . . . . . . . . . . . . . . . . . . . . . 23
Appendix B. (Informative) Draft Notes . . . . . . . . . . . . . . 23 Appendix B. (Informative) Draft Notes . . . . . . . . . . . . . . 23
Appendix C. (Informative) Draft Change Log . . . . . . . . . . . 23 Appendix C. (Informative) Draft Change Log . . . . . . . . . . . 24
C.1. Changes in Httpauth WG revision 03 . . . . . . . . . . . . 23 C.1. Changes in Httpauth WG revision 04 . . . . . . . . . . . . 24
C.2. Changes in Httpauth WG revision 02 . . . . . . . . . . . . 23 C.2. Changes in Httpauth WG revision 03 . . . . . . . . . . . . 24
C.3. Changes in Httpauth WG revision 01 . . . . . . . . . . . . 23 C.3. Changes in Httpauth WG revision 02 . . . . . . . . . . . . 24
C.4. Changes in Httpauth revision 00 and HttpBis revision 00 . 24 C.4. Changes in Httpauth WG revision 01 . . . . . . . . . . . . 24
C.5. Changes in revision 02 . . . . . . . . . . . . . . . . . . 24 C.5. Changes in Httpauth revision 00 and HttpBis revision 00 . 24
C.6. Changes in revision 01 . . . . . . . . . . . . . . . . . . 24 C.6. Changes in revision 02 . . . . . . . . . . . . . . . . . . 24
C.7. Changes in revision 00 . . . . . . . . . . . . . . . . . . 24 C.7. Changes in revision 01 . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 C.8. Changes in revision 00 . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
The document proposes several extensions to the current HTTP The document proposes several extensions to the current HTTP
authentication framework, to provide enough functionality comparable authentication framework, to provide enough functionality comparable
with current widely-used form-based Web authentication. A majority with current widely-used form-based Web authentication. A majority
of the recent Web-sites on the Internet use custom application-layer of the recent Web-sites on the Internet use custom application-layer
authentication implementations using Web forms. The reasons for authentication implementations using Web forms. The reasons for
these may vary, but many people believe that the current HTTP Basic these may vary, but many people believe that the current HTTP Basic
(and Digest, too) authentication method does not have enough (and Digest, too) authentication method does not have enough
skipping to change at page 4, line 32 skipping to change at page 4, line 32
methods can be used with Web applications. The extensions proposed methods can be used with Web applications. The extensions proposed
in this document include: in this document include:
o non-mandatory, optional authentication on HTTP (Section 3), o non-mandatory, optional authentication on HTTP (Section 3),
o log out from both server and client side (Section 4), and o log out from both server and client side (Section 4), and
o finer control for redirection depending on authentication status o finer control for redirection depending on authentication status
(Section 4). (Section 4).
[I-D note: These extensions are initially proposed as a part of
[I-D.ietf-httpauth-mutual]. However, since these functionalities
might possibly be useful in combination even with other
authentication schemes, the extensions were separated from the
original document as this independent draft.]
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
The terms "encouraged" and "advised" are used for suggestions that do The terms "encouraged" and "advised" are used for suggestions that do
not constitute "SHOULD"-level requirements. People MAY freely choose not constitute "SHOULD"-level requirements. People MAY freely choose
not to include the suggested items regarding [RFC2119], but complying not to include the suggested items regarding [RFC2119], but complying
skipping to change at page 7, line 44 skipping to change at page 7, line 44
| non-auth. \successful successful +-----------+ | non-auth. \successful successful +-----------+
| response (*2) \ / | ^ | response (*2) \ / | ^
v \ / | | v \ / | |
----------------- \ -------------- / `----' ----------------- \ -------------- / `----'
( UNAUTHENTICATED ) ----->( AUTH-SUCCEED )<---- intermediate ( UNAUTHENTICATED ) ----->( AUTH-SUCCEED )<---- intermediate
----------------- -------------- ----------------- --------------
Figure 1: Generic state diagram for HTTP authentication Figure 1: Generic state diagram for HTTP authentication
Note: (*1) For example, "Digest" scheme requires server-provided Note: (*1) For example, "Digest" scheme requires server-provided
nonces to construct client-side challenges. nonce to construct client-side challenges.
(*2) In "Basic" and some others, this cannot be distinguished from a (*2) In "Basic" and some others, this cannot be distinguished from a
successfully-authenticated response. successfully-authenticated response.
2.2. Syntax Notation 2.2. Syntax Notation
This specification uses an extended BNF syntax defined in [RFC7230]. This specification uses an extended BNF syntax defined in [RFC7230].
The following syntax definitions are quoted from [RFC7230] and The following syntax definitions are quoted from [RFC7230] and
[RFC7235]: auth-scheme, quoted-string, auth-param, SP, BWS, header- [RFC7235]: auth-scheme, quoted-string, auth-param, SP, BWS, header-
field, and challenge. It also uses the convention of using header field, and challenge. It also uses the convention of using header
names for specifying syntax of header values. names for specifying syntax of header values.
Additionally, this specification uses the following syntax elements Additionally, this specification uses the following syntax elements
following syntax definitions as a refinement for token and the following syntax definitions as a refinement for token and the right-
righthand-side of auth-param in [RFC7235]. (Note: these definitions hand-side of auth-param in [RFC7235]. (Note: these definitions are
are consistent with those in [I-D.ietf-httpauth-mutual].) consistent with those in [I-D.ietf-httpauth-mutual].)
bare-token = 1*(%x30-39 / %x41-5A / %x61-7A / "-" / "_") bare-token = 1*(%x30-39 / %x41-5A / %x61-7A / "-" / "_")
extension-token = "-" bare-token 1*("." bare-token) extension-token = "-" bare-token 1*("." bare-token)
extensive-token = bare-token / extension-token extensive-token = bare-token / extension-token
integer = "0" / (%x31-39 *%x30-39) ; no leading zeros integer = "0" / (%x31-39 *%x30-39) ; no leading zeros
Figure 2: the BNF syntax for common notations Figure 2: the BNF syntax for common notations
Extensive-tokens are used in this protocol where the set of Extensive-tokens are used in this protocol where the set of
acceptable tokens may include private extensions. Any private acceptable tokens may include private extensions. Any private
skipping to change at page 11, line 37 skipping to change at page 11, line 37
a client accepts this header, users may always be able to circumvent a client accepts this header, users may always be able to circumvent
semantics of this header. Therefore, if this header is used for semantics of this header. Therefore, if this header is used for
security purposes, its use MUST be limited for providing some non- security purposes, its use MUST be limited for providing some non-
fundamental additional security measures valuable for end-users (such fundamental additional security measures valuable for end-users (such
as client-side log-out for protecting against console takeover). as client-side log-out for protecting against console takeover).
Server-side application MUST NOT rely on the use of this header for Server-side application MUST NOT rely on the use of this header for
protecting server-side resources. protecting server-side resources.
Note: The header syntax allows servers to specify Authentication- Note: The header syntax allows servers to specify Authentication-
Control for multiple authentication schemes, either as multiple Control for multiple authentication schemes, either as multiple
occurances of this header or as a combined single header (see Section occurrences of this header or as a combined single header (see
3.2.2 of [RFC7230] for rationale). The same care as for parsing Section 3.2.2 of [RFC7230] for rationale). The same care as for
multiple authnetication challenges SHALL be taken. parsing multiple authentication challenges SHALL be taken.
4.1. Non-ASCII extended header parameters 4.1. Non-ASCII extended header parameters
Parameters contained in the Authentication-Control header MAY be Parameters contained in the Authentication-Control header MAY be
extended to ISO 10646-1 values using the framework described in extended to ISO 10646-1 values using the framework described in
[RFC5987]. All servers and clients MUST be capable of receiving and [RFC5987]. All servers and clients MUST be capable of receiving and
sending values encoded in [RFC5987] syntax. sending values encoded in [RFC5987] syntax.
If a value to be sent contains only ASCII characters, the field MUST If a value to be sent contains only ASCII characters, the field MUST
be sent in clear using plain RFC 7235 syntax. The syntax extended by be sent in clear using plain RFC 7235 syntax. The syntax extended by
skipping to change at page 20, line 5 skipping to change at page 20, line 5
authenticated pages. authenticated pages.
* For mandatory authenticated pages, either put a link to Form- * For mandatory authenticated pages, either put a link to Form-
based authenticated pages, or put a HTML-level redirection based authenticated pages, or put a HTML-level redirection
(using META element) to such pages. (using META element) to such pages.
o In Form-based authenticated pages, if users are not authenticated, o In Form-based authenticated pages, if users are not authenticated,
it may have a diversion for HTTP-level authentication by it may have a diversion for HTTP-level authentication by
"location-when-unauthenticated" setting. "location-when-unauthenticated" setting.
o Users are identified for authorizations and content customizations o Users are identified for authorizations and content customization
by the following logic. by the following logic.
* First, check the result of the HTTP-level authentication. If * First, check the result of the HTTP-level authentication. If
there is a Cookie session tied to a specific user, both ones there is a Cookie session tied to a specific user, both ones
should match. should match.
* If the user is not authenticated on the HTTP-level, use the * If the user is not authenticated on the HTTP-level, use the
conventional Form-based method to determine the user. conventional Form-based method to determine the user.
* If there is a Cookie tied to an HTTP authentication, but there * If there is a Cookie tied to an HTTP authentication, but there
is no corresponding HTTP authentication result, that session is no corresponding HTTP authentication result, that session
will be discarded (because it means that authentication is will be discarded (because it means that authentication is
deactivated by the corresponding user). deactivated by the corresponding user).
6. Methods to extend this protocol 6. Methods to extend this protocol
If a private extension to this protocol is implemented, it MUST use If a private extension to this protocol is implemented, it MUST use
the extension-param to avoid conflicts with this protocol and other the extension-param to avoid conflicts with this protocol and other
future official extensions. future official extensions.
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 to IANA, regardless of
the kind of tokens used.
Extension-tokens MAY be freely used for any non-standard, private, Extension-tokens MAY be freely used for any non-standard, private,
and/or experimental uses. The extension-tokens MUST be with format and/or experimental uses. The extension-tokens MUST be with format
"-<bare-token>.<domain-name>", where <domain-name> is a validly "-<bare-token>.<domain-name>", where <domain-name> is a validly
registered (sub-)domain name on the Internet owned by the party who registered (sub-)domain name on the Internet owned by the party who
defines the extensions. Unknown parameter names are to be ignored defines the extensions. Unknown parameter names are to be ignored
regardless of whether it is extension-tokens or bare-tokens. regardless of whether it is extension-tokens or bare-tokens.
7. IANA Considerations 7. IANA Considerations
The header "Optional-WWW-Authenticate" and "Authentication-Control" This document defines two new entries for the "Permanent Message
should be registered to IANA registry appropriately (TO-DO). Header Field Names" registry.
Tokens used for the authentication control parameters may be either +---------------------------+----------+----------------------------+
extension-tokens or bare-tokens as outlined in Section 2.2. When | Header Field Name | Protocol | Specification |
bare-tokens are used in this protocol, these MUST be allocated by +---------------------------+----------+----------------------------+
IANA. Any tokens used for non-private, non-experimental parameters | Optional-WWW-Authenticate | http | Section 3 of this document |
are RECOMMENDED to be registered to IANA, regardless of the kind of | Authentication-Control | http | Section 4 of this document |
tokens used. +---------------------------+----------+----------------------------+
This document also establishes a registry for HTTP authentication
control parameters. The registry manages a 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 To acquire registered tokens, a specification for the use of such
tokens MUST be available as a publicly-accessible documents, as tokens MUST be available as a publicly-accessible documents, as
outlined as "Specification Required" level in [RFC5226]. outlined as "Specification Required" level in [RFC5226].
Note: More formal declarations will be added in the future drafts to Registrations for authentication algorithms are required to include a
meet the RFC 5226 requirements. 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 a 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 8. Security Considerations
The purpose of the log-out timeout feature in the Authentication- The purpose of the log-out timeout feature in the Authentication-
control header is to protect users of clients from impersonation control header is to protect users of clients from impersonation
caused by an attacker having access to the same console. Server caused by an attacker having access to the same console. Server
application implementors SHOULD be aware that the directive may application implementer SHOULD be aware that the directive may always
always be ignored by either malicious clients or clients not be ignored by either malicious clients or clients not supporting this
supporting this extension. If the purpose of introducing a timeout extension. If the purpose of introducing a timeout for an
for an authentication period is to protect server-side resources, authentication period is to protect server-side resources, such
such features MUST be implemented by other means such as HTTP Cookies features MUST be implemented by other means such as HTTP Cookies
[RFC6265]. [RFC6265].
All parameters in Authentication-Control header SHOULD NOT be used All parameters in Authentication-Control header SHOULD NOT be used
for any security-enforcement purposes. Server-side applications MUST for any security-enforcement purposes. Server-side applications MUST
be implemented always considering that the header may be either be implemented always considering that the header may be either
ignored by clients or even bypassed by users. ignored by clients or even bypassed by users.
The "username" parameter may reveal sensitive information about the The "username" parameter may reveal sensitive information about the
HTTP server and its configurations, useful for security attacks. The HTTP server and its configurations, useful for security attacks. The
use of the "username" parameter SHOULD be limited to cases where the use of the "username" parameter SHOULD be limited to cases where the
all of the following conditions are met: all of the following conditions are met:
(1) the valid user name is pre-configured and not modifiable (such (1) the valid user name is pre-configured and not modifiable (such
as root, admin or similar ones); as root, admin or similar ones);
(2) the valid user name for such an appliance is publicly known (for (2) the valid user name for such an appliance is publicly known (for
example, written in a manual); and example, written in a manual); and
(3) either the valid user name for the server is easily guessable by (3) either the valid user name for the server is easily guessable by
other means (for example, from the model number shown in an other means (for example, from the model number shown in an
unauthenticated page), or the server is only accesible from unauthenticated page), or the server is only accessible from
limited networks. limited networks.
Especially, it SHOULD NOT be used in any case when the valid user Especially, it SHOULD NOT be used in any case when the valid user
names are configured by its users or administrators. names are configured by its users or administrators.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 22, line 21 skipping to change at page 22, line 51
June 2014. June 2014.
[RFC7235] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol [RFC7235] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Authentication", RFC 7235, June 2014. (HTTP/1.1): Authentication", RFC 7235, June 2014.
9.2. Informative References 9.2. Informative References
[I-D.ietf-httpauth-mutual] [I-D.ietf-httpauth-mutual]
Oiwa, Y., Watanabe, H., Takagi, H., Maeda, K., Hayashi, Oiwa, Y., Watanabe, H., Takagi, H., Maeda, K., Hayashi,
T., and Y. Ioku, "Mutual Authentication Protocol for T., and Y. Ioku, "Mutual Authentication Protocol for
HTTP", draft-ietf-httpauth-mutual-04 (work in progress), HTTP", draft-ietf-httpauth-mutual-05 (work in progress),
February 2015. July 2015.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
April 2011. April 2011.
[W3C.REC-webstorage-20130730] [W3C.REC-webstorage-20130730]
Hickson, I., "Web Storage", World Wide Web Consortium Hickson, I., "Web Storage", World Wide Web Consortium
Recommendation REC-webstorage-20130730, July 2013, Recommendation REC-webstorage-20130730, July 2013,
<http://www.w3.org/TR/2013/REC-webstorage-20130730>. <http://www.w3.org/TR/2013/REC-webstorage-20130730>.
Appendix A. (Informative) Applicability of features for each messages Appendix A. (Informative) Applicability of features for each messages
skipping to change at page 23, line 29 skipping to change at page 24, line 12
analysis on the behavior of existing clients and intermediate analysis on the behavior of existing clients and intermediate
proxies for such possibly-confusing responses. Optional-WWW- proxies for such possibly-confusing responses. Optional-WWW-
Authenticate is safer, at least for minimum backward Authenticate is safer, at least for minimum backward
compatibility, because clients not supporting this extension will compatibility, because clients not supporting this extension will
consider this header as an unrecognized entity-header, possibly consider this header as an unrecognized entity-header, possibly
providing opportunity for silently falling-back to application- providing opportunity for silently falling-back to application-
level authentications. level authentications.
Appendix C. (Informative) Draft Change Log Appendix C. (Informative) Draft Change Log
C.1. Changes in Httpauth WG revision 03 C.1. Changes in Httpauth WG revision 04
o IANA consideration section added.
C.2. Changes in Httpauth WG revision 03
o Adopting RFC 5987 extended syntax for non-ASCII parameter values. o Adopting RFC 5987 extended syntax for non-ASCII parameter values.
C.2. Changes in Httpauth WG revision 02 C.3. Changes in Httpauth WG revision 02
o Added realm parameter. o Added realm parameter.
o Added username parameter. We acknowledge Michael Sweet's proposal o Added username parameter. We acknowledge Michael Sweet's proposal
for including this to the Basic authentication. for including this to the Basic authentication.
C.3. Changes in Httpauth WG revision 01 C.4. Changes in Httpauth WG revision 01
o Clarification on peers' responsibility about handling of relative o Clarification on peers' responsibility about handling of relative
URLs. URLs.
o Automatic reloading should be allowed only on safe methods, not o Automatic reloading should be allowed only on safe methods, not
always on idempotent methods. always on idempotent methods.
C.4. Changes in Httpauth revision 00 and HttpBis revision 00 C.5. Changes in Httpauth revision 00 and HttpBis revision 00
None. None.
C.5. Changes in revision 02 C.6. Changes in revision 02
o Added usage examples. o Added usage examples.
C.6. Changes in revision 01 C.7. Changes in revision 01
o Syntax notations and parsing semantics changed to match httpbis o Syntax notations and parsing semantics changed to match httpbis
style. style.
C.7. Changes in revision 00 C.8. Changes in revision 00
o Separated from HTTP Mutual authentication proposal (-09). o Separated from HTTP Mutual authentication proposal (-09).
o Adopting httpbis works as a referencing point to HTTP. o Adopting httpbis works as a referencing point to HTTP.
o Generalized, now applicable for all HTTP authentication schemes. o Generalized, now applicable for all HTTP authentication schemes.
o Added "no-auth" and "auth-style" parameters. o Added "no-auth" and "auth-style" parameters.
o Loosened standardization requirements for parameter-name tokens o Loosened standardization requirements for parameter-name tokens
registration. registration.
Authors' Addresses Authors' Addresses
Yutaka Oiwa Yutaka Oiwa
National Institute of Advanced Industrial Science and Technology National Institute of Advanced Industrial Science and Technology
Research Institute for Secure Systems Information Technology Research Institute
3-11-46 Nakouji Tsukuba Central 2
Amagasaki, Hyogo 1-1-1 Umezono
Tsukuba-shi, Ibaraki
JP JP
Email: mutual-auth-contact-ml@aist.go.jp Email: mutual-auth-contact-ml@aist.go.jp
Hajime Watanabe Hajime Watanabe
National Institute of Advanced Industrial Science and Technology National Institute of Advanced Industrial Science and Technology
Research Institute for Secure Systems Information Technology Research Institute
Tsukuba Central 2 Tsukuba Central 2
1-1-1 Umezono 1-1-1 Umezono
Tsukuba-shi, Ibaraki Tsukuba-shi, Ibaraki
JP JP
Hiromitsu Takagi Hiromitsu Takagi
National Institute of Advanced Industrial Science and Technology National Institute of Advanced Industrial Science and Technology
Research Institute for Secure Systems Information Technology Research Institute
Tsukuba Central 2 Tsukuba Central 2
1-1-1 Umezono 1-1-1 Umezono
Tsukuba-shi, Ibaraki Tsukuba-shi, Ibaraki
JP JP
Tatsuya Hayashi Tatsuya Hayashi
Lepidum Co. Ltd. Lepidum Co. Ltd.
#602, Village Sasazuka 3 #602, Village Sasazuka 3
1-30-3 Sasazuka 1-30-3 Sasazuka
Shibuya-ku, Tokyo Shibuya-ku, Tokyo
JP JP
Yuichi Ioku Yuichi Ioku
Individual Individual
 End of changes. 31 change blocks. 
61 lines changed or deleted 90 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/