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

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

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]>
发送时间：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/ <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]