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 80932120DF165 for ; Wed, 29 Jul 2026 22:09:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1785388171; bh=V4/3+E1es9CbTHKeE2wUw4zp3vfP+tbGYlROHgSlpUk=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=UoSUsGUe5fOv3JVXGHQEO7ByQpqO8xqeZeAEftWk3RhLtTi0oBP0VZp+6x801tOWZ Jb0dGYxpY54IAAe8cO4a2rkiwOW8VklkOrH0BQLtrXmZjfqjB2suXon/oOBI6l+b5W ju2LPN3j+9e+vvWwxLWRv2uJdqgQM8E5s8F+SdeY= 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 jYP5AgtC7sU1 for ; Wed, 29 Jul 2026 22:09: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 69F51120DF156 for ; Wed, 29 Jul 2026 22:09: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=BhuMQZ+NBTpns8q0E2cmlClMeJf4IAleHx8QanvXqHg=; b=De1Y/eg2vlevO0RZWo09nb47JF BrkVLTec+BlsQ75PYR99SMo0xjLHm4dk9FViOdQrlqqPUYbdLXBX4m4/x92hSc8JfIzAG06IBmrSa 6IOEyYRKeNfyszi343eolNG7uztB6tHDJdyfdAPyamaWh0iABwCWETtc5idEycncsOO5zK/6yJwl0 45C0ofo59G1XnWxjCNk48XczJdwznmUGoVAYeB0C41xSlwMzM6wkQPijERcyc0cM/hDAV+AcoW104 re+UPVsBuxApbY9XE52Cz8TZiMWubN02FMBMqw5/jogUfQW83O/lxGIohUu1ZOYCB/mBczJbLlVvV OFKfJl2w==; Received: from mailnull by cp53-ga.privatesystems.net with spam-scanner (Exim 4.99.5) (envelope-from ) id 1wpJ1H-000000083Nf-0dZF for agentproto@ietf.org; Thu, 30 Jul 2026 00:09:23 -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=61747 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 1wpJ1F-000000083Mt-1X8M; Thu, 30 Jul 2026 00:09:22 -0500 Content-Type: multipart/alternative; boundary="------------007kdLZKVlh4ZItiHFiB6Iv8" Message-ID: Date: Wed, 29 Jul 2026 22:08:58 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: 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: 62TRIQYZZNC4Y46RUSJWKEZY6EKFKAZL X-Message-ID-Hash: 62TRIQYZZNC4Y46RUSJWKEZY6EKFKAZL 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?q?=5BAgentproto=5D_Re=3A_DRAFT_minutes_from_the_AGENTPROTO_BoF?= 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. --------------007kdLZKVlh4ZItiHFiB6Iv8 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi all, I'm new to the list, so sorry if some of this was already covered. I've spent a lot of time on the (a,b,c) problem. Here's where I got to, including the parts I can't solve. For those I'm mostly pointing at other people's work. I'd take Charles's point one step further. The password or private key should never travel. Not to c, and not through b. Once it moves, I don't see how you get safety back. b built c, and as noted upthread, b is in a fine place to cheat. So what travels instead? A permission slip that isn't worth much to steal. The one I built works like this: 1) It's tied to one exact request, down to the byte. The approver approves the exact bytes it read. Change anything afterward and the approval stops matching. 2) It works once. There's a ledger. A second use gets refused. 3) It carries a cap on how much harm the action can do. Anything unrecognized is treated as the worst case and refused. A delegated permission can never be broader than the one it came from. 4) Every use lands in a tamper-evident log that records what caused what. None of that needs my draft. You could build the same properties as an OAuth extension. The properties are the point. Credit where it's due, because most of this is not new. Macaroons have done offline narrowing since 2014, where whoever holds the token can add restrictions without going back to the issuer. Biscuit does the same and verifies with public keys, so its verifiers don't need a secret that would let them forge. So narrowing isn't mine and neither is public key verification. The part I haven't found in either, and I may have missed it, is that both are bearer tokens. Whoever holds one can use it again and again until it expires or gets revoked. The slip above is tied to one exact request and gets refused on the second use. I also read the drafts already in front of the group, and some of this ground is being worked. Apologies to those authors if I'm restating them. draft-bu-agentproto-security-principal-binding splits out which party verifies which claim, with binding, freshness and failure behavior stated per claim. draft-rampalli-cross-org-delegation-mapping already has human authorization bound to the exact action digest, failing closed when it's missing, stale, or bound to different bytes. That second one is close to what I described above, so please read me as agreeing with it rather than proposing something new. What I can add is running code and test vectors. > Wouldn't we also end up with OAuth tokens that allow 'c' to > just change a pwd or add an SSH key? With permission slips like this, I don't think so. There's nothing sitting around that says "may manage keys." The most a thief gets is triggering the one action that was already approved, once, on the record. b can still drop or delay traffic. I don't have a fix for that either. And I'm not saying this is the only way to do it. It's one I've built. A Go and a Rust implementation produce identical bytes against shared test vectors, so at least it's buildable. Draft at [1]. It's input, not an answer. Now the part I agree is hard. Key custody. If b builds c, then b can read c's key, so b can be c. No message format fixes that, mine included. Two angles look workable to me. None are wire-only and none are mine. First, protect the key. 1) Run c on hardware where even its creator can't read its memory, generate the key inside, and require proof of that before granting anything. That's the RATS and EAT work. Cloud enclaves already gate key services this way. One catch. "The key can't be extracted" isn't enough if b can still ask the hardware to sign. Use of the key has to be tied to the measured workload, which is what the proof is for. 2) Split the key between c and a service run by a, so c alone can't sign. Then every signature has to ask a's half, and a's half can say no each time. FROST does this today, RFC 9591, with implementations in more than one language. Post-quantum threshold signing isn't ready yet though. 3) Give c a key that lives minutes instead of months, and make it re-prove its environment to get a new one. A stolen copy goes dead fast. Second, assume the key does get copied and make that not pay off. 4) Catch the copy. Have every action from c carry a counter in a chain that only moves forward. If b copies the key and uses it while c is also running, you get two different chains claiming the same identity, and that's proof the key was duplicated. You can't tell which one is really c, but you can prove it happened and shut the identity down. This is a suggestion, not something I've built. 5) Make the key change after each use, in a way that can't be run backwards. A copy taken today stops working, and using the old copy shows up out of order. 6) Put a total budget on the whole delegation, not just on each permission. One use per approval still allows a thousand small approvals across a tree. One budget for the tree means when it's spent it's spent, no matter who holds which key. 7) For destructive actions, put a delay between approval and execution and let a cancel during the delay. It's also worth sorting actions by whether they can be undone at all. If you can't stop misuse, being able to reverse it inside an hour is worth a lot. 8) Don't let the creator be the only approver. If b creates c, b shouldn't be able to approve c's actions by itself. Two parties that don't share machines. Bank wires work this way for the same reason. That doesn't stop b from cheating. It makes cheating small and hard to hide. When b owns the machine, I don't know how to do better than that. On legacy targets. If the far end only understands the old password, then somebody who holds the password has to do the typing. The realistic shapes are the ones already named upthread, with the costs already named. c sends its one-shot exact request back to a, and a either does the operation itself or sets up a short-lived credential scoped to that one job. A protocol can make those round trips exact, single use, and logged. It can't make them go away. Getting rid of them means the target, or a gateway in front of it, learns to check delegated permissions. That's adoption work, not cryptography. One more thing, since this is all about long-term secrets. Traffic recorded today can be decrypted years from now, and long-term credentials are exactly what's worth recording. So these links should probably use post-quantum hybrid encryption. I have a draft on that side too [2], though it's hop by hop and does nothing about b in the middle. On the charter, the gating idea seems right to me, and it might be easier to state as properties than as a worked solution. Long-term secrets never pass through intermediaries or newly created agents. Delegated authority is exact, single use, no broader than its parent, and logged. Copying an agent's key is detectable. A key that can't be shown to be out of its creator's reach is treated as untrusted for anything that matters. One process note. I see the charter text is being worked on GitHub, and I also see that not everyone can follow GitHub over the next few weeks. If a property list like that is useful, I'm happy to open it as an issue there and post the same text here so it's visible to people who aren't watching the repo. Happy to help with test vectors too. And happy to be told where I'm wrong. [1] https://datatracker.ietf.org/doc/draft-bubblefish-naalp/ [2] https://datatracker.ietf.org/doc/draft-bubblefish-npamp/ Cheers, Shawn S. On 7/29/2026 5:44 PM, Stephen Farrell wrote: > > 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 toagentproto-leave@ietf.org -- *Shawn Sammartano*, Founder BubbleFish Technologies, Inc. Sovereign AI infrastructure bubblefish.sh --------------007kdLZKVlh4ZItiHFiB6Iv8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Hi all,

I'm new to the list, so sorry if some of this was already covered. I've spent a lot of time on the (a,b,c) problem. Here's where I got to, including the parts I can't solve. For those I'm mostly pointing at other people's work.

I'd take Charles's point one step further. The password or private key should never travel. Not to c, and not through b. Once it moves, I don't see how you get safety back. b built c, and as noted upthread, b is in a fine place to cheat.

So what travels instead? A permission slip that isn't worth much to steal. The one I built works like this:

1) It's tied to one exact request, down to the byte. The approver approves the exact bytes it read. Change anything afterward and the approval stops matching.

2) It works once. There's a ledger. A second use gets refused.

3) It carries a cap on how much harm the action can do. Anything unrecognized is treated as the worst case and refused. A delegated permission can never be broader than the one it came from.

4) Every use lands in a tamper-evident log that records what caused what.

None of that needs my draft. You could build the same properties as an OAuth extension. The properties are the point.

Credit where it's due, because most of this is not new. Macaroons have done offline narrowing since 2014, where whoever holds the token can add restrictions without going back to the issuer. Biscuit does the same and verifies with public keys, so its verifiers don't need a secret that would let them forge. So narrowing isn't mine and neither is public key verification. The part I haven't found in either, and I may have missed it, is that both are bearer tokens. Whoever holds one can use it again and again until it expires or gets revoked. The slip above is tied to one exact request and gets refused on the second use.

I also read the drafts already in front of the group, and some of this ground is being worked. Apologies to those authors if I'm restating them. draft-bu-agentproto-security-principal-binding splits out which party verifies which claim, with binding, freshness and failure behavior stated per claim. draft-rampalli-cross-org-delegation-mapping already has human authorization bound to the exact action digest, failing closed when it's missing, stale, or bound to different bytes. That second one is close to what I described above, so please read me as agreeing with it rather than proposing something new. What I can add is running code and test vectors.

> Wouldn't we also end up with OAuth tokens that allow 'c' to
> just change a pwd or add an SSH key?

With permission slips like this, I don't think so. There's nothing sitting around that says "may manage keys." The most a thief gets is triggering the one action that was already approved, once, on the record. b can still drop or delay traffic. I don't have a fix for that either. And I'm not saying this is the only way to do it. It's one I've built. A Go and a Rust implementation produce identical bytes against shared test vectors, so at least it's buildable. Draft at [1]. It's input, not an answer.

Now the part I agree is hard. Key custody. If b builds c, then b can read c's key, so b can be c. No message format fixes that, mine included. Two angles look workable to me. None are wire-only and none are mine.

First, protect the key.

1) Run c on hardware where even its creator can't read its memory, generate the key inside, and require proof of that before granting anything. That's the RATS and EAT work. Cloud enclaves already gate key services this way. One catch. "The key can't be extracted" isn't enough if b can still ask the hardware to sign. Use of the key has to be tied to the measured workload, which is what the proof is for.

2) Split the key between c and a service run by a, so c alone can't sign. Then every signature has to ask a's half, and a's half can say no each time. FROST does this today, RFC 9591, with implementations in more than one language. Post-quantum threshold signing isn't ready yet though.

3) Give c a key that lives minutes instead of months, and make it re-prove its environment to get a new one. A stolen copy goes dead fast.

Second, assume the key does get copied and make that not pay off.

4) Catch the copy. Have every action from c carry a counter in a chain that only moves forward. If b copies the key and uses it while c is also running, you get two different chains claiming the same identity, and that's proof the key was duplicated. You can't tell which one is really c, but you can prove it happened and shut the identity down. This is a suggestion, not something I've built.

5) Make the key change after each use, in a way that can't be run backwards. A copy taken today stops working, and using the old copy shows up out of order.

6) Put a total budget on the whole delegation, not just on each permission. One use per approval still allows a thousand small approvals across a tree. One budget for the tree means when it's spent it's spent, no matter who holds which key.

7) For destructive actions, put a delay between approval and execution and let a cancel during the delay. It's also worth sorting actions by whether they can be undone at all. If you can't stop misuse, being able to reverse it inside an hour is worth a lot.

8) Don't let the creator be the only approver. If b creates c, b shouldn't be able to approve c's actions by itself. Two parties that don't share machines. Bank wires work this way for the same reason.

That doesn't stop b from cheating. It makes cheating small and hard to hide. When b owns the machine, I don't know how to do better than that.

On legacy targets. If the far end only understands the old password, then somebody who holds the password has to do the typing. The realistic shapes are the ones already named upthread, with the costs already named. c sends its one-shot exact request back to a, and a either does the operation itself or sets up a short-lived credential scoped to that one job. A protocol can make those round trips exact, single use, and logged. It can't make them go away. Getting rid of them means the target, or a gateway in front of it, learns to check delegated permissions. That's adoption work, not cryptography.

One more thing, since this is all about long-term secrets. Traffic recorded today can be decrypted years from now, and long-term credentials are exactly what's worth recording. So these links should probably use post-quantum hybrid encryption. I have a draft on that side too [2], though it's hop by hop and does nothing about b in the middle.

On the charter, the gating idea seems right to me, and it might be easier to state as properties than as a worked solution. Long-term secrets never pass through intermediaries or newly created agents. Delegated authority is exact, single use, no broader than its parent, and logged. Copying an agent's key is detectable. A key that can't be shown to be out of its creator's reach is treated as untrusted for anything that matters.

One process note. I see the charter text is being worked on GitHub, and I also see that not everyone can follow GitHub over the next few weeks. If a property list like that is useful, I'm happy to open it as an issue there and post the same text here so it's visible to people who aren't watching the repo. Happy to help with test vectors too. And happy to be told where I'm wrong.

[1] https://datatracker.ietf.org/doc/draft-bubblefish-naalp/
[2] https://datatracker.ietf.org/doc/draft-bubblefish-npamp/

Cheers,
Shawn S.

On 7/29/2026 5:44 PM, Stephen Farrell wrote:

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

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

--------------007kdLZKVlh4ZItiHFiB6Iv8--