]> Google LLC

bemasc@google.com

Transport Multiplexed Application Substrate over QUIC Encryption Internet-Draft HTTP proxies can operate several different kinds of access services. This specification provides a format for identifying a collection of such services. About This Document Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction In HTTP/1.1, forward proxy service was originally defined in two ways: absolute-uri request form (encrypted at most hop-by-hop), and HTTP CONNECT (potentially encrypted end-to-end). Both of these services were effectively origin-scoped: the access service was a property of the origin, not associated with any particular path. Recently, a variety of new standardized proxy-like services have emerged for HTTP. These new services are defined by a URI template, allowing distinct instances of the same service type to be served by a single origin. These services include:

• DNS over HTTPS
• CONNECT-UDP
• CONNECT-IP
• Modern HTTP Proxies

This specification provides a unified format for describing a collection of such access services, and a mechanism for reaching such services when the initial information contains only an HTTP origin.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Format An access service collection is defined by a JSON dictionary containing keys specified in the corresponding registry (). Inclusion of each key is OPTIONAL. The corresponding media type is application/access-services+json. The initially defined keys are "http", tcp", "dns", "udp", and "ip". Each of these keys holds a JSON dictionary containing the key "template" with a value that is a URI template suitable for configuring a Modern HTTP proxy, Modern TCP Transport Proxy, DNS over HTTPS, CONNECT-UDP, or CONNECT-IP, respectively. (Future keys might hold other JSON types.) If the Access Description is for a general-purpose proxy, all proxy targets are presumed to be supported. Otherwise, the supported targets must be understood from context.

An example proxy with many supported services

Client Authentication General-purpose clients of this specification SHOULD also implement support for Popup Authentication when fetching the Access Description. If Popup Authentication produced any Authorization or Cookie headers for the Access Description, the client MUST also apply those headers to any HTTP requests made using the included templates (subject to proxy-specific modifications, see ). These headers are applied even if the Access Description and the included services are on different HTTP origins. This arrangement allows the use of Access Descriptions to describe access-controlled services, and avoids asking the user to authenticate separately with each service.

Discovery from an Origin In cases where the HTTP access service is identified only by an origin (e.g. when configured as a Secure Web Proxy), operators can publish an associated access service collection at the path "/.well-known/access-services", with the Content-Type "application/access-services+json". Clients MAY fetch this Access Description and use the indicated services (in addition to any origin-scoped services) automatically. Clients SHOULD use the description only while it is fresh according to its HTTP cache lifetime, refreshing it as needed.

Security Considerations TODO Security

IANA Considerations IANA is requested to open a Specification Required registry entitled "HTTP Access Service Descriptors", with the following initial contents:

Key	Specification
http	(This document)
tcp	(This document)
dns	(This document)
udp	(This document)
ip	(This document)

IANA is requested to add the following entry to the "Well-Known URIs" registry:

URI Suffix	Change Controller	Reference	Status	Related Information
access-services	IETF	(This document)	provisional	Sub-registry at (link)

IANA is requested to add the following entry to the "application" sub-registry of the "Media Types" registry:

Name	Template	Reference
access-services+json	application/access-services+json	(This document)

• TODO: Full registration template for this Media Type.

Normative References This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS. Each DNS query-response pair is mapped into an HTTP exchange. This document describes how to proxy UDP in HTTP, similar to how the HTTP CONNECT method allows proxying TCP in HTTP. More specifically, this document defines a protocol that allows an HTTP client to create a tunnel for UDP communications through an HTTP server that acts as a proxy. Apple Inc. Google LLC Google LLC Ericsson Ericsson This document describes a method of proxying IP packets over HTTP. This protocol is similar to CONNECT-UDP, but allows transmitting arbitrary IP packets, without being limited to just TCP like CONNECT or UDP like CONNECT-UDP. Google LLC HTTP proxying features have long been part of the core HTTP specification. However, the core proxying functionality has several important deficiencies in modern HTTP environments. This specification defines alternative proxy service configurations for HTTP requests and TCP connections. These services are identified by URI Templates and designed for parallelism with DoH, MASQUE, and Oblivious HTTP. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Google LLC On the World Wide Web, a rich ecosystem of authentication options has been developed to support access control for HTTP resources. However, non-interactive usage of HTTP remains limited to the simple authentication mechanisms defined in the HTTP standards. This specification allows non-interactive HTTP contexts to open a browser- like authentication context when necessary, and close it when authentication is complete.

Acknowledgments TODO acknowledge.