Thanks — you’ve read it exactly as intended, and I should be plain about one thing first: the sidecar, its connection and its certificate are the pattern I recommend, not code the series builds. The published policies take the stamp as given; depth is a context value the tests set, and the forbid caps it at two. So everything below is design, not something I can point at a test for.

Queues: a stamp bound to a connection doesn’t survive a store, so I’d do both of the things you name, not one. The enqueuing relay signs the hand-off record (tenant pair, on-behalf-of user, initiator, depth, deadline, task id); the dequeuing relay verifies that signature, increments depth itself, and does a fresh RFC 8693 exchange with the consumer as audience and scope ≤ what the record carries. The queue is one more hop that can become a confused deputy, so it gets no authority of its own.

Clock skew: agreed on a small grace window at the verifier. The constraint I’d add is that a child’s deadline may only shrink from its parent’s, and must sit within the exchanged token’s exp — a retry can re-issue a task, never a wider deadline. Leeway at the check, nothing that extends.

On 8693: yes, that split. One extra use for the nested chain beyond audit: its length should equal the relay’s depth count. Two independent records of the chain; if they disagree, something forged one.

Your comment changed the post. The last section, What this doesn’t solve, now ends with a paragraph on hand-offs through a queue: the signed record, re-stamp at dequeue, the deadline bound and the chain-length check, stated as the natural next step rather than code the series runs. The relay paragraphs now read as the design the policies assume.