Context
Issue #30 implemented workflow and job permission narrowing for the permission keys used by Kelos. GitHub Actions currently documents a broader set, including artifact-metadata, attestations, code-quality, deployments, discussions, id-token, models, pages, security-events, and vulnerability-alerts in addition to the keys Open Actions accepts.
Open Actions rejects these names while parsing the workflow. A valid deployment, provenance, Pages, security, or model workflow therefore cannot be migrated even when the configured GitHub App has the required permission. OIDC token issuance itself remains tracked by #31.
Goal
Parse, narrow, mint, and expose job tokens for the complete permission vocabulary and precedence documented by GitHub Actions.
Acceptance criteria
- Accept every permission key and access level in the current GitHub Actions workflow syntax.
- Apply workflow, job, repository default, fork adjustment, and shorthand precedence according to GitHub behavior.
- Map each token permission to the corresponding GitHub App installation permission when one exists.
- Handle permissions backed by a runner service, such as
id-token, through their documented protocol and fail clearly until that service is configured.
- Reject unsupported access levels for permission-specific contracts rather than widening or silently ignoring them.
- Fail before execution with the resource name and missing App grant when the installation cannot provide the effective permission.
- Preserve least privilege through token creation and refresh.
- Add table-driven parser, precedence, fork, installation request, shorthand, and unsupported-grant tests for the complete documented set.
- Keep the Workflow API and installation-permission documentation synchronized with the accepted vocabulary.
References:
Context
Issue #30 implemented workflow and job permission narrowing for the permission keys used by Kelos. GitHub Actions currently documents a broader set, including
artifact-metadata,attestations,code-quality,deployments,discussions,id-token,models,pages,security-events, andvulnerability-alertsin addition to the keys Open Actions accepts.Open Actions rejects these names while parsing the workflow. A valid deployment, provenance, Pages, security, or model workflow therefore cannot be migrated even when the configured GitHub App has the required permission. OIDC token issuance itself remains tracked by #31.
Goal
Parse, narrow, mint, and expose job tokens for the complete permission vocabulary and precedence documented by GitHub Actions.
Acceptance criteria
id-token, through their documented protocol and fail clearly until that service is configured.References: