Hi Bob, Thanks for the close read. The fact that you start from agreement on the core premise, that an agent presenting itself to a counterparty needs an accountable party behind it, established without a central registry, is the part that matters most. Several of your objections actually sharpen the draft rather than undermine it.
Let me start with a distinction that I think resolves much of what follows. Groundmark is not asserting the domain as the agent's identity namespace. It is asserting an attestation about the accountable operator behind whatever agent presents itself. The domain is the control point that lets that operator publish and revoke, and that lets a third party attest to it. It is not a name for the agent. Discovery and naming are a separate layer. That is the territory of work like DNSid and ANS, and they are composable with this, not in competition with it. That reframing speaks directly to your points on uniqueness, collision avoidance, and split identity. Those are real requirements for an identity namespace, and they are deliberate non-goals here, because Groundmark mints no names. You noted that the explicit non-goals section is good. I take your comment as a prompt to make this one far more explicit in the next revision. An agent that appears under two domains operated by the same party produces two attestations pointing at the same accountable operator. There is no split accountability, even with two anchor points. The durable subject of the attestation is the operator, not the hostname. On "how would I know procurement.enterprise.com <http://procurement.enterprise.com/> is an agent and not some URL": agent-ness is not inferred from the hostname string. It is established by the presence of the _agentid record and a verified RFC 9421 signature on the request. The string does no identity work. The cryptographic material does. On DKIM: your critique is fair, and I would rather narrow the analogy than defend it. You are right that DKIM carries namespace coupling. The address lives in the domain, and the MX designates the key holder, and Groundmark does not work that way. The single property we borrow from DKIM is narrower: administrative control of the zone as proof of authority to publish and revoke what sits under it. That is the trust property we rely on, without the namespace coupling. We will make that scoping explicit and stop implying the fuller parallel. On DNSSEC MUST: the requirement is scoped, and I think that scoping answers your "commensurate with other DNS assets" concern. The MUST attaches to retrieval of the IDSP attestation key, which is the trust chain a relying party uses to make a decision. There, an unauthenticated answer permits key substitution and a forged attestation, which is a categorically different downside than email sender authentication, where DKIM and DMARC operate against a different threat model with other signals available. The Level 0 self-standing core does not carry the DNSSEC requirement. It attaches where the attestation chain does. The alternative, validating attestation authenticity through WebPKI, reintroduces a certificate-authority dependency and a bootstrap circularity that DNS-anchoring exists to avoid. I will make the threat model explicit in the security considerations rather than leaving the MUST to stand on assertion. Thank you for the DKA pointer. I have now read draft-swaminathan-dka-framework, and I think it is a useful reference point precisely because it sits on an adjacent layer. DKA binds public keys to email-address identifiers and distributes them from a domain-designated key service, reporting which verification methods that service performed at registration. Its security considerations are explicit, in §10.4, that this provides provenance of the binding and not trust, and that relying applications apply their own trust policy. That is the distinction Groundmark addresses. Groundmark does not bind a key to an identifier and report self-performed checks. It introduces an independent attesting party, the IDSP, whose defining obligation is disclosure of the method behind an attestation about the accountable operator behind an agent. DKA reports provenance from the key publisher. Groundmark provides attestation from a third party. The two read as composable layers rather than alternatives, and I expect they would compose cleanly. A more thorough treatment of what "identity" means in this context is a fair ask, and the next revision will carry it. Regards Elliot Noss > On Jun 14, 2026, at 11:28 AM, Bob Traverz <[email protected]> wrote: > > Eliot - > > I read the first specification: draft-noss-jeftovic-groundmark-core > > Here are some comments on your specification: > > - I fully agree with this sentiment: "when an agent presents itself to a > counterparty, is there an accountable party behind it, established without a > central registry." Agents need an anchored identity for any contracts to be > meaningful. > > - I need more convincing that "domain" is that identity anchor. I also think > DKIM analogy ineeds work. DKIM is not just a public key that happens to be in > the DNS. It authenticates outgoing email as originating from a given domain > because the email address and the domain share the same namespace and the > domain controls the MX record that designates the mail server that holds the > DKIM public key. In the groundmark framework, the domain is just a discovery > point for a public key. > > - DNS can be a useful discovery mechanism for agents it hosts; the document > is less convincing that the domain provides a natural namespace for agent > identity. Identity management requires uniqueness management and collision > avoidance among other things. > > - DNSSEC "MUST" seems like a steep requirement. While extra security is > always a good thing, it must be commensurate with other DNS assets. If DKIM > and DMARC - which you use as analogous concepts, operate without DNSSEC, why > GroundMark warrants DNSSEC MUST needs explanation. > > - I think explicit statement of non-goals is good. > > - The document has put a lot of thought into the cryptographic attestation > which is good. I'd encourage a more thorough description of what agent > "identity" means. Given "procurement.enterprise.com > <http://procurement.enterprise.com/>", how would I know it is not some url, > but an agent? If an agent is cross-organizational and have different urls on > two different domains but is really the same agent, does the domain > affiliation create split identity unnecessarily? > > - FYI: I recently reviewed a specification with similar goals and > architecture for associating keys with email identities. > https://datatracker.ietf.org/doc/draft-swaminathan-dka-framework/ > > Good luck. > > Bob Traverz >
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
