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

["刘大鹏(鹏成)" <[e-mail]>]

Hi Shawn,
If b builds and hosts c and has c's key, I would be curious what the trust model would be. Does b control c's code, runtime, keys? If so, then no protocol mechanism makes c independent of b. Only architectural mechanisms (TEEs, keys provisioned by a, etc.) may create independence. But then the question would be: if b has full control of c, what makes c a separate trust entity?
So before discussing solutions, the trust model should be clarified. This is exactly what agentproto should do: discuss and clarify the scenarios, trust models, and requirements, then coordinate with the relevant WGs to develop solutions.
Thanks,
Dapeng
------------------------------------------------------------------
发件人：Shawn Sammartano <[e-mail]>
发送时间：2026年7月31日(周五) 00:18
收件人："刘大鹏(鹏成)"<[e-mail]>; Stephen Farrell<stephen.farrell=[e-mail]>; "Charles Eckel (eckelcu)"<eckelcu=[e-mail]>
抄　送：Leslie Daigle<[e-mail]>; "[e-mail]"<[e-mail]>; Orie<[e-mail]>
主　题：Re: [Agentproto] 回复：Re: DRAFT minutes from the AGENTPROTO BoF
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/ <https://datatracker.ietf.org/doc/draft-gerber-oauth-deferred-token-response/ > 
[2] https://www.ietf.org/archive/id/draft-klrc-aiagent-auth-00.html <https://www.ietf.org/archive/id/draft-klrc-aiagent-auth-00.html >
Regards,
Dapeng
------------------------------------------------------------------
发件人：Stephen Farrell <stephen.farrell=[e-mail]> <mailto:stephen.farrell=[e-mail] >
发送时间：2026年7月30日(周四) 08:44
收件人："Charles Eckel (eckelcu)"<eckelcu=[e-mail]> <mailto:eckelcu=[e-mail] >
抄　送：Leslie Daigle<[e-mail]> <mailto:[e-mail] >; "[e-mail]" <mailto:[e-mail] ><[e-mail]> <mailto:[e-mail] >; Orie<[e-mail]> <mailto:[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]> <mailto: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/ <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] <mailto:[e-mail] >
 To unsubscribe send an email to [e-mail] <mailto:[e-mail] >
_______________________________________________ Agentproto mailing list -- [e-mail] <mailto:[e-mail] > To unsubscribe send an email to [e-mail] <mailto:[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.