HTTP Authentication
charter-ietf-httpauth-00-00

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
re-charter.

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