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

Abstract

Most protocols support users under domain names, but HTTP is an exception. Given that it is useful to have this facility for HTTP and that it merely requires a consistent treatment by clients, we specify how to map such URI patterns to HTTP Requests.

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 User-View
• 4. Caching Behaviour
• 5. IANA Considerations
• 6. Security Considerations
• 7. Normative References
• Author's Address

1. Introduction

Most protocols support Network Access Identifiers like john@example.com to identify users like john within domains such as example.com. The URI format for HTTP can express such authority sections, and many online applications seem to want to address individual users, but HTTP offers no representation for user names. This specification solves that with a new header.

Historically, user names have been derived from (Basic and Digest) authentication. This is not generally correct; the user name in the URI represents the resource, not the visitor. The use of a new header allows indepedency between authentication and resource viewing.

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" but not ":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.

The purpose of this specification is to give a clear meaning to a URI with a user name portion, but with no password. Such a URI may be implemented by variation of the HTTP resource space, just as is often done for host name.

2. The HTTP User-View Header

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

The "User-View" header field in a request provides the user name from the target URI. The value is taken from the userinfo in the authority section [Section 3.2 of [RFC3986]] which MUST NOT include a colon. An empty header value indicates absense of a user name. The header value holds precisely one value with the following ABNF grammar: [RFC3986].

The User-View header MAY occur in requests and responses, but MUST NOT be included in trailers [Section 4.1 of [RFC7230]].

3. Protocol Handling of User-View

User agents SHOULD render user names in authority sections as they do host names. User agents SHOULD NOT remove user names from the URI. User agents MAY remove the "@" symbol (U+0040) from a URI when the preceding user name is empty. User agents SHOULD indicate deprecation of the form "user:password" and MUST NOT complain in any way about a user name that adheres to the above grammar.

HTTP servers SHOULD NOT use the User-View in responses except when responding to a user agent known to support it, possibly because they sent the User-View header in a request.

When the User-View header is included in a response, it declares that any references relative to the resource returned should consider the returned user name part of the origin of the relative reference [Section 4.2 of [RFC3986]], inasfar as no authority information is provided in the relative reference.

An empty User-View header value in a response indicates absense of a user name, due to removal relative to a request. User agents receiving a User-View as part of an HTTP redirect [Section 6.4 of [RFC7231]] MUST update the user name in the URI accordingly when the authority part of the URI is not replaced as part of a new URI location.

HTTP servers MAY redirect a request to a location that encodes the user name in the path of the URI, possibly setting the User-View header to an empty value. This allows sites to define their own path syntax for user names, without users or tools needing to be aware of such local conventions.

Whether a User-View header is used after a redirect, and what value it has, is determined by the target URI after its construction from the redirection and, possibly, the previous target URI. This means that the User-View header MUST NOT be carried from a redirection response to its follow-up request, but instead freshly constructed.

Intermediates MUST NOT add, remove or modify the User-View header.

4. Caching Behaviour

The privacy or security of an HTTP resource does not change if it uses an additional User-View header. This is because the header addresses a resource location, but is independent of authentication or authorisation, for which other headers are in use.

HTTP caches [RFC7234] need to distinguish responses when they are requested with different User-View header values. To this end, the Vary header [Section 7.1.4 of [RFC7231]] MUST be present, and MUST either be valued "*" or include the "user-view" token, for any response that has been influenced by a User-View header. Software or configurations that ignore the header are not under 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 names in HTTP URIs as defined herein is not related to authentication or authorisation, and implies no security concerns.

These user names refine the model of resource addressing for HTTP, but any concerns related to privacy or secrecy of resources are already habitually addressed in HTTP servers. This habit MUST be applied to this new, more refined resource addressing model.

7. Normative References

Author's Address