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

[Shawn Sammartano <[e-mail]>]

Dapeng,

You're right, and that's the better question to settle first.

If b controls c's code, runtime, and keys, then nothing on the wire 
makes c its own trust entity. Same point Mikhail made. The independence 
has to come from the deployment, keys provisioned by a, or a TEE b can't 
see into, not from any format or token we add.

So your order is right. Name the scenarios and the trust models and the 
requirements first, then hand the pieces to the WGs that own them. I 
don't think agentproto can answer Stephen's credential case before 
that's written down, since every mechanism we've named leans on 
something outside b, and we still haven't said what that thing is or who 
keeps it honest.

The one I've been building has the same limit. It's application layer, 
so by your own logic it can't make c independent of b either. It assumes 
b owns the wire, it fails closed on anything it can't check, and the 
receipts only mean something if the roots reach someone outside b. It's 
not a fix for the trust model, it's just a protocol already sitting 
inside the limit you and Mikhail are describing, which might only be 
worth something for the closed by default line I raised earlier.

If I've got the TEE part wrong, or there's a case where a protocol 
mechanism really does make c independent, tell me. Still new to how this 
group works, so weigh it accordingly.

Shawn S.

On 8/1/2026 10:40 PM, 刘大鹏(鹏成) wrote:
> 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/
>
>     [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.
>
>
-- 

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