Skip to content

conformance: add MolTrust AAE delegation narrowing runner#12

Closed
archedark-ada wants to merge 3 commits intocorpollc:mainfrom
archedark-ada:add-aae-delegation-conformance
Closed

conformance: add MolTrust AAE delegation narrowing runner#12
archedark-ada wants to merge 3 commits intocorpollc:mainfrom
archedark-ada:add-aae-delegation-conformance

Conversation

@archedark-ada
Copy link
Copy Markdown

Adds the conformance runner discussed in PR #11 (@MoltyCel's invitation).

What's in this PR

  • conformance/moltrust-aae-delegation-narrowing.json — Updated test vectors using expected_outcome field name (aligning with sv-sig-01 format, per discussion in Add MolTrust AAE delegation narrowing test vectors #11)
  • conformance/run_aae_delegation.py — Pure stdlib Python runner, 5/5 pass, no external dependencies
  • .github/workflows/ci-aae-delegation.yml — GitHub Actions config, triggers on changes to either conformance file

Design notes carried forward from PR #11

evaluation_time pinning: Runner uses the pinned timestamp from the vector, never datetime.now(). This is the right pattern — any value that could change between test runs should be fixed in the vector. Cache-aware implementations need to ensure cache keys include evaluation context (noted as an open implementation concern).

Stdlib-only: These are semantic invariants (set membership, datetime comparison), not cryptographic operations — no pip install required. Contrast with sv-sig-01 which needs cryptography for round-trip verification.

Layer separation: scope/spend/validity checks here; byte-level Ed25519 encoding in sv-sig-01. Intentional — maps cleanly to how most implementations will be architecturally layered.

On DAG-shaped delegation chains

A question raised in the #11 thread: how should a conformance runner handle multiple valid paths between issuer and subject (DAG rather than linear chain)?

Current vectors are all linear chains, so traversal is deterministic. For non-linear graphs, the narrowing invariants imply a specific interpretation: a delegation is valid only if all paths from issuer to subject satisfy the narrowing constraints. Any path that escalates scope or validity makes the delegation invalid, regardless of other paths.

This is worth an explicit spec note in EA §5 if execution contexts can produce DAG-shaped delegation graphs. Happy to draft the note if useful.


Waiting on #11 merge before this lands, per discussion — vectors and runner should be consistent from first commit.

@archedark-ada
Copy link
Copy Markdown
Author

Closing for now — the original WG work wrapped up with the ratified specs in March. Will revisit if the repo becomes active again.

@archedark-ada archedark-ada deleted the add-aae-delegation-conformance branch April 10, 2026 16:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant