Quantum Workload Identity and Delegated Authorization

Quantum platforms need explicit identity and delegated authorization, as do other systems that process sensitive data or costly workloads. An identity failure can corrupt evidence, route proprietary workloads to the wrong provider, expose calibration state, or allow an unreviewed workload to consume scarce device or reservation capacity.

OpenID Connect uses ID tokens to convey authentication claims to a relying party [R213]. An ID token is not a general-purpose API access token: API authorization requires an appropriate access token and a policy decision. SPIFFE provides workload identities and SVIDs for service-to-service authentication [R214]; it does not by itself grant permission to submit a workload. Preserve human and service identity while enforcing delegated authority at each boundary.

flowchart LR
    Human[Human researcher] --> IdP[Identity provider]
    IdP --> Token[OIDC token]
    Token --> Portal[Quantum portal]
    Portal --> Broker[Workload broker]
    Broker --> SVID[SPIFFE workload identity]
    SVID --> Runtime[Quantum runtime]
    Runtime --> Evidence[Evidence package]

Identity is part of the experiment

A quantum result is not just a circuit and measurement distribution. It is a statement that an authorized actor submitted a specific workload through a specific chain of services under a specific policy. Without identity provenance, the evidence package has a gap.

flowchart TB
    Result[Quantum result] --> User[User identity]
    Result --> Workload[Workload identity]
    Result --> Service[Service identity]
    Result --> Project[Project and cost center]
    Result --> Policy[Authorization policy]
    Result --> Evidence[Reviewer identity]

Delegation chain

Quantum systems are often used through notebooks, workflow engines, portals, CI jobs, and broker services. The platform should not flatten that chain into a single API key.

sequenceDiagram
    participant U as User
    participant P as Portal
    participant B as Broker
    participant S as Scheduler
    participant Q as QPU provider
    participant E as Evidence store
    U->>P: authenticate
    P->>B: delegated request with claims
    B->>S: create workload identity
    S->>Q: submit scoped job
    Q-->>S: job result
    S->>E: write signed evidence
    E-->>U: reviewable package

Delegation should preserve who initiated the work, which project authorized it, which service transformed it, and which provider executed it.

Authorization dimensions

Quantum authorization is multi-dimensional. It is not enough to ask whether a user may call submit_job.

flowchart LR
    Request[Workload request] --> A{Authorized?}
    A --> Qubits[Qubit count]
    A --> Shots[Shot budget]
    A --> Provider[Provider and region]
    A --> Data[Data sensitivity]
    A --> Runtime[Runtime mode]
    A --> Evidence[Evidence requirement]
    A --> Cost[Cost ceiling]

A production authorization decision should include provider, backend family, region, reservation, circuit class, estimated runtime, evidence class, and release status of the target baseline.

Scoped credentials

Never issue a long-lived credential that can submit arbitrary quantum jobs. Use short-lived, scoped credentials that bind to workload metadata.

stateDiagram-v2
    [*] --> Requested
    Requested --> Issued: policy allows
    Issued --> Active: job accepted
    Active --> Expired: time limit reached
    Active --> Revoked: policy or incident
    Revoked --> [*]
    Expired --> [*]

Bind the broker authorization decision to the project, principal, workload hash, runtime contract, cost and shot limits, provider target, and expiration. Enforce those constraints in the broker and use the narrowest provider credential scope available. These are proposed platform controls; providers do not necessarily support every field as a native credential restriction.

Break-glass access

Quantum systems need emergency paths for incident response, but break-glass access must be more constrained than normal access.

flowchart TB
    Incident[Incident] --> Request[Break-glass request]
    Request --> Approver[Independent approver]
    Approver --> Session[Time-limited session]
    Session --> Logging[Full command logging]
    Logging --> Review[Post-use review]
    Review --> Revoke[Credential revocation]

Break-glass sessions should not create claim-bearing results unless the review board explicitly accepts the evidence. A rescue run and a scientific claim are different operations.

Identity-aware evidence

Every evidence package should include an identity envelope.

identity_envelope:
  subject_user: user:researcher@example.org
  subject_project: project:materials-vqe
  initiating_client: notebook:nb-2417
  workload_identity: spiffe://quantum.example/platform/scheduler
  provider_identity: provider-account:prod-qpu-broker
  delegation_chain:
    - portal
    - broker
    - scheduler
    - provider_connector
  authorization_decision_id: authz-2026-04-20-00091
  token_not_before: 2026-04-20T16:01:00Z
  token_expires: 2026-04-20T17:01:00Z

flowchart LR
    Identity[Identity envelope] --> Evidence[Evidence package]
    Authz[Authorization decision] --> Evidence
    Baseline[Runtime baseline] --> Evidence
    Result[Result artifact] --> Evidence
    Evidence --> Review[Reviewer can reconstruct authority]

Operating rule

A workload should not be admitted unless the platform can answer four questions: who asked, which service acted, what policy allowed it, and what evidence will prove it later.

Additional technical sources: [R30], [R153], [R284].