Return-Path: X-Original-To: agentproto@mail2.ietf.org Delivered-To: agentproto@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 5BF1912125ABE for ; Thu, 30 Jul 2026 09:18:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1785428311; bh=W99nfqe0mVyO1Eqh+YcUMWDqwfQyVaM9SYZPhaaTBXo=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=wNJi39A/KRiqCn9sfzbj59Wg6cqsgIbWEkPx8k2+XiYPIwURbmUcWcVjzVT8OzZKT YuneB1lt+Xqy9Vvh0dShe5SNg4XuKcqzBlBrQmIaoE/x5pVkz/w4RqHgRjMoCJjLgN tExVYARGOe6+wPKrchDBEI6cfooCiux1oSk2EuSc= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=bubblefish.sh Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PfhFNI3YnL8z for ; Thu, 30 Jul 2026 09:18:30 -0700 (PDT) Received: from cp53-ga.privatesystems.net (cp53-ga.privatesystems.net [67.222.25.199]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 6636C12125AAD for ; Thu, 30 Jul 2026 09:18:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bubblefish.sh; s=default; h=In-Reply-To:From:References:Cc:To:Subject: MIME-Version:Date:Message-ID:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=u1FJYirCdyIeYLH6albsDjZZWeNIanWGNrjuee8sGBE=; b=WhD0cYsbwS0rKvmOoyT5dsub4y dYUTRZIe73hzAmznQOyy342lcR8R5v6icxBd0QDxfzlUlG850c7ulm6p5ZrlfyvzYvA17KoA9rwqm fyo0m3/hPoSgwht5NdSUJ5iGqmsiQKHXpU2N+KRi7WWwjfNmgbvGhrohoJO3q0SW5D51cuPTBNs4y BZCifqADLVB/rxb3oUa86aVOkf7hkPPxXs9ggKumLCafDx6jF9xvz38bJOuBsWnq9RCC4LYWQ0NPd 8JTvKggibhv8X9eTkc1Qrrkov3shUhFMO2JfJNOqsjeZhaE/ZkrNZf5He3B2nTbmUCdMSC2HWs3sF CiXvnGLg==; Received: from mailnull by cp53-ga.privatesystems.net with spam-scanner (Exim 4.99.5) (envelope-from ) id 1wpTSo-0000000BbOx-0iNX for agentproto@ietf.org; Thu, 30 Jul 2026 11:18:30 -0500 X-ImunifyEmail-Filter-Score: -9.64 X-ImunifyEmail-Filter-Version: 3.8.26/202607291128 X-ImunifyEmail-Filter-Info: UkNQVF9DT1VOVF9GSVZFIE1JTUVfVFJBQ0UgUkNWRF9DT1VO VF9PTkU gSEFTX09SR19IRUFERVIgVkVSSUxPQ0tfQ0IgQVJDX05BIFJDVkRfVE xTX0FMTCBNSU1FX1VOS05PV04gVE9fRE5fRVFfQUREUl9TT01FIFJDV kRfVklBX1NNVFBfQVVUSCBUT19NQVRDSF9FTlZSQ1BUX1NPTUUgRlJP TV9IQVNfRE4gQkFZRVNfSEFNIFRPX0ROX1NPTUUgQVNOIE1JRF9SSFN fTUFUQ0hfRlJPTSBGUk9NX0VRX0VOVkZST00gWE1fVUFfTk9fVkVSU0 lPTg== X-ImunifyEmail-Filter-Action: no action Received: from [67.60.35.204] (port=51485 helo=[192.168.0.56]) by cp53-ga.privatesystems.net with esmtpsa (TLS1.3) tls TLS_AES_128_GCM_SHA256 (Exim 4.99.5) (envelope-from ) id 1wpTSm-0000000BbNW-1vnn; Thu, 30 Jul 2026 11:18:29 -0500 Content-Type: multipart/alternative; boundary="------------gHTdiEoc5XbvwAP4HoK056Jg" Message-ID: <6ecc3641-b021-4378-830a-8a77fab0e202@bubblefish.sh> Date: Thu, 30 Jul 2026 09:18:04 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: =?UTF-8?B?5YiY5aSn6bmPKOm5j+aIkCk=?= , Stephen Farrell , "Charles Eckel (eckelcu)" References: <69DE8C85-04A4-45C4-8726-3AF98FAB7637@cisco.com> <22e6cd10-6e08-4e75-b6a6-506bc90bf25f@cs.tcd.ie> <2CF7C662-76B6-412F-86D6-FA1F35858F01@cisco.com> Content-Language: en-US From: Shawn Sammartano Organization: BubbleFish Technologies, Inc In-Reply-To: X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cp53-ga.privatesystems.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bubblefish.sh X-Get-Message-Sender-Via: cp53-ga.privatesystems.net: authenticated_id: shawn.sammartano@bubblefish.sh X-Authenticated-Sender: cp53-ga.privatesystems.net: shawn.sammartano@bubblefish.sh X-Source: X-Source-Args: X-Source-Dir: Message-ID-Hash: 4TH6UQEFIMBPKTHDYQSA7OGT73R7UWPJ X-Message-ID-Hash: 4TH6UQEFIMBPKTHDYQSA7OGT73R7UWPJ X-MailFrom: shawn.sammartano@bubblefish.sh X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Leslie Daigle , "agentproto@ietf.org" , Orie X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?b?W0FnZW50cHJvdG9dIFJlOiDlm57lpI3vvJpSZTogRFJBRlQgbWludXRlcyBmcm9t?= =?utf-8?b?IHRoZSBBR0VOVFBST1RPIEJvRg==?= List-Id: Agent Communication Protocols Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. --------------gHTdiEoc5XbvwAP4HoK056Jg Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 > 发送时间：2026年7月30日(周四) 08:44 > 收件人："Charles Eckel (eckelcu)" > 抄　送：Leslie Daigle; > "agentproto@ietf.org"; Orie > 主　题：[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 > >> 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 -- agentproto@ietf.org > To unsubscribe send an email to agentproto-leave@ietf.org > > > > _______________________________________________ > Agentproto mailing list --agentproto@ietf.org > To unsubscribe send an email toagentproto-leave@ietf.org -- *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. --------------gHTdiEoc5XbvwAP4HoK056Jg Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

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.

  

Regards,
Dapeng
------------------------------------------------------------------
发送时间：2026年7月30日(周四) 08:44
收件人："Charles Eckel (eckelcu)"<eckelcu=40cisco.com@dmarc.ietf.org>
主　题：[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=40cs.tcd.ie@dmarc.ietf.org> 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 -- agentproto@ietf.org
To unsubscribe send an email to agentproto-leave@ietf.org


_______________________________________________
Agentproto mailing list -- agentproto@ietf.org
To unsubscribe send an email to agentproto-leave@ietf.org
--

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.
--------------gHTdiEoc5XbvwAP4HoK056Jg--