Web Bot Auth K. Kelley Internet-Draft Anthropic Intended status: Standards Track 22 October 2026 Expires: 25 April 2027 SAIL: Source Address Identity List draft-kelley-webbotauth-sail-00 Abstract This document defines SAIL (Source Address Identity List), a metadata format served at a well-known URI in which the operator of automated HTTP clients publishes the IP prefixes its services send from, together with two optional assertions: that a service sends from nowhere else, and that nothing else of the operator's sends from a given set of prefixes. A site that receives a request claiming to be one of those services can use that metadata to confirm the claim or, under those assertions, to refute it. The mechanism is intended to complement reverse-DNS verification and HTTP Message Signatures. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-kelley-webbotauth-sail/. Discussion of this document takes place on the Web Bot Auth Working Group mailing list (mailto:web-bot-auth@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/web-bot-auth/. Subscribe at https://www.ietf.org/mailman/listinfo/web-bot-auth/. 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." Kelley Expires 25 April 2027 [Page 1] Internet-Draft SAIL October 2026 This Internet-Draft will expire on 25 April 2027. Copyright Notice Copyright (c) 2026 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 3. Location of the SAIL Document . . . . . . . . . . . . . . . . 4 4. Document Format . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Serialization . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Invalid Documents . . . . . . . . . . . . . . . . . . . . 6 4.3. Schema . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.3.1. Identifiers . . . . . . . . . . . . . . . . . . . . . 8 4.4. Prefixes . . . . . . . . . . . . . . . . . . . . . . . . 9 4.4.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . 9 4.4.2. Permitted Address Space . . . . . . . . . . . . . . . 9 4.4.3. Resolving Prefixes . . . . . . . . . . . . . . . . . 10 4.5. Example . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Validity Period . . . . . . . . . . . . . . . . . . . . . . . 13 6. Identity Claims . . . . . . . . . . . . . . . . . . . . . . . 14 7. Permissible Inferences . . . . . . . . . . . . . . . . . . . 15 8. Publisher Responsibilities . . . . . . . . . . . . . . . . . 16 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 9.1. Fetching from Request-Derived Locations . . . . . . . . . 18 9.2. Unverified Prefix Claims . . . . . . . . . . . . . . . . 18 9.3. False Assertions . . . . . . . . . . . . . . . . . . . . 18 9.4. Infrastructure Disclosure . . . . . . . . . . . . . . . . 19 9.5. Redirected Documents . . . . . . . . . . . . . . . . . . 19 9.6. Counterfeit Documentation URLs . . . . . . . . . . . . . 19 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 10.1. Well-Known URI . . . . . . . . . . . . . . . . . . . . . 20 10.2. Media Type . . . . . . . . . . . . . . . . . . . . . . . 20 10.3. Structured Syntax Suffix . . . . . . . . . . . . . . . . 21 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 11.1. Normative References . . . . . . . . . . . . . . . . . . 21 Kelley Expires 25 April 2027 [Page 2] Internet-Draft SAIL October 2026 11.2. Informative References . . . . . . . . . . . . . . . . . 23 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 24 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 24 1. Introduction This document defines SAIL (Source Address Identity List), a machine- readable and machine-discoverable metadata format that allows service operators to publish information about which addresses other parties should expect to receive inbound traffic from. It also defines a well-known URI for discovering that metadata. Among other uses, this mechanism is intended to allow a consumer that has received a request to determine whether the identity the request claims is consistent with the address it arrived from. For example, it allows a consumer that has received an HTTP request to determine whether the service named in the User-Agent header could have sent it, or whether the request may be an attempt to impersonate that service. Operators of well-behaved automated clients already publish documentation about the services that they operate, including e.g. IP prefixes; however, each publisher chooses its own schema and publication location today, which makes automatically consuming that metadata difficult. A SAIL document is published by a single operator and describes only traffic that operator itself originates. It identifies that operator's services, not the people or organisations on whose behalf a service may be acting: identity that is delegated, federated, or scoped more finely than the operator — per user, per customer, or per task — is outside the scope of this document. Site operators extend privileges to automated clients they recognise and trust, such as access that other clients are refused or higher rate limits, so impersonating such a client is valuable. This draft is intended to complement, and not to be an alternative to, reverse-DNS verification and HTTP Message Signatures [RFC9421] as applied to automated clients by [WBA-ARCH], which are two other widespread means of accomplishing the same outcome. Kelley Expires 25 April 2027 [Page 3] Internet-Draft SAIL October 2026 2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. This document uses the following terms: Publisher: The operator that generates and serves a SAIL document describing its own services and the prefixes they send from. Consumer: A party that retrieves a SAIL document and acts on it, typically the operator of a site that receives automated requests, or an intermediary acting on such a site's behalf. Holder: Any party in possession of a copy of a SAIL document, however obtained: a consumer that fetched it from the publisher, or one that received it from a shared cache, a mirror, or a file. Every consumer is a holder; Section 5 places obligations on holders generally. Origin: The scheme, host, and port of a URI, as defined in Section 4.3.1 of [RFC9110]. A SAIL document speaks for the origin at whose well-known URI it was requested (Section 3). Service: A named source of outbound traffic operated by the publisher, typically an automated HTTP client such as a crawler or fetcher, described by an entry in the document's services array (Section 4.3). Section 6 describes how a request claims a service. Prefix: An IPv4 or IPv6 address prefix in CIDR notation [RFC4632], or a single address, written as described in Section 4.4.1. "IP range" and "address list" in deployed practice refer to the same thing; arbitrary start–end ranges that are not a single prefix cannot be expressed. Prefix set: A named collection of prefixes published together, typically corresponding to one egress pool, and the unit over which exclusive is asserted (Section 4.3). 3. Location of the SAIL Document A publisher MUST serve its SAIL document at the well-known URI [RFC8615] whose path component is "/.well-known/sail" on the origin by which it wishes its services to be identified (Section 6): Kelley Expires 25 April 2027 [Page 4] Internet-Draft SAIL October 2026 https://example.com/.well-known/sail The document MUST be served using the "https" scheme only; it MUST NOT be served with any other URI scheme, and a consumer MUST query it using HTTPS only. If the HTTPS request fails, a consumer MUST NOT reissue it over a non-secure connection. A publisher MUST serve it with status 200 (OK) and Content-Type application/sail+toml (Section 4.1). A consumer MUST NOT treat a response with any other status code as a SAIL document, and MUST accept a 200 response whose body parses and validates as a SAIL document (Section 4.3) whatever Content-Type it carries. Retrieval MAY result in an HTTP redirect, and redirects are handled as [RFC9309] (Section 2.3.1.2) handles them for robots.txt. A consumer SHOULD follow at least five consecutive redirects, even across origins; if the document is reached within five, it is fetched, validated, and applied in the context of the origin whose well-known URI was originally requested; if there are more than five, the consumer MAY treat the document as unavailable. Any such redirect MUST be to an "https" URI; a consumer MUST NOT follow a redirect to any other scheme. A publisher MAY redirect other schemes to "https". A document obtained by following redirects therefore speaks for the origin whose well-known URI was originally requested, not for the origin that ultimately serves it: a redirect is an act of the requested origin, and a consumer redirected from a.example to b.example has obtained a.example's SAIL document. This lets a publisher serve one document for several hosts, or from static hosting on another origin (Section 9.5). The well-known path is the only location this specification defines. Consumers MUST NOT look for the document elsewhere on the origin. Many automated clients include, in the comment portion of their User- Agent header field, a URL for a page describing the client and its operator [CBCP]. A publisher whose clients do so MUST also serve its SAIL document, directly or by redirect, at the well-known path on the host of that URL, so that https:///.well-known/sail resolves as described above. A consumer that receives such a request can then derive the location of the publisher's SAIL document from the request alone, without prior configuration. A publisher SHOULD additionally link to the well-known URI from the human-readable page that describes its automated clients, for example alongside links to existing machine-readable lists of egress addresses it already publishes. Kelley Expires 25 April 2027 [Page 5] Internet-Draft SAIL October 2026 4. Document Format This section defines the serialization, schema, and prefix notation of a SAIL document, and how a consumer resolves its prefixes. Section 4.5 gives a complete example. 4.1. Serialization A SAIL document is a TOML [TOML] document and, as TOML requires, MUST be encoded in UTF-8 [RFC3629]. Its date-time values are TOML offset date-times, which are [RFC3339] timestamps. Its media type is application/sail+toml (Section 10; the +toml suffix is not yet registered, see the note there). We use TOML rather than alternatives such as JSON so that the document can carry comments. A document MUST NOT exceed 524288 octets (512 KiB). The limit applies to the TOML text itself, after any HTTP content coding has been removed, not to the size on the wire. A consumer MAY stop reading a response once the limit is passed. A document that exceeds the limit, is not valid UTF-8, or is not valid TOML is invalid (Section 4.2). [[EDNOTE: 512 KiB is a first guess. Also open is whether per-item limits (counts of prefix sets, services, or prefixes per set) are needed in addition.]] 4.2. Invalid Documents Wherever this specification says a document is _invalid_, a consumer MUST ignore it in its entirety and MUST NOT act on any part of it. In particular a consumer MUST NOT act on the readable portion of a truncated or partly parseable document. For example, an incomplete list under exhaustive would cause genuine traffic to be rejected. A final response with any status code other than 200 (OK), once redirects have been followed, is invalid. A consumer that already holds a valid document from the same origin SHOULD continue to use it until its effective expiry (Section 5), as if the invalid retrieval had not occurred. 4.3. Schema A SAIL document (Section 4.1) is a single TOML table with the following top-level keys. Unrecognised keys at any level MUST be ignored. Kelley Expires 25 April 2027 [Page 6] Internet-Draft SAIL October 2026 schema (string, REQUIRED): The specification the document conforms to; for this version, "draft-kelley-webbotauth-sail-00". modified (offset date-time, REQUIRED): When the document's content last changed, for the benefit of mirrors, caches, and other systems that track the metadata a SAIL document expresses. Regenerating or re-serving unchanged content, or changing only the expiry, MUST NOT advance it. expires (offset date-time) / expires_after (integer seconds): A publisher MUST include exactly one. expires is the absolute instant at which the content ceases to be valid (Section 5). expires_after obliges any holder to refresh the document within that many seconds of receiving it and not to rely on an unrefreshed copy beyond that; it MUST NOT exceed 2592000 (30 days), and a consumer that receives a larger value MUST treat it as 2592000. It is provided for publishers for whom regularly advancing an absolute expires is infeasible. A document with neither key is invalid (Section 4.2); a consumer that receives a document with both MUST use whichever yields the earlier effective expiry (Section 5). prefix_sets (array of tables): Each entry describes one egress pool: * name (identifier, REQUIRED; see Section 4.3.1) — unique within the document and meaningless outside it. * ipv4_prefixes, ipv6_prefixes (arrays of strings) — prefixes in the syntax of Section 4.4.1, subject to Section 4.4.2. * exclusive (boolean, default false) — the publisher asserts that all of _its own_ use of these prefixes is described in this SAIL document (Section 7). A prefix set that no service references and is not marked exclusive asserts nothing and MUST be ignored. One that no service references and _is_ marked exclusive is meaningful: it states that none of the publisher's services send from those prefixes, so that any request claiming one of them from there is refuted (Section 7); a publisher can use this for address space it holds but does not send from. A prefix MAY appear in more than one set and in service entries; Section 4.4.3 defines how occurrences combine, and a prefix in an unreferenced exclusive set that also appears elsewhere in the document takes its services from those other occurrences. services (array of tables): Each entry describes one source of outbound traffic: Kelley Expires 25 April 2027 [Page 7] Internet-Draft SAIL October 2026 * name (identifier, REQUIRED; see Section 4.3.1) — unique within the document. This is the name a request claims (Section 6). * prefix_sets (array of identifiers) — names of prefix sets in this document from which the service sends. An unknown name makes the document invalid. * ipv4_prefixes, ipv6_prefixes (arrays of strings) — prefixes from which the service sends, listed directly. Exactly equivalent to an anonymous prefix set, referenced only by this service, whose other keys all take their default values. * exhaustive (boolean, default false) — the publisher asserts that this service sends from nowhere outside its prefixes as resolved by Section 4.4.3 (Section 7; see Section 8 on when to set it). A service with no prefix_sets and no directly listed prefixes has no prefixes. A document with duplicate prefix-set names, duplicate service names, a dangling prefix-set reference, an identifier that violates Section 4.3.1, neither expiry key, or expires not later than modified is invalid (Section 4.2). 4.3.1. Identifiers Prefix-set names, service names, and the references to prefix sets in a service's prefix_sets array are _identifiers_. An identifier is a TOML string whose value: * MUST be a token as defined in Section 5.6.2 of [RFC9110]: one or more of the ASCII characters ALPHA, DIGIT, and ! # $ % & ' * + - . ^ _ ` | ~; and * MUST NOT exceed 128 characters. Length limits on strings in this specification are stated in characters and apply to the parsed TOML string value, after the document has been decoded and any TOML escapes resolved; only the overall document limit (Section 4.1) is stated in octets, because it is checked before parsing. This is the same grammar as an HTTP product name, so every service name can appear verbatim in a User-Agent field value (Section 6) and as a robots.txt product token, which [RFC9309] likewise matches case- insensitively. Kelley Expires 25 April 2027 [Page 8] Internet-Draft SAIL October 2026 Identifiers are compared ASCII-case-insensitively: two identifiers are equal if and only if they are identical, character for character, after each character in the range U+0041–U+005A ("A"–"Z") is replaced by the corresponding character in the range U+0061–U+007A ("a"–"z"). No other folding or normalisation is applied. This rule governs uniqueness of names within a document, resolution of prefix_sets references, and matching a service name against a User-Agent field value (Section 6). 4.4. Prefixes 4.4.1. Syntax Each element of ipv4_prefixes and ipv6_prefixes is a TOML string in exactly one of two forms: * CIDR notation [RFC4632]: an address in the family's textual form, "/", and a decimal prefix length ("192.0.2.0/24", "2001:db8::/32"); or * a bare address with no "/", which denotes that single address and is equivalent to the same address with "/32" (IPv4) or "/128" (IPv6). No other form is permitted: start–end ranges, netmask notation, wildcards, and lists within one string MUST NOT be used. Each element of ipv4_prefixes MUST be an IPv4 prefix and each element of ipv6_prefixes an IPv6 prefix. Publishers SHOULD write prefixes in canonical form, with all bits beyond the prefix length zero and, for IPv6, in the text representation of [RFC5952]; a consumer that receives one with host bits set MUST honour it as the prefix obtained by clearing those bits, and neither this nor a non-canonical text representation alone makes the document invalid. 4.4.2. Permitted Address Space A prefix MUST lie wholly within globally reachable unicast space. It MUST NOT overlap: * any block whose "Globally Reachable" property is anything other than an unqualified True in the IANA IPv4 Special-Purpose Address Registry [IANA-IPV4-SP] or IPv6 Special-Purpose Address Registry [IANA-IPV6-SP] (established by [RFC6890] and [RFC8190]; this covers private, shared, loopback, link-local, documentation, benchmarking, discard, and reserved space); * multicast space (224.0.0.0/4 [RFC5771], ff00::/8 [RFC4291]); Kelley Expires 25 April 2027 [Page 9] Internet-Draft SAIL October 2026 * IPv6 prefixes that embed IPv4 addresses (::ffff:0:0/96 and ::/96, Section 2.5.5 of [RFC4291]); or * transition-mechanism and shared-anycast assignments from which no single operator originates ordinary unicast traffic, even where the registry marks them reachable: 6to4 (2002::/16 [RFC3056], and the deprecated relay anycast prefix 192.88.99.0/24 [RFC7526]), Teredo (2001::/32 [RFC4380]), the NAT64 well-known prefix (64:ff9b::/96 [RFC6052]), AS112 (192.31.196.0/24 and 2001:4:112::/48 [RFC7535]; 192.175.48.0/24 and 2620:4f:8000::/48 [RFC7534]), and AMT (192.52.193.0/24 and 2001:3::/32 [RFC7450]). The registries [IANA-IPV4-SP] [IANA-IPV6-SP] are authoritative for the first item and consumers SHOULD track them as updated; the remaining items are fixed by this specification. A consumer MUST validate every prefix on receipt. A document containing any prefix that is malformed (Section 4.4.1), in the wrong family for its key, or outside the permitted space MUST be treated as invalid (Section 4.2). [[EDNOTE: Whole-document rejection is simple and consistent with the handling of unparseable and oversize documents, but one bad prefix then withdraws the publisher's entire document until corrected. More graceful degradation is probably possible, but I haven't thought about it carefully yet.]] 4.4.3. Resolving Prefixes A consumer resolves a document into, for each address family, a map from prefix to the set of services that send from it and whether it is exclusive, as follows. 1. Every prefix contributes equally, whether it appears in a named prefix set or in a service's anonymous set (Section 4.3). A prefix is associated with every service that references the set containing it (with no service, if it appears only in an unreferenced exclusive set), and is exclusive if that set is marked exclusive. Prefixes of unreferenced sets not marked exclusive do not contribute. 2. After clearing host bits (Section 4.4.1), identical prefixes are merged: the associated services are the union of those from each occurrence, and the prefix is exclusive if any occurrence is. Exact duplicates therefore carry no additional meaning and SHOULD be discarded. Kelley Expires 25 April 2027 [Page 10] Internet-Draft SAIL October 2026 3. For a given address, the _governing prefix_ is the longest resolved prefix that contains it. The services and exclusive value that apply to the address are those of the governing prefix alone; any shorter prefix that also contains the address contributes nothing to it. A publisher can thus list a broad allocation under one service and carve a more specific prefix out of it for another without enumerating the remainder. An address is "within S's prefixes", for the purposes of Section 7, if and only if S is among the services of its governing prefix. A consumer that observes a request's source as an IPv4-mapped IPv6 address (Section 2.5.5.2 of [RFC4291], ::ffff:0:0/96), as is common on dual-stack hosts, MUST match it against ipv4_prefixes as the embedded IPv4 address and MUST NOT match it against ipv6_prefixes. 4.5. Example The following is a complete SAIL document for a publisher that operates two crawlers from a dedicated egress pool, a fetcher that additionally uses shared corporate egress, holds a block it does not send from, and wishes to disown a name it has retired. The prefixes shown are documentation prefixes [RFC5737] [RFC3849]; a real document could not contain them (Section 4.4.2). Kelley Expires 25 April 2027 [Page 11] Internet-Draft SAIL October 2026 schema = "draft-kelley-webbotauth-sail-00" modified = 2026-09-02T14:00:00Z expires_after = 604800 # 7 days # Dedicated crawl egress. All of our own use of these prefixes is # described in this document. [[prefix_sets]] name = "crawl" exclusive = true ipv4_prefixes = ["192.0.2.0/24"] ipv6_prefixes = ["2001:db8:4000::/40"] # Shared with staff and other internal systems; not exclusive. [[prefix_sets]] name = "corp" ipv4_prefixes = ["198.51.100.64/26"] # Held but unused: nothing of ours sends from here. [[prefix_sets]] name = "parked" exclusive = true ipv4_prefixes = ["198.51.100.0/26"] # ExampleBot sends only from the crawl pool. [[services]] name = "ExampleBot" exhaustive = true prefix_sets = ["crawl"] # ExampleBot-News sends only from two addresses, listed directly. [[services]] name = "ExampleBot-News" exhaustive = true ipv4_prefixes = ["203.0.113.7", "203.0.113.8"] # Example-Fetcher sends from the crawl pool and corporate egress. [[services]] name = "Example-Fetcher" exhaustive = true prefix_sets = ["crawl", "corp"] # Retired name; we send nothing as OldExampleBot any more. [[services]] name = "OldExampleBot" exhaustive = true Based on the rules in Section 7: Kelley Expires 25 April 2027 [Page 12] Internet-Draft SAIL October 2026 * A request claiming ExampleBot from 192.0.2.10 is confirmed. * One claiming ExampleBot from 198.51.100.70 is refuted, because ExampleBot is exhaustive and that address is not within its prefixes. * A request claiming Example-Fetcher from 198.51.100.70 is confirmed. * A request from 192.0.2.10 claiming ExampleBot-News is refuted twice over: ExampleBot-News is exhaustive and does not list that address, and the governing prefix 192.0.2.0/24 is exclusive and ExampleBot-News is not among its services. * Every request claiming OldExampleBot is refuted. * A request from 198.51.100.10 claiming any of these services is refuted: parked is exclusive and no service references it. * The document says nothing about a request from 192.0.2.10 that claims no identity, or that claims some other operator's. 5. Validity Period HTTP caching [RFC9111] governs when a consumer refetches the _resource_; modified and the expiry keys describe the _data_. The in- document keys exist because HTTP response metadata is not always passed along faithfully. The _effective expiry_ of a document is the earliest of: * the value of expires, if present; * the time at which the holder received the document plus expires_after seconds, if present; and * the time at which the holder received the document plus 2592000 seconds (30 days), in every case. The last term bounds how long any copy can be relied on regardless of what the document says. A holder MUST NOT act on a document more than 30 days after receiving it without refreshing it, even if expires is later, and publishers SHOULD NOT set expires further ahead than that. This limits how long a copy the publisher cannot recall (in a cache, a mirror, or on disk) can continue to assert something the publisher has since withdrawn (Section 9.3). Kelley Expires 25 April 2027 [Page 13] Internet-Draft SAIL October 2026 For expires_after each holder uses its own receipt time, from whichever source it fetched, so the obligation applies per hop. As a consequence, publishers SHOULD prefer to provide expires rather than expires_after; expires_after is provided for use in situations where regularly refreshing the expires timestamp is difficult. A SAIL document using expires_after and whose receipt time is unknown MUST be treated as expired. A consumer MUST NOT act on a document after its effective expiry, regardless of HTTP cache state, except in cases where the origin is unavailable. Consumers using stale metadata in that situation SHOULD exercise caution. When a document expires, confirmations and refutations (Section 7) alike lapse. A consumer MAY refresh more often than expiry or HTTP freshness require, but is not obliged to. Publishers SHOULD, where feasible, send HTTP freshness information (Cache-Control: max-age or Expires) that agrees with the document's own expiry and in no case extends beyond it. Consumers MUST NOT refresh a non-expired SAIL document more frequently than every 1800 seconds, regardless of other caching signals. 6. Identity Claims A service name is not by itself an identity. Names are chosen freely by each publisher, and nothing prevents two publishers, or a publisher and an impostor, from using the same one. The identity that a SAIL document speaks to, and that a consumer confirms or refutes, is the pair (origin of the SAIL document, service name). Any trust or policy a consumer attaches to a service MUST be attached to that pair, with the origin established by means outside the request. In particular, a URL carried in a request (such as the User-Agent comment used for discovery in Section 3) tells a consumer only where the sender says to look; it is not evidence of which origin is authoritative for a name (Section 9.6). The inferences in Section 7 apply to a request that _claims_ one of the publisher's services. For HTTP, that claim is carried in the request's User-Agent header field (Section 10.1.5 of [RFC9110]); a request claims service S when S's name appears there. Publishers SHOULD choose each service's name to be the product token its client sends, and for crawlers the token it answers to in robots.txt (Section 2.2.1 of [RFC9309]), so that one identifier serves throughout. Kelley Expires 25 April 2027 [Page 14] Internet-Draft SAIL October 2026 [[EDNOTE: This is a little bit tricky because User-Agent headers routinely contain lots of different things. In practice, heuristic libraries are used to interpret these values. We should figure out if there's something more definite we can say here.]] 7. Permissible Inferences A SAIL document lets a consumer test a request's _claim_ to be one of the publisher's services (Section 6) against the address the request came from. It provides a basis for exactly the following conclusions, and for no others. Confirmation: A request that claims service S and originates from an address within S's prefixes is supported by the SAIL metadata. No assertion (e.g. exhaustive or exclusive) is required beyond S being listed. Refutation by service (exhaustive): If S is marked exhaustive, the publisher has stated that S sends from nowhere else. A request claiming S from an address outside S's prefixes is therefore not from the publisher, and the consumer MUST treat the claim as refuted, MUST NOT extend to the request any treatment it reserves for S, and MAY additionally reject the request. Absent exhaustive, no such conclusion follows; the listed prefixes are a subset. A consumer MAY nonetheless count the absence of a matching prefix as a weak signal against the claim, for example as one input to its own risk scoring, provided it does not reject or otherwise treat the request as refuted on that basis alone. A service that has no prefixes (Section 4.3) and is marked exhaustive is valid and means that the service currently sends from nowhere, so every request claiming it is refuted. A publisher can use this to retire a service name, or to disown one it has never used but sees being impersonated. Refutation by prefix (exclusive): If the prefix governing an address (Section 4.4.3) is exclusive, the publisher has stated that none of its other services send from there. A request from that address claiming any of the publisher's services _other than_ those associated with that prefix (or claiming any of them at all, if the prefix has no associated service) is therefore not from the publisher. The consumer MUST treat the claim as refuted, MUST NOT extend to the request any treatment it reserves for the claimed service, and MAY additionally reject the request. Absent exclusive, no such conclusion follows. Used together the two assertions close the mapping in both directions: exhaustive says "this service of ours, only from here"; exclusive says "from here, only these services of ours". Where Kelley Expires 25 April 2027 [Page 15] Internet-Draft SAIL October 2026 either refutation permits a consumer to reject the request, this document does not specify the form the rejection takes (see the note at the end of this section). These conclusions serve permissive decisions as well as restrictive ones. A consumer MAY use confirmation to allowlist a service — for example to exempt requests that claim S and arrive from S's prefixes from challenges, rate limits, or blocks applied to other automated traffic — just as it uses the refutations to deny impostors. In every case the decision is keyed on the pair of claimed identity and source address, never on the address alone. A SAIL document provides no basis for any of the following, and a consumer that acts as though it did is acting on its own evidence, outside this format (Section 9.2): * that traffic from a listed prefix which makes no identity claim, or claims some other operator's identity, is from the publisher — no key in the format speaks to unidentified traffic, and exclusive concerns only which of the publisher's _own_ services use a prefix, not who else does; * that the publisher owns, is the registered holder of, or is the sole occupant of any prefix it lists; * anything about parties other than the publisher — two publishers may list overlapping prefixes, each truthfully; * either refutation above when the corresponding flag is false or absent. [[EDNOTE: Open issue: We should define response error codes and a way for signaling why SAIL metadata caused the request to be refused.]] 8. Publisher Responsibilities The value of a SAIL document to consumers, and the safety of its assertions, rest entirely on the publisher keeping it true. Accuracy: A publisher MUST NOT list prefixes it does not control, Kelley Expires 25 April 2027 [Page 16] Internet-Draft SAIL October 2026 nor any prefix from which its traffic cannot actually originate, nor any prefix outside the space permitted by Section 4.4.2. It MUST NOT set exhaustive or exclusive unless the assertion is true when published and is expected to remain true until the document's effective expiry (Section 5). In particular, a publisher SHOULD add new egress addresses to the document, and allow the previously published document's validity period to elapse, before an exhaustive service begins sending from them. A false assertion harms no third party; its cost falls on the publisher's own traffic and on consumers that wanted it (Section 9.3). Completeness: A publisher SHOULD set exhaustive on every service for which it is true. A document without it lets consumers confirm genuine requests but never refute impostors, which forgoes the format's main benefit. A publisher MAY list, with no prefixes and exhaustive set, names it has retired or has never used but sees impersonated (Section 7), and MAY list, as an exclusive prefix set that no service references, address space it holds but sends nothing from (Section 4.3). Shared address space: Listing address space that the publisher shares with other parties — a provider's general-purpose egress pool, for example — allows those parties' traffic to be confirmed as the publisher's services, since confirmation rests on source address alone. A publisher SHOULD prefer dedicated egress for any service whose identity consumers are expected to act on, and SHOULD NOT mark shared space exclusive: although the assertion concerns only the publisher's own services and may be literally true, it signals dedicated use and invites the over-reading cautioned against in Section 9.2. Stable origin: Because consumers attach trust to the pair (origin, service name) (Section 6), a publisher SHOULD serve its SAIL document from one well-known origin, link to it from its crawler documentation, and keep the host in its clients' User-Agent comment stable, so that consumers can associate the pair once and are not exposed to the confusion described in Section 9.6. Other publisher requirements appear where they arise: location and discovery in Section 3, choice of service names in Section 6, canonical prefix form in Section 4.4.1, HTTP freshness in Section 5, and granularity of disclosure in Section 9.4. 9. Security Considerations Kelley Expires 25 April 2027 [Page 17] Internet-Draft SAIL October 2026 9.1. Fetching from Request-Derived Locations A consumer that derives the location of a SAIL document from the host of the URL in a request's User-Agent comment (Section 3) is acting on attacker-controlled input. Any client can name any host, turning the consumer into a fetcher of the attacker's choosing. A consumer doing so SHOULD NOT fetch inline with handling the triggering request, MUST fetch only via "https" on port 443 at exactly the well-known path, MUST rate-limit fetches, and SHOULD cache negative results, so that a stream of requests naming fresh hosts cannot be used for request amplification or to probe internal services. Only the host of the URL is used: any port, path, or query it carries is ignored, a URL whose scheme is not "http" or "https" is ignored, and a consumer MUST NOT fetch when the host is an IP literal. 9.2. Unverified Prefix Claims Nothing in a SAIL document establishes that the publisher controls, holds, or solely occupies any address it lists. The format carries no proof of holdership, and a careless or hostile publisher can list space belonging to, or shared with, someone else. The inferences in Section 7 tolerate this because each is keyed on a claim of the publisher's own identity: a wrong listing causes the publisher's names to be honoured or refused in the wrong places and affects no one else. Any decision keyed on the address alone — admitting, blocking, or labelling traffic from a listed prefix regardless of what identity it claims — lacks that protection and lands on whoever actually occupies the space. A consumer that makes such a decision is acting on its own evidence, outside this format, and should first establish the publisher's control of the prefix by independent means (for example forward-confirmed reverse DNS, or RPKI [RFC6480] or IRR origin data), bearing in mind that control does not imply sole occupancy. 9.3. False Assertions A false exhaustive (the service in fact also sends from elsewhere) or a false exclusive (another of the publisher's services in fact also sends from the set) causes consumers to refuse genuine traffic from the publisher the treatment it is due. The harm falls on the publisher, which is the party that made the assertion; third parties are unaffected because neither assertion concerns them. In-document expiry (Section 5) bounds how long a once-true assertion can outlive the deployment it described. Kelley Expires 25 April 2027 [Page 18] Internet-Draft SAIL October 2026 9.4. Infrastructure Disclosure A SAIL document necessarily reveals something about the publisher's egress. Fine-grained prefix sets and service names can reveal considerably more: data-centre footprint, provider relationships, internal service boundaries, and the timing of deployments as entries appear and disappear. Publishers should treat the document as a public interface and choose its granularity accordingly. 9.5. Redirected Documents Because a document reached by redirect is attributed to the origin that issued the redirect (Section 3), an origin can point its well- known URI at some other publisher's document. Doing so is self- limiting: the redirecting origin thereby adopts that document's prefixes and assertions as its own statement about its own service names, and can cause only claims of (its own origin, name) to be confirmed or refuted by them (Section 6). It gains nothing it could not have said directly, and the other publisher's names are unaffected. 9.6. Counterfeit Documentation URLs A SAIL document speaks for the origin at whose well-known URI it was requested (Section 3), not for any product token that appears in it. Nothing prevents an impostor from sending User-Agent: AcmeBot/1.0 (+https://not-really-acme.example/bot.html) and serving, at https://not-really-acme.example/.well-known/sail, a well-formed document that lists the impostor's own addresses under a service named AcmeBot with exhaustive = true. A consumer that derives the document's location from the User-Agent comment (Section 3) and then checks the request against that document will find the claim "confirmed" — correctly, in the narrow sense that the operator of not-really-acme.example did send it — while learning nothing about whether Acme did. This is why Section 6 defines the identity as the pair (origin, service name) and why a request-supplied URL is not evidence of authority. A consumer that has pinned (acme.example, AcmeBot) by means outside the request is unaffected: the counterfeit document speaks only for not-really-acme.example, and if Acme's genuine document marks AcmeBot exhaustive, the impostor's request is refuted by it regardless of what the counterfeit says, and the consumer SHOULD act on that refutation. A consumer with no pinned origin for AcmeBot learns from the counterfeit document only that some party at not-really-acme.example vouches for the request, and MUST NOT carry Kelley Expires 25 April 2027 [Page 19] Internet-Draft SAIL October 2026 over to it any standing it associates with Acme. Section 8 advises publishers on keeping their origin stable so that this confusion does not arise for their own names. [[EDNOTE: Should we discuss Forwarded and X-Forwarded-For headers?]] 10. IANA Considerations 10.1. Well-Known URI IANA is requested to register the following in the "Well-Known URIs" registry established by [RFC8615]: URI suffix: sail Change controller: IETF Specification document(s): this document, Section 3 Status: permanent Related information: N/A 10.2. Media Type IANA is requested to register the following in the "Media Types" registry, per the procedure in [RFC6838]: Type name: application Subtype name: sail+toml Required parameters: N/A Optional parameters: N/A. The format version is carried in-document by the schema key (Section 4.3). Encoding considerations: 8bit. A SAIL document is TOML, which is UTF-8 text (Section 4.1). Security considerations: see Section 9 Interoperability considerations: Consumers accept a document that parses and validates regardless of the Content-Type it was served with (Section 3), to accommodate publishers on static hosting that cannot set this type. Published specification: this document Kelley Expires 25 April 2027 [Page 20] Internet-Draft SAIL October 2026 Applications that use this media type: operators of automated HTTP clients publishing their egress addresses, and sites and intermediaries verifying the claimed identity of automated requests Fragment identifier considerations: N/A Additional information: Deprecated alias names for this type: N/A. Magic number(s): N/A. File extension(s): N/A. Macintosh file type code(s): N/A. Person & email address to contact for further information: see Authors' Addresses Intended usage: COMMON Restrictions on usage: N/A Author: see Authors' Addresses Change controller: IETF 10.3. Structured Syntax Suffix [[EDNOTE: +toml is not currently in the IANA "Structured Syntax Suffixes" registry. Either this document registers it per Section 6 of [RFC6838] (Name: TOML; +suffix: +toml; References: [TOML]; encoding, fragment identifier, and security considerations as for TOML text; Contact and Change controller: IETF), or the media type above falls back to a bare application/sail. To be resolved before this document progresses.]] 11. References 11.1. Normative References [IANA-IPV4-SP] IANA, "IANA IPv4 Special-Purpose Address Registry", . [IANA-IPV6-SP] IANA, "IANA IPv6 Special-Purpose Address Registry", . Kelley Expires 25 April 2027 [Page 21] Internet-Draft SAIL October 2026 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, . [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, . [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 2006, . [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, DOI 10.17487/RFC5952, August 2010, . [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, "Special-Purpose IP Address Registries", BCP 153, RFC 6890, DOI 10.17487/RFC6890, April 2013, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, . [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, . [RFC9111] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Caching", STD 98, RFC 9111, DOI 10.17487/RFC9111, June 2022, . Kelley Expires 25 April 2027 [Page 22] Internet-Draft SAIL October 2026 [RFC9309] Koster, M., Illyes, G., Zeller, H., and L. Sassman, "Robots Exclusion Protocol", RFC 9309, DOI 10.17487/RFC9309, September 2022, . [TOML] "TOML: Tom's Obvious Minimal Language, v1.0.0", 2021, . 11.2. Informative References [CBCP] "Crawler Best Practices", 2026, . [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, DOI 10.17487/RFC3056, February 2001, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, . [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix Reserved for Documentation", RFC 3849, DOI 10.17487/RFC3849, July 2004, . [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, DOI 10.17487/RFC4380, February 2006, . [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks Reserved for Documentation", RFC 5737, DOI 10.17487/RFC5737, January 2010, . [RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for IPv4 Multicast Address Assignments", BCP 51, RFC 5771, DOI 10.17487/RFC5771, March 2010, . [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, DOI 10.17487/RFC6052, October 2010, . Kelley Expires 25 April 2027 [Page 23] Internet-Draft SAIL October 2026 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, . [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, . [RFC7450] Bumgardner, G., "Automatic Multicast Tunneling", RFC 7450, DOI 10.17487/RFC7450, February 2015, . [RFC7526] Troan, O. and B. Carpenter, Ed., "Deprecating the Anycast Prefix for 6to4 Relay Routers", BCP 196, RFC 7526, DOI 10.17487/RFC7526, May 2015, . [RFC7534] Abley, J. and W. Sotomayor, "AS112 Nameserver Operations", RFC 7534, DOI 10.17487/RFC7534, May 2015, . [RFC7535] Abley, J., Dickson, B., Kumari, W., and G. Michaelson, "AS112 Redirection Using DNAME", RFC 7535, DOI 10.17487/RFC7535, May 2015, . [RFC8190] Bonica, R., Cotton, M., Haberman, B., and L. Vegoda, "Updates to the Special-Purpose IP Address Registries", BCP 153, RFC 8190, DOI 10.17487/RFC8190, June 2017, . [RFC9421] Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP Message Signatures", RFC 9421, DOI 10.17487/RFC9421, February 2024, . [WBA-ARCH] "Web Bot Auth Architecture", 2026, . Acknowledgments TODO Author's Address Kevin Kelley Anthropic Kelley Expires 25 April 2027 [Page 24] Internet-Draft SAIL October 2026 Email: kelleyk-ietf@kelleyk.net Kelley Expires 25 April 2027 [Page 25]