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