Skip to content

epic: TEL/ACDC sans-io credentials — Tever/registry fold, ACDC validation, IPEX types (post-KERI-core) #98

Description

@joeldsouzax

Goal

TEL/ACDC as sans-io verdicts — the third verse of the pattern. keripy's credential stack is structurally the KEL stack again: Tever mirrors Kever (registry state fold), Tevery mirrors Kevery (same escrow shapes), Reger mirrors Baser (tables — NOT ours). Decision 2026-07-05: pure credential logic lives in keri-rs after the KERI-core milestone (K0–K9) completes; runtime lives in bombay-keri; issuance product flows stay in agency (#61#63 there).

Scope (child cards when work starts, mirroring K1–K9)

  • Registry state fold (Tever): vcp/vrt/iss/rev/bis/brv event validation + registry KeyState-equivalent
  • Escrow verdicts for TEL (reuse the K2 EscrowReason pattern; new reasons only where TEL differs)
  • ACDC: SAID-verified schema validation, edge/rule sections, chained-credential verification (pure, given issuer KELs via KelProvider)
  • IPEX message types (grant/admit/spurn/offer/agree) — typed events, encode/decode + verdicts only; exchange choreography is bombay-keri's
  • Semantic differential vectors vs keripy vdr/acdc (extends the K9 harness)

Boundary

Same rules as KERI-core: no db, no runtime, no config; registry storage arrives via the K6 trait family; wasm/no_std green. The wasm credential-verification story (verify a vLEI-chained ACDC in a browser) is a headline capability — keep it in scope.

Home decided in the 2026-07-05 credential-stack decision (agency board cleanup). Depends on: KERI-core milestone. Runtime counterpart: bombay-keri TEL epic. Absorbs the intent of former agency #37/#38/#39.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions