idnits 2.17.1
draft-vanrein-http-unauth-user-05.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The document seems to lack a both a reference to RFC 2119 and the
recommended RFC 2119 boilerplate, even if it appears to use RFC 2119
keywords.
RFC 2119 keyword, line 134: '... Note that the header MUST NOT include...'
RFC 2119 keyword, line 171: '...iant user agents MUST pass userinfo fr...'
RFC 2119 keyword, line 174: '... part. They MUST NOT remove userinf...'
RFC 2119 keyword, line 175: '... Empty userinfo MUST be treated as an...'
RFC 2119 keyword, line 178: '... The User header MAY appear in request...'
(12 more instances...)
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (February 3, 2020) is 1544 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Missing Reference: 'Appendix A' is mentioned on line 160, but not defined
== Unused Reference: 'RFC7230' is defined on line 367, but no explicit
reference was found in the text
== Unused Reference: 'RFC7231' is defined on line 372, but no explicit
reference was found in the text
== Unused Reference: 'RFC7235' is defined on line 382, but no explicit
reference was found in the text
** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112)
** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110)
** Obsolete normative reference: RFC 7234 (Obsoleted by RFC 9111)
** Obsolete normative reference: RFC 7235 (Obsoleted by RFC 9110)
Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group R. Van Rein
3 Internet-Draft InternetWide.org
4 Intended status: Standards Track February 3, 2020
5 Expires: August 6, 2020
7 HTTP Resources with User Names
8 draft-vanrein-http-unauth-user-05
10 Abstract
12 Many protocols support users under domain names, but HTTP does not.
14 This specification defines a header for user names, independent of
15 authenticated identities, and a link to userinfo in HTTP URIs. This
16 intergrates naturally with HTTP, and results in a more refined
17 resource authentication model, in support of advanced usage
18 scenarios.
20 Status of This Memo
22 This Internet-Draft is submitted in full conformance with the
23 provisions of BCP 78 and BCP 79.
25 Internet-Drafts are working documents of the Internet Engineering
26 Task Force (IETF). Note that other groups may also distribute
27 working documents as Internet-Drafts. The list of current Internet-
28 Drafts is at https://datatracker.ietf.org/drafts/current/.
30 Internet-Drafts are draft documents valid for a maximum of six months
31 and may be updated, replaced, or obsoleted by other documents at any
32 time. It is inappropriate to use Internet-Drafts as reference
33 material or to cite them other than as "work in progress."
35 This Internet-Draft will expire on August 6, 2020.
37 Copyright Notice
39 Copyright (c) 2020 IETF Trust and the persons identified as the
40 document authors. All rights reserved.
42 This document is subject to BCP 78 and the IETF Trust's Legal
43 Provisions Relating to IETF Documents
44 (https://trustee.ietf.org/license-info) in effect on the date of
45 publication of this document. Please review these documents
46 carefully, as they describe your rights and restrictions with respect
47 to this document. Code Components extracted from this document must
48 include Simplified BSD License text as described in Section 4.e of
49 the Trust Legal Provisions and are provided without warranty as
50 described in the Simplified BSD License.
52 Table of Contents
54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
55 2. Definition of the HTTP User Header . . . . . . . . . . . . . 3
56 3. URI with Resource User . . . . . . . . . . . . . . . . . . . 3
57 4. Protocol Handling of URI and User Header . . . . . . . . . . 4
58 5. The Logic of User in HTTP . . . . . . . . . . . . . . . . . . 5
59 6. Environment Variable with Local User . . . . . . . . . . . . 6
60 7. Orthogonality of Authentication (Example) . . . . . . . . . . 6
61 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
62 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8
63 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
64 10.1. Normative References . . . . . . . . . . . . . . . . . . 8
65 10.2. Informative References . . . . . . . . . . . . . . . . . 9
66 Appendix A. Compatibility with Basic Authentication . . . . . . 9
67 Appendix B. Compatibility with RESTful Patterns . . . . . . . . 10
68 Appendix C. Compatibility with Caching . . . . . . . . . . . . . 10
69 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 11
70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
72 1. Introduction
74 Many protocols support global identities like john@example.com to
75 represent users like john under domains such as example.com. The URI
76 format for HTTP can express [Section 2.7.1 of [RFC7230]] such
77 authority components (with a userid named "resource user" herein),
78 with an intended interpretation of locating user-specific resources.
79 Many online applications publish resources on individual users, but
80 there is no standard in HTTP to express user names to address them.
81 This specification adds that through a header "User", closely
82 paralleling the "Host" header.
84 Some current URIs for HTTP have used the userinfo field in the URI to
85 express an authentication user (named "client identity" herein), in
86 spite of the intended use to refine the authority information. This
87 conflates the resource user with the client identity. This
88 specification defines client identity and resource user as orthogonal
89 concepts, and specifies a clear relation to the URI format.
91 Orthogonality yields a generalisation, but voluntary conflation of
92 client identity and resource user remains possible. In fact,
93 software may use it as default behaviour. Servers can be configured
94 with resource users that demand authentication with the same client
95 identity; they may even accept authentication with a client identity
96 as a bypass to the same resource user. Clients may accept
97 authentication requests and use the resource user from the target URI
98 as a hint to the expected client identity.
100 Orthogonal concepts can however be untied to support advanced use
101 cases. Servers may use resource users to identify groups and welcome
102 members to authenticate against such a group resource. While
103 authenticating, client identities can be drawn from another domain,
104 so it is possible to "bring your own identity" as long as the server
105 can rely on a mechanism of realm crossover for credentials.
107 TOBEREMOVED: We have designed two mechanisms for realm crossover in
108 other specifications; SXOVER is a SASL mechanism for realm crossover
109 via a Diameter backend, which can be provisioned to user agents
110 through HTTP SASL; KXOVER is a Kerberos mechanism that is taken care
111 of in the KDC. Both rely on DNSSEC, DANE and TLS.
113 The purpose of this specification is to define clear meaning for http
114 and https URIs and their userinfo mappings to HTTP.
116 2. Definition of the HTTP User Header
118 The "User" header carries a resource user as part of the requested
119 authority, and therefore refines the resource name scope. The value
120 can be explicitly inserted
122 or be
124 the user in the userinfo component of the target URI.
126 The User header value holds precisely one value with the following
127 ABNF grammar:
129 User = *( unreserved / pct-encoded / sub-delims )
131 The referenced non-terminals are as for URIs [RFC3986] and can be
132 directly included in the quoted-string header form; a plain token
133 cannot express "(", ")", "=", ";" and "," without escaping
134 [Section 3.2.6 of [RFC7230]]. Note that the header MUST NOT include
135 a ":" colon (U+003a) character.
137 3. URI with Resource User
139 This section is informative.
141 Naming a user in the authority component of a URI is a general idea,
142 already used for addressing users with SMTP, SIP, XMPP and many other
143 protocols. The addition of users in the URIs for HTTP, a refined
144 resource name is provided, and better crossover of identities with
145 these protocols can be achieved. Unlike server-specific user name
146 mapping conventions, the specified generic meaning of URI userinfo as
147 part of the authority information enables such crossovers to be
148 automated.
150 There is a current practice of writing a client identity in the
151 userinfo portion of a URI. This is considered useful if it adds
152 Basic authentication to the first request; Basic can do this because
153 it does not incorporate a server-sent challenge.
155 Having never been standardised, the mechanistic side of this practice
156 is highly diverse, and URIs are far from portable between browsers or
157 even the various places where they occur within one browser. As a
158 result, these URIs cannot be distributed freely and their usage
159 pattern is dedicated to the client software in use. This
160 specification does completely support [Appendix A] this pattern as a
161 special case.
163 This specification follows the URI's intention of the userinfo field,
164 and prescribes copying its value into the User header. It will
165 however remove anything from a colon onward, to suppress the portion
166 of userinfo that should not be rendered [Section 3.2.1 of [RFC3986]]
167 as well as a colon hinting at an empty password.
169 4. Protocol Handling of URI and User Header
171 Compliant user agents MUST pass userinfo from the target URI (up to
172 but excluding the first colon ":" (U+003a) if it contains any) as a
173 User header field if, and only if, the target URI contains a userinfo
174 part. They MUST NOT remove userinfo from the target URI during this
175 process. Empty userinfo MUST be treated as any other userinfo
176 string.
178 The User header MAY appear in requests and MUST NOT occur in
179 responses.
181 When sending it, the user agent SHOULD generate User as the next
182 header field after Host. Transparent intermediates such as proxies
183 and caches MUST NOT add, remove or modify the User header. The
184 CONNECT method and Host header both exclude this information, so the
185 User header complements them.
187 Compliant servers MAY ignore the User header [Section 3.2.1 of
188 [RFC7230]] and they MAY impose a more restrictive grammar (like a
189 NAI's utf8-username [RFC7542]) than the URI syntax before further
190 processing it. When they do use it, the Effective Request URI
191 [Section 5.5 of [RFC7230]] MUST be constructed with the userinfo and
192 the "@" at delimiter (U+0040) prefixed to the host name and optional
193 port. Realms are specific to an authority section [Section 2.2 of
194 [RFC7235]] and so a realm never spans across different userinfo
195 values.
197 As a result of a consistent translation of any User header value into
198 the Effective Request URI, the server would map consistently to
199 resources. It is merely enabled to include a User header as an extra
200 input variable to this mapping to resources.
202 HTTP caches [RFC7234] need to differentiate requests based on the
203 User header. To accommodate that, the Vary header [Section 7.1.4 of
204 [RFC7231]] MUST be generated by the server in the matching response,
205 and the header MUST either be a single "*" star (U+002a) or list the
206 "User" name, for all responses whose processing was influenced by the
207 User header. This requirement has no bearing on software and
208 configurations that ignore the User header.
210 Compliant user agents MUST NOT change the support of the User header
211 depending on the source of a reference; be it a redirect form a
212 server, a click in a hyperlinked document, a script or a part of a
213 browser interface or an external source. When processing URIs that
214 are relative to the context of a previous URI, compliant user agents
215 MUST replace the userinfo in the target URI when the new URI
216 specifies an authority component, and MUST keep it otherwise.
218 5. The Logic of User in HTTP
220 This section is informative.
222 HTTP structures a number of things around the authority component of
223 its URIs, and the addition of resource users in this position form a
224 logical extension. This leads to improved user experiences.
226 Realms are identified by a scheme, the authority and a descriptive
227 string passed with authentication challenges. Clients can use this
228 combination to decide about a client identity to present to a server;
229 it is common for people to have roles relative to one another, and
230 the standard definition of realm identity allows the user agent to
231 select an identity to match the role for the remote party. This can
232 even be used for credentials passed in the TLS handshake, such as
233 X.509 certificates.
235 A similar logic is found for robot exclusion files. They are found
236 at a path /robots.txt for a given scheme and authority. The
237 inclusion of the resource user in the authority enables personal
238 pages to each have their own robot exclusion file.
240 More futuristic would be a suggestion that a server may relay
241 connections to user-operated web servers on the basis of the resource
242 user; this is once again an intended use of the authority field. It
243 may not be possible under current specifications yet, but HTTP with
244 User header can support it as soon as TLS can.
246 6. Environment Variable with Local User
248 The following variable SHOULD be passed to applications that run on
249 top of the HTTP stack in a server:
251 LOCAL_USER gives the HTTP User header value after syntax checking
252 and percent-decoding. If used at all, it MUST be treated as a
253 resource user. This header does not describe the authenticated
254 client identity, which is usually passed in a variable
255 REMOTE_USER.
257 7. Orthogonality of Authentication (Example)
259 This section is informative.
261 This section provides an example of an advanced use case. Not only
262 does this use the resource user to locate a shared server account, it
263 is also distinct from the client identity used during authentication.
264 Whether the client identity is welcomed by the resource user is
265 determined with an access control list. Furthermore, this example
266 shows the logic of a realm identity that involves the resource user
267 in finding the right client identity to the contacted resource user.
269 John and Mary are both part of the Sales group of Example, Inc and
270 John has written a document that he wants Mary to review. Mary opens
271 a link to the document name space under the group's shared account
272 "sales" at https://sales@example.com/docs and her user agent sends:
274 GET /docs HTTP/1.1
275 Host: example.com
276 User: sales
278 The server redirects to add a slash, and when this is specific to the
279 sales name space, it must inform caches about this with the Vary
280 header:
282 HTTP/1.1 301 Moved Permanently
283 Location: /docs/
284 Vary: User
285 Since the new location lacks an authority component, this part is
286 retained from the referring URI, and the user agent redirects to
287 https://sales@example.com/docs/ by sending:
289 GET /docs/ HTTP/1.1
290 Host: example.com
291 User: sales
293 By this time, the server runs into access control, and decides that
294 it needs an authenticated client identity. To this end, it responds
295 with a challenge to the "Documents" realm:
297 HTTP/1.1 401 Unauthorized
298 WWW-Authenticate: KnockKnock realm="Documents"
299 Vary: User
301 Mary's user agent needs to collect credentials, and may hint at the
302 user name "sales" from the URI but, this being the name of a shared
303 resource, Mary has no fitting credentials and instead authenticates
304 with client identity "mary":
306 GET /docs/ HTTP/1.1
307 Host: example.com
308 User: sales
309 Authorization: KnockKnock realm="Documents", user="mary", ...
311 At some point, the server accepts Mary's authentication and proceeds
312 to access control. This phase checks if client identity "mary" may
313 access realm "Documents" of "https://sales@example.com" by checking
314 that Mary works for the Sales department. Once this is assured, the
315 server returns the requested document list:
317 HTTP/1.1 200 OK
318 Vary: User
319 Content-Type: text/html
321 ...
322 Review 123 now
323 ...
325 Mary clicks on the link to /docs/review.cgi?docid=123 and her user
326 agent sees a relative reference with no authority component, so this
327 is again reused from the referring URI. The new URI is
328 https://sales@example.com/docs/review.cgi?docid=123 with same root
329 https://sales@example.com for which Mary has an authenticated client
330 identity, so the same "Documents" realm can be tried. The user agent
331 therefore sends:
333 GET /docs/review.cgi?docid=123 HTTP/1.1
334 Host: example.com
335 User: sales
336 Authorization: KnockKnock realm="Documents", user="mary", ...
338 After access control, the server starts the CGI script with
339 environment variables LOCAL_USER=sales and REMOTE_USER=mary for the
340 resource user and authenticated client identity, respectively. The
341 script interprets the LOCAL_USER as a group account and the
342 REMOTE_USER as the acting group member, and returns a page for review
343 of the document and Mary can get to work.
345 8. IANA Considerations
347 Please add the following entry to the Message Headers registry:
349 Header Field Name Template Protocol Status Reference
350 ------------------ --------- --------- ------- ----------
351 User http TBD TBD:THIS_SPEC
353 9. Security Considerations
355 The User header field as defined herein is orthogonal to issues of
356 authentication and authorisation, and adds no security concerns.
358 10. References
360 10.1. Normative References
362 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
363 Resource Identifier (URI): Generic Syntax", STD 66,
364 RFC 3986, DOI 10.17487/RFC3986, January 2005,
365 .
367 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
368 Protocol (HTTP/1.1): Message Syntax and Routing",
369 RFC 7230, DOI 10.17487/RFC7230, June 2014,
370 .
372 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
373 Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
374 DOI 10.17487/RFC7231, June 2014,
375 .
377 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
378 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
379 RFC 7234, DOI 10.17487/RFC7234, June 2014,
380 .
382 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
383 Protocol (HTTP/1.1): Authentication", RFC 7235,
384 DOI 10.17487/RFC7235, June 2014,
385 .
387 10.2. Informative References
389 [RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542,
390 DOI 10.17487/RFC7542, May 2015,
391 .
393 Appendix A. Compatibility with Basic Authentication
395 This appendix is informative.
397 Basic authentication is regularly used as a quick and easy HTTP
398 authentication technique. Several user agents continue to support it
399 with the "user:password@" URI prefix to a hostname, despite its
400 deprecation [Section 3.2.1 of [RFC3986]]. This specification imposes
401 no new constraints on this practice; it merely prescribes sending the
402 User header field, and leaves it to client software whether to also
403 sends Basic authentication.
405 The mapping from HTTP requests to resources is the prerogative of the
406 server. A server supportive of resource selection through Basic
407 authentication could ignore the User header field and still comply
408 with this specification. A server that does recognise the User
409 header field would use it to locate a resource, before deciding about
410 access control to that resource; it may subsequently require
411 authentication, and select schemes that could be supported. At this
412 time, it may or may not welcome an added Basic authentication
413 attempt. All this depends on server configuration.
415 This flexibility can support a transition from Basic authentication
416 to User headers on the server, and allows client software to also
417 migrate by first adding the User header, and later supporting the
418 advanced uses by allowing differentiation between resource user and
419 client identity. Server administrators have a free choice whether to
420 gradually phase out older clients or to continue to support them.
422 Sending both the User header and Basic authentication is only to be
423 expected from user agents who conflate resource user with client
424 identity. Such user agents will be less flexible, and will not be
425 able to support more advanced usage patterns that separate these
426 concepts, such as shared/group resources addressed with the User
427 header field and, when desired, authentication through a set of other
428 headers.
430 Appendix B. Compatibility with RESTful Patterns
432 This appendix is informative.
434 Whether and how the User header is interpreted is the prerogative of
435 the server. The server will translate resources in the same manner
436 when provided with the same User header, and may do so without regard
437 for the HTTP method. The main concern is now if it will be addressed
438 in the same manner in every case. This depends on the user agents.
440 Development environments make sending the User header field simple,
441 so application support is as easy as the applications are flexible.
442 Binary user agents and ones that may lag behind in updates do however
443 call for backward compatibility support of consistent translation to
444 resources.
446 Backward compatibility can be guaranteed for host names that always
447 require a User header; all resources would be described with URIs
448 having a (possibly empty) userinfo field. Failure to send a User
449 header to such resources when the URI holds userinfo indicates that
450 the user agent fails to support the User header. When an offer for
451 Basic authentication is presented, it may be interpreted as the
452 conflated approach to userinfo, and treated as a substitute for the
453 User header. If neither is offered, then an error may be reported or
454 control redirected to another means of selecting a resource user,
455 perhaps through an alternate local naming convention.
457 This indicates that the server is able to detect inconsistent
458 tranlation risks, and avoid accidentally binding a request to an
459 unintended resource as a result of a missing User header.
461 Appendix C. Compatibility with Caching
463 This appendix is informative.
465 Whether and how the User header is used to find resources is the
466 prerogative of their server. A conservative cache design might
467 insert the User header value in request URIs, but lose the capability
468 of seeing the equivalence of a resource as perceived by the server.
469 The inclusion of the name "User" in the Vary header of the response
470 adds explicit non-equivalence information, and thereby provides a
471 more accurate cache controlling instruction.
473 Whether a result is "private" is independent of the User header, as
474 that only signifies a refinement of the resource name space on the
475 server. The rules that signify authentication as default indicator
476 of privacy is orthogonal to the User header. Independent inclusion
477 of Basic authentication may still invalidate caching, but not as a
478 result of this specification.
480 User agents that send Basic authentication will invalidate
481 intermediate caching. When an empty password is used to select a
482 resource user, it would improve caching performance to switch from
483 Basic authentication to the User header.
485 Appendix D. Acknowledgements
487 This specification could be improved thanks to input from Daniel
488 Stenberg, Amos Jeffries, Paul Vixie, James Fuller and Henri Manson.
490 Author's Address
492 Rick van Rein
493 InternetWide.org
494 Haarlebrink 5
495 Enschede, Overijssel 7544 WP
496 The Netherlands
498 Email: rick@openfortress.nl