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

[Kaveh Ranjbar <[e-mail]>]

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]
>