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

[Kaveh Ranjbar <[e-mail]>]

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
<https://www.google.com/url?q=http://rdap.db.ripe.net/autnum/219419&source=gmail&ust=1785674826607000&sa=E>
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
<https://www.google.com/url?q=http://rdap.db.ripe.net/ip/2a04:2a00::80&source=gmail&ust=1785674826607000&sa=E>
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]
>