[SCITT] EP-SCITT profile demo (running code) — which SCRAPI implementation is the current interop target?

[Iman Schrock <[e-mail]>]

Hi all,

I've built a small EP-SCITT profile demo and would value the list's steer
on one concrete question.

An EMILIA authorization receipt (a portable, offline-verifiable proof that
a named, accountable human authorized one specific irreversible action) is
carried as a COSE_Sign1 Signed Statement, registered through SCRAPI, and
then verified as two separate checks:

- EMILIA authorization check: Ed25519 over the canonical EP receipt
payload, offline, no service needed.
- SCITT transparency check: the returned inclusion/transparency receipt
verified against the service's parameters.

The in-repo harness already proves the EP/COSE profile and a reproducible
register -> receipt -> verify-inclusion path in CI against a
clearly-labeled mock transparency service. I deliberately do *not* claim
official SCITT conformance against our own mock — the mock exists only so
the demo runs green in CI; the credible interop claim needs a real external
target.

So the question: which public SCRAPI-compatible implementation should I
point this profile demo at today? I found
scitt-community/scitt-api-emulator, but it appears archived (last commit
late 2024), so I don't want to overstate its current status. If the WG has
a preferred emulator, test service, or reference implementation, I'd rather
point the EP demo there and document the verifier behavior precisely.

Running code, for anyone who wants to look:

- End-to-end harness (register -> receipt -> inclusion verify):
https://github.com/emiliaprotocol/emilia-protocol/blob/main/examples/scitt/ep-receipt-scitt-end-to-end.mjs
- The profile (COSE_Sign1 field mapping, SCRAPI registration, multi-hop
lineage):
https://github.com/emiliaprotocol/emilia-protocol/blob/main/docs/EP-RECEIPT-SCITT-PROFILE.md
- The EP receipt I-D (individual, Apache-2.0),
draft-schrock-ep-authorization-receipts (current -04):
https://datatracker.ietf.org/doc/draft-schrock-ep-authorization-receipts/

The boundary I'm trying to keep crisp: SCITT logs (proves a statement was
recorded); EMILIA authorizes (proves who approved the action). Two
artifacts, "transparency/inclusion receipt" vs "authorization receipt" —
they compose, neither replaces the other. I'd genuinely welcome being told
where this maps badly onto the architecture / SCRAPI / COSE Receipts work.

Thanks,
Iman Schrock
EMILIA Protocol
[e-mail]