Hello Ben, all, Ben raises a key point: if the protocol is HTTP-based, .well-known may suffice for discovery. I agree. But discovery and identity verification are different problems.
Discovery answers “what agents does this domain have?” AID handles that. Identity verification answers “is this agent genuinely authorized by this domain, and can it prove it?” nothing handles that today. A .well-known endpoint is controlled by the agent itself. A compromised agent can modify its own .well-known. DNS records are controlled by the domain owner. This separation of control is why DKIM publishes keys in DNS rather than on the mail server. I have submitted two drafts applying the SPF/DKIM/DMARC pattern to agent identity: - draft-ferro-dnsop-apertoid-00: DNS-based agent declaration and key publication https://datatracker.ietf.org/doc/draft-ferro-dnsop-apertoid/ - draft-ferro-httpbis-apertoid-sig-00: HTTP request signing with Ed25519 https://datatracker.ietf.org/doc/draft-ferro-httpbis-apertoid-sig/ Plain TXT records at <selector>._apertoid.<domain>, same pattern as _domainkey for DKIM. No SVCB, no new record types. Designed to complement AID, not replace it. Best regards, Andrea Ferro
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
