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

[Dick Hardt <[e-mail]>]

Hi Joshua

In AAuth, the mission is the wrong place for the user authentication
mechanism to be recorded as there is no token. A resource that wants to
know the authentication strength of the user can request the `acr` claim or
something like that from OpenID Connect in the resource token. It will then
get an auth token that binds the authentication mechanism to the user
identity and to the mission identifiers.

AAuth is reusing the OpenID Connect authentication claims, and there is
work in the IPSIE WG to drive more standardization on those claims and how
to request them.

/Dick

On Mon, Aug 3, 2026 at 6:57 AM Joshua Ashcroft <[e-mail]>
wrote:

> Blake, Kaveh, Dick, Nick,
>
> Joining this late, but the thread names a seam I have been building
> against for some months, and I think I can add a fourth question and
> one distinction.
>
> The split as stated -- which key signed this, which operator stands
> behind it, did the subject consent -- is the same decomposition I
> arrived at, from the authorization side rather than from consent or
> from the name system. Signature verification, operator resolution, and
> the authority decision are three separate layers in what I run, and
> keeping them apart is load-bearing: the thing I find myself saying
> most often is that verifying an agent's key tells you nothing about
> what it may do. Blake's test seems right. This is the third direction
> the same seam has fallen out of.
>
> One difference worth stating rather than letting it be assumed. My
> third layer is not your third question. Blake's consent is authored by
> the data subject, a third party to the agent, for a read of their own
> attributes. Mine is authored by the operator, authorising their own
> agent to act. Same word, different principal, and they no more
> substitute for each other than one and two do.
>
> Which brings me to a fourth question that does not reduce to any of the
> three.
>
> May this agent, acting for operator A, take this action inside
> operator B's domain, with scope, expiry and revocation, where B did
> not issue A's identity and does not administer it?
>
> That is not question three. The granting party is neither the data
> subject nor the agent's own principal. And it is not question two: an
> operator anchor tells you who stands behind the agent in general, not
> what authority a different operator extended to it for a particular
> engagement.
>
> Dick, your answer to Blake on 12 July is what makes me think this
> composes rather than needing new machinery. If the AS issues only
> where the grant has been made, it is verifying an authority someone
> else signed rather than originating the decision. That is the shape I
> have implemented: the granting operator signs the delegation, and the
> party enforcing it is neither the issuer of the agent's identity nor
> the author of the grant. If AAuth's four-party model already covers
> that, I would rather build on it than beside it, and I would value
> being told whether Person or Mission is the right carrier, or whether
> it belongs at the payload layer with Blake's work instead.
>
> Kaveh, on the RDAP anchor: I think it is the right shape for question
> two, and the no-issuer-to-trust property is doing real work. The
> boundary I would draw is the one you drew yourself, that RDAP tells
> you who is accountable for the infrastructure the agent runs on. For
> agents on shared cloud infrastructure that resolves many unrelated
> operators to a single abuse contact, and it stays silent on what
> authority any of them extended to a particular agent. So I read it as
> answering question two at infrastructure granularity, with a
> sub-question underneath that registration data structurally cannot
> reach. Not a criticism of the anchor; an argument that question two
> has two floors.
>
> Blake, on your 9 July point -- once an agent can drive a browser, a
> click inside its execution context is not evidence of a human
> decision. I agree, and it is the reason I moved authority decisions
> off the agent's machine entirely. When the key and the policy both
> live where the agent runs, the agent can sign what it likes and
> rewrite what it is permitted to do, so operator control is advisory.
> Putting policy behind an authenticated operator session the agent
> holds no credential for is what makes it enforceable.
>
> That does not fully answer you and I do not want to pretend it does.
> If the agent can drive the operator's own logged-in browser, it can
> click through my approval too. Out-of-band signing with a key the
> agent cannot reach is the only complete answer.
>
> What I would add is that two different properties are being called
> consent here, and separating them may matter as much as the
> three-question split does:
>
> 1. Evidence that a human decided. This is what you are protecting, and
> it requires the out-of-band key.
> 2. Binding of accountability, meaning who answers for what the agent
> did. This requires a verified legal principal and survives the
> approval being automated.
>
> Dick's Person is defined as the legal entity that bears accountability
> for the agent's conduct, which is the second property, and it does
> real work even where the first is unavailable. A principal who sets an
> agent running is answerable for what it does whether or not they
> approved the specific act. That is the ordinary position for human
> agents and I do not see why it changes here.
>
> For disclosure of a subject's attributes I think you need the first
> property and there is no substitute. For actions taken under an
> operator's authority, I would argue the second is often the one that
> matters. What makes an authorization worth anything after something
> has gone wrong is a non-repudiable binding to an entity that can be
> held to it, not proof of a mouse click. Which is also an argument that
> question two has to be verified rather than self-asserted, since the
> whole property rests on the operator being a real and identifiable
> entity.
>
> If that is right, the practical shape is to tier it rather than pick
> one. Routine reversible actions carry the accountability binding;
> high-stakes or irreversible ones additionally require an out-of-band
> signature the agent cannot produce. Two things I would want to get
> right about that. It has to be a property the verifier requires and
> can check, not a level the operator declares about itself, or it
> collapses back into self-attestation. And it appears to be a different
> axis from how well the operator is verified: a well-identified company
> can still click through in-session, and a hardware-backed key does not
> tell you who is holding it.
>
> To be concrete about where I intend to take this, and clear that I
> have not built it yet: the direction I am planning is a standing grant
> approved behind a hardware-backed authenticator, in practice a
> passkey, with a freshness requirement on the approval rather than on
> the session. An agent driving the operator's browser can raise that
> prompt but cannot satisfy it, which gets the out-of-band property
> without a second device and without per-request friction, since the
> grant is standing rather than per-call. That is a plan rather than a
> shipped feature today and I would rather say so.
>
> Nick, the Shopify example is useful, and the part I would draw out is
> what it costs. Operator-vouched bearer capability with the agent's own
> key absent is a clean demonstration that the layers are separable. It
> also means that with a thirty-day credential and no per-request agent
> identity, revoking a single misbehaving agent is not expressible --
> you can only revoke the operator's credential and take every agent
> behind it down at once. That is the price of answering two without
> one, and it is the case my work has had to handle.
>
> For context on where I am coming from: I built the
> operator-holds-their-own-key model first, ran it, and moved off it to
> server-side custody with per-organization key isolation and audited
> provisioning. Happy to write up why if it is useful to anyone. The
> short version is that keeping key and policy on the agent's own
> machine makes operator control advisory rather than enforceable, which
> matters more for actions than for reads.
>
> Two questions to close.
>
> Dick, can a Mission express how strongly its approval was
> authenticated? The fields I can see carry approver, agent, approval
> timestamp and authorized tools, so there is a record of when it was
> approved but not of how. A Mission approved behind a hardware key and
> one approved by a click in the agent's own browser look identical to a
> relying party, and under the argument above those are different
> assurances even though the resulting authority is the same.
>
> I ask because my own delegations have the same hole. They carry scope
> and expiry and are signed by the operator ahead of any request, but
> nothing in them records the strength of the approval act, so a
> verifier cannot make the distinction either. If that is a gap in both,
> it may be worth a field rather than a convention.
>
> And more broadly: if anyone has a better mechanism than a
> hardware-backed standing grant for the case where the operator is
> simply not present at the moment the agent acts, I would like to hear
> it. That unattended case is the one I keep failing to solve cleanly.
>
> Best, Joshua Ashcroft
>
> _______________________________________________
> Web-bot-auth mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>