feat(composition): add bounded AIC-to-AEB exact-action mappings

[FutureEnterprises]

What changes

This PR adds two bound AIC composition mappings for EP-AEB-CROSSING-RECORD-v1:

• compact AIC-JWT with RFC 7638 JKT
• AIC agent and principal certificate bundles with SHA-256 SPKI

It also adds issueAicBoundCrossingRecord, which maps the native result and issues the record as one operation. The helper compares the caller's exact action and all four admission-domain members with relying-party-owned context before any signature is produced.

Only the bound authority mappings are public. The earlier unbound authority constructors and profiles have been removed from both the main package and the adapter subpath.

The JWT-SVID projection remains workload identity only. It uses a private source verifier, refuses AIC_AUTHORITY, requires a new signature, and binds the accepted native evaluation into source_evaluation_digest.

Trust boundary

Native AIC verification remains authoritative. This adapter does not verify AIC signatures or certificate paths, interpret capabilities, or authorize execution.

The relying party owns the trust anchor, verifier descriptor, mapping profile, action-projection profile, requested-capability digest, exact action, and admission domain. The presented native result stays separate from that policy.

The JWT/JKT path requires the original compact token and an explicit public JWK. It derives and compares the carrier digest, typ, issuer, subject, JTI, audience, temporal claims, and RFC 7638 thumbprint.

The X.509/SPKI path requires distinct, parseable agent and principal certificate DER. It derives the bundle digest, agent serial, and principal SHA-256 SPKI hash. JWT/JKT and X.509/SPKI cannot substitute for one another.

The v0.2 profile fixes source-status freshness at 60 seconds. Callers cannot widen it. JWT exp is exclusive; X.509 notAfter remains inclusive.

Native FAILED and INDETERMINATE results refuse before carrier parsing. The issue helper snapshots the trusted context, draft, and signing configuration before inspecting hostile input, rejects accessor-bearing JSON graphs, and copies mutable key byte arrays.

Frozen v1 boundary

This PR preserves the existing EP-AEB-CROSSING-RECORD-v1 contract bytes and compatibility digest:

sha256:0d17ad047e432fd235d60ae06ab6f819691d90dc3b09ecf553b33d4d2c0472fc

The bound AIC authority commits the full admission domain, including relying_party_id, inside its authority, replay, and constraints digests. The AIC issue helper proves equality with the separately signed record boundary before signing.

The generic v1 issuer cannot recompute that opaque AIC relationship, so it is not the AIC issuance API. Issue #705 tracks a versioned EP-AEB-CROSSING-RECORD-v2 with an explicit, recomputable admission-domain commitment. v1 is not silently redefined.

Upstream scope

The conformance kit pins two archived IETF draft texts and nine exact upstream source files. Source-lock digest:

sha256:4db4c7e1db99663caecc82887cbf60c826725383b9e0e01f186a08fc105e0f4a

At the pinned gateway-core revision, VerifyBearer returns a synthesized X.509 object without raw certificate DER, raw SPKI, a public key, or an authenticated original-carrier tag. No non-test VerifyBearer call site was found in that revision. Those observations are limited to the pinned source.

The JWT path therefore requires the original compact token, and the synthesized object cannot enter the native X.509 mapping. A process-boundary deployment still needs an authenticated, carrier-tagged native-result wrapper proving that the same raw carrier and capability request were evaluated.

Exact-head evidence

Base: 7888d204a009aa415ccc0e9da2fe4820f8a8497c
Head: 4dffbf6c5e85243d12c010d02609b7200620b7df
Tree: 107a2f222a5bdfbfaefddf68d09cc9169030953a

• AIC source lock and composition: 28/28 tests; deterministic report 20/20.
• Mapping-profile digest: sha256:cda0f113627b79e7dcd79e9181f4cf3fd2d3136bdbb016cf4c19d1370bcffb98.
• Results digest: sha256:1eac98d86ccc496938ba9c7efd006b047d4bc3216ed7b651f3a8bd2630751ebf.
• Verify package: 1,105 passed and one skipped; portable handoff 32/32; qualification 62/62.
• Repository proof totals: 10,611 cases across 659 files.
• Formal evidence: 26 TLA+ invariants, 78 selected scenarios, and 51 paired negative controls.
• Security case: 35/35 executable claims over 259 evidence files; bundle sha256:03e23262bf2e778608daeaadb3c24b3a451d3d7a21d80498966b236e71aae9e7.
• Conformance corpus: 21 suites, 332 vectors, and 3 same-team ports; canonical manifest sha256:9fb14a40af62b7a94b629021dc316ea6087ba6c2873da23a43e07e71bf7a9200; file sha256:cb64bb6cf65672d0ee785e92765d7e4028db7e31ce5c94a2c71fb89865c4e8c4.
• Clean-room v2: 8/8 contract tests with both manifest pins independently enforced.
• External Rust hostility corpus: 359 cases; this remains same-project evidence, not independent implementation acceptance.
• Generated public context: proof snapshot 2026-09-01T14:52:23.203Z; input sha256:b532abe6876389a10aac43bd2c66faef2d58c5cc50a644aa7578772e68052845.
• Production build: 786 pages.
• All production TypeScript surfaces passed, including the secure app in its lockfile-local dependency context.
• Generated context, public claims, formal freshness, lifecycle, standalone runtime, packed export, repository boundary, package install, and dependency audit gates passed.

The positive fixtures stipulate native VERIFIED. The JWT uses a placeholder signature, and the certificates lack the AIC extensions required by the upstream verifier. These are EMILIA boundary vectors, not upstream acceptance, independent interoperability, production deployment, IETF adoption, certification, proof of possession, or endorsement.

Review gate

The AIC author approved source head 2201e6fc1e898b9b56693a091b48d4bbae04338b. The six commits after that approval are a bounded evidence repair only: conformance manifest regeneration, clean-room digest repinning, proof census refresh, generated public context, and the preprint traceability marker. They do not change AIC adapter or issuance semantics.

Branch protection correctly requires fresh approval after the last push. This PR remains draft until the AIC author confirms the exact final head above.

[strix-security]

Strix is installed on this repository, but we couldn't run this PR security review because this workspace's trial has ended. Add a card to resume code reviews here.

So far, Strix has reviewed 68 pull requests, surfaced 13 security issues (8 critical/high) and blocked 8 risky merges across this workspace.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
emilia-protocol	Ready	Preview	Sep 1, 2026 3:13pm UTC

[varwof-cn]

Posted from the wrong account. The AIC author's review is submitted from the varwof account.

[varwof]

Reviewed as author of draft-wei-aic-identity-cert and draft-wei-aic-jwt.

The AIC projection and status-input handling faithfully preserve AIC semantics within the agreed boundary:

• Native AIC verification remains authoritative; the adapter consumes its result and refuses FAILED/INDETERMINATE. It does not reimplement AIC signature, delegation, capability, constraint, or status validation.

• The bound path requires an exact match on caid and action_digest, and commits relying_party_id, audience, executor_id, and state_domain_id in both the mapping digest and the signed crossing contract digest, so records cannot
  be transplanted.

• Source status must be CURRENT with an explicit observation time and source-head digest; future, stale (over 60 s), revoked, unavailable, or outside the native validity window all refuse.

• The RFC 7638 jkt and X.509 SPKI paths remain separate native mappings and are never treated as interchangeable.

• The JWT-SVID projection is strictly workload-identity only: it refuses the AIC_AUTHORITY purpose, requires a single audience and a new signature, and explicitly records authority_semantics_preserved=false.

• I independently verified both pinned draft hashes in source-lock.json against the published IETF texts; they match.

Two non-blocking notes for the record:

1. The adapter permits max_status_age_seconds up to 86,400; the 60-second ceiling is enforced at the profile level and committed in the report. Deployments must keep the profile-level cap.
2. The X.509 SPKI path accepts sha-256/384/512; the native profile/verifier remains authoritative for the required hash algorithm.

The claim boundary is stated precisely and matches what we agreed. Approving.

Dismissed at the reviewer's request because this approval was submitted from the wrong account. The authoritative AIC-author review is the approval from varwof.

[FutureEnterprises]

@varwof The AIC adapter has been rebuilt at exact head 99f03226185a084c656a4322b30a13579e8e11ae on main 56ccfd0b8d728205d1c8273f954b6f3eee169032. The repair keeps native AIC verification authoritative, separates relying-party policy from the presented result, binds original carrier provenance, validity, status, capability, action, and admission domain, and records the inspected gateway helper limits. Please review this exact head as AIC author and confirm whether it faithfully preserves AIC semantics within the stated non-authorizing boundary. The previous approval is not being reused, and the PR remains draft pending your answer.

Dismissed because the final head preserves the frozen v1 digest, removes public unbound authority constructors, narrows SPKI to SHA-256, fixes the freshness limit, and adds pre-sign exact-bound issuance. The approval on 7bdcf45 does not review head 2201e6f.

[FutureEnterprises]

@varwof, I rebuilt this at exact head 2201e6fc1e898b9b56693a091b48d4bbae04338b on base 7888d204a009aa415ccc0e9da2fe4820f8a8497c. Your approval on 7bdcf452939e1dfae7705f7b971b696b07bba84d is dismissed because the final boundary is materially different.

The new head preserves the frozen generic v1 contract digest, exposes only bound authority mappings, requires the pre-sign AIC issue helper for exact action and admission-domain equality, fixes status age at 60 seconds, treats JWT exp as exclusive, narrows X.509 to SHA-256 SPKI, and binds the workload-only JWT-SVID projection to the accepted source evaluation.

Could you review this exact head and tell us whether it preserves AIC semantics across the JWT/JKT path, X.509/SPKI path, and workload-only JWT-SVID projection? Native AIC verification remains authoritative. The adapter compares a separately evaluated capability projection with one exact action; it does not interpret capabilities or authorize execution.

The fixtures stipulate VERIFIED and are not upstream interoperability tests. We will keep the PR draft until your review of this head.

[varwof]

Reviewed as author of draft-wei-aic-identity-cert and draft-wei-aic-jwt, at
exact head 99f0322 (base 56ccfd0
8205d1c8273f954b6f3eee169032). This supersedes my earlier approval, which
was tied to the replaced head 7bdcf45.

The v0.2 rebuild faithfully preserves AIC semantics within the stated
non-authorizing boundary:

1. Native verification remains authoritative. FAILED/INDETERMINATE are
   refused before any mapping; the adapter does not reimplement AIC-JWT
   signature, delegation, capability, constraint, or status validation, or
   X.509 path validation.

2. Relying-party policy is structurally separate from the presented
   result. Mapping profile, action-projection profile, native verifier
   descriptor, and issuer trust anchors are pinned by the RP policy; the
   presented result cannot self-pin any of them.

3. Raw carrier provenance is required on both paths. JKT requires the
   original compact token (typ=aic+jwt; iss/sub/jti/aud checked; the
   signed iat/nbf/exp envelope must equal the mapped validity exactly;
   RFC 7638 thumbprint derived from the presented principal JWK and
   matched against claimed and presented key hashes). X.509 requires
   exact agent and principal certificate DER with raw-byte equality and
   distinct leaves, with the principal SPKI SHA-256 computed from the
   principal certificate public key. The bare synthesized X.509 object
   returned by the inspected bearer helper is therefore inadmissible to
   the native X.509 mapping -- enforced in code, not just documented.

4. RFC 7638 JKT and X.509 SPKI remain separate native mappings; type
   confusion is refused by exact kind/hash_alg checks.

5. The BOUND-v2 request binding commits requested_capability_digest,
   caid, action_digest, and the admission-domain digest
   (relying_party_id, audience, executor_id, state_domain_id) into the
   bound-constraints digest, and relying_party_id is now part of the
   crossing-record contract digest. Records cannot be transplanted
   across relying parties, audiences, executors, or state domains.

6. Status handling is fail-closed: CURRENT with explicit checked_at and
   source_head_digest; future, stale, unavailable, revoked, or
   indeterminate observations refuse. The validity window must contain
   the evaluation time.

7. The JWT-SVID projection is workload-identity-only: single audience,
   SPIFFE subject, new typ=JWT TBS bytes under a fresh signature, with
   authority_semantics_preserved=false and authorization_decision=false.

Source-lock: I independently verified all pinned hashes against
upstream -- both draft texts and all nine varwof repository files
(aic-jwt@a3499b07, types@683520cd, gateway-core@718d42ec,
types@76f725ff/v0.4.0). All match.

Two non-blocking notes:

1. draft-wei-aic-identity-cert has since moved to -01 (the JWT draft is
   still -00); the update is the main change and adapter semantics are
   unaffected (the only normative delta in the bounded area is the
   RSA-PSS signature-algorithm sentence: SHA-256/384/512 MAY instead of
   SHA-256 only). The source lock pins -00, which is internally
   consistent with the text reviewed here, so this does not block the
   PR; updating the pin (and the bounded_sections labels) can be done
   in a follow-up.

2. The bounded_sections labels in source-lock.json do not match the
   actual section titles of the pinned texts (identity-cert-00 Sec.5 is
   "Validation Procedure", not "AI Agent Identity Certificate
   Extension"; jwt-00 Sec.5 is "Claims", not "AIC-JWT Token Format").
   Cosmetic, but worth correcting for future audits.

Previous note carried forward: keep the profile-level 60-second
status-age cap (mapping-profile maximum_age_seconds: 60); the
adapter-level bound of 86,400 is a sanity limit and the profile digest
commits the 60s rule. The v0.2 SPKI path is narrowed to sha-256 only,
which resolves the earlier hash-algorithm observation.

Approving.

[FutureEnterprises]

@varwof, thank you for reviewing source head 2201e6fc1e898b9b56693a091b48d4bbae04338b.

The only commits since that approval repair the evidence chain triggered by the AIC source files: regenerated conformance manifest, clean-room digest pins, proof census, generated public context, and preprint traceability. No AIC adapter or issuance code changed.

Final head: 4dffbf6c5e85243d12c010d02609b7200620b7df
Tree: 107a2f222a5bdfbfaefddf68d09cc9169030953a

The final local exact-head gates pass, including AIC 28/28 and 20/20, clean-room v2 8/8, manifest freshness, formal traces, security case, proof freshness, packages, repository boundary, and preprint guards. Would you re-approve this final head so branch protection records the evidence-only repair? The PR remains draft.

[varwof]

Re-approving at final head 4dffbf6
(tree 107a2f222a5bdfbfaefddf68d09cc9169030953a).

I verified the 6 commits since 2201e6f: all 12 changed files are
evidence-chain/context/preprint artifacts (conformance manifest and
clean-room bundle regeneration, proof census, public context, preprint
traceability). No AIC adapter, crossing-record, source-lock, or
issuance code changed.

I also checked the verify-script and clean-room test diffs: the pinned
manifest/claim SHA-256 values were updated to match the regenerated
manifest (source tree 335->339 files); the verification logic itself is
unchanged, so the repair does not weaken any check.

The substantive approval on 2201e6f stands; this re-approval records
the evidence-only repair at the exact final head. Approving.