[WIMSE] Re: IETF 127 Hackathon: WIMSE interop scenarios for agent call chains

[Iman Schrock <[e-mail]>]

Hi Ben,

Thanks for building on the revocation case.

For the scenario files, could you distinguish confirmed revocation from an
expired status cache and an unavailable status service? A test policy may
deny all three, but the log should preserve the reason. That will let us
tell whether the revocation check worked.

It would also help to label which expectations come from the planned -01
changes. Section 7 of -00
<https://www.ietf.org/archive/id/draft-le-agent-passport-00.html#section-7>
leaves an unavailable valid status list to local policy and recommends
denial for high-value operations, so the tested policy needs to be explicit.

For the before-effect case, I would keep the expected result simple: once
the enforcing service sees the revocation, the protected operation produces
no effect.

Best,
Iman


On Thu, 12 Nov 2026 16:44:27 -0600, Ben Le <[e-mail]> wrote:

Hi Alexander,

Thank you for running this. Your negative cases are close to what
draft-le-agent-passport tries to pin down, so here are scenarios from that
draft that extend yours across the two trust domains. Each has one expected
result that two implementations can compare.

1. Status list unreachable. Make the status list for one hop unavailable,
with no cached copy inside its time-to-live. Expected: the receiving
service treats the credential as revoked and rejects the request. Variant:
the operation is designated low value and a bounded grace period applies;
expected: accepted only inside the grace period, rejected after it. Second
variant: one unresolvable status anywhere in a delegation chain invalidates
the whole chain.

2. Revocation after delegation. This extends your mid-transaction case, and
I support Iman's version of it. Agent A in domain A delegates to agent B,
the first request succeeds, and then A is revoked while B's credential has
not expired. Expected: B's next call fails closed at the receiving hop,
including when that hop is in domain B, and any high-value operation
revalidates before it takes effect. Record the check that stopped it,
whether any effect occurred, and the time from revocation to the first
rejection, which the draft bounds by the smaller of the credential's
remaining lifetime, the status list's time-to-live and the cache bound.

3. Delegation that widens. A downstream receipt grants more than the
receipt it came from (a wider host, more methods, a longer lifetime).
Expected: rejected at the hop that receives it. The draft's table of
per-constraint comparison rules (host, port, methods, paths, tools, body
size, call count, spend, expiry, audience) gives each implementation the
same pass or fail for a given pair of receipts.

4. Cumulative limit across two services. Run it twice with a limit of N
calls. First, each of two services counts on its own: expect the chain to
exceed N in total, which shows why a shared limit cannot be enforced that
way. Second, the receipt names exactly one service as the accounting party:
expect the limit to hold at N. A receipt that carries a limit but names two
audiences should be rejected.

5. Request rewritten in transit. A proxy changes the authority or path
after the client signed. Expected: signature verification fails at the
receiving service, unless the proxy forwards its own verification result
over an authenticated channel that the service already trusts.

6. Tool description changes between hops. The credential pins the digest of
each tool definition (and of the agent's build). Partway through the chain,
a service serves a changed tool description, or the agent presents a
different build. Expected: the next receiving hop checks the digests at
call time and rejects the request.

I can write each of these as a short scenario file with the inputs, the
expected result and the log line to record, in whatever format your harness
uses. If you tell me the format (or point me to the AI2II repository), I
will send them before the hackathon starts. I would also like to join
remotely; please send the details.

The draft is at
https://www.google.com/url?q=https://datatracker.ietf.org/doc/draft-le-agent-passport/&source=gmail&ust=1794609866981000&sa=E,
and -01 will be posted after IETF 127. There is a side meeting on Tuesday
17 November (18:45 to 19:45 PT, Plaza A), where results from the hackathon
would be very welcome.

Best regards,
Ben Le
Redthread Security