Non-repudiation and key rotation: audit trail considerations?

[christian-posta]

Agent delegates use ephemeral keys, and agent servers can rotate their JWKS. The spec focuses on proving message authenticity at request time where the entity signing the message holds the private key bound to the agent identity. But how should adopters think about audit and non-repudiation after the fact?

Once keys rotate out of JWKS, old signatures become unverifiable. The only persistent identifiers are agent and sub (agent delegate), but these don't help you cryptographically prove "agent X signed request Y at time T" after key rotation.

Is this intentional (privacy-preserving by design)?

Should the spec offer guidance for deployments that need audit trails?

Are there recommended patterns (e.g., resources archiving tokens at verification time, key transparency logs)?

[dickhardt]

Good points. I think a transparency log is a good direction to explore for this.

[dickhardt]

@christian-posta what are your thoughts on recommending a transparency log?

[nickgamb-strata]

Our trajectory hash chaining proposal in PR #10 addresses part of this.

The core idea: each audit entry in the mission log chains to the previous via SHA-256(prev_hash | action | params | result), seeded from the mission's s256. This gives you a tamper-evident execution log whose integrity is verifiable independently of key material - you don't need the signing key to verify the chain, just the s256 anchor and the ordered entries.

This doesn't solve the full non-repudiation problem (you still can't prove agent X signed request Y after key rotation), but it does give you a cryptographic guarantee that the audit trail hasn't been modified, reordered, or had entries removed after the fact. If the PS records the chain at verification time, you get durable audit integrity even as keys rotate out.

For deployments that need stronger non-repudiation, the hash chain could be extended with a receipt pattern - the PS returns a signed receipt for each audit entry that the agent or a third party can archive. That way you have both chain integrity (our proposal) and point-in-time attestation (receipts signed with a PS key that has a longer lifecycle than agent keys).