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

[Blake <[e-mail]>]

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]