[Web-bot-auth] Re: Interest in the human-principal layer above bot authentication

[Nick Mathews <[e-mail]>]

Kaveh, Blake,

Offering a second running implementation, and one worked example the thread does not have yet.

We operate a production merchant-side verifier for automated commerce traffic (Web Bot Auth, Visa TAP, Google AP2), open source at github.com/AVA-PAY/ava-pay. The three-question split reads exactly like the separation we enforce in practice, so if it is useful to test the wording against a second implementation, ours is available: which key signed this is our signature verification, which operator stands behind it is our directory resolution, and did the subject consent is a mandate check that we deliberately never infer from the first two. Merchants get those as distinct answers because collapsing them is where the money mistakes live.

The worked example: Shopify is running Web Bot Auth in production today. Any store admin can issue crawler credentials (Online Store, Preferences, Crawler access), and what comes out is a signature with tag="web-bot-auth", covered components ("@authority" "signature-agent"), and Signature-Agent: "https://shopify.com". They publish a live key directory at https://shopify.com/.well-known/http-message-signatures-directory with the correct media type, and the RFC 7638 thumbprint of the published Ed25519 key matches the keyid in issued signatures. Anyone can recompute that in a few lines.

Two observations from it that bear on this thread.

First, it answers question two while deliberately not answering question one per request. The signature covers only authority and signature-agent, and is valid for thirty days, so it is operator-vouched bearer capability rather than per-request agent identity. The agent's own key appears nowhere. That is a reasonable design for its purpose, and it is a clean example of the layers being genuinely different things: an operator anchor can exist and be cryptographically solid while the per-request and consent layers are simply absent.

Second, on nonce encoding and the Signature-Agent form, a deployed implementation has now voted: padded base64 for the nonce, plain quoted string for Signature-Agent. Worth knowing for anyone writing verifier tolerance rules.

On the RDAP anchor: from the merchant side that shape is attractive for the same reason Kaveh gives, it is accountability data a verifier recomputes with no issuer to trust. Our resolver is a chain of such sources with first-match-wins and revocations never shadowed, and registry-anchored operator accountability slots in as a different kind of source than a key directory, answering question two rather than question one. If a worked example of that composition would be useful, we are glad to build one against the live Shopify deployment above.

Nick Mathews
AVA Pay, Agentic Verification Architecture
https://github.com/AVA-PAY/ava-pay
On Aug 1, 2026 at 8:49 AM -0400, Kaveh Ranjbar <kaveh=[e-mail]>, wrote:
> Blake, picking up your offer to read this against the running implementation. And yes to the point under it: when the same seam keeps falling out from two directions, the name system and your a2a work with Iman, it is probably real.
>
> Here is the operator anchor resolving on a live AS, all of it public registration data a verifier recomputes for itself, no issuer to trust:
>
> http://rdap.db.ripe.net/autnum/219419 returns whisper-as, operator of record viaGraph b.v. (ORG-VB155-RIPE), NOC WN1322-RIPE, and abuse contact [e-mail]
> http://rdap.db.ripe.net/ip/2a04:2a00::80 returns inet6num NL-VIAGRAPH, the same operator and abuse contact
>
> That is the whole of it: who is accountable for the number resource, and a reachable contact, read straight out of the registry that already governs the AS, so it cannot be restated by whoever holds the agent's key today. Standing operator anchor underneath, your per-action consent decision on top, and neither standing in for the other.
>
> If you also want to kick the key-to-name half, I will mint you a live identity and send its name; its DANE-EE 3 1 1 TLSA validates from the DNSSEC root with openssl at depth 0, no CA in the path. But the operator anchor above is the part you asked to see resolve, so I led with that.
>
> All the best,
> K.
>
> On Tue, Jul 14, 2026 04:12 AM, Blake <blake=[e-mail]> wrote:
> > Dick, Kaveh,
> >
> > Dick, that answers it. If the AS issues only where the grant has been
> > made, then it is verifying an authority someone else signed rather than
> > originating the decision, and that is the shape I needed. It also means
> > the two compose without changing AAuth. The subject's grant is the thing
> > the AS checks, and the auth token is what the resource sees. I had been
> > assuming I would need a new issuance path and I don't.
> >
> > Kaveh, the three-question split is right and I'd adopt your wording for
> > it. Which key signed this, which operator stands behind it, did the
> > subject consent to this read. RDAP under AAuth's Person, consent above.
> >
> > The boundary you drew between them is worth naming, because it is the
> > same cut that just landed on the agent2agent thread from a different
> > direction. RDAP is durable registration state that a verifier
> > recomputes; Person is a live decision about one mission. Standing anchor
> > underneath, per-action decision on top, and neither substitutes for the
> > other. That is exactly the standing-grant versus binding-moment
> > separation Iman Schrock and I converged on for the consent objects, and
> > it is reassuring to see the same shape fall out of the name system. If
> > two layers keep splitting the same way, it is probably a real seam.
> >
> > I'm following 126 remotely, so I'll miss the side meeting on Thursday,
> > but I'd take you up on comparing notes. If either of you has a worked
> > example of the operator anchor resolving on a live AS, I'll read it
> > against the running implementation rather than the prose.
> >
> > Best,
> > Blake
> >
> >
> > On Monday, 13 July 2026 at 17:45, Kaveh Ranjbar <kaveh=[e-mail]> wrote:
> >
> > > Blake, Dick, this layering is the right decomposition, and the one I keep arriving at from the DNS side, so let me add that view where it fits and be clear where it does not.
> > >
> > > Three questions, kept apart: which key signed this request, which accountable operator stands behind it, and did the data subject consent to a given read. RFC 9421 answers the first and stays person-agnostic, as you both note. AAuth's Person and Mission answer the second. Blake's consent-settlement answers the third at the payload layer. I agree with that split.
> > >
> > > Where DNS adds something is the operator layer, next to AAuth's Person rather than instead of it. RDAP resolves a name and its address to an operator of record, an ASN and a reachable abuse contact, from public registration data a verifier recomputes for itself, no issuer to trust. The honest boundary: that is not AAuth's Person. RDAP tells you who is accountable for the infrastructure the agent runs on, as durable registration state; AAuth's Person is the legal principal who approved a specific mission, per request. One is a standing operator anchor, the other a live delegating decision, and I would not have either stand in for the other.
> > >
> > > And to be clear about the far end, DNS carries nothing about subject consent or settlement. Whether the subject agreed to a read, and how it is priced and settled, is Blake's payload layer and does not belong in the name system.
> > >
> > > So: a root-verifiable operator anchor beneath AAuth's Person, complementary to the consent layer above it. Happy to compare notes; we run RDAP per address on AS219419 today.
> > >
> > > Kaveh
> > >
> > >
> > > On Sun, Jul 12, 2026 07:42 AM, Dick Hardt <[e-mail]> wrote:
> > >
> > > > Hi Blake
> > > >
> > > > The AS should only issue the auth token in your scenario if the grant had been made.
> > > > /Dick
> > > >
> > > >
> > > > On Sun, Jul 12, 2026 at 4:34 AM Blake <[e-mail]> wrote:
> > > >
> > > > > Hi Dick,
> > > > >
> > > > > Yes, that makes sense and you're right about the Mission - if it guides
> > > > > the person running the agent, it can't carry a grant issued by someone
> > > > > else. UMA rhymes too.
> > > > >
> > > > > It turns on who signs. A pre-configured AS token carries no subject
> > > > > signature, so the verifier trusts a server to have applied the owner's
> > > > > policy rather than checking what the subject signed.
> > > > >
> > > > > Can an AAuth AS issue an auth token on a grant it didn't author,
> > > > > verifying a third party's signed authority rather than originating the
> > > > > decision?
> > > > >
> > > > > Best,
> > > > > Blake
> > > > >
> > > > >
> > > > > On Friday, 10 July 2026 at 01:53, Dick Hardt <[e-mail]> wrote:
> > > > >
> > > > > > Hi Blake, thanks for the clarification.
> > > > > >
> > > > > > Some of what you describes rhymes with the User Managed Access (UMA)[1] work that Eve Maler and others worked on a while ago
> > > > > >
> > > > > > To answer your question, the mission is guiding the person running the agent, so I don't think it is where your subject's consent would be captured.
> > > > > > If I understand the scenario correctly, the AS for the resource would be where an auth token could be issued that would grant the agent access to the request on behalf of your subject.
> > > > > > This is the 4 party model in AAuth where the resource delegates access decisions to its AS, independent of the PS.
> > > > > >
> > > > > > Does that framing make sense?
> > > > > >
> > > > > > /Dick
> > > > > >
> > > > > > [1] https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-grant-2.0.html
> > > > > >
> > > > > > On Thu, Jul 9, 2026 at 3:12 PM ~blake <[e-mail]> wrote:
> > > > > >
> > > > > > > Hi Dick,
> > > > > > >
> > > > > > > Yes, but with one correction.
> > > > > > >
> > > > > > > The endpoint isn't a third party holding data about the subject. The
> > > > > > > subject is the resource owner, and the endpoint serves their attributes
> > > > > > > on their behalf, so the stranger in the picture is the requesting
> > > > > > > client. You're right in that it needn't be an agent; nothing in the
> > > > > > > mechanism is agent-specific.
> > > > > > >
> > > > > > > The consent isn't collected at request time either. The subject signs a
> > > > > > > grant with their own key ahead of any particular read, naming which
> > > > > > > clients it covers (a named client, a class of clients, or any), which
> > > > > > > attributes, which tiers, when it starts and expires, and a revocation
> > > > > > > commitment they can burn later by publishing the preimage. The client
> > > > > > > never holds that consent. It echoes the grant's content address in its
> > > > > > > payment payload, and the server verifies scope and revocation status
> > > > > > > before it discloses anything.
> > > > > > >
> > > > > > > So on the UX flow, in the common case the agent never gets the subject
> > > > > > > involved (deliberate, not an omission). Once an agent can drive a
> > > > > > > browser, a click inside its execution context isn't evidence of a
> > > > > > > human decision. The subject decides once, out of band, with a key the
> > > > > > > agent can't reach, rather than being interrupted mid-request by
> > > > > > > whoever happens to be querying.
> > > > > > >
> > > > > > > What starts it is the read. The client resolves the subject's
> > > > > > > identifier and asks; the endpoint answers 402 - advertising the subject
> > > > > > > - an opaque attribute reference, the disclosure tier, that consent is
> > > > > > > required, and optionally a hint for where a grant may be requested.
> > > > > > > With a grant in scope the client pays, the server discloses and the
> > > > > > > subject is settled a share at disclosure time. Without one, that hint
> > > > > > > is the only path that reaches the subject and it reaches the subject
> > > > > > > directly rather than through a consent screen in the agent's session.
> > > > > > >
> > > > > > > Which leaves the question I put to you. Can a Mission carry a grant
> > > > > > > issued by someone who isn't the agent's Person, or does that sit as a
> > > > > > > layer beside AAuth?
> > > > > > >
> > > > > > > Cheers,
> > > > > > > Blake
> > > > > > >
> > > > > > >
> > > > > > > On Thursday, 9 July 2026 at 23:58, Dick Hardt <[e-mail]> wrote:
> > > > > > >
> > > > > > > > Hi Blake
> > > > > > > >
> > > > > > > > Let me restate the scenario you are wanting to support so I can connect all the dots.
> > > > > > > >
> > > > > > > > An agent (but really could be just any client) is calling an endpoint that has data about a particular person, and you want that person to provide consent for the agent / client to get that data (PII) about the person being served by the endpoint?
> > > > > > > >
> > > > > > > > To support your scenario, the agent would get consent from the person first, and then present that consent to the endpoint?
> > > > > > > >
> > > > > > > > From a UX flow -- how are you thinking that the agent gets the person / subject involved? What starts this scenario?
> > > > > > > >
> > > > > > > > /Dick
> > > > > > > >
> > > > > > > > On Thu, Jul 9, 2026 at 2:49 AM ~blake <blake=[e-mail]> wrote:
> > > > > > > >
> > > > > > > > > Hi Dick,
> > > > > > > > >
> > > > > > > > > Thank you, that was the pointer I needed. Having now read
> > > > > > > > > draft-hardt-oauth-aauth-protocol-09 and aauth.dev, signed requests
> > > > > > > > > over RFC 9421 instead of bearer tokens, and OAuth being the wrong
> > > > > > > > > shape for MCP, both match what I kept running into.
> > > > > > > > >
> > > > > > > > > AAuth already carries a human principal in the Person and Missions,
> > > > > > > > > well beyond Web Bot Auth's key-only model. My consent-settlement work
> > > > > > > > > is about a different human role; not the accountable operator behind
> > > > > > > > > the agent, but the data subject an identity attribute is about, who
> > > > > > > > > issues a scoped, revocable consent grant for a specific read of their
> > > > > > > > > own attributes and takes a share of what the reader pays. That
> > > > > > > > > subject is usually a third party to the agent.
> > > > > > > > >
> > > > > > > > > Specifically, can AAuth's Person and Mission machinery carry a consent
> > > > > > > > > grant issued by someone who is not the agent's Person, or does
> > > > > > > > > subject-side consent and settlement sit as a separate layer beside
> > > > > > > > > AAuth? As I read AAuth-09 it establishes authorisation but does not
> > > > > > > > > price or settle a read, which is the piece I have written up in
> > > > > > > > > draft-morrison-consent-settlement.
> > > > > > > > >
> > > > > > > > > Thibault, yes, Section 6.2 is
> > > > > > > > > draft-meunier-webbotauth-httpsig-protocol, and the
> > > > > > > > > transport-versus-payload split is the seam. The signature
> > > > > > > > > authenticates the agent and stays person-agnostic, while subject
> > > > > > > > > identity and settlement bind at the payload layer, as UCP does with
> > > > > > > > > buyer identity. Consent-settlement lives at that payload layer. Of
> > > > > > > > > your pointers, crawl-payment and draft-klrc-aiagent-auth are closest
> > > > > > > > > to what I am doing, so I will follow those first; the case I care
> > > > > > > > > about is the cross-domain read of a third party's attributes, which
> > > > > > > > > is why it sits beside the established-trust-domain work rather than
> > > > > > > > > inside it. A pointer to the crawl-payment thread would be welcome.
> > > > > > > > >
> > > > > > > > > Cheers,
> > > > > > > > >
> > > > > > > > > Blake
> > > > > > > > >
> > > > > > > > > _______________________________________________
> > > > > > > > > Web-bot-auth mailing list -- [e-mail]
> > > > > > > > > To unsubscribe send an email to [e-mail]
> > > >
> > > > _______________________________________________
> > > > Web-bot-auth mailing list -- [e-mail]
> > > > To unsubscribe send an email to [e-mail]
> >
> > _______________________________________________
> > Web-bot-auth mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> _______________________________________________
> Web-bot-auth mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]