[Agentproto] Re: DRAFT minutes from the AGENTPROTO BoF

[Shawn Sammartano <[e-mail]>]

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=[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 [e-mail]
-- 

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