Skip to main content

HTTP Authentication

The information below is for an older proposed charter
Document Proposed charter Hypertext Transmission Protocol Authentication WG (httpauth) Snapshot
Title HTTP Authentication
Last updated 2013-02-19
State Start Chartering/Rechartering (Internal Steering Group/IAB Review)
WG State BOF
IESG Responsible AD Kathleen Moriarty
Charter edit AD Sean Turner
Send notices to (None)

HTTP authentication is currently used for user authentication by few web 
sites. Form-based or "web" authentication is much more commonly used. 
Only the former is in scope here, the latter is out of scope.

The httpauth WG will be a short-lived working group that will document a 
small number of HTTP user authentication schemes that might offer 
security benefits, and that could, following experimentation, be widely 
adopted as standards-track schemes for HTTP user authentication. Each of 
the RFCs produced should include a description of when it is appropriate 
to be used, e.g. via a use-case or other distinguishing characteristics.

All schemes to be developed in the httpauth WG must be usable with the 
existing HTTP authentication framework, or with evolutions of that 
framework as developed in the httpbis WG. That is, the evolution of the 
HTTP authentication framework is to be done in the httpbis WG and not in 
the httpauth WG.

The httpauth WG will work closely with the httpbis WG to ensure that the 
outcomes from the httpauth WG do not conflict with work done elsewhere.

The starting points for work will be:

- draft-williams-http-rest-auth
- draft-oiwa-http-mutualauth and draft-oiwa-http-auth-extension
- draft-farrell-httpbis-hoba
- draft-montenegro-httpbis-multilegged-auth
- draft-melnikov-httpbis-scram-auth

In addition, the WG will aim to get rough consensus on two drafts that 
will obsolete the basic and digest schemes defined in RFC 2617 taking 
into account errata on that specification.

For the digest scheme, "more modern" algorithm agility and 
internationalisation support will be developed as a standards-track RFC. 
The starting point for this will be 
draft-ahrens-httpbis-digest-auth-update, but the WG is not precluded 
from e.g. adding a Diffie-Hellman exchange to this method.

For the basic scheme, no technical changes are envisaged other than to 
handle i18n of usernames and passwords, the goal will simply be to 
improve the documentation of the scheme to allow obsoleting RFC 2617 
which has some significant flaws when looked back at 13 years later.

Other than the documents that aim to obsolete RFC 2617, the rest of the 
WG output will be a set of informational or experimental RFCs.

Other than obsoleting RFC 2617 developing standards track solutions is 
out of scope as none of the proposals are expected to be sufficiently 
widely deployed to warrant that status before the WG closes.

The WG is not required to merge all proposals into one. The goal is not 
that participants reach rough consensus on every proposal, but rather to 
review and improve proposals and to quickly produce stable 
specifications and then close.

It is expected that the market/community will select which if any of the 
RFCs developed might be worth progressing on the standards-track at a 
later date, in a different WG.

Adoption of additional work items is not expected and will require a 

The following are explicitly out of scope:

- changes to TLS
- changes to HTTP, however, if some change is proposed
  that is clearly supported by the httpbis WG then that would
  be fine, for example, one might envisage that a new HTTP header
  field might be acceptable if both this and the httpbis wg
  had rough consensus for the addition of that header field,
  albeit that working solely within the existing authentication
  framework is preferable to defining new header fields
- definition of authentication mechanisms that do not work with
  the HTTP authentication framework
- authentication schemes that distinguish between devices and humans
  or for components of web services, and that cannot be sensibly used
  for humans, for example device state authentication such as done
  by the NEA wg is out of scope
- "web" authentication that is not HTTP authentication