Binding PqP messages to their sender
The identity implementation now connects authenticated principals, queue ownership, and message-signing identity across the control plane and clients.
Establish who controls a peer identity
We have implemented a stronger identity boundary for PqP. The Worker derives a stable principal from the supported identity provider, binds it to a queue identity, and carries that relationship into authenticated control-plane operations.
An email address can be useful display information, but it should not decide durable ownership. The new contract uses provider identity claims for the principal and keeps that principal separate from mutable contact details.
Connect the signature to the claimed sender
Message integrity requires more than accepting a signature over some content. The recipient also needs the claimed sender, the authenticated queue sender, and the published signing identity to agree. The client changes enforce that relationship at the message boundary.
Control-plane changes apply the same ownership logic to identity publication and updates. Key rotation and recovery need to preserve the relationship rather than allowing a stale client to overwrite a newer identity state.
Exercise the complete lifecycle
The implementation is in place, with Worker-first deployment and limited HTTP smoke checks completed. Packaged-client rollout, migration, recovery, and controlled identity-provider scenarios remain active gates. A successful local test does not close those operational cases.
Acknowledgements, replay handling, duplicate suppression, and delivery recovery remain separate protocol work. This milestone strengthens who may send and mutate identity state; the next layer must establish what happened to an authorized message after it was accepted.