Currently, the Red Hat Quay Management API is architecturally human-centric. Authentication requires an OAuth 2.0 Bearer token that must be manually generated by a user within the Web UI. This is problematic for the following reasons:

• Human Dependency: Automation (e.g., Terraform, Crossplane, or custom CI/CD scripts) must "masquerade" as a human user.
• Lifecycle Management: If the human user who generated the token leaves the organization or is deactivated in LDAP/AD, the automation breaks.
• Security Risk: There is no native way to provision a non-human identity with programmatic-only access. Robot Accounts exist, but they are restricted to registry operations (push/pull) and cannot be used to manage the platform itself.

Proposed solution:
Introduce Service Accounts (or "API-capable Robot Accounts") as first-class non-human identities capable of authenticating against the Red Hat Quay Management API
Key features:

• Programmatic Provisioning: Ability to create these accounts and rotate their secrets/tokens via the API itself (using a bootstrap or administrative credential).
• Decoupled Identity: These accounts should not be tied to a specific human user or external identity provider (IdP) entry.
• Fine-Grained Scoping: Allow these accounts to be restricted to specific organizations or specific actions (e.g., "Create Repository" or "Manage Team Members") without granting full administrative rights.
• Secret Management Integration: Support for standard machine-to-machine (M2M) flows, such as OAuth 2.0 Client Credentials Grant AND (crucially) supporting workload identity federation with OIDC-based workload identities (e.g., SPIFFE/Spire or Kubernetes ServiceAccount token exchange).

User Stories / Use Cases

• Infrastructure as Code (IaC): As a Platform Engineer, I want to use Terraform to provision 50 new repositories and set up team permissions without having to manually paste an OAuth token from my personal profile into a CI secret store.
• Automated Governance: As a Security Administrator, I want a script to run every hour to audit repository permissions and prune old tags using an identity that is audited as svc-quay-auditor rather than a specific employee's name.
• Dynamic CI/CD Pipelines: As a Developer, I want my pipeline to dynamically create a new Quay Organization for a project using a short-lived token, ensuring no long-lived human credentials are saved in the CI environment.

Comparison with Current Workarounds

• Current Workaround: Creating a "dummy" human user in identity provider solely for Quay automation.
• Why it fails: It consumes a seat license (if applicable), requires bypassing MFA for that account, and violates the principle of "non-human" identity management in modern security audits.

While "Keyless Authentication for Robot Accounts" was a great step forward, it currently only solves the problem for the Registry API (push/pull). We are specifically asking for this same "machine identity" philosophy to be extended to the Management API.