Hi Ben, Thanks for the careful read, especially on the ParamKey allocation question.
On (1), you are right. ParamKeys are service-connection hints, not indirection pointers. Using them to reference a document at a different URL is the wrong shape for SVCB. I will drop the atn and atn-digest SVCB ParamKey registrations from -01. On (2), this is convergent with feedback I received from Aijun Wang on the dmsc thread, and it matches my own reassessment of -00. -01 will reposition ATN around HTTP-resource identity using a .well-known origin discovery pattern: • Bootstrap is per-origin, not per-agent. The client fetches https://{origin}/.well-known/atn (RFC 8615) to get an Index Document. • The Index Document is signed with JWS, lists the agents available at the origin, and carries origin-level capability declarations. • Each agent is an HTTP resource at its own URL under the origin (e.g., https://example.com/agents/alice), returning the Capability Manifest and the other per-agent artifacts. • Many agents share one origin. Creating, modifying, or removing agents requires no DNS changes. DNS becomes one optional binding for the cross-organizational, domain-keyed case. The TXT record collapses to a thin announcement: “ATN is supported at this origin, see the well-known URI.” It no longer points at individual agents and no longer carries integrity hints. That is the part of -00 that earned your criticism, and rightly so. On (3), the new architecture sharpens the JWS justification. The Index Document is exactly the artifact that needs offline-verifiable provenance. It gets cached, mirrored, fed into SCITT transparency services, and reconstructed during audit long after the original TLS connection has closed. HTTPS authenticates the fetch; JWS authenticates the content for everything downstream. -01 will make JWS on the Index Document MUST, not RECOMMENDED, regardless of DNSSEC posture. To your underlying point on whether DNS is the right discovery substrate at all: -01 reframes ATN as discovery-agnostic, with the four artifacts and the handshake as the normative core. .well-known on origin is the default binding for HTTP-native agents. DNS is one optional binding among several. I will post -01 before IETF 126 with these changes. Happy to discuss further before then or at the dnsop session. Thanks, Enrique On May 18, 2026, at 11:29 AM, Ben Schwartz <[email protected]> wrote: There have been several messages asking similar questions on DNSOP recently. Maybe we should write an FAQ for SVCB... As I wrote in previous discussions on this topic [1][2]: 1. SVCB generally assumes that you are connecting to a service identified by (part of) a URI, including a scheme. What is the URI in this case? If there is none, SVCB is likely not the right solution. 2. It sounds like you are assuming that agents are identified by domain names, but are operating in a HTTP-centric world. In an HTTP-centric world, it's probably better to let agents be identified by an HTTP resource, so that they can be created and modified more easily. (There are also privacy advantages.) 3. It looks like this proposal is trying to fetch HTTP resources that are authenticated by a non-HTTP signature chain. This is a lot more complicated than a solution using standard HTTP server authentication, and the benefit is not clear to me. --Ben Schwartz [1] https://mailarchive.ietf.org/arch/msg/dnsop/8v6J897lNyVil4zW3hsR8xGbExw/<https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_dnsop_8v6J897lNyVil4zW3hsR8xGbExw_&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=XXqibAFiYDdfWNiaTQ7_UQfyRgIxsoUr07awOSGSXHs&m=YlADFbbUDAGEy3h56uLwmMfK4kjj496DNWUDM0KKLVQLVTuYrgOa5AxzPSx43Ees&s=FaHZjfkdSrMuyambkRbvKx0AHYPnKyd-Djlyy1FNB9s&e=> [2] https://mailarchive.ietf.org/arch/msg/dnsop/EUpxbLgilznpyJgaaR7GZwleqOw/<https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_dnsop_EUpxbLgilznpyJgaaR7GZwleqOw_&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=XXqibAFiYDdfWNiaTQ7_UQfyRgIxsoUr07awOSGSXHs&m=YlADFbbUDAGEy3h56uLwmMfK4kjj496DNWUDM0KKLVQLVTuYrgOa5AxzPSx43Ees&s=2RpQ8xA8jXzfF6y9LoW6cHGDxPZiUOqI1lAdLaMVBBs&e=> On Sun, May 17, 2026 at 6:15 PM Enrique Somoza <[email protected]<mailto:[email protected]>> wrote: Hi dnsop, This is a cross-post pointer from my dmsc thread earlier today on draft-somoza-atn-agent-trust-negotiation-00. The draft sits primarily in dmsc but registers SVCB ParamKeys, so I wanted to give dnsop visibility on the DNS-layer content Hi dnsop, This is a cross-post pointer from my dmsc thread earlier today on draft-somoza-atn-agent-trust-negotiation-00. The draft sits primarily in dmsc but registers SVCB ParamKeys, so I wanted to give dnsop visibility on the DNS-layer content specifically. The dnsop-relevant part is small. The draft requests two SVCB ParamKey registrations: atn URI Absolute HTTPS URI pointing to an ATN Index Document atn-digest hex-string SHA-256 digest of the Index Document for integrity binding It also proposes the same two names as TXT key=value tags for compatibility with existing TXT-based agent discovery records (notably AID). The integrity model: the digest is bound to the content at the URL, not the DNS lookup itself. This is the same model as Subresource Integrity in web platforms. DNSSEC remains useful for authenticating the binding; the digest covers the artifact after fetch. The draft requires JWS signature on the Index Document when DNSSEC is not validated, and makes it RECOMMENDED but not REQUIRED when DNSSEC is in use. Questions where I would value dnsop input: 1. The name pattern. "atn" and "atn-digest" mirrors patterns in existing TXT-based discovery drafts. Is there a dnsop preference for the integrity field name (e.g., "atn-i", "atn-sha256", etc.) before this goes anywhere near IANA? 2. Allocation path. The draft is Experimental. Is the right path: (a) provisional allocation from the private-use range during the Experimental period, (b) early allocation with WG sponsorship, or (c) wait until standards-track maturity? 3. SVCB vs TXT. The draft offers both forms for compatibility with the discovery proposals already in flight (AID uses TXT; DNS-AID uses SVCB). Should ATN deprecate the TXT form and require SVCB given dnsop's general direction? 4. DNSSEC interaction. The current language ("RECOMMENDED but not REQUIRED when DNSSEC is in use") may be too permissive. Should JWS-on-Index be MUST regardless? The draft itself is at: https://datatracker.ietf.org/doc/draft-somoza-atn-agent-trust-negotiation/<https://urldefense.proofpoint.com/v2/url?u=https-3A__urldefense.com_v3_-5F-5Fhttps-3A__datatracker.ietf.org_doc_draft-2Dsomoza-2Datn-2Dagent-2Dtrust-2Dnegotiation_-5F-5F-3B-21-21Bt8RZUm9aw-215LBAuicD5Zum5Csa-2DGkjTXR-5FTGt1AazU8V9MEbNqSPz-2DybsAYd-5FhxPXryqdXN-2DZ5LCv-5FoVJR-5F9tjMA-24&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=XXqibAFiYDdfWNiaTQ7_UQfyRgIxsoUr07awOSGSXHs&m=YlADFbbUDAGEy3h56uLwmMfK4kjj496DNWUDM0KKLVQLVTuYrgOa5AxzPSx43Ees&s=GYpToxflICiU3LGaMMHprGjiaBz44FaMv0WerdXbA8k&e=> The DNS Binding section is Section 4 and is short. Thanks, Enrique _______________________________________________ DNSOP mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
