Audit metadata is not cryptographically bound to the token request anchor #2110

Summary

During auditor approval, TokenRequestMetadata is checked for structural/cryptographic consistency with the accompanying TokenRequest.Actions, but it is never cryptographically bound to the TokenRequestAnchor (the transaction identifier). Only Actions are covered by the anchor-bound signing scheme; Metadata is not.

Details

The audit-approval pipeline validates that metadata matches the actions it is submitted alongside:

• common.Auditor.Check → ValidateStructure (token/core/common/auditor.go) checks action-count parity, per-action ActionID positional alignment, and action-type/metadata-type alignment.
• IssueMetadata.Match(action) / TransferMetadata.Match(action) (token/driver/request.go) check structural correspondence (input/output counts, extra signers, issuer identity) between metadata and the deserialized action.
• In the zkatdlog driver, InspectOutput/InspectIdentity (token/core/zkatdlog/nogh/v1/audit/auditor.go) recompute Pedersen commitments from the cleartext value/type/blinding-factor in the metadata and check them against the action's on-the-wire commitments, and match audit info against identities.

None of these checks take the transaction Anchor into account. The Anchor/txID value is threaded through the entire AuditContext/Context call chain, but only ever appears inside log statements and error-message strings — never in a comparison.

Separately, the only part of a token request that is ever cryptographically signed — by participants (MarshalToSign) or by the auditor (MarshalToAudit) — is Actions bound to Anchor via TokenRequest.MarshalToMessageToSign (token/driver/request.go). Its own doc comment states: "The anchor MUST be unique per transaction to prevent signature reuse." TokenRequestMetadata has no signature, hash, or MAC field at all, and is explicitly excluded from every signing path:

• Request.MarshalToAudit() (token/request.go): "serializes the request for auditor signatures (excludes metadata)"
• Request.MarshalToSign() (token/request.go): "serializes the request for participant signatures" — same exclusion.

docs/driverapi.md states that the Auditor Service allows auditors "to inspect token requests and their associated metadata against a provided anchor to ensure compliance" — this is not what the implementation does today.

Impact

Because metadata is validated only for structural consistency with a set of actions — and never for having been produced specifically for the anchor it's submitted with — metadata that was legitimately generated for one transaction can be resubmitted paired with a different, structurally-compatible action set under a different anchor, and every metadata check (ValidateStructure, Match, InspectOutput, InspectIdentity) will pass. The auditor's own signature, which is anchor-bound, is computed strictly after this (already-succeeded) metadata check and never covers metadata, so it provides no retroactive protection against this scenario. The legitimate parties for the original transaction have no way to detect that their metadata was reused elsewhere.

Suggested direction

Bind TokenRequestMetadata to the Anchor before/while it is validated during audit — e.g., include the anchor in the metadata's structural validation, or require metadata to carry (or be accompanied by) something that ties it to the specific anchor it was generated for, so metadata generated for transaction A cannot be replayed as valid metadata for transaction B.