A1 Implementation And Qualification Status

Historical record. This report records the former A1 credential-broker implementation and its 2026 qualification evidence. Workflow Invoke later retired the broker, including both browser callback and backend enrollment routes. Current invocation sends the acting user’s bearer through Gateway to Workflow. Asynchronous workflow_start runs that can outlive that bearer may use a LONG registration exchanged through light-oauth; synchronous workflow_invoke does not register LONG. See Workflow Invoke. The historical commands, deployment steps, and acceptance plans below are not instructions for the current stack. The linked activation receipt retains its original observations, including the retired callback, as audit evidence.

Historical status: A1 source implementation complete; scope-consent reuse correction qualified in the short integration suite and deployed locally before broker retirement.

Historical acceptance amendment (2026-09-14)

The user requires only the existing Portal portal.r / portal.w scope consent. There must be no additional workflow-specific consent screen or second login. Workflow identity, policy binding, credential ceilings, expiry and revocation remain backend enforcement requirements; existing scope consent is not permission to skip issuer provenance validation.

The user waived scheduled and hours-long renewal qualification after the original user token expires. Record these tests as waived / not run, not passed; they are no longer A1 acceptance blockers. Historical requirements below describe the previous baseline and are superseded by this amendment.

The extra Portal enrollment prompt and generated Gateway workflow_authorize tool remained removed. At that time, root HTTPS Workflow invocation without a supplied grant acquired one internally through /workflow/credentials/enroll. Workflow used the issuer’s mTLS /oauth2/{provider}/workflow/enrollments/acquire endpoint, then redeemed the returned one-time PKCE code server-to-server. Only a grant UUID was returned to Gateway; no redirect, password or second consent was involved.

The issuer records SHA-256 access-token fingerprints in ordinary authorization-code and refresh issuance audits. Acquisition requires exact issuance evidence tied to an active authorization-code session, matching user/Host/client/provider and scope ceilings. Tokens issued before this change need a normal Portal refresh to obtain this evidence; unsigned claims, app tokens and unrecorded user tokens cannot bootstrap renewal. Acquired grants retain the source-session relationship; revocation, scope removal or missing provenance blocks renewal. Legacy browser grants require their original login evidence and remain only for compatibility.

Short real-HTTPS/mTLS integration passed: initial acquisition, acquisition after normal Portal refresh, direct broker renewal, scope-expansion rejection, wrong Host rejection, unrecorded-token rejection, missing-provenance rejection and source-session revocation. OAuth unit tests: 22 passed, 2 ignored. Workflow library: 86 passed. MCP module: 175 passed, 3 ignored. Scheduled/hours-long tests were waived, not passed. No live personal/native workflow was launched for this change.

At that checkpoint, the updated OAuth, Workflow and Gateway binaries were running locally with zero restarts; the unauthenticated enrollment probe returned 403. This was container-layer qualification, not a rebuilt release image, and would have been lost on container recreation. Rollback binaries were recorded under /tmp/phase1-backend-acquisition.4FBLYy/; their current presence is not assumed. Snapshot 01a0a222-a6dc-7288-9845-f709ead64d8e was current at the time. The editable instance property then contained an enrollment ACL assignment; its present state requires a separate check. Application databases were not wiped. A separate oauth_a1_qualification database held schema-only fixtures and test evidence.

The implementation follows the frozen A0 baseline. It does not admit personal orchestration Phase 1: production receiver enforcement and dispatch are A2/A3, and live deployment qualification remains separate.

Historical implementation

• Issuer: dedicated, reserved JwtClaims.token_use; live tenant-bound refresh authority; explicit custom-claim sources; PKCE and browser consent; dedicated certificate-authenticated broker listener; strict rotation, consumed-token history, grant lookup and revocation. Broker clients cannot use secret-only authentication through another provider binding. Specialized non-broker grants retain their supported behavior.
• Recovery: revocation tombstones serialize with enrollment and redemption, including when revocation arrives before the grant exists. Uncertain refreshes require reauthorization; the broker never retrieves a replacement through interactive retry grace.
• Workflow: encrypted credential storage, a store-to-issuer/client binding, durable enrollment and renewal ownership, run binding, key rotation, restart recovery, cancellation/revocation fencing, and retryable issuer revocation. At the time, enrollment APIs returned references and an authorization URL, never refresh credentials. The browser callback used a separate optional TLS listener with stored OAuth state and backend PKCE. Both enrollment routes and the callback listener have since been retired.
• Shared client/verifiers: fixed HTTPS endpoints, explicit CA trust, mTLS, bounded responses, signed-token validation and disabled redirects/retries; user/app purpose validation including duplicate-marker rejection and the explicit app-only legacy-key exception. Receiver-wide wiring remains A2.
• Deployment: the canonical Portal patch and fresh schema, regenerated bootstrap SQL for both distributions, a separate credential database/runtime principal, private mount preparation and ownership, registration/replay checks, certificate/key rotation procedures, opt-in Compose overlays, and a null-default Portal configuration catalog delta. The OAuth image build now includes the complete external Cargo path-dependency manifests needed by A1.

The former issuer schema came from portal-db/postgres/patch_20260913_01_workflow_broker.sql and was once reflected in canonical DDL and distribution bootstrap SQL. The later portal-db/postgres/migrations/patch_20260928_04_retire_workflow_broker.sql dropped the broker tables. The old patch and bootstrap state are historical evidence, not installation instructions; applying the old patch would recreate retired tables.

The former Workflow credential schema was light-fabric/apps/light-workflow/migrations/credential_broker.sql. Provisioning assets formerly lived in light-fabric/deployment/workflow-broker and the matching local and installer overlays. These source assets were retired; the paths here identify historical qualification inputs.

Historical qualification

Machine-readable results and local image IDs and working-tree source hashes identify the earlier qualified artifacts. The image IDs are local builds, not published registry receipts, and predate the availability fixes below. That historical issuer image was not a release qualification and is no longer a deployment target.

The HTTP tests use the real Workflow broker and local issuer together, with PostgreSQL and actual TLS handshakes. Faults are injected around transport delivery or database persistence, rather than replacing renewal with a mock success. These are isolated integration tests, not a claim that the live Portal frontend and deployed configuration have been qualified.

The historical issuer/Workflow integration gates used portal-service/apps/light-oauth/scripts/run-a1-gates.sh. That script was removed with the broker; the deferred two-hour soak was never recorded as passed.

The historical gate used the disposable oauth_a1_qualification database with a schema-only configserver fixture. Credentials were supplied privately. The script recorded base revisions and working-tree source hashes and rejected source drift during qualification. The A1 source was later committed and retired; the recorded base revision alone was not qualification evidence. Remote GitHub CI had not been run at the time.

Availability Review Follow-up

Both portal-service availability findings are fixed:

• The broker listener starts TLS handshakes and certificate extraction in separate tasks, capped at 128 pending handshakes with a five-second timeout per task. Silent peers do not serialize acceptance. A real mTLS regression keeps four earlier TCP connections idle while an authenticated request completes.
• Broker redemption and renewal use their existing transaction connection for session authority, live claims, custom-claim sources and signing-key reads. They never acquire another pool connection while holding rotation locks. Twelve concurrent redemptions, then twelve concurrent renewals, complete with a one-connection pool alongside ordinary issuance. Strict reuse detection is preserved.

The complete short gate suite passed again on a fresh isolated PostgreSQL database: 21 OAuth unit tests, explicit live-authority and workload-compatibility tests, and real HTTPS/mTLS broker integration including the new contention regression. Source hashes for this follow-up identify this tested revision. The earlier image receipts and partial soak describe older source; no images or soak were rebuilt/rerun for this follow-up. The deployed scheduled and hours-long runs remain pending, and the A1 exit gate has not passed. The subsequent Workflow/client review below refines pre-request error classification.

Workflow And Client Review Follow-up

All five light-fabric findings are addressed:

• Periodic recovery logs store failures and retries; it no longer terminates the managed task and closes unrelated Workflow admission. Startup configuration validation remains strict.
• Connection refusal, TLS establishment failure and pre-request JWKS failures return NotSent. The same live owner atomically records NOT_SENT and restores ACTIVE without changing the token or generation. Later caller attempts may retry. Post-send failures and lost ownership still fence the grant.
• Verification keys are cached for five minutes before rotation, with one refetch for an unknown key ID. A post-rotation verification failure remains uncertain; issuers must publish new keys before using them.
• Canceling one run preserves a valid committed shared-grant rotation and denies only that run’s token. A sibling run can renew; grant revocation and owner fencing still reject late responses.
• At that time, credentialBroker.legacyLongLivedAppKeys configured approved local issuer/key pairs for markerless app fixtures. It defaulted empty, applied only to X-Scope-Token, and cannot override explicit invalid purpose markers or authenticate a user. Former distribution preparation scripts carried the setting.

Short gates passed on a disposable PostgreSQL database with actual HTTPS/mTLS: 21 OAuth unit tests, explicit live-authority/workload tests, full broker integration, 80 Workflow library tests, 20 light-client tests, 17 security tests, two purpose contract tests, and two preparation tests. The integration exercises refused and failed-TLS connections without token POSTs, JWKS outage/rollover, post-rotation verification failure, recovery store failure, sibling-run cancellation, and the actual API legacy-key allowlist. Source hashes identify this follow-up. No soak or deployed-stack acceptance was run. Both previous image receipts predate these fixes and require rebuilding/requalification. At that stage, the credential-store SQL (the NOT_SENT result constraint) and issuer database patch were prerequisites for the then-current images. Both broker paths were retired later. No live database or service was changed in this follow-up.

Local Database Migration Applied

At this historical migration checkpoint, the local all-in-lt PostgreSQL instance had the issuer patch in configserver.configserver and the credential migration in the newly provisioned workflow_credentials.workflow_secret. All seven issuer tables, five credential tables, the NOT_SENT constraint, runtime password authentication and restricted role privileges were verified. Cascade validation passes after repairing three stale A2A schema references and adding four missing canonical gateway policies. Migration receipt records hashes and checks without secrets. The runtime URL is in the ignored mode-0600 file portal-config-loc/all-in-lt/postgres-db/secrets/workflow-broker-database-url. That file was an input to the retired broker preparation, not a current setup input.

This supersedes earlier statements that no live database was changed. No images were rebuilt and no application services were restarted. Broker registration, certificates, configuration activation and selected-stack qualification remain pending; the broker profile is not enabled by this migration alone.

Historical local broker activation

The user rebuilt the issuer and Workflow images. At the time, the local broker was enabled with a dedicated private client CA and a registered 180-day client certificate. The existing local issuer HTTPS certificate is used for its internal server and localhost callback. Private mounts remain ignored by Git, directories 0700 and files 0600, owned by the measured service UID/GID 999:999. No user grant was created.

The catalog and instance configuration were imported through event-importer using the registered ConfigInstanceCreatedEvent with commandkind: MUTATION for the instance property. Workflow snapshot 04c798da-c95b-499f-9167-a86bd248a145 is active. The broker JWKS URL uses light-oauth:6881 inside Docker; its authorization URL uses localhost:6881 for the browser. The local legacy app exception is restricted to the verified LC signing key. OAuth and Workflow were recreated and are healthy with zero restarts. Registered mTLS reaches grant lookup; no certificate fails TLS, wrong client and secret-only broker authentication return 401. JWKS returns 200. The callback returns 400 without state/code over verified HTTPS.

Activation receipt records image IDs, snapshot IDs and certificate fingerprint from that historical activation. At the time, deploy-local.sh lt included a broker overlay when the ignored workflow-broker/.runtime/enabled marker existed; the overlay was later removed. At the time, the host system trust store did not trust the local issuer CA; explicit CA-file verification passed. The browser consent path was later retired.

This activation supersedes the historical no-import/no-restart statements above. The live preflight returned nine unclassified names on four clients: Support Triage Local Demo, Tech Support LLM Workload Dev, mcp379-local-qualification and pylon. No claim-source classifications were changed. The broker has no custom claims, so these do not block its registration or activation.

Superseded selected-stack acceptance plan

The former selected-stack plan called for reviewing custom-claim sources, enrolling a user through Gateway and a browser authorization flow, and running scheduled and hours-long renewal qualification. Those steps were not completed as an A1 exit gate. Workflow Invoke subsequently retired that enrollment flow, so this plan is no longer a deployment or test procedure.

The A1 implementation described here was later committed and retired.