[Agentproto] Re: 回复：Re: DRAFT minutes from the AGENTPROTO BoF

[Shawn Sammartano <[e-mail]>]

Mikhail, thank you. You said what I was trying to say, but a lot better. 
The split between enforcement and observation, and independence being a 
property of the deployment and not the mechanism, is clearer than what I 
wrote. I'll use your framing from here.

Spot on where you corrected me too. My counter-chain only catches a copy 
if the two chains reach someone outside b that b can't quietly cut off. 
If b can drop the bad chain and nobody outside ever sees it, it catches 
nothing. That observer has to sit outside the wire. A message format 
can't make one. Best I can say is the signed receipt roots could go to a 
party outside b, and even then it's only as good as that party.

One small thing to add, and only to your last line. Where the design has 
to say what happens when the dependency is missing or can't be checked, 
I'd default that to closed. If a design keeps working when its 
enforcement or observation point drops, that's the exact gap b waits 
for. It's the one spot I can point to something I've worked on: the 
effect model refuses anything it doesn't recognize instead of passing it 
through. So the text could ask that a missing or unverifiable dependency 
denies the action, not just that the behaviour is defined. Take it or 
leave it.

Dapeng, thanks for laying out the OAuth pieces. Treat this as a 
question, not a correction, since you know that work better than I do. 
DPoP ties the token to c's key, which stops someone who grabs the token 
but doesn't have the key. But in Stephen's case b builds and hosts c. So 
wouldn't b already have c's key, and be able to make a valid proof 
itself? If I'm wrong on that, I'd want to know. I'm not knocking the 
mechanisms. It just looks to me like each one, DPoP, the deferred token, 
the step-up, still leans on something being outside b. Same thing 
Mikhail is pointing at. That's the only reason I'd keep the gate from 
assuming any one mechanism, so the OAuth pieces and everything else get 
judged the same way.

So for what it's worth, I think Mikhail's text is a strong one for the 
charter, maybe with the closed-by-default line added. It gives Stephen 
the gate he asked for without picking the mechanism for anyone. I'm 
newer at this than most of you, so weigh my read accordingly.

Shawn

On 7/30/2026 8:26 AM, 刘大鹏(鹏成) wrote:
> Hi Stephen,
>
> I'd like to provide a perspective on how the OAuth WG's ongoing work 
> may address your concerns.
>
> 1. Preventing 'b' from using 'c's token: Sender-constrained tokens 
> (DPoP [RFC 9449]) bind the token to 'c's key material. Even if 'b' 
> intercepts it, 'b' cannot present it without 'c's private key.
>
> 2. When 'c' needs credentials: We should not refuse to provide the 
> credential, but authorize based on 'c's behavior. High-risk operations 
> should trigger user confirmation. The Deferred Token Response 
> mechanism [1] enables this: the AS returns a deferral code, and the 
> user approves out-of-band before the token is issued. The AI Agent 
> Auth draft [2] further specifies that "such interactions do not by 
> themselves constitute authorization and MUST be bound to a verifiable 
> authorization grant issued by the authorization server. The agent 
> SHOULD therefore translate user confirmation into an OAuth 
> authorization event (e.g., step-up authorization via CIBA) before 
> accessing protected resources" (Section 10.6).
>
> These mechanisms are actively under discussion in the OAuth/WIMSE WG 
> (including at IETF 126). I agree the charter should treat solving 
> these issues as a gating factor, but believe the OAuth/WIMSE WG is 
> already building the necessary building blocks. The agentproto WG's 
> charter should align with these efforts rather than reinvent them.
>
> [1] 
> https://datatracker.ietf.org/doc/draft-gerber-oauth-deferred-token-response/ 
>
> [2] https://www.ietf.org/archive/id/draft-klrc-aiagent-auth-00.html
>
> Regards,
> Dapeng
>
>     ------------------------------------------------------------------
>     发件人：Stephen Farrell <stephen.farrell=[e-mail]>
>     发送时间：2026年7月30日(周四) 08:44
>     收件人："Charles Eckel (eckelcu)"<eckelcu=[e-mail]>
>     抄　送：Leslie Daigle<[e-mail]>;
>     "[e-mail]"<[e-mail]>; Orie<[e-mail]>
>     主　题：[Agentproto] Re: DRAFT minutes from the AGENTPROTO BoF
>
>
>     Hiya,
>
>     On 30/07/2026 01:07, Charles Eckel (eckelcu) wrote:
>     > Hi Stephen,
>     >
>     >> On Jul 29, 2026, at 4:31 PM, Stephen Farrell
>     >> <stephen.farrell=[e-mail]> wrote:
>     >>
>     >>
>     >> Hiya,
>     >>
>     >> On 29/07/2026 23:59, Charles Eckel (eckelcu) wrote:
>     >>> Please be sure to review and provide your comments on the
>     Issues (https://
>     >>> github.com/ietf-artarea/charters/issues) that have been
>     opened, the
>     >>> Pull Requests (https://github.com/ietf-artarea/charters/ pulls)
>     >>> that have been submitted, and the reviews and comments that have
>     >>> been provided. This input will be used to update the draft
>     charter.
>     >>> In the interest of maintaining momentum, my goal is for this
>     update
>     >>> to be posted to the datatracker and to the list for additional
>     >>> review and discussion by early next week.
>     >>
>     >> I won't have time to follow GH issues/PRs in the coming weeks. (It
>     >> is vacation time.)
>     >>
>     >> My main charter comments though might be ones I can express now:
>     >>
>     >> - I'm v. unclear that IETF work in this space would prosper due
>     to other
>     >> efforts having far more adoption. I don't however object to lots of
>     >> other people wasting lots of time if that's the case, but it'd seem
>     >> sub-optimal.
>     >>
>     >> - If agents can talk to one another in paths or trees, then before
>     >> chartering a WG I would suggest we need to have an answer for this
>     >> question: If (a,b,c) is a comms path between agents (perhaps
>     within a
>     >> tree) and if 'c' is actually a newly created entity, but one
>     that needs
>     >> access to a long-term secret credential accessible at 'a' (e.g. pwd
>     >> or SSH private key) and where that credential must not be
>     exposed to
>     >> 'b' nor easily abused - then how's that going to work?
>     >
>     > I agree that agentproto needs an answer for this. My take on it is
>     > that ‘c’ should not be able to access "a long-term secret credential
>     > accessible at ‘a' (e.g. pwd or SSH private key)”; rather, ‘a’ should
>     > have a mechanism to authorize ‘c’ to do something specific on behalf
>     > of ‘a’.
>
>     I can see why you'd go there. However, it's unclear to me that
>     OAuth can effectively solve the problems.
>
>     I should emphasise that the scenario I posited is one where 'b'
>     creates 'c' and so is in a fine place to cheat;-)
>
>     Firstly, I'm not sure how OAuth could stop 'b' from getting at
>     the token(s) we'd only like to be visible to 'c'.
>
>     Wouldn't we also end up with OAuth tokens that allow 'c' to
>     just change a pwd or add an SSH key? (In practice I mean, for
>     many instances of 'c'.)
>
>     And (despite hating the idea), I'm unclear that instances of
>     'c' could in practice do what's needed without access to a
>     pwd or SSH private key or equivalent. (One might posit use of
>     OTPs or ephemeral SSH private keys perhaps, at the expense of
>     either callbacks to 'a' or needing 'a' to do some setup with
>     the targets with which 'c' interacts, but that's where we
>     maybe get beyond the remit of the OAuth WG.)
>     > My understanding is that the OAuth WG intends to define such a
>     > mechanism, per this statement in its updated charter, "Complex
>     > Delegation: Developing new mechanisms or/and extensions for
>     > authorization of automated agents working on behalf of users,
>     > including addressing scenarios where automated agents act across
>     > multiple administrative domains.”
>
>     It's not clear to me that that's something this putative WG can
>     delegate to the OAuth WG. I may well be wrong, or just unable to
>     grok the complexity inherent in an OAuth solution though;-)
>
>     It'd also be quite the challenge to explain the security of such
>     an OAuth solution I think, and it'd be liable to be a solution
>     that easily resulted in mis-configuration, or in the opposite
>     of least-privilege.
>
>     All that said, I do accept that a good IETF OAuth scheme might
>     well be better than what MCP or A2A people independently invent.
>
>     I'm also not asking that the charter text include a worked out
>     solution. But I do think the charter text ought have solving
>     such issues as a gating factor before publication.
>
>     Lastly - I'm not asking this to be awkward (honest:-), but it
>     seems a plausible scenario, and is one I dunno how to solve.
>
>     Cheers,
>     S.
>
>
>     >
>     > Cheers, Charles
>     >
>     >> (And the more obvious general cases too of course:-) If there's
>     no good
>     >> answer for that, then I'm sorta strongly against chartering a WG as
>     >> we'd be inevitably enabling pick-pocket agents. (And it'd just be
>     >> smelly;-)
>     >>
>     >> I do not think OAuth or any other existing IETF technology by
>     itself
>     >> provides an answer to the credential question above.
>     >>
>     >> Thanks, S.
>     >>
>     >>
>     >>
>     >>
>     >
>
>
>     _______________________________________________
>     Agentproto mailing list -- [e-mail]
>     To unsubscribe send an email to [e-mail]
>
>
>
> _______________________________________________
> Agentproto mailing list [e-mail]
> To unsubscribe send an email [e-mail]
-- 

*Shawn Sammartano*, Founder
BubbleFish Technologies, Inc.
Sovereign AI infrastructure
bubblefish.sh

---
CONFIDENTIALITY NOTICE:
The contents of this email message and any attachments are intended 
solely for the addressee(s) and may contain confidential and/or 
privileged information and may be legally protected from disclosure. If 
you are not the intended recipient of this message or their agent, or if 
this message has been addressed to you in error, please immediately 
alert the sender by reply email and then delete this message and any 
attachments. If you are not the intended recipient, you are hereby 
notified that any use, dissemination, copying, or storage of this 
message or its attachments is strictly prohibited.