byot-e2e-validation

Validates AWID team-certificate authentication with real keys, signatures, and dockerized e2e tests.

82|9|Updated Feb 2, 2026
One-click install
npx skills add https://github.com/awebai/aweb --skill byot-e2e-validation-awebai
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: byot-e2e-validation
Source: https://github.com/awebai/aweb/tree/main/naapp/folio/skills/byot-e2e-validation
Command: npx skills add https://github.com/awebai/aweb --skill byot-e2e-validation-awebai

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? End-to-end tests for certificate-based authentication often mock certificates, signatures, or registry responses, which means they prove nothing about the real auth path. This Skill enforces a no-mock e2e discipline for apps relying on AWID team certificates, so replay, revocation, fail-closed, and team-scoping behavior are verified against real keys and a real awid-service. ## Core Features & Use Cases - Real-crypto harness: Provisions identities through the aw id CLI (create, team create, add-member, fetch-cert, switch) against a local awid-service started by Docker Compose with Postgres and Redis. - Mandatory negative suite: Hard assertions for missing envelopes (401), replayed requests across paths/methods/audiences, certificate revocation, registry outage fail-closed behavior, cross-team scoping, and raw-body contract violations. - Operational hardening: Teardown traps before compose up, fixture-level health waits, stale-state cleanup, and a single repeatable make e2e command that passes from a dirty Docker environment. - Use Case: You are shipping an agent-first app that gates document writes behind AWID team certificates. Use this Skill to build an e2e suite proving a revoked member loses access and a second team cannot read the first team's documents. ## Quick Start Set up an e2e test harness for my app that exercises AWID team-certificate auth with real keys via docker compose and the aw CLI, including replay and revocation negative tests.

Frequently Asked Questions about byot-e2e-validation

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write e2e tests for AWID team-certificate auth?

Provision real identities through the aw CLI (aw id create, team create, add-member, fetch-cert, switch) against a local awid-service started by Docker Compose, then send requests with aw id request --team-auth. Never mock certificates, signatures, or AWID responses in the e2e layer.

How do I test certificate revocation and fail-closed behavior?

Revoke the member certificate through AWID, wait for the app's auth cache to refresh, and assert the next request fails. For registry outages, stop awid-service and assert requests succeed while the cache is valid, then fail with 503 or 401 after expiry.

Why does aw id request --team-auth fail without a workspace binding?

The released CLI requires an active workspace, not just .aw/teams.yaml and .aw/team-certs/. The harness writes a minimal .aw/workspace.yaml containing the service URL, one membership, and workspace metadata after fetching the cert as a documented workaround.

Can I use xfail for expected auth failures in e2e tests?

No. Auth-critical negatives must be hard assertions, because an xfail on auth failure can hide a regression back to 422, 500, or a full bypass. Expected failures should be asserted explicitly in test output.

How do I make docker compose e2e tests repeatable?

Install the teardown trap before compose up, clear stale compose state first, prefer fixture-level health waits over docker compose --wait, and keep one documented command like make e2e that starts services, runs pytest, and tears everything down.