[DNSOP] Re: Cross-post from dmsc: SVCB ParamKey registration in draft-somoza-atn-agent-trust-negotiation-00

[Ben Schwartz <[e-mail]>]

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/
[2] https://mailarchive.ietf.org/arch/msg/dnsop/EUpxbLgilznpyJgaaR7GZwleqOw/
On Sun, May 17, 2026 at 6:15 PM Enrique Somoza <[e-mail]> 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.com/v3/__https://datatracker.ietf.org/doc/draft-somoza-atn-agent-trust-negotiation/__;!!Bt8RZUm9aw!5LBAuicD5Zum5Csa-GkjTXR_TGt1AazU8V9MEbNqSPz-ybsAYd_hxPXryqdXN-Z5LCv_oVJR_9tjMA$>
>
> The DNS Binding section is Section 4 and is short.
>
> Thanks,
> Enrique
> _______________________________________________
> DNSOP mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>