Grants one external identity — an issuer this tenant trusts, plus the
sub claim its tokens carry — the ability to authenticate as this

Cryptographic Actor.

🔴 This is the act that actually grants access. Declaring a trusted

issuer says only that this deployment is willing to accept tokens from it; nothing
can authenticate until a binding exists. From the moment this call returns, a token
naming that issuer and that subject — carrying the derived audience, signed with an
admitted algorithm, from an enabled issuer — authenticates this actor with
every role, capability grant and exchange context the actor holds.

The issuer may be one this tenant declared or a deployment-scoped one every tenant inherits; both are equally bindable. It does not have to be enabled yet: the natural order of work is declare, bind the workloads, then enable, and requiring the issuer to be live first would mean widening the trust set before the bindings that make it useful exist.

🔴 Uniqueness is per tenant. The same (issuer, subject) pair

already bound in THIS tenant is a 409; the identical pair under a
different tenant succeeds. Two customers whose workloads carry the same subject
from the same public issuer is legitimate and common, and a global constraint would
answer the second one with the existence of the first one's binding.

🔴 No credential is submitted here, and none exists. The workload keeps

the credential its own identity provider issues it. ANKASecure stores nothing that
could authenticate it, so revoking it in your own IdP is sufficient.

The actor is never created. An actor id that does not exist in this

tenant answers 404 and writes nothing — an actor provisioned by this
call would exist with defaults this endpoint chose rather than the authorization
surface an administrator reviewed, and it would have been created by the external
identity being bound to it.

Entitlement-gated. Reading the bindings and removing them are not.