draft-ietf-httpbis-p7-auth-24.txt		draft-ietf-httpbis-p7-auth-25.txt
	HTTPbis Working Group R. Fielding, Ed.		HTTPbis Working Group R. Fielding, Ed.
	Internet-Draft Adobe		Internet-Draft Adobe
	Obsoletes: 2616 (if approved) J. Reschke, Ed.		Obsoletes: 2616 (if approved) J. Reschke, Ed.
	Updates: 2617 (if approved) greenbytes		Updates: 2617 (if approved) greenbytes
	Intended status: Standards Track September 25, 2013		Intended status: Standards Track November 17, 2013
	Expires: March 29, 2014		Expires: May 21, 2014
	Hypertext Transfer Protocol (HTTP/1.1): Authentication		Hypertext Transfer Protocol (HTTP/1.1): Authentication
	draft-ietf-httpbis-p7-auth-24		draft-ietf-httpbis-p7-auth-25
	Abstract		Abstract
	The Hypertext Transfer Protocol (HTTP) is an application-level		The Hypertext Transfer Protocol (HTTP) is an application-level
	protocol for distributed, collaborative, hypermedia information		protocol for distributed, collaborative, hypermedia information
	systems. This document defines the HTTP Authentication framework.		systems. This document defines the HTTP Authentication framework.
	Editorial Note (To be removed by RFC Editor)		Editorial Note (To be removed by RFC Editor)
	Discussion of this draft takes place on the HTTPBIS working group		Discussion of this draft takes place on the HTTPBIS working group
	mailing list (ietf-http-wg@w3.org), which is archived at		mailing list (ietf-http-wg@w3.org), which is archived at
	<http://lists.w3.org/Archives/Public/ietf-http-wg/>.		<http://lists.w3.org/Archives/Public/ietf-http-wg/>.
	The current issues list is at		The current issues list is at
	<http://tools.ietf.org/wg/httpbis/trac/report/3> and related		<http://tools.ietf.org/wg/httpbis/trac/report/3> and related
	documents (including fancy diffs) can be found at		documents (including fancy diffs) can be found at
	<http://tools.ietf.org/wg/httpbis/>.		<http://tools.ietf.org/wg/httpbis/>.
	The changes in this draft are summarized in Appendix D.5.		The changes in this draft are summarized in Appendix D.1.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 March 29, 2014.		This Internet-Draft will expire on May 21, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	skipping to change at page 3, line 17		skipping to change at page 3, line 17
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. Conformance and Error Handling . . . . . . . . . . . . . . 4		1.1. Conformance and Error Handling . . . . . . . . . . . . . . 4
	1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4		1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4
	2. Access Authentication Framework . . . . . . . . . . . . . . . 4		2. Access Authentication Framework . . . . . . . . . . . . . . . 4
	2.1. Challenge and Response . . . . . . . . . . . . . . . . . . 4		2.1. Challenge and Response . . . . . . . . . . . . . . . . . . 4
	2.2. Protection Space (Realm) . . . . . . . . . . . . . . . . . 6		2.2. Protection Space (Realm) . . . . . . . . . . . . . . . . . 6
	3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 7		3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 7
	3.1. 401 Unauthorized . . . . . . . . . . . . . . . . . . . . . 7		3.1. 401 Unauthorized . . . . . . . . . . . . . . . . . . . . . 7
	3.2. 407 Proxy Authentication Required . . . . . . . . . . . . 7		3.2. 407 Proxy Authentication Required . . . . . . . . . . . . 7
	4. Header Field Definitions . . . . . . . . . . . . . . . . . . . 7		4. Header Field Definitions . . . . . . . . . . . . . . . . . . . 7
	4.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 8		4.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 7
	4.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . . 8		4.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . . 8
	4.3. Proxy-Authorization . . . . . . . . . . . . . . . . . . . 8		4.3. Proxy-Authorization . . . . . . . . . . . . . . . . . . . 8
	4.4. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . . 9		4.4. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . . 9
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	5.1. Authentication Scheme Registry . . . . . . . . . . . . . . 10		5.1. Authentication Scheme Registry . . . . . . . . . . . . . . 10
	5.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 10		5.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 10
	5.1.2. Considerations for New Authentication Schemes . . . . 10		5.1.2. Considerations for New Authentication Schemes . . . . 10
	5.2. Status Code Registration . . . . . . . . . . . . . . . . . 11		5.2. Status Code Registration . . . . . . . . . . . . . . . . . 11
	5.3. Header Field Registration . . . . . . . . . . . . . . . . 12		5.3. Header Field Registration . . . . . . . . . . . . . . . . 12
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 12		6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	skipping to change at page 3, line 39		skipping to change at page 3, line 39
	6.2. Protection Spaces . . . . . . . . . . . . . . . . . . . . 13		6.2. Protection Spaces . . . . . . . . . . . . . . . . . . . . 13
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 14		8.1. Normative References . . . . . . . . . . . . . . . . . . . 14
	8.2. Informative References . . . . . . . . . . . . . . . . . . 14		8.2. Informative References . . . . . . . . . . . . . . . . . . 14
	Appendix A. Changes from RFCs 2616 and 2617 . . . . . . . . . . . 15		Appendix A. Changes from RFCs 2616 and 2617 . . . . . . . . . . . 15
	Appendix B. Imported ABNF . . . . . . . . . . . . . . . . . . . . 15		Appendix B. Imported ABNF . . . . . . . . . . . . . . . . . . . . 15
	Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 15		Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 15
	Appendix D. Change Log (to be removed by RFC Editor before		Appendix D. Change Log (to be removed by RFC Editor before
	publication) . . . . . . . . . . . . . . . . . . . . 16		publication) . . . . . . . . . . . . . . . . . . . . 16
	D.1. Since draft-ietf-httpbis-p7-auth-19 . . . . . . . . . . . 16		D.1. Since draft-ietf-httpbis-p7-auth-24 . . . . . . . . . . . 16
	D.2. Since draft-ietf-httpbis-p7-auth-20 . . . . . . . . . . . 17		Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
	D.3. Since draft-ietf-httpbis-p7-auth-21 . . . . . . . . . . . 17
	D.4. Since draft-ietf-httpbis-p7-auth-22 . . . . . . . . . . . 17
	D.5. Since draft-ietf-httpbis-p7-auth-23 . . . . . . . . . . . 17
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
	1. Introduction		1. Introduction
	This document defines HTTP/1.1 access control and authentication. It		This document defines HTTP/1.1 access control and authentication. It
	includes the relevant parts of RFC 2616 with only minor changes		includes the relevant parts of RFC 2616 with only minor changes
	([RFC2616]), plus the general framework for HTTP authentication, as		([RFC2616]), plus the general framework for HTTP authentication, as
	previously defined in "HTTP Authentication: Basic and Digest Access		previously defined in "HTTP Authentication: Basic and Digest Access
	Authentication" ([RFC2617]).		Authentication" ([RFC2617]).
	HTTP provides several OPTIONAL challenge-response authentication		HTTP provides several OPTIONAL challenge-response authentication
	skipping to change at page 5, line 30		skipping to change at page 5, line 30
	include a WWW-Authenticate header field containing at least one		include a WWW-Authenticate header field containing at least one
	challenge applicable to the requested resource.		challenge applicable to the requested resource.
	The 407 (Proxy Authentication Required) response message is used by a		The 407 (Proxy Authentication Required) response message is used by a
	proxy to challenge the authorization of a client and MUST include a		proxy to challenge the authorization of a client and MUST include a
	Proxy-Authenticate header field containing at least one challenge		Proxy-Authenticate header field containing at least one challenge
	applicable to the proxy for the requested resource.		applicable to the proxy for the requested resource.
	challenge = auth-scheme [ 1*SP ( token68 / #auth-param ) ]		challenge = auth-scheme [ 1*SP ( token68 / #auth-param ) ]
	Note: User agents will need to take special care in parsing the
	WWW-Authenticate and Proxy-Authenticate header field values
	because they can contain more than one challenge, or if more than
	one of each is provided, since the contents of a challenge can
	itself contain a comma-separated list of authentication
	parameters.
	Note: Many clients fail to parse challenges containing unknown		Note: Many clients fail to parse challenges containing unknown
	schemes. A workaround for this problem is to list well-supported		schemes. A workaround for this problem is to list well-supported
	schemes (such as "basic") first.		schemes (such as "basic") first.
	A user agent that wishes to authenticate itself with an origin server		A user agent that wishes to authenticate itself with an origin server
	-- usually, but not necessarily, after receiving a 401 (Unauthorized)		-- usually, but not necessarily, after receiving a 401 (Unauthorized)
	-- can do so by including an Authorization header field with the		-- can do so by including an Authorization header field with the
	request.		request.
	A client that wishes to authenticate itself with a proxy -- usually,		A client that wishes to authenticate itself with a proxy -- usually,
	skipping to change at page 6, line 12		skipping to change at page 6, line 5
	Both the Authorization field value and the Proxy-Authorization field		Both the Authorization field value and the Proxy-Authorization field
	value contain the client's credentials for the realm of the resource		value contain the client's credentials for the realm of the resource
	being requested, based upon a challenge received in a response		being requested, based upon a challenge received in a response
	(possibly at some point in the past). When creating their values,		(possibly at some point in the past). When creating their values,
	the user agent ought to do so by selecting the challenge with what it		the user agent ought to do so by selecting the challenge with what it
	considers to be the most secure auth-scheme that it understands,		considers to be the most secure auth-scheme that it understands,
	obtaining credentials from the user as appropriate.		obtaining credentials from the user as appropriate.
	credentials = auth-scheme [ 1*SP ( token68 / #auth-param ) ]		credentials = auth-scheme [ 1*SP ( token68 / #auth-param ) ]
	Upon a request for a protected resource that omits credentials,		Upon receipt of a request for a protected resource that omits
	contains invalid credentials (e.g., a bad password) or partial		credentials, contains invalid credentials (e.g., a bad password) or
	credentials (e.g., when the authentication scheme requires more than		partial credentials (e.g., when the authentication scheme requires
	one round trip), an origin server SHOULD send a 401 (Unauthorized)		more than one round trip), an origin server SHOULD send a 401
	response that contains a WWW-Authenticate header field with at least		(Unauthorized) response that contains a WWW-Authenticate header field
	one (possibly new) challenge applicable to the requested resource.		with at least one (possibly new) challenge applicable to the
			requested resource.
	Likewise, upon a request that requires authentication by proxies that		Likewise, upon receipt of a request that requires authentication by
	omit credentials or contain invalid or partial credentials, a proxy		proxies that omit credentials or contain invalid or partial
	SHOULD send a 407 (Proxy Authentication Required) response that		credentials, a proxy SHOULD send a 407 (Proxy Authentication
	contains a Proxy-Authenticate header field with a (possibly new)		Required) response that contains a Proxy-Authenticate header field
	challenge applicable to the proxy.		with a (possibly new) challenge applicable to the proxy.
	A server receiving credentials that are valid, but not adequate to		A server receiving credentials that are valid, but not adequate to
	gain access, ought to respond with the 403 (Forbidden) status code		gain access, ought to respond with the 403 (Forbidden) status code
	(Section 6.5.3 of [Part2]).		(Section 6.5.3 of [Part2]).
	The HTTP protocol does not restrict applications to this simple		HTTP does not restrict applications to this simple challenge-response
	challenge-response framework for access authentication. Additional		framework for access authentication. Additional mechanisms can be
	mechanisms MAY be used, such as encryption at the transport level or		used, such as authentication at the transport level or via message
	via message encapsulation, and with additional header fields		encapsulation, and with additional header fields specifying
	specifying authentication information. However, such additional		authentication information. However, such additional mechanisms are
	mechanisms are not defined by this specification.		not defined by this specification.
	A proxy MUST forward the WWW-Authenticate and Authorization header		A proxy MUST forward the WWW-Authenticate and Authorization header
	fields unmodified and follow the rules found in Section 4.1.		fields unmodified and follow the rules found in Section 4.1.
	2.2. Protection Space (Realm)		2.2. Protection Space (Realm)
	The authentication parameter realm is reserved for use by		The authentication parameter realm is reserved for use by
	authentication schemes that wish to indicate the scope of protection.		authentication schemes that wish to indicate the scope of protection.
	A protection space is defined by the canonical root URI (the scheme		A protection space is defined by the canonical root URI (the scheme
	skipping to change at page 7, line 11		skipping to change at page 7, line 4
	with its own authentication scheme and/or authorization database.		with its own authentication scheme and/or authorization database.
	The realm value is a string, generally assigned by the origin server,		The realm value is a string, generally assigned by the origin server,
	which can have additional semantics specific to the authentication		which can have additional semantics specific to the authentication
	scheme. Note that a response can have multiple challenges with the		scheme. Note that a response can have multiple challenges with the
	same auth-scheme but different realms.		same auth-scheme but different realms.
	The protection space determines the domain over which credentials can		The protection space determines the domain over which credentials can
	be automatically applied. If a prior request has been authorized,		be automatically applied. If a prior request has been authorized,
	the user agent MAY reuse the same credentials for all other requests		the user agent MAY reuse the same credentials for all other requests
	within that protection space for a period of time determined by the		within that protection space for a period of time determined by the
	authentication scheme, parameters, and/or user preference. Unless		authentication scheme, parameters, and/or user preferences (such as a
	specifically allowed by the authentication scheme, a single		configurable inactivity timeout). Unless specifically allowed by the
	protection space cannot extend outside the scope of its server.		authentication scheme, a single protection space cannot extend
			outside the scope of its server.
	For historical reasons, a sender MUST only generate the quoted-string		For historical reasons, a sender MUST only generate the quoted-string
	syntax. Recipients might have to support both token and quoted-		syntax. Recipients might have to support both token and quoted-
	string syntax for maximum interoperability with existing clients that		string syntax for maximum interoperability with existing clients that
	have been accepting both notations for a long time.		have been accepting both notations for a long time.
	3. Status Code Definitions		3. Status Code Definitions
	3.1. 401 Unauthorized		3.1. 401 Unauthorized
	skipping to change at page 9, line 31		skipping to change at page 9, line 26
	The "WWW-Authenticate" header field consists of at least one		The "WWW-Authenticate" header field consists of at least one
	challenge that indicates the authentication scheme(s) and parameters		challenge that indicates the authentication scheme(s) and parameters
	applicable to the effective request URI (Section 5.5 of [Part1]).		applicable to the effective request URI (Section 5.5 of [Part1]).
	It MUST be included in 401 (Unauthorized) response messages and MAY		It MUST be included in 401 (Unauthorized) response messages and MAY
	be included in other response messages to indicate that supplying		be included in other response messages to indicate that supplying
	credentials (or different credentials) might affect the response.		credentials (or different credentials) might affect the response.
	WWW-Authenticate = 1#challenge		WWW-Authenticate = 1#challenge
	User agents are advised to take special care in parsing the WWW-		User agents are advised to take special care in parsing the field
	Authenticate field value as it might contain more than one challenge,		value, as it might contain more than one challenge, and each
	or if more than one WWW-Authenticate header field is provided, the		challenge can contain a comma-separated list of authentication
	contents of a challenge itself can contain a comma-separated list of		parameters. Furthermore, the header field itself can occur multiple
	authentication parameters.		times.
	For instance:		For instance:
	WWW-Authenticate: Newauth realm="apps", type=1,		WWW-Authenticate: Newauth realm="apps", type=1,
	title="Login to \"apps\"", Basic realm="simple"		title="Login to \"apps\"", Basic realm="simple"
	This header field contains two challenges; one for the "Newauth"		This header field contains two challenges; one for the "Newauth"
	scheme with a realm value of "apps", and two additional parameters		scheme with a realm value of "apps", and two additional parameters
	"type" and "title", and another one for the "Basic" scheme with a		"type" and "title", and another one for the "Basic" scheme with a
	realm value of "simple".		realm value of "simple".
	Note: The challenge grammar production uses the list syntax as		Note: The challenge grammar production uses the list syntax as
	well. Therefore, a sequence of comma, whitespace, and comma can		well. Therefore, a sequence of comma, whitespace, and comma can
	be considered both as applying to the preceding challenge, or to		be considered either as applying to the preceding challenge, or to
	be an empty entry in the list of challenges. In practice, this		be an empty entry in the list of challenges. In practice, this
	ambiguity does not affect the semantics of the header field value		ambiguity does not affect the semantics of the header field value
	and thus is harmless.		and thus is harmless.
	5. IANA Considerations		5. IANA Considerations
	5.1. Authentication Scheme Registry		5.1. Authentication Scheme Registry
	The HTTP Authentication Scheme Registry defines the name space for		The HTTP Authentication Scheme Registry defines the name space for
	the authentication schemes in challenges and credentials. It will be		the authentication schemes in challenges and credentials. It will be
	created and maintained at		created and maintained at (the suggested URI)
	<http://www.iana.org/assignments/http-authschemes>.		<http://www.iana.org/assignments/http-authschemes>.
	5.1.1. Procedure		5.1.1. Procedure
	Registrations MUST include the following fields:		Registrations MUST include the following fields:
	o Authentication Scheme Name		o Authentication Scheme Name
	o Pointer to specification text		o Pointer to specification text
	skipping to change at page 14, line 8		skipping to change at page 14, line 8
	further acknowledgements.		further acknowledgements.
	See Section 10 of [Part1] for the Acknowledgments related to this		See Section 10 of [Part1] for the Acknowledgments related to this
	document revision.		document revision.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[Part1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer		[Part1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
	Protocol (HTTP/1.1): Message Syntax and Routing",		Protocol (HTTP/1.1): Message Syntax and Routing",
	draft-ietf-httpbis-p1-messaging-24 (work in progress),		draft-ietf-httpbis-p1-messaging-25 (work in progress),
	September 2013.		November 2013.
	[Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer		[Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
	Protocol (HTTP/1.1): Semantics and Content",		Protocol (HTTP/1.1): Semantics and Content",
	draft-ietf-httpbis-p2-semantics-24 (work in progress),		draft-ietf-httpbis-p2-semantics-25 (work in progress),
	September 2013.		November 2013.
	[Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,		[Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
	Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",		Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
	draft-ietf-httpbis-p6-cache-24 (work in progress),		draft-ietf-httpbis-p6-cache-25 (work in progress),
	September 2013.		November 2013.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax		[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", STD 68, RFC 5234, January 2008.		Specifications: ABNF", STD 68, RFC 5234, January 2008.
	8.2. Informative References		8.2. Informative References
	[BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration		[BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration
	skipping to change at page 16, line 34		skipping to change at page 16, line 34
	*( OWS "," [ OWS auth-param ] ) ] ) ]		*( OWS "," [ OWS auth-param ] ) ] ) ]
	quoted-string = <quoted-string, defined in [Part1], Section 3.2.6>		quoted-string = <quoted-string, defined in [Part1], Section 3.2.6>
	token = <token, defined in [Part1], Section 3.2.6>		token = <token, defined in [Part1], Section 3.2.6>
	token68 = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" )		token68 = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" )
	*"="		*"="
	Appendix D. Change Log (to be removed by RFC Editor before publication)		Appendix D. Change Log (to be removed by RFC Editor before publication)
	Changes up to the first Working Group Last Call draft are summarized		Changes up to the IETF Last Call draft are summarized in <http://
	in <http://trac.tools.ietf.org/html/		trac.tools.ietf.org/html/draft-ietf-httpbis-p7-auth-24#appendix-D>.
	draft-ietf-httpbis-p7-auth-19#appendix-C>.
	D.1. Since draft-ietf-httpbis-p7-auth-19
	Closed issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/348>: "Realms and
	scope"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/349>: "Strength"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/357>:
	"Authentication exchanges"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/361>: "ABNF
	requirements for recipients"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/368>: "note
	introduction of new IANA registries as normative changes"
	D.2. Since draft-ietf-httpbis-p7-auth-20
	Closed issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/376>: "rename
	b64token for clarity"
	Other changes:
	o Conformance criteria and considerations regarding error handling
	are now defined in Part 1.
	D.3. Since draft-ietf-httpbis-p7-auth-21
	Closed issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/403>:
	"Authentication and caching - max-age"
	D.4. Since draft-ietf-httpbis-p7-auth-22		D.1. Since draft-ietf-httpbis-p7-auth-24
	Closed issues:		Closed issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/436>: "explain list		o <http://tools.ietf.org/wg/httpbis/trac/ticket/510>: "SECDIR review
	expansion in ABNF appendices"		of draft-ietf-httpbis-p7-auth-24"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/439>: "terminology:
	mechanism vs framework vs scheme"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/463>: "Editorial
	suggestions"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/464>: "placement of
	extension point considerations"
	D.5. Since draft-ietf-httpbis-p7-auth-23
	Closed issues:		o <http://tools.ietf.org/wg/httpbis/trac/ticket/513>: "APPSDIR
			review of draft-ietf-httpbis-p7-auth-24"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/473>: "Forwarding		o <http://tools.ietf.org/wg/httpbis/trac/ticket/516>: "note about
	Proxy-*"		WWW-A parsing potentially misleading"
	Index		Index
	4		4
	401 Unauthorized (status code) 7		401 Unauthorized (status code) 7
	407 Proxy Authentication Required (status code) 7		407 Proxy Authentication Required (status code) 7
	A		A
	Authorization header field 8		Authorization header field 7
	C		C
	Canonical Root URI 6		Canonical Root URI 6
	G		G
	Grammar		Grammar
	auth-param 5		auth-param 5
	auth-scheme 5		auth-scheme 5
	Authorization 8		Authorization 8
	challenge 5		challenge 5
	credentials 6		credentials 5
	Proxy-Authenticate 8		Proxy-Authenticate 8
	Proxy-Authorization 9		Proxy-Authorization 8
	token68 5		token68 5
	WWW-Authenticate 9		WWW-Authenticate 9
	P		P
	Protection Space 6		Protection Space 6
	Proxy-Authenticate header field 8		Proxy-Authenticate header field 8
	Proxy-Authorization header field 8		Proxy-Authorization header field 8
	R		R
	Realm 6		Realm 6
End of changes. 25 change blocks.
	112 lines changed or deleted		55 lines changed or added
This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/