Ben Schwartz <[email protected]> writes:
> Every secure connection starts with a trusted identifier. It sounds like the
> proposed trusted identifier
> here is a domain name (example.com). The contents of the DNS record are
> validated from the DNS
> (presumably via DNSSEC) and participate in a chain of trust that reaches the
> later protocol stages.
>
> Instead, I would encourage you to use an HTTP URL as your initial
> trusted identifier.
Though I do generally like using well known suffixes when possible, he
did state the below (maybe you missed it):
.well-known also assumes an HTTP server. A domain that hosts no website can
still publish an AID TXT
record and advertise an agent endpoint. Some AID endpoints aren’t HTTP
origins at all: the protocol
covers docker:, npx:, and other local execution schemes.
Not everything lives on the web, and I suspect many AI agents may not be
able to place web objects (I'll leave it as an exercise to the reader to
figure out what all the use cases are where this may or may not be
true... might be easier to predict after waiting 5 years though).
> This arrangement offers many advantages:
FYI, though I agree with many of those bullets I don't agree with them
all. A pro/con list comparison would be helpful here (eg, "ease" is
harder to quantify than just "better" -- I've been fighting a hosting
service for 5 days about renewing an SSL cert, so even the "easier to
maintain" bullet to me is a thorn in my side at the moment, but I agree
completely that DNS isn't always easy either depending on the use case.
AKA: they're both difficult at times).
--
Wes Hardaker
Google
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
