< draft-vanrein-http-unauth-user-00.txt   draft-vanrein-http-unauth-user-01.txt >
Network Working Group R. Van Rein Network Working Group R. Van Rein
Internet-Draft InternetWide.org Internet-Draft InternetWide.org
Intended status: Standards Track January 23, 2020 Intended status: Standards Track January 23, 2020
Expires: July 26, 2020 Expires: July 26, 2020
User Names for HTTP Resource Views User Names for HTTP Resource Views
draft-vanrein-http-unauth-user-00 draft-vanrein-http-unauth-user-01
Abstract Abstract
Most protocols support users under domain names, but HTTP is an Most protocols support users under domain names, but HTTP does not.
exception. Given that it is useful to have this facility for HTTP Usage patterns in the wild do suggest a desire to have this
and that it merely requires a consistent treatment by clients, we facilitated. This specification defines a header for this purpose,
specify how to map such URI patterns to HTTP Requests. orthogonal to any authentication or authorisation concerns.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
skipping to change at page 2, line 9 skipping to change at page 2, line 9
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The HTTP User-View Header . . . . . . . . . . . . . . . . . . 2 2. The HTTP User-View Header . . . . . . . . . . . . . . . . . . 2
3. Protocol Handling of User-View . . . . . . . . . . . . . . . 3 3. Protocol Handling of HTTP User-View . . . . . . . . . . . . . 3
4. Caching Behaviour . . . . . . . . . . . . . . . . . . . . . . 4 4. Caching Behaviour . . . . . . . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4
7. Normative References . . . . . . . . . . . . . . . . . . . . 4 7. Normative References . . . . . . . . . . . . . . . . . . . . 4
Appendix A. HTTP User-View Environment Variable . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction 1. Introduction
Most protocols support Network Access Identifiers like Most protocols support Network Access Identifiers [RFC7542] like
john@example.com to identify users like john within domains such as john@example.com to identify users like john within domains such as
example.com. The URI format for HTTP can express such authority example.com. The URI format for HTTP can express [Section 2.7.1 of
sections, and many online applications seem to want to address [RFC7230]] such authority sections, and many online applications seem
individual users, but HTTP offers no representation for user names. to want to address individual users, but HTTP lacks the customary
This specification solves that with a new header. representation for user names. This specification therefore
introduces a new header field, similar to the "Host" header field.
Historically, user names have been derived from (Basic and Digest) Historically, user names have been coupled to (Basic and Digest)
authentication. This is not generally correct; the user name in the authentication. This is not generally correct; the user name in the
URI represents the resource, not the visitor. The use of a new URI represents a resource, not an (authenticating) visitor. By using
header allows indepedency between authentication and resource a new header field, this specification allows authentication to be
viewing. orthogonal to resource selection.
Browsers have supported (Basic and Digest) authentication with a Browsers have supported (Basic and Digest) authentication with a
scheme of "user:password" in the authority section of URIs. This has 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 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 just "user" and no ":password" is still open to use. Various HTTP
clients have different handling of this form, sometimes flagging it clients have different handling of this form, sometimes flagging it
incorrectly as a security hazard, which is another reason to specify incorrectly as a security hazard, which is another reason to specify
what to do. what to do.
The purpose of this specification is to give a clear meaning to a URI TODO: Erratum #5964 against RFC 7230, https://www.rfc-
with a user name portion, but with no password. Such a URI may be editor.org/errata/eid5964
implemented by variation of the HTTP resource space, just as is often
done for host name. 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 2. The HTTP User-View Header
The "User-View" header field in a request provides the user name from The "User-View" header field provides the user name as part of the
the target URI. The value is taken from the userinfo in the authority that selects a name scope. The value usually is taken from
authority section [Section 3.2 of [RFC3986]] which MUST NOT include a the authority section [Section 3.2 of [RFC3986]] which MUST NOT
colon. An empty header value indicates absense of a user name. The include a colon and/or a password. An empty header value is valid;
header value holds precisely one value with the following ABNF it indicates absense of a user name, and additionally signals support
grammar: for the User-View header.
The User-View header value holds precisely one value with the
following ABNF grammar:
User-View = 0*( unreserved / pct-encoded / sub-delims ) User-View = 0*( unreserved / pct-encoded / sub-delims )
The referenced non-terminals are as for URIs [RFC3986]. The referenced non-terminals are as for URIs [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 The User-View header MAY occur in requests and responses, but MUST
NOT be included in trailers [Section 4.1 of [RFC7230]]. 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]].
3. Protocol Handling of User-View Intermediate such as proxies and caches MUST NOT add, remove or
modify the User-View header.
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 3. Protocol Handling of HTTP User-View
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 User agents SHOULD render user names in authority sections whenever
any references relative to the resource returned should consider the they render host names, though it is helpful if it stands out
returned user name part of the origin of the relative reference graphically [Section 7.6 of [RFC3986]]. User agents SHOULD NOT
[Section 4.2 of [RFC3986]], inasfar as no authority information is remove user names from the URI except when a response indicates a new
provided in the relative reference. 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.
An empty User-View header value in a response indicates absense of a When the User-View header is included in a response, it declares a
user name, due to removal relative to a request. User agents reference point for relative references [Section 4.2 of [RFC3986]],
receiving a User-View as part of an HTTP redirect [Section 6.4 of but this information MUST be ignored by any reference that mentions
[RFC7231]] MUST update the user name in the URI accordingly when the an authority component, with or without a userinfo sub-component.
authority part of the URI is not replaced as part of a new URI However, when constructing an absolute URI from a relative URI such
location. 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 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 same or another user name in the path of the URI, while setting the
header to an empty value. This allows sites to define their own path User-View header to a new value. This enables HTTP servers to define
syntax for user names, without users or tools needing to be aware of a local path syntax for user names, even when users and tools can
such local conventions. approach them without knowing about this local convention.
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 4. Caching Behaviour
The privacy or security of an HTTP resource does not change if it The privacy or security of an HTTP resource is not impacted by the
uses an additional User-View header. This is because the header use of a User-View header. This is because User-View is about
addresses a resource location, but is independent of authentication resource location. Its value has no bearing on authentication or
or authorisation, for which other headers are in use. authorisation.
HTTP caches [RFC7234] need to distinguish responses when they are HTTP caches [RFC7234] need to distinguish responses when they are
requested with different User-View header values. To this end, the requested with different User-View header values. Given a User-View
Vary header [Section 7.1.4 of [RFC7231]] MUST be present, and MUST header in a request, the Vary header [Section 7.1.4 of [RFC7231]]
either be valued "*" or include the "user-view" token, for any MUST be present, and MUST either be valued "*" or list the "user-
response that has been influenced by a User-View header. Software or view" name, as part of any response that has been influenced by the
configurations that ignore the header are not under this requirement. User-View header. Software or configurations that ignore the User-
View header are not subjected to this requirement.
5. IANA Considerations 5. IANA Considerations
IANA adds the following entry to the Message Headers registry: IANA adds the following entry to the Message Headers registry:
Header Field Name Template Protocol Status Reference Header Field Name Template Protocol Status Reference
------------------ --------- --------- ------- ---------- ------------------ --------- --------- ------- ----------
User-View http TBD TBD:THIS_SPEC User-View http TBD TBD:THIS_SPEC
6. Security Considerations 6. Security Considerations
The user names in HTTP URIs as defined herein is not related to The User-View header field as defined herein is orthogonal to issues
authentication or authorisation, and implies no security concerns. of authentication or authorisation, and so it 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 7. Normative References
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", Protocol (HTTP/1.1): Message Syntax and Routing",
skipping to change at page 5, line 10 skipping to change at page 5, line 10
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231, Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014, DOI 10.17487/RFC7231, June 2014,
<https://www.rfc-editor.org/info/rfc7231>. <https://www.rfc-editor.org/info/rfc7231>.
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
RFC 7234, DOI 10.17487/RFC7234, June 2014, RFC 7234, DOI 10.17487/RFC7234, June 2014,
<https://www.rfc-editor.org/info/rfc7234>. <https://www.rfc-editor.org/info/rfc7234>.
[RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542,
DOI 10.17487/RFC7542, May 2015,
<https://www.rfc-editor.org/info/rfc7542>.
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 Author's Address
Rick van Rein Rick van Rein
InternetWide.org InternetWide.org
Haarlebrink 5 Haarlebrink 5
Enschede, Overijssel 7544 WP Enschede, Overijssel 7544 WP
The Netherlands The Netherlands
Email: rick@openfortress.nl Email: rick@openfortress.nl
 End of changes. 21 change blocks. 
79 lines changed or deleted 95 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/