#ByteOr Enterprise Approval Credentials v1

This document records the intended approval credential contract used to satisfy enterprise side-effect gates in staging and production environments.

The current policy engine evaluates a boolean approval_token_present signal. The enterprise runtime layer is responsible for turning that signal on only after a supplied credential has been verified.

#Goals

• bind approval to a specific spec and environment,
• keep credentials time-limited,
• allow offline verification by the runtime or agent,
• preserve an audit trail for issuance and use.

#Credential format

Credentials use a two-part structure:

<payload_base64url>.<signature_base64url>

The payload is canonical JSON signed with Ed25519.

#Payload fields

Required payload fields:

• v: credential format version
• kid: signing key identifier
• org_id
• project_id
• environment_id
• environment_posture: dev, staging, or prod
• spec_hash: canonical sha256: digest of the approved spec
• capabilities: approved side-effect capabilities
• issued_at
• expires_at
• issued_by
• approval_id

#Verification rules

The verifier should reject a credential when any of the following checks fails:

1. the payload or signature cannot be decoded,
2. the signature does not verify against the trusted public key for kid,
3. the payload version is unsupported,
4. the credential spec_hash does not match the spec being executed,
5. the target environment does not match the current runtime posture,
6. the credential is expired,
7. the required action capabilities are not present.

Only after those checks pass should the runtime set the approval gate as satisfied for the policy engine.

#Key distribution

The runtime or agent should carry a trusted key set that can contain more than one active public key at once. That enables key rotation without invalidating still-live credentials.

Minimum key-set fields:

• kid
• algorithm
• public_key
• fetched_at

#Offline and online behavior

• Offline execution should continue to verify credentials locally against the cached key set.
• Online runtimes may also check revocation or fetch fresh keys, but expiry remains the hard safety boundary when the control plane is unavailable.
• Every verification attempt should be auditable, even when the final policy decision is denial.