Stage 7: complete AWS OIDC federation deployment (deferred from PR #61)

[hanwencheng]

Context

PR #61 ships Stage 7 phase 2: OIDC issuer in the Rust broker, AWS-cred wiring through provisioner-scripts, and the operator-side bring-up (DNS + EIP + nginx + certbot + AWS OIDC provider registration). The federation infrastructure is in place; the end-to-end isolation proof is deferred to this issue.

What's done (in PR #61)

• Broker serves /.well-known/openid-configuration at https://broker.litentry.org with the correct iss claim.
• Broker serves JWKS at /.well-known/jwks.json with ES256 P-256 key + stable kid.
• Bearer-gated POST /v1/mint-oidc-jwt issues short-lived JWTs.
• AWS OIDC provider registered: arn:aws:iam::429071895007:oidc-provider/broker.litentry.org.
• Public nginx + Let's Encrypt cert auto-renewing.
• Operator runbook + cloud-setup docs for the registration recipe (cloud-setup.md §4).

What's deferred to this issue

The cloud-enforced PrincipalTag isolation property — "a JWT for wallet A can read s3://bucket/A/ but never s3://bucket/B/" — needs an end-to-end live test before we can call Stage 7 federation truly complete:

• Update agentkeys-data-role trust policy to the federated variant (replaces static IAM-user trust). Per cloud-setup.md §4.3.
• Update bucket policy to the PrincipalTag-scoped variant. Per cloud-setup.md §4.4.
• Acceptance test (cloud-setup.md §4.5):

  # Mint a JWT for wallet A, exchange for AWS temp creds, prove:
  aws s3api list-objects-v2 --bucket "$BUCKET" --prefix "$WALLET/"      # ← OK
  aws s3api list-objects-v2 --bucket "$BUCKET" --prefix "0xdeadbeef/"    # ← MUST AccessDenied

The first AccessDenied is the property Stage 6's static-IAM path can't prove. Until that test passes against real AWS, federation is wired but unproven.

Why deferred

Auth is the upstream blocker. Until the broker can reliably authenticate a session bearer to a specific wallet (currently any auth_token is accepted by the mock-server stub — see #63), running the federation acceptance test is meaningless: any caller could mint a session for any wallet, so PrincipalTag isolation isn't actually being tested.

Once auth lands (either Option A or Option C path), the federation acceptance test becomes a one-afternoon validation step.

Related

• PR feat(stage7): phase 2 — OIDC issuer in Rust broker + provisioner-scripts AWS-cred wiring #61 — Stage 7 phase 2 (this issue's prerequisite)
• Auth implementation issue: see Stage 7: implement broker-side user auth (Option A — port dexs-backend pattern + add CLIENT_ID_AGENTKEYS to Heima TEE) #63
• docs/cloud-setup.md §4 — the recipe to follow when this issue is picked up

🤖 Generated with Claude Code

[hanwencheng]

Closing as fixed.

PR #92 (issue #90 follow-up) ships harness/v2-stage3-demo.sh which proves the §4.5 acceptance test end-to-end on Heima Mainnet:

• POSITIVE: actor A writes to s3://$BUCKET/bots/<A>/credentials/* → OK
• NEGATIVE: actor A writes to s3://$BUCKET/bots/<B>/credentials/* → AccessDenied
• NEGATIVE: actor A lists s3://$BUCKET/bots/<B>/credentials/* → AccessDenied (s3:prefix condition on ListBucket — codex P2 fix split-statement v3)
• NEGATIVE: vault creds against memory bucket → AccessDenied (per-data-class IAM role separation, arch.md §17.2)
• NEGATIVE: memory creds against vault bucket → AccessDenied (symmetric)

The federated agentkeys-data-role trust policy + PrincipalTag-scoped bucket policy from cloud-setup.md §4.3/§4.4 are live and verified. The 4-layer isolation invariants are codified in CLAUDE.md "Per-actor + per-data-class isolation invariants".

Live verification any time:

AWS_PROFILE=agentkeys-admin bash harness/v2-stage3-demo.sh

Strict mode default — unmet prerequisites fail the demo (no silent skip). Final summary tracks actual per-step outcomes via STEP_OUTCOMES[].