Replies: 2 comments 1 reply
-
|
This is a clean way to answer the operator-of-record question, and anchoring the DANE-EE binding to the IANA root rather than a new CA is the right instinct. Worth naming a second, orthogonal question the same seam raises, since the two compose well. DANE-EE answers "which accountable operator holds this signing key." It does not, by itself, answer "is the offering I am verifying byte-for-byte the one that key stood behind," which is the integrity half of the Manipulated Discovery mitigation you quote ("the Merchant signature ensures the integrity of the offering"). A verifier can resolve the TLSA record, match the key, and trust the operator, while the offering under that key still changes a price, a payee, or a security scheme between one check and the next. A key match alone does not surface that. A content-addressed reference over the signed object closes that half without adding infrastructure. Canonicalize the object with RFC 8785 (JCS) excluding its signature field, hash with SHA-256, and you have a stable offline identity of exactly the bytes that were advertised. It recomputes with only a JCS serializer and SHA-256, no key resolution and no CA, so it sits naturally beside a DANE lookup: DANE tells you whose key it is, the content hash tells you whether the offering under that key is unchanged. Different questions, and neither substitutes for the other. The technique is protocol-neutral, so it lands wherever the signed artifact lives, the Payment Mandate payee object being the obvious spot here. We run the same discipline on the A2A side as an open reference ( It also helps the revocation gap you were honest about. Because the content hash is taken over the same canonical bytes the signature signs, a verifier holding the bytes can detect a changed offering even mid-TTL, when it has not or cannot resolve the key at that moment. Glad to compare notes on where the operator anchor and the byte anchor meet if the DANE-anchored identity draft is useful to look at alongside it. Both stay optional and CA-free, which is the part that makes this attractive. |
Beta Was this translation helpful? Give feedback.
-
|
Agreed on the orthogonality, and it is the useful part. DANE-EE answers whose key it is; a content hash over the canonical signed bytes (JCS per RFC 8785, then SHA-256) answers whether the offering under that key is unchanged. Those are genuinely different questions, and neither substitutes for the other, so carrying the hash on the Payment Mandate payee object is a clean home for it. One clarification on the revocation point, so I do not overstate a gap we do not actually have: we serve the per-identity records at a zero TTL, so there is no caching window. A revocation or a key change is visible on the next lookup rather than after a TTL, and in practice that works fine. So the content hash earns its place as pure integrity, catching an offering whose bytes changed under a still-valid key, not as a workaround for DNS freshness. Both stay CA-free, which is the property worth keeping. |
Beta Was this translation helpful? Give feedback.
-
|
That is a fair correction, and zero TTL does remove the freshness window cleanly, so the content hash is not doing any DNS work here. Pure integrity is the right way to frame it. The place that framing earns its keep is the gap between check and use. The key resolves current at the moment of the DANE lookup, but the verifier acts on the offering at a later moment, and a still-valid key can sign a different offering in between. A signature check at that later moment only tells you the bytes in hand are validly signed, not that they are the same bytes you evaluated when the decision was made. Carrying the hash on the payee object pins that exact version across the decision to settlement gap, and across parties, so "the offering I authorized equals the offering being settled" becomes checkable rather than assumed. Same CA free property either way. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
I know the core spec has moved to the FIDO Alliance and this repo is samples and SDK now, so I am raising this as an Idea for the community, and as a companion to the same proposal I put to x402 (x402-foundation/x402#2831), not as a spec change here. I am new to the AP2 community, so tell me if this belongs in the FIDO Agentic Authentication working group instead and I will bring it there too. I would rather learn where you want it than route around you.
The gap
AP2 mandates prove a user authorized a specific purchase. What they deliberately leave open is how a verifier establishes trust in the signing key on the other side. The Trusted Agent Provider model says as much: it "makes the provider of the Agent the party trusted by the Verifier ... but requires Verifiers to establish trust with every Agent Provider." And the Manipulated Discovery mitigation leans on "the Merchant signature ensures the integrity of the offering," without saying how a verifier comes to trust that Merchant key in the first place. That is the seam I want to fill.
The mechanism
The operator behind a Merchant or Trusted Agent Provider publishes its endpoint signing public key as a DANE-EE TLSA record (3 1 1, that is DANE-EE / SPKI / SHA-256 per RFC 7218 and RFC 7671) under a DNSSEC-signed name. A verifier resolves the name, validates DNSSEC, matches the key, and reads RDAP for the address and its ASN to get a real, contactable operator of record. Trust chains to the IANA root, not to a new CA and not to a new identity issuer. It answers one narrow question: which accountable operator stands behind this Merchant or Agent Provider.
This is a friendly extension of something AP2 already does. The OpenID4VP example in the spec uses
client_id_scheme: x509_san_dns, a DNS-name-bound identity. DANE-EE is that same DNS binding made CA-free and DNSSEC-anchored: you check the key against the name in the DNS itself, rather than against a certificate some CA issued for that name.Where it plugs in: the Merchant and Trusted Agent Provider signing keys; the Payment Mandate
payeeobject; and the spec's own Extension Points, which already invite new types under "a collision-resistant naming approach, for example via a rDNS prefix controlled by the specifying entity."How it relates to what is already here
Honest about the fit
Try it now
A live, DNSSEC-validated example anyone can check (short TTL, so re-run):
You get
3 1 1 ...at the TLSA name, the matching AAAA with the AD bit set by a validating resolver, and RDAP resolving the address and AS219419 to an active operator of record. No account, no CA, no prior exchange.Disclosure: I co-founded Whisper Security and we run this in production. I am also bringing the underlying Internet-Draft (draft-ranjbar-dane-anchored-identity) to the IETF DANCE community; it is not on the datatracker yet and I am glad to share the text directly in the meantime. I am keeping this to mechanism and architecture, not commercial specifics, and I am happy to bring it to the FIDO Agentic Authentication working group and to supply a reference implementation if there is interest.
Kaveh
Beta Was this translation helpful? Give feedback.
All reactions