Automatic Configuration of Email, Calendar, and Contact Server Settings

Automatic Configuration of Email, Calendar, and Contact Server Settings Apple Inc

One Apple Park Way Cupertino CA 95014 USA deggert@apple.com https://www.apple.com

Beonex

ben.bucksch@beonex.com

Apple Inc

One Apple Park Way Cupertino CA 95014 USA diephouse@apple.com https://www.apple.com

ART mailmaint configuration autoconfig auto-configuration ua-auto-config autodiscover mail email calendar contacts IMAP CalDAV CardDAV SMTP JMAP OAuth2 This document specifies an automatic configuration mechanism for email, calendar, and contact user agent applications. Service providers publish standardized configuration information that user agent applications retrieve and use to simplify server setup procedures.

Introduction Manual configuration of email, calendar, and contact user agent applications requires users to correctly specify numerous technical parameters including server hostnames, port numbers, and authentication protocols. This manual process frequently results in configuration errors and setup failures, even among technically skilled users. This document defines a mechanism that significantly simplifies this configuration process. Service providers can publish standardized configuration data that user agents can automatically retrieve and use. In most cases, users need only provide their email address and account password to complete the setup. For service providers that support the OAuth Profile for Open Public Clients , this mechanism also enables automatic OAuth configuration. The user agent automatically determines all necessary details to set up OAuth authentication for the associated account.

Document Conventions In protocol examples, this document uses a prefix of "C: " to denote lines sent by the user agent to the server, and "S: " for lines sent by the server to the user agent. Lines prefixed with "// " are comments explaining the previous protocol line. These prefixes and comments are not part of the protocol. Lines without any of these prefixes are continuations of the previous line, and no line break is present in the protocol unless specifically mentioned. 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.

Overview The automatic configuration process begins when a user wants to set up their user agent application. The user agent requests the user's email address and then uses the domain portion of that address to retrieve configuration data for the account. Configuration retrieval uses the Well-Known URIs mechanism defined in . The specific suffix for this configuration is user-agent-configuration. provides detailed information about the retrieval process. The configuration is provided as a JSON document (detailed in ) that informs the user agent about:

Human-readable information about the service provider
Supported protocols for this domain
Server endpoints for each protocol
OAuth Profile for Open Public Clients support availability

The user agent uses this configuration to determine whether the provider supports protocols that the user agent can also use, helping decide whether to continue with the setup process. For example, an email user agent might check for support of JMAP, IMAP, POP3, and SMTP protocols. Next, the user agent typically connects to the relevant services to verify which authentication methods they support and whether the user agent can use those methods. For instance, if the user agent needs both IMAP and SMTP, it will connect to both servers to check their capabilities and confirm compatibility with the user agent's supported authentication mechanisms. Based on the available options, the user agent then proceeds with one of two approaches:

Continue configuration using OAuth Profile for Open Public Clients, or
Request the user's password for traditional authentication

Finally, the user agent uses the obtained credentials (OAuth tokens or password) to connect to the servers specified in the configuration document and validates that the credentials work correctly with the desired protocols.

Server Requirements Summary The following is a non-normative, high-level summary of what a server operator needs to implement.

Publish a JSON configuration document at a well-known HTTPS URI, listing the domain's supported protocols and their server endpoints.
Publish DNS TXT records containing a digest of that configuration document, so clients can verify its integrity.
Accept the user's full email address as the username on all servers listed in the configuration.
Optionally, support the OAuth Profile for Open Public Clients to enable OAuth-based authentication.

Client Requirements Summary The following is a non-normative, high-level summary of what a client needs to implement.

Ability to construct the well-known URI from a user's email address and retrieve the JSON configuration document over HTTPS.
Ability to validate the configuration document's integrity by comparing its digest against a DNS TXT record.
Ability to connect to each server listed in the configuration and retrieve its supported authentication mechanisms.
User interface to present the server hostnames for the user to confirm before any credentials are entered.
Support for OAuth Profile for Open Public Clients and/or password-based authentication, to complete account setup.

JSON Configuration The configuration document describes which services are available and their corresponding endpoints for a specific domain. The configuration file MUST conform to the JSON schema specification provided in . The configuration uses the media type application/json. The HTTP server MUST set the corresponding Content-Type header as specified in .

Example The following example demonstrates a typical JSON configuration:

Protocols The protocols object specifies all protocols that the domain supports and identifies the server endpoint for each protocol. For the following HTTP-based protocols:

JMAP defined in ,
CalDAV defined in , and
CardDAV defined in
WebDAV defined in

each protocol entry MUST include a url value containing a URL with the https scheme. This URL MUST specify an endpoint that serves the corresponding protocol. The server MUST use the default port 443 for HTTPS, and the URL MUST NOT include an explicit port number. Hostnames in URLs MUST support Internationalized Domain Names (IDNs) as defined in and . Service providers MAY use either Unicode labels (u-labels) or ASCII Compatible Encoding labels (a-labels) in their configuration. User agents MUST support both forms and handle the conversion between them as specified in . Example: For the following text-based protocols:

IMAP defined in ,
SMTP defined in , and
POP3 defined in
ManageSieve defined in

each protocol entry MUST include a host value specifying the hostname of the server that provides the corresponding protocol. The server MUST use the default port number for that protocol, with connections secured using TLS. goes into details about TLS and which ports to use. Hostnames MUST support Internationalized Domain Names (IDNs) as defined in and . Service providers MAY use either Unicode labels (u-labels) or ASCII Compatible Encoding labels (a-labels) in their configuration. User agents MUST support both forms and handle the conversion between them as specified in . Example:

Authentication The authentication object specifies which authentication mechanisms the provider supports. The nested password value indicates whether the provider supports username and password authentication. The nested oauth-public object contains a single issuer value that specifies the authorization server's issuer identifier as defined in . This value is a URL that uses the https scheme and has no query or fragment components. User agents can use this identifier for authentication via . The presence of the oauth-public object indicates that the provider supports OAuth.

Informational The info object contains information that user agents can present to users. The only required field is info/provider/name, which SHOULD clearly identify the provider to the user. The optional info/provider/shortName provides a shorter version of name. The info/provider/logo array can contain one or more entries pointing to the provider's logo images. User agents can use these to display the provider's logo to users. The info/help/documentation field provides a URL that can be presented to users for additional information about the provider. The info/help/developer field contains a URL with information specifically for user agent developers. The info/help/contact array lists URLs that users can use to contact the provider, such as mailto URLs. A minimal info example:

Provider Information provider object can have name, shortName, and logo properties. The name and shortName values are intended for display to the user. The name property specifies the provider's display name, such as the name used in the provider's marketing materials. It SHOULD be no longer than 30 characters, but MUST be no longer than 60 characters. The shortName property is optional. It specifies a brief version of the provider's name, as commonly recognized by users. It SHOULD be no longer than 12 characters, and it MUST NOT be longer than 20 characters. Both name and shortName MUST NOT include any Control-characters and SHOULD NOT include any excessive white space. The logo property contains an array of provider logo variants. User agents select the variant that best matches their UI requirements and technical constraints. Each object in the array contains the following properties:

url - Location where the logo can be retrieved. User agents MAY download the logo file during configuration and store it locally.
content-type - Media type of the logo image. This follows media type format, specifying the main type and subtype without parameters. The main media type MUST be image.
width - Image width in pixels. Optional. Omitted for SVG files.
height - Image height in pixels. Optional. Omitted for SVG files.

The logos SHOULD at least include one of each

image/svg+xml
image/png with size 128 by 128
image/png with size 512 by 512

If the server provides images in the SVG format, these images MUST use the SVG Tiny PS Profile specified in .

Help These fields are intended to allow a service provider to provide additional information about configuring user agents. The documentation property should link to a document intended for users. It can provide additional information to users about how to configure their user agent. A user agent MAY choose to display a link to this URL. User agent SHOULD NOT display links with a URL scheme other than https. The developer property should link to a document intended for user agent developers. The document this URL links to can provide additional information to the developer. The contact property should provide a way for user agent developers to contact the service providers. It is not intended as a way for users to contact the service provider. User agents MUST NOT display this link in their user interface. This URL would typically be a mailto URL or a URL linking to a contact form for developers to use.

Flow provides a high-level overview of the automatic configuration process. This section details the individual steps involved in this process.

Email Address During the initial configuration process, the user agent requests the user's email address. User agents SHOULD accept any valid mailbox format as specified in .

Configuration Source After the user provides their email address, the user agent extracts the domain part of the user's email address according to . For example: Domain from email address

Text Entered by User	domain
jdoe@foo.example.com	foo.example.com
"J Doe" <jdoe@foo.example.com>	foo.example.com
<jdoe@foo.example.com>	foo.example.com

This domain is then used to retrieve the JSON configuration resource using well-known URIs with DNS-based digest validation.

Well-Known Uniform Resource Identifier The user agent retrieves configuration data over HTTP using the format described in . Configuration retrieval uses Well-Known URIs. The user agent constructs the URI using the domain from the user's email address and the configuration name user-agent-configuration. The detailed URI construction process is specified in . The domain name MUST support Internationalized Domain Names (IDNs) as defined in and . User agents MUST handle both Unicode labels (u-labels) and ASCII Compatible Encoding labels (a-labels) when processing domain names from email addresses, and convert them appropriately for URI construction as specified in . The URI follows this template: If the user's email address' domain is foo.example.com, the user agent constructs the following URI: This URI always uses the https scheme. User agents MUST retrieve the configuration file only via https (HTTP over TLS). The user agent MUST validate that the connection is secured by TLS. See for details about TLS with respect to retrieving the configuration. The media type of the configuration is application/json, and the HTTP server MUST set a corresponding Content-Type type header. See . The user agent MUST validate that the content-type of the returned resource is application/json. The HTTP server that serves the JSON configuration MUST NOT require any form of HTTP authentication to return the configuration. For example:

DNS-Based Digest Validation After retrieving the auto-configuration resource from the well-known URI as described in , the user agent MUST validate its integrity before use. This validation is performed by comparing a locally computed digest of the resource against a digest published in a DNS TXT resource record (RR). If the validation fails, the user agent MUST ignore the auto-configuration resource.

Validation Procedure The user agent MUST perform the following steps to validate the auto-configuration resource:

Let the "decoded message content" be the payload body of the HTTP response after all Transfer-Encoding (e.g., "chunked") and Content-Encoding (e.g., "gzip", "br") transformations have been reversed. This is the final, decompressed representation of the resource. See Section 6.1 of and Section 8.4 of for details on these encodings.
Construct a DNS query QNAME using the template _ua-auto-config.{domain}, where {domain} is the domain part of the user's identifier (e.g., "foo.example.com" for "jdoe@foo.example.com").
Perform a DNS query for the TXT RR type at the constructed QNAME. The response may contain multiple TXT RRs.
For each TXT RR returned in the DNS response:
1. Parse the record according to the syntax in . If the record is malformed or is missing any of the mandatory tags (v, a, d), discard this RR and proceed to the next one.
2. Let the "remote algorithm" be the value of the a tag. If the user agent does not support this algorithm, discard this RR and proceed to the next one.
3. Let the "remote digest" be the Base64-decoded value of the d tag. If decoding fails, discard this RR and proceed to the next one.
4. Using the "remote algorithm", compute a "local digest" of the "decoded message content" obtained in step 1.
5. Perform a byte-for-byte comparison of the "local digest" and the "remote digest". If they are identical, the validation is successful. The user agent MUST immediately stop processing further TXT RRs and MAY use the auto-configuration resource.
If, after checking all valid and supported TXT RRs, no match is found, the validation has failed. The user agent MUST discard the "decoded message content" and behave as if no auto-configuration resource was found.

Note: A compliant HTTP client library will typically handle the decoding of Transfer-Encoding and Content-Encoding transparently. The requirement in this document is to ensure that the digest is computed on the final data, not on an intermediate, encoded representation.

DNS Resource Record for Auto-Configuration Configuration information for a given domain is published as a DNS TXT resource record (RR) at a special name, _ua-auto-config, prepended to the domain name. For example, for the domain example.com, the lookup would be for a TXT record at _ua-auto-config.example.com.

Record Syntax The content of the TXT RR is a string of tag=value pairs separated by semicolons (;). Tags are short ASCII strings that identify a particular parameter. Values are ASCII strings whose format depends on the tag. The formal syntax of the record is described using ABNF as follows:

Tags The following tags are defined. Tag names are case-sensitive and MUST be processed as lowercase. Defined Tags

Tag	Description	Status
`v`	Version. The value MUST be "UAAC1" for records compliant with this specification.	Mandatory
`a`	Digest Algorithm. The value MUST be "sha256". This identifies the algorithm used to create the digest in the 'd' tag.	Mandatory
`d`	Digest. The Base64-encoded digest of the JSON resource described in . The encoding MUST follow Section 4 of .	Mandatory

Digest Algorithm SHA-256 ("sha256") as defined in is the supported digest algorithm. The digest is computed over the raw bytes of the JSON resource retrieved from the well-known URI, after any HTTP transfer or content encoding has been decoded. Servers MUST publish a DNS record using the SHA-256 algorithm.

Parsing Rules A client parsing the record MUST adhere to the following rules:

The record MUST contain the v, a, and d tags. If any of these tags are missing, the record is invalid and MUST be ignored.
The order of the tags is not significant.
Whitespace (WSP) is permitted on either side of the = and ; separators and MUST be ignored.
If a tag is encountered that is not defined in this document (e.g., a tag from a future version), the parser MUST ignore that entire tag=value pair. This allows for future extensions.
If any of the mandatory tags (v, a) have values other than those specified in this document, the record is invalid and MUST be ignored.

Example This example demonstrates the configuration retrieval process for a user with email address user@example.com. The user agent performs the following steps:

Constructs the well-known URI from the email domain:
Retrieves the JSON configuration over HTTPS and receives:
Queries DNS for TXT record at _ua-auto-config.example.com and receives:
Computes the SHA-256 digest of the retrieved JSON configuration and verifies it matches the digest in the DNS TXT record.
Since validation succeeds, the user agent may proceed to use this configuration for account setup.

Configuration JSON Validation After successfully retrieving a configuration resource, user agents MUST validate that the configuration contains valid JSON syntax according to RFC 8259. Additionally, user agents MUST validate the retrieved configuration against the JSON schema specification provided in . If the JSON syntax is invalid, user agents MUST ignore the configuration entirely and not use any portion of it. User agents MUST process only the properties that they support and MUST ignore properties not specified in the schema. This requirement enables future extensions of the format without breaking existing user agent implementations.

Selecting Protocols and Authentication After successfully retrieving and validating the configuration JSON, the user agent needs to determine:

Which protocols to use
Which authentication mechanism to employ

Both user agents and servers support multiple protocols. The user agent needs to decide which protocols to use and determine whether the protocols specified in the configuration are sufficient to proceed. This document does not provide recommendations regarding protocol preferences or minimum protocol requirements, as these decisions depend on the specific needs and implementation details of individual user agents. The automatic configuration flow supports two distinct authentication types:

Username and password-based authentication
OAuth-based authentication

User agents can support one or both authentication methods. Similarly, servers for each protocol can support one or both methods. Additionally, the specific implementation details of authentication can vary between protocols. User agents SHOULD probe each protocol and server of interest to determine compatible authentication methods. This probing process can influence the user agent's protocol selection and allows the user agent to verify server availability. This document does not provide recommendations regarding protocol preferences. The user agent MUST make these decisions based on its needs. If the user agent determines that it can use either password-based authentication or OAuth authentication, the user agent SHOULD prefer OAuth-based authentication.

OAuth The JSON configuration includes an oauth-public entry when the provider supports OAuth. The issuer value specifies the authorization server's issuer identifier. According to , the OAuth Authorization Server Metadata is served at a URL constructed using this issuer value with the template For example, if the JSON configuration contains this entry: the OAuth Authorization Server Metadata would be at the URL https://auth.example.com/.well-known/oauth-authorization-server Note that as defined in , the authorization server's issuer identifier MUST be a URL that uses the https scheme without any query or fragment components. Clients MUST verify that the issuer value is valid according to . Before the user agent chooses to use OAuth for any protocols, it SHOULD make sure that it can retrieve the OAuth Authorization Server Metadata from the corresponding URI. The user agent SHOULD connect to each protocol that it might be interested in to detect which authentication mechanism it supports. The user agent MUST NOT perform any authentication at this point, but it SHOULD record which mechanism(s) the server for each protocol of interest supports. The user agent SHOULD still probe each server as described in the next sections and to check that the servers it is interested in have OAuth support.

HTTP Authentication Mechanisms To check which HTTP authentication schemes a particular HTTP server supports, the user agent SHOULD send a request to the server's endpoint without any Authorization header. For example: As detailed in the server SHOULD respond to this with a 401 Unauthorized status code and a www-authenticate response header indicating which authentication scheme(s) are supported. The user agent SHOULD include an accept header with the content type it would expect for the given protocol. For JMAP, for example, the user agent SHOULD include accept: application/json as a header in this request. If the server supports OAuth, the www-authenticate response header would include Bearer. describes this in more detail. and describe username + password authentication using the so-called 'Basic' HTTP authentication scheme and the HTTP digest access authentication respectively. Other password based authentication mechanisms exist for HTTP, but their discussion is outside the scope of this document. For example, a response header would indicate that the server supports OAuth. Alternatively, a response such as would indicate that the server supports digest access authentication. Details of HTTP authentication are described in but it is worth noting that a server supporting multiple authentication methods can return either multiple www-authenticate header fields in its response or a single www-authenticate header field with multiple authentication methods.

Other Protocols Authentication Mechanisms For text-based protocols (IMAP, POP3, and SMTP) the user agent SHOULD connect to the server to check that:

the user agent can reach the server,
the server implements the expected protocol, and
which authentication mechanisms the server supports.

The user agent MUST attempt to connect to the server on the default ports:

port 993 for IMAP
port 995 for POP3
port 465 for SMTP

using TLS. See and for details about using TLS with these protocols. The user agent SHOULD NOT attempt to connect to an IMAP, POP3, or SMTP server on their cleartext ports. The user agent MUST NOT allow for configuration with a cleartext protocol that is not protected by TLS. The user agent MUST validate that the connection is secured by TLS, and that the server certificate is valid and matches the expected domain name. See for details on transport security validation. If the server announces the OAUTHBEARER SASL authentication method, the user agent can assume that this server supports using . For IMAP for example, if the server's CAPABILITY contains AUTH=OAUTHBEARER this would indicate this support. Servers SHOULD NOT announce support for the OAUTHBEARER SASL mechanism if they do not support . Servers MUST announce support for the OAUTHBEARER SASL mechanism if they support OAuth Profile for Open Public Clients. Servers SHOULD NOT use the XOAUTH2 SASL mechanism. There are various SASL authentication mechanisms for password-based authentication, and additionally IMAP and POP3 also support password-based authentication through LOGIN and APOP respectively. The user agent needs to probe each server to determine which authentication methods are supported by both the user agent and the server.

IMAP The IMAP protocol provides various other authentication mechanisms. There are various SASL mechanisms for username + password authentication. describes how to use SASL with IMAP. Unless the server sends the LOGINDISABLED capability, clients know that they can use the LOGIN command for username + password authentication. For IMAP, a sample session might look like this: In this case the server returned its IMAP capabilities as part of the so-called greeting messages. The support for the OAUTHBEARER SASL authentication mechanism indicates to the client that the server supports OAuth. Similarly the PLAIN SASL authentication mechanism indicates that the server supports username + password authentication. The absence of the LOGINDISABLED also indicates support for username and password authentication. If the server doesn't include its capabilities in the server greeting, the client SHOULD send a CAPABILITY command as outlined in . The client SHOULD send a LOGOUT command as outlined in and check that the server sends an untagged BYE response.

SMTP SMTP similarly announces which authentication mechanisms is supports. describes how to use SASL with SMTP. For SMTP, the client would use the EHLO command to retrieve the SMTP server's supported authentication mechanisms. For example: describe this client initiation of the SMTP protocol. describes SMTP authentication in detail. In the above example PLAIN and LOGIN indicate that the server supports username + password based authentication, and OAUTHBEARER indicates that the server supports OAuth. The client SHOULD send a QUIT command and check for the server's 221 Bye response.

POP3 For POP3 describes how to use SASL. POP3 additionally supports password based authentication using its USER and PASS commands, or through the optional APOP command. The client can check which SASL authentication methods the server supports using the CAPA command. For example: The client SHOULD send a QUIT command and check for the server's +OK response.

Confirming Server Names The client SHOULD display to the user the hostnames of all servers that it intends to authenticate with. This list of server hostnames gives the user a chance to validate if they want to move ahead. The client MAY choose to limit the hostnames to their second-level domain names when displaying this list. Instead of displaying mail.example.com the client would display example.com if it chooses to do so. Limiting the hostnames to their second-level domain names helps users identify if this is the domain they intend to connect to or not. The client MUST NOT cut off parts of long second-level domains, to avoid spoofing. At least 63 characters of the second-level domain names MUST be displayed. If the user mistyped their email address in , letting the user confirm the server hostnames gives the user a chance to notice this. Clients can enhance the user experience by using the info section of the configuration (described in ) to display the provider's name and logo during this configuration step. list security considerations related to the user confirming these hostnames.

Username For password-based authentication, the full addr-spec part of the email address MUST be used as the username. For example: Username from email address

Text Entered by User	username
jdoe@example.com	jdoe@example.com
"J Doe" <jdoe@example.com>	jdoe@example.com
<jdoe@example.com>	jdoe@example.com

For OAuth Profile for Open Public Clients, the client MUST send this username as the login_hint in the authorization request URL. The provider MUST ensure that any valid email address that the user might enter during setup is a valid username for all servers given in this configuration. This will require a mapping on the server level from email address to internal username. This mapping happens internally in the server and the client is not involved in this mapping.

Configuring OAuth If the client and the provider both support OAuth Profile for Open Public Clients, and if the servers that the client wants to use support OAuth, the client can configure OAuth. The authentication section in the JSON configuration described in will let the client create a URL to retrieve the OAuth Authorization Server Metadata as described in section . With this metadata, the client can then use to configure OAuth. Part of this will require opening the authorization request URL in an external user-agent, which is typically the default browser. The client SHOULD make it very apparent to the user which hostname is being used for the authorization request URL. The client SHOULD make the user confirm least the second-level domain name(s) of the hostname of this URL. This is to minimize the risk of the user exposing their credentials to a third party. As described in , the client SHOULD also confirm the server hostnames with the user. For OAuth authentication, the client SHOULD include the hostname of the authorization request URL in this list of hostnames.

Configuring Password-Based Authentication If the client and provider both support password-based authentication, and if the servers that the client wants to use support password-based authentication, the client can configure itself to use these servers. The client SHOULD at this point ask the user for the password for their account with the provider. Once the user has entered their password, the client SHOULD validate that it is able to authenticate using the entered password with all servers that it is interested in. Only then would it save the new configuration.

Configuration Validation

User Approval Regardless of the mechanism used to obtain the configuration, clients SHOULD display the configuration details to users and request explicit confirmation before use. During this confirmation process:

At least the second-level domain names of all involved hostnames MUST be displayed clearly and prominently.
Clients MUST NOT truncate long second-level domain names to prevent spoofing attacks. At least 63 characters MUST be displayed.

OAuth2 requirements If OAuth2 is used, the OAuth2 server MUST adhere to . Notably, the Dynamic Client Registration MUST be implemented and return a working Client ID in response HTTP calls defined by the specification. The OAuth2 scopes defined in MUST be included and MUST give access to the servers returned in the JSON configuration described in . A single token MUST work for all servers in the JSON configuration, such that a single user login is sufficient for all services. For that purpose, the client will include all relevant scopes in the authentication requests.

Security Considerations While the mechanism described in this document makes it easier for users to correctly configure their user agent, there's an associated risk with making it easier for users to expose their credentials to a third party. User agents using the mechanism described in this document need to design their user interface and user experience such that this risk is minimized. Actual affordances depend on implementation details of the user interface and are outside the scope of this document.

Mistyped Domain Names As part of the first step of the mechanism described in this document, the user enters their email address. If the user mistyped the domain part of their email address, and if the mistyped domain exists and supports the mechanism described in this document, the user could expose their credentials to the owner of that domain. An attacker could use this in an attempt to gain knowledge of the user's credentials. As a result, user agents need to carefully design their user interface and user experience as to let the user know which domain is being used. It would make sense to display this very clearly to the user, before they enter any credentials. The user agent would want to display a list of all second-level domains (SLDs) for all the servers that it intends to use. The user can then confirm these. When the mechanism described in this document uses OAuth, it would make sense to ask the user to confirm the domains of the servers that will be used and additionally confirm the domains of

the URL to retrieve the OAuth Authorization Server Metadata and/or
the authorization request URL.

When asking the user to confirm these domains, it would make sense to only display the second-level domain (SLD) of those domains. This would make it more difficult for an attacker to do URL obfuscation and use subdomain phishing. When using a browser for OAuth, the user agent would want to display the second-level domain (SLD) that the browser is currently displaying, and update this when redirects happen or new pages are loaded.

Attacker Controlled JSON Configuration If an attacker can direct the user agent to use an attacker-controlled JSON configuration, the attacker would be able to direct the user to servers of the attacker's choosing. In some mechanisms to limit this attack vector are described. However, the user agent needs to combine this with a conservative trust policy for its TLS when retrieving the JSON configuration.

DNS If the user agent uses the DNS mechanisms described in , care needs to be taken to make sure that an attacker hasn't altered the DNS response. Using DNSSEC is one method of improving the security aspects of this approach. Alternatively, user agents MAY choose not use the DNS based mechanisms described in at all.

Transport Security Validation Whenever secure transport is used (including TLS for HTTPS connections and QUIC's TLS-based security layer for HTTP/3), user agents MUST check the certificates presented by the server. This certificate MUST be within its validity period (prior to its expiration date) and MUST chain to a root CA that is trusted by the user agent. The certificate MUST have a subject alternative name (SAN) () with a DNS-ID () matching the hostname, per the rules given in . The certificate MAY also be checked for revocation via OCSP (), CRLs (), or some other mechanism. The general TLS usage guidance in SHOULD be followed. If these checks fail or the server certificate is otherwise invalid, the user agent MUST disconnect and MUST NOT use any configuration retrieved from that URI. Certificate validation failures represent significant security risks, as they may indicate attempts to redirect users' credentials to an attacker. User agents SHOULD NOT allow users to override certificate validation checks. User agents MAY implement more restrictive transport security policies for configuration retrieval than those typically required for web browsing, in order to provide stronger security guarantees. For TLS connections, user agents MAY want to limit the allowed protocol version(s) to recent versions, and MAY similarly want to restrict the allowed cipher suites. For QUIC connections, user agents MAY apply similar restrictions to the underlying TLS handshake parameters. The HTTP server serving the Well-Known resource described in MUST have support for TLS 1.3 () or higher.

Updating the Configuration The mechanism described in this document can be used to upgrade a user's configuration. The user agent could check for configurations even when it has a working configuration for an account. If the user agent finds a configuration that is better (in some way) than the already existing configuration, it could then upgrade the existing configuration. But in doing so, the user agent would increase the attack window that a potential attacker has. Instead of only giving an attacker the opportunity when the user configures their user agent for the first time, the attacker would now have an opportunity each time the user agent checks for a better configuration. That could be undesirable.

Provider Information Image parsers are a common attack vector, and clients MUST NOT display the logo images described in unless they can do so in a way that doesn't expose the client to such attacks.

IANA Considerations

The User-Agent Auto-Configuration Protocol Registry This document establishes the user-agent auto-configuration protocol registry. User-agent auto-configuration protocols are registered on the advice of one or more Designated Experts (appointed by the IESG or their delegate), with a Specification Required (using terminology from ). However, to allow for the allocation of values prior to publication, the Designated Expert(s) may approve registration once they are satisfied that such a specification will be published. Registration requests are sent to the ____@ietf.org mailing list for review and comment, with an appropriate subject (e.g., "Request for well-known URI: example"). Before a period of 14 days has passed, the Designated Expert(s) will either approve or deny the registration request, communicating this decision both to the review list and to IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful. Registration requests that are undetermined for a period longer than 21 days can be brought to the IESG's attention (using the iesg@iesg.org mailing list) for resolution.

Registry Name:: User-Agent Auto-Configuration Protocols
Registration Procedure:: Specification Required (per )

Registration Template

Name: The commonly used name of the protocol
Protocol Key:: The JSON key using in the protocols object in the JSON configuration described in
URL Scheme:: (Optional) The URL scheme to be used for this protocol. HTTP based protocols specify https. If left empty, the protocols entry in the JSON configuration will only specify a hostname using host. If a URL scheme is specified, the JSON configuration entry will instead use url with a URL using this URL scheme.
Specification: Which RFC(s) or document(s) specify the protocol
Additional Properties:: Which additional property values are present in the protocol's JSON object.

Initial Registrations Initial registrations to the User-Agent Auto-Configuration Protocol Registry

Name	Protocol Key	URL scheme	Specification
JMAP	`jmap`	https	RFC 8620, RFC 8621, RFC 8887, RFC 9610
IMAP	`imap`		RFC 9051
POP3	`pop3`		RFC 1939, RFC 5034
SMTP	`smtp`		RFC 5321, RFC 2822
CalDAV	`caldav`	https	RFC 4791
CardDAV	`carddav`	https	RFC 6352
WebDAV	`webdav`	https	RFC 4918
ManageSieve	`managesieve`		RFC 5804, RFC 5228

The Additional Properties field is empty in all of the initial values.

Registration

Registration of Well-Known URI user-agent-configuration This registers the user-agent-configuration name from in the "Well-Known URIs" registry as specified in . Registration in Well-Known URIs Registry

URI suffix	Change controller	Specification document(s)	Related information
`user-agent-configuration`	IETF	This document	/

Registration of DNS Underscore Label _ua-auto-config This registers the DNS underscore label _ua-auto-config used in in the "Underscored and Globally Scoped DNS Node Names" registry as specified in . Registration in Underscored and Globally Scoped DNS Node Names Registry

RR Type	_NODE NAME	Reference
TXT	`_ua-auto-config`	This document

Normative References OAuth Profile for Open Public Clients Fastmail Beonex This document specifies a profile of the OAuth authorization protocol to allow for interoperability between native clients and servers using open protocols, such as JMAP, IMAP, SMTP, POP, CalDAV, and CardDAV.

Configuration JSON Schema The following JSON schema defines the format of the JSON configuration in

Acknowledgements This document is based on the work of Ben Bucksch.