HTTP Resources with User Names
draft-vanrein-http-unauth-user-04
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Author | Rick van Rein | ||
| Last updated | 2020-01-31 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-vanrein-http-unauth-user-04
Network Working Group R. Van Rein
Internet-Draft InternetWide.org
Intended status: Standards Track January 31, 2020
Expires: August 3, 2020
HTTP Resources with User Names
draft-vanrein-http-unauth-user-04
Abstract
Many protocols support users under domain names, but HTTP does not.
Usage patterns in the wild do suggest a desire to have this facility.
This specification defines a header for user names, orthogonal to
authenticated identities.
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 August 3, 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.
Van Rein Expires August 3, 2020 [Page 1]
Internet-Draft HTTP user@ January 2020
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The HTTP User Header . . . . . . . . . . . . . . . . . . . . 3
3. URI with User Information . . . . . . . . . . . . . . . . . . 3
4. Protocol Handling of URI and User . . . . . . . . . . . . . . 4
5. Environment Variable with Local User . . . . . . . . . . . . 5
6. Orthogonality of Authentication (Example) . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . 7
9.2. Informative References . . . . . . . . . . . . . . . . . 8
Appendix A. Compatibility with Basic Authentication . . . . . . 8
Appendix B. Compatibility with RESTful Patterns . . . . . . . . 9
Appendix C. Compatibility with Caching . . . . . . . . . . . . . 10
Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
Many protocols support global identities like john@example.com to
identify users like john under domains such as example.com. The URI
format for HTTP can express [Section 2.7.1 of [RFC7230]] such
authority components, with an intended interpretation of locating a
user-specific resources. Many online applications publish about
individual users, but there is no standard in HTTP to express user
names to address them. This specification therefore introduces a
header "User", in close parallel to the "Host" header.
Some current URIs for HTTP have used the userinfo field in the URI to
express an authentication user, in spite of the intended use to
refine the authority information. This conflates the user part of
the resource with the (authenticated) client-side identity. This
specification makes authentication and resource user two orthogonal
concepts, and specifies a clear relation to the URI format.
Orthogonality yields a generalisation, but voluntary conflation of
the user concepts remains possible, and may even be useful as default
behaviour. Servers can be configured with resource users that demand
authentication with the same client name; they may even accept
authentication as a bypass to a resource user. Clients may accept
authentication requests and use their submitted resource user as a
hint to the authentication user.
Orthogonal concepts can however be untied to support advanced use
cases, of which these practices are a specific form. Servers may
welcome members to authenticate against a shared/group resource.
Van Rein Expires August 3, 2020 [Page 2]
Internet-Draft HTTP user@ January 2020
Clients treat the resource user as part of the realm identity and can
use it to locate the customary authentication user for that realm.
Credentials need not be tied to the server, so it is possible to
"bring your own identity" by facilitating realm crossover for
credentials.
The purpose of this specification is to define clear meaning for HTTP
URIs with a userinfo component and their mapping to HTTP.
2. The HTTP User Header
The "User" header field provides an aspect of the desired resource
name scope. The value can be inserted by software or be taken from
the visible portion of the userinfo component [Section 3.2 of
[RFC3986]] of the target URI but it MUST NOT include a ":" colon
(U+003a) character.
The User header value holds precisely one value with the following
ABNF grammar:
User = *( unreserved / pct-encoded / sub-delims )
The referenced non-terminals are as for URIs [RFC3986] and can be
directly included in the quoted-string header form; a plain token
cannot express "(", ")", "=", ";" and "," without escaping
[Section 3.2.6 of [RFC7230]].
3. URI with User Information
This section is informative.
The use of a user name in the authority component of a URI is a
general concept, already used for addressing users with SMTP, SIP,
XMPP and many other protocols. By allowing users in HTTP resource
names, better crossover of identities with these protocols can be
achieved. Unlike server-specific user name mapping conventions, the
specified generic meaning of URI userinfo as part of the authority
information enables such crossovers to be automated.
There is a current practice of writing an authentication name in the
userinfo portion of a URI. This can be useful if it adds Basic
authentication to the first request; Basic can do this because it
does not incorporate a server-sent challenge.
Having never been standardised, the mechanistic side of this practice
is highly diverse, and URIs are far from portable between browsers or
even the various places where they occur within one browser. As a
result, these URIs cannot be spread freely and their usage pattern is
Van Rein Expires August 3, 2020 [Page 3]
Internet-Draft HTTP user@ January 2020
dedicated to the client software in use. On grounds of this
immobility, it would have been sufficient to not break this practice.
What this specification does is completely support [Appendix A] this
pattern as a special case.
This specification follows the URI's intention of the userinfo field,
and prescribes copying its value into the User header. It will
however remove anything from a colon onward, to suppress the portion
of userinfo that is prescribed to not be rendered.
Both the general userinfo format and the removal of anything starting
from a colon may lead to an empty string as the User header value.
Servers may interpret this empty User header as they see fit; the
underlying resource may be a default page, for example one that asks
for a user name to redirect to. After client authentication, such a
page may list user names that would be accessible.
4. Protocol Handling of URI and User
User agents are supposed to render userinfo in the target URI (up to
the first colon ":" (U+003a) if it contains any [Section 3.2.1 of
[RFC3986]]) where it may be helpful if it stands out graphically
[Section 7.6 of [RFC3986]]. User agents SHOULD NOT remove userinfo
from the target URI.
Compliant user agents MUST pass userinfo in the target URI (up to the
first colon ":" (U+003a) if it contains any) as a User header field
if, and only if, the target URI contains a userinfo part.
The User header MAY appear in requests and MUST NOT occur in
responses.
When sending it, the user agent SHOULD generate User as the next
header field after Host. Transparent intermediates such as proxies
and caches MUST NOT add, remove or modify the User header. The
CONNECT method and Host header both exclude this information, so the
User header complements them.
Compliant servers MAY ignore the User header [Section 3.2.1 of
[RFC7230]] and they MAY impose a more restrictive grammar (like a
NAI's utf8-username [RFC7542]) than the URI syntax before further
processing it. When they do use it, the Effective Request URI
[Section 5.5 of [RFC7230]] MUST be constructed with the userinfo and
the "@" at delimiter (U+0040) prefixed to the host name and optional
port. Realms are specific to an authority section [Section 2.2 of
[RFC7235]] and so a realm never spans across different userinfo
values.
Van Rein Expires August 3, 2020 [Page 4]
Internet-Draft HTTP user@ January 2020
As a result of a consistent translation of any User header value into
the Effective Request URI, the server would map consistently to
resources. It is merely enabled to include a User header as an extra
input variable to this mapping to resources.
HTTP caches [RFC7234] derive no privacy or security concerns from the
User header, but they do need to differentiate requests based on it.
To accommodate that, the Vary header [Section 7.1.4 of [RFC7231]]
MUST be generated by the server in the matching response, and the
header MUST either be a single "*" star (U+002a) or list the "User"
name, for all responses whose processing was influenced by the User
header. This requirement has no bearing on software and
configurations that ignore the User header.
During redirects or other traversals to relative HTTP URIs, compliant
user agents MUST overwrite the userinfo in the target URI when the
new URI specifies an authority component, and MUST keep it otherwise.
5. Environment Variable with Local User
The following variable SHOULD be passed to applications that run on
top of the HTTP stack in a server:
LOCAL_USER gives the HTTP User header value after syntax checking
and percent-decoding. Like the customary variables HTTP_HOST
and PATH_INFO, this specifies the resource being requested.
The HTTP_USER header does not describe the identity of the
client-side user, which usually lands in a variable REMOTE_USER
after authentication.
6. Orthogonality of Authentication (Example)
This section is informative.
The authority user in a URI refines the server's resource name space,
and the server is free to distinguish this resource user from an
authenticated client identity. The example below demonstrates the
expressive power gained by treating these user concepts as separate,
in an advanced pattern of use in which an individual user accesses a
group resource. This advanced binding between the group resource and
an authenticated client can build on access control lists.
John and Mary both work at the Sales department of Example, Inc and
John has written a document that he wants Mary to review. Mary opens
a link to the document name space under the shared sales account at
https://sales@example.com/docs and her user agent sends:
Van Rein Expires August 3, 2020 [Page 5]
Internet-Draft HTTP user@ January 2020
GET /docs HTTP/1.1
Host: example.com
User: sales
The server redirects to add a slash, and when this is specific to the
sales name space, it must inform caches about this with the Vary
header:
HTTP/1.1 301 Moved Permanently
Location: /docs/
Vary: User
Since the new location lacks an authority component, this part is
retained from the referring URI, and the user agent redirects to
https://sales@example.com/docs/ by sending:
GET /docs/ HTTP/1.1
Host: example.com
User: sales
By this time, the server runs into access control, and decides that
it needs an authenticated user identity. To this end, it responds
with a challenge to the "Documents" realm:
HTTP/1.1 401 Unauthorized
WWW-Authenticate: KnockKnock realm="Documents"
Vary: User
Mary's user agent needs to collect credentials, and may hint at the
user name "sales" from the URI but, this being the name of a shared
resource, Mary has no fitting credentials and instead authenticates
as "mary":
GET /docs/ HTTP/1.1
Host: example.com
User: sales
Authorization: KnockKnock realm="Documents", user="mary", ...
At some point, the server accepts Mary's authentication and proceeds
to access control. This phase checks if user "mary" may access realm
"Documents" of "https://sales@example.com" by checking that Mary
works for the Sales department. Once this is assured, the server
returns the requested document list:
Van Rein Expires August 3, 2020 [Page 6]
Internet-Draft HTTP user@ January 2020
HTTP/1.1 200 OK
Vary: User
Content-Type: text/html
...
<a href="/docs/review.cgi?docid=123">Review 123 now</a>
...
Mary clicks on the link to /docs/review.cgi?docid=123 and her user
agent sees a relative reference with no authority component, so this
is again reused from the referring URI. The new URI is
https://sales@example.com/docs/review.cgi?docid=123 with same root
https://sales@example.com for which Mary has established credentials,
so the same realm can be tried. The user agent therefore sends:
GET /docs/review.cgi?docid=123 HTTP/1.1
Host: example.com
User: sales
Authorization: KnockKnock realm="Documents", user="mary", ...
After access control, the server starts the CGI script with
environment variables LOCAL_USER=sales and REMOTE_USER=mary of which
only the latter is an authenticated result. The script interprets
the LOCAL_USER as a group account and the REMOTE_USER as the acting
group member, and returns a page for review of the document and Mary
can get to work.
7. IANA Considerations
IANA adds the following entry to the Message Headers registry:
Header Field Name Template Protocol Status Reference
------------------ --------- --------- ------- ----------
User http TBD TBD:THIS_SPEC
8. Security Considerations
The User header field as defined herein is orthogonal to issues of
authentication and authorisation, and adds no security concerns.
9. References
9.1. Normative References
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
Van Rein Expires August 3, 2020 [Page 7]
Internet-Draft HTTP user@ January 2020
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014,
<https://www.rfc-editor.org/info/rfc7230>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014,
<https://www.rfc-editor.org/info/rfc7231>.
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
RFC 7234, DOI 10.17487/RFC7234, June 2014,
<https://www.rfc-editor.org/info/rfc7234>.
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Authentication", RFC 7235,
DOI 10.17487/RFC7235, June 2014,
<https://www.rfc-editor.org/info/rfc7235>.
9.2. Informative References
[RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542,
DOI 10.17487/RFC7542, May 2015,
<https://www.rfc-editor.org/info/rfc7542>.
Appendix A. Compatibility with Basic Authentication
This appendix is informative.
Basic authentication is regularly used as a quick and easy HTTP
authentication technique. Several user agents continue to support it
with the "user:password@" URI prefix to a hostname, despite its
deprecation [Section 3.2.1 of [RFC3986]]. This specification imposes
no new constraints on this practice; it merely prescribes to send the
User header field, and leaves it to client software whether it also
sends Basic authentication.
The mapping from authority names to resources is the prerogative of
the server. A server supportive of resource selection through Basic
authentication could ignore the User header field and still comply
with this specification. A server that does recognise the User
header field would use it to locate a resource, before deciding about
access control to that resource; it may subsequently require
authentication, and select schemes that could be supported. At this
time, it may or may not welcome an added Basic authentication
attempt. All this depends on server configuration.
Van Rein Expires August 3, 2020 [Page 8]
Internet-Draft HTTP user@ January 2020
This flexibility can support a transition from Basic authentication
to User headers on the server, and allows client software to also
migrate by first adding the User header, and later supporting the
advanced uses by allowing differentiation between resource user and
authentication user. Server administrators have a free choice
whether to gradually phase out older clients or to continue to
support them.
Sending both the User header and Basic authentication is only to be
expected from user agents who conflate authority userinfo with
authentication user. Such user agents will be less flexible, and
will not be able to support more advanced usage patterns that
separate these concepts, such as shared/group resources addressed
with the User header field and, when desired, authentication through
an independent set of headers. Among the tools to drive separate
authentication could be the negotiation of more advanced mechanisms,
even just Digest authentication.
Appendix B. Compatibility with RESTful Patterns
This appendix is informative.
Whether and how the User header is interpreted is the prerogative of
the server. The server will translate resources in the same manner
when provided with the same User header, and may do so without regard
for the method used. The main concern is now if it will be addressed
in the same manner in every case. This depends on the user agents.
Development environments make sending the User header field simple,
so application support is as easy as the applications are flexible.
Binary user agents and ones that may lag behind in updates do however
call for backward compatibility support of consistent translation to
resources.
Backward compatibility can be guaranteed for host names that always
require a User header; such resources may be described with a URI
holding a (possibly empty) userinfo field. Failure to send a User
header to such resources when the URI holds one can be assumed to
have originated from a user agent that fails to support it. When an
offer for Basic authentication is presented, it may be interpreted as
the conflated approach to userinfo, and treated as a substitute for
the User header. If neither is offered, then an error may be
reported or control redirected to another means of selecting a
resource user, perhaps through an alternate local naming convention.
This indicates that the server is able to detect inconsistent
tranlation risks, and avoid accidentally binding a request to an
unintended resource as a result of a missing User header.
Van Rein Expires August 3, 2020 [Page 9]
Internet-Draft HTTP user@ January 2020
Appendix C. Compatibility with Caching
This appendix is informative.
Whether and how the User header is used to find resources is the
prerogative of their server. A conservative cache design might
insert the User header value in request URIs, but lose the capability
of seeing the equivalence of a resource as perceived by the server.
The inclusion of the name "User" in the Vary header of the response
adds explicit non-equivalence information, and thereby provides a
more accurate cache controlling instruction.
Whether a result is "private" is independent of the User header, as
that only signifies a refinement of the resource name space on the
server. The rules that signify authentication as default indicator
of privacy is orthogonal to the User header. Independent inclusion
of Basic authentication may still invalidate caching, but not as a
result of this specification.
Appendix D. Acknowledgements
This specification could be improved thanks to input from Daniel
Stenberg, Amos Jeffries, Paul Vixie, James Fuller and Henri Manson.
Author's Address
Rick van Rein
InternetWide.org
Haarlebrink 5
Enschede, Overijssel 7544 WP
The Netherlands
Email: rick@openfortress.nl
Van Rein Expires August 3, 2020 [Page 10]