User Names for HTTP Resource Views
draft-vanrein-http-unauth-user-01

Abstract

Most protocols support users under domain names, but HTTP does not. Usage patterns in the wild do suggest a desire to have this facilitated. This specification defines a header for this purpose, orthogonal to any authentication or authorisation concerns.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on July 26, 2020.

Copyright Notice

Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. The HTTP User-View Header
• 3. Protocol Handling of HTTP User-View
• 4. Caching Behaviour
• 5. IANA Considerations
• 6. Security Considerations
• 7. Normative References
• Appendix A. HTTP User-View Environment Variable
• Author's Address

1. Introduction

Most protocols support Network Access Identifiers [RFC7542] like john@example.com to identify users like john within domains such as example.com. The URI format for HTTP can express [Section 2.7.1 of [RFC7230]] such authority sections, and many online applications seem to want to address individual users, but HTTP lacks the customary representation for user names. This specification therefore introduces a new header field, similar to the "Host" header field.

Historically, user names have been coupled to (Basic and Digest) authentication. This is not generally correct; the user name in the URI represents a resource, not an (authenticating) visitor. By using a new header field, this specification allows authentication to be orthogonal to resource selection.

Browsers have supported (Basic and Digest) authentication with a scheme of "user:password" in the authority section of URIs. This has now been deprecated [Section 3.2.1 of [RFC3986]] but the form with just "user" and no ":password" is still open to use. Various HTTP clients have different handling of this form, sometimes flagging it incorrectly as a security hazard, which is another reason to specify what to do.

TODO: Erratum #5964 against RFC 7230, https://www.rfc-editor.org/errata/eid5964

The purpose of this specification is to provide a clear meaning to a URI with a user name portion, and treat it similar to the host name.

2. The HTTP User-View Header

The "User-View" header field provides the user name as part of the authority that selects a name scope. The value usually is taken from the authority section [Section 3.2 of [RFC3986]] which MUST NOT include a colon and/or a password. An empty header value is valid; it indicates absense of a user name, and additionally signals support for the User-View header.

User-View = 0*( unreserved / pct-encoded / sub-delims )

The User-View header value holds precisely one value with the following ABNF grammar: [RFC3986]. Zeal in use of the "pct-encoded" non-terminal for plain characters that have a direct representation MAY be considered an attempted attack.

The User-View header MAY occur in requests and responses, but MUST NOT be included in trailers [Section 4.1 of [RFC7230]]. It is normal for HTTP to ignore unrecognised headers [Section 3.2.1 of [RFC7230]]. Intermediate such as proxies and caches MUST NOT add, remove or modify the User-View header.

3. Protocol Handling of HTTP User-View

User agents SHOULD render user names in authority sections whenever they render host names, though it is helpful if it stands out graphically [Section 7.6 of [RFC3986]]. User agents SHOULD NOT remove user names from the URI except when a response indicates a new value. User agents MAY remove the "@" (U+0040) symbol from a URI when the preceding user name is empty. User agents SHOULD refuse URIs with the deprecated form "user:password" but MUST NOT complain about a user name that does not hold a ":" (U+003A) symbol.

When the User-View header is included in a response, it declares a reference point for relative references [Section 4.2 of [RFC3986]], but this information MUST be ignored by any reference that mentions an authority component, with or without a userinfo sub-component. However, when constructing an absolute URI from a relative URI such as in an HTTP redirect [Section 6.4 of [RFC7231]], without an authority component, a User-View header in a response MUST be considered the source of a user name to include in the newly formed URI. Likewise, in the same situation MUST the absense of a User-View header field cause the removal of the user name from the newly formed URI. Other than this, the User-View header field is not automatically copied from a redirection response to a follow-up request.

HTTP servers MAY redirect a request to a location that encodes the same or another user name in the path of the URI, while setting the User-View header to a new value. This enables HTTP servers to define a local path syntax for user names, even when users and tools can approach them without knowing about this local convention.

4. Caching Behaviour

The privacy or security of an HTTP resource is not impacted by the use of a User-View header. This is because User-View is about resource location. Its value has no bearing on authentication or authorisation.

HTTP caches [RFC7234] need to distinguish responses when they are requested with different User-View header values. Given a User-View header in a request, the Vary header [Section 7.1.4 of [RFC7231]] MUST be present, and MUST either be valued "*" or list the "user-view" name, as part of any response that has been influenced by the User-View header. Software or configurations that ignore the User-View header are not subjected to this requirement.

5. IANA Considerations

Header Field Name   Template   Protocol   Status    Reference
------------------  ---------  ---------  -------   ----------
User-View                      http       TBD       TBD:THIS_SPEC

IANA adds the following entry to the Message Headers registry:

6. Security Considerations

The User-View header field as defined herein is orthogonal to issues of authentication or authorisation, and so it implies no security concerns.

7. Normative References

Appendix A. HTTP User-View Environment Variable

We define a variable that SHOULD be passed from an HTTP stack to applications run on top of it. The intention of defining this is to obtain maximum interoperability between these layers of software.

The following variable MAY be included in the environment available passed to active HTTP server components:

HTTP_USERVIEW

reports the User-View header value after percent-decoding. The value is not authenticated, but HTTP server configuration MAY have applied access controls.

Author's Address