pub const AUTH_NONCE_KEY_ID: &'static str;Expand description
The key_id every bridged nonce is claimed under.
The opener passes one string, cose:<hex kid>:<hex cti>
(replay::nonce_key); auth’s store takes two and stores
{key_id}:{nonce} (in Redis, under cratestack:signature-nonce:). The
bridge does not split the string. It claims all of it as the nonce
under this fixed key_id, so two different opener keys never map to
one entry (splitting on : would not guarantee that). A COSE entry is
therefore cose-envelope:cose:<hex kid>:<hex cti>.
Shared namespace with signed requests. Auth’s {key_id}:{nonce}
join is not injective, and SignedRequestVerifier claims its nonces
the same way, so when both point at one store (the same Redis, or one
shared Arc) they share a keyspace. A verified signed request whose
keyId is cose-envelope or starts with cose-envelope: can
produce the same entry as a COSE message (for example keyId = "cose-envelope:cose",
nonce = "<hex kid>:<hex cti>"). The effect is refuse-only: whichever
claim comes second is reported as a replay, never accepted. To block a
COSE request that way, the signer of such a keyId would have to know
the victim’s random 16-byte cti before the victim’s request lands.
Operators sharing one store between the two must not issue
signed-request key ids with the cose-envelope prefix.