Every issuer THAT TENANT has declared, whether it is currently in the trust set or
not, ordered by canonical issuer URL.

Disabled declarations are included deliberately. A configuration surface that showed only the enabled rows would hide a disabled issuer from the operator who disabled it, and there would be no way back to it.

The list does not include the deployment-scoped issuers this tenant also

trusts. Those are the operator's own declarations, live at the deployment plane, and
they are composed into the effective trust set at verification time — a tenant's
issuers are additional to them, never a replacement.

This is the tenant's configuration, not its data: no principal, credential, key or audit content is reachable through it. That is what makes an operator read here consistent with can_access_tenant_data being false.

The ROOT tenant is a valid target for this READ, unlike on every write of this plane. It owns no TENANT-scoped declarations, so the honest answer is an empty list — which is information, where a 4xx would be an error about a well-formed question.

Not entitlement-gated. The operator is the party that sells the edition, so

refusing them on it would be the platform refusing itself. The tenant's own verdict is
readable at ../workload-identity/entitlement (SR-10.6).