XCIM C01 local reference and conformance examples =============================================== Status: draft-saez-xcim-02 development artifacts. The normative candidate is CONTRACT.txt and its RFCXML rendition. These artifacts do not change or reinterpret the published -00/-01 or the P1/MAIL01 artifacts. Scope ----- An independently admitted third party signs the observation of explicit recipient consent to one identified sender entity, for exact type definitions. The verifier accepts an address, sender, type, time, authenticated local policy, and signed evidence. It accepts NO message, header, body, SMTP context, MSA, MP, DKIM result, presentation identifier or email replay key. Files ----- reference.py: strict JSON/JCS, closed schema definitions, real Ed25519 signature verification, entity and recipient binding, explicit type selection, terminal revocation history, current status, role policy, anchor adapter boundary, and an in-memory authenticated floor example. schemas/consent.schema.json: generated JSON Schema 2020-12 with closed $defs. Schema validation alone does not verify cryptography or all semantic rules. test_reference.py: deterministic fixtures and positive/adversarial cases. vectors/positive-consent-test-only.json: complete synthetic consent evidence. vectors/partial-revocation-test-only.json: one type withdrawn, other retained. vectors/verifier-policy-TEST-ONLY.json: public test keys and local admission. vectors/query.json: query independent of any email. vectors/cases.json: encoded evidence, local query, policy and expected results. test-report.json: executed results and explicit implementation limitations. coverage.json: contract clause to implementation/test and remaining work. Run from the XCIM workspace using installed dependencies: .venv-ietf\Scripts\python.exe docs\ietf\c01\test_reference.py No installs, network requests, nodes, paid API calls, deployment or publication occur. IDNA data must be Unicode 15.1.0; mismatched local tables fail closed. Meaning of positive fixtures ---------------------------- Ed25519 signatures are real. Test seeds are deterministic and public in the generator and MUST NOT be used by any real issuer. Issuer and provider observations, enrollment and explicit action evidence are synthetic observations signed by those test keys. They are not live OIDC proofs or a production enrollment service. The only supplied anchor adapter is an equality-checking TEST ONLY stub. It returns VERIFIED_TEST_ONLY, never VERIFIED. A positive fixture therefore has consent_checks_result=CONSENT_CURRENT but public outcome=INDETERMINATE and reason=ANCHOR_TEST_ONLY. Every result has can_assert_xcim_pass=false. No fixture establishes blockchain consensus, finality, a production XCIM result, independent interoperation, or uninterrupted ownership of an address. Real positive consent requires a separately implemented, pre-admitted and verified blockchain adapter. FloorStore demonstrates authenticated rollback/fork detection in memory. It compares shared history prefixes, latches conflicts, and retains terminal type removals. It also records the immutable title/description for each authenticated issuer/sender/epoch/type/version tuple. Changed definitions for the same tuple latch a conflict; local policy may also pin known definitions. It is NOT durable. Production crash recovery, disk persistence, multiple verifier coordination and authenticated administrative recovery remain unimplemented. The test runner preserves FloorStore only across specifically identified cases. Those cases must be replayed in report order; standalone vectors cannot encode the authenticated state established by previous queries. When malformed or invalid signed evidence is rejected it cannot create a floor. Authenticated terminal restrictions may be retained before their anchor is available. They do not restore consent when a status snapshot is stale. An active-only floor is staged until its anchor structure has been checked. What these tests do not implement -------------------------------- Actual third-party observation and immutable chain operation are mandatory protocol/deployment obligations but are NOT demonstrated by this local suite. Specifically: live OIDC authorization-code/PKCE/session transactions; provider address-authority assessment; sender entity enrollment; actor authentication and atomic withdrawal producer/idempotence; private evidence retention/access control; network retrieval or SSRF enforcement; chain consensus/finality; production key custody and policy distribution; durable state; independently developed peers. No count of passing local cases closes those deployment or interoperation gaps. Amoy is paused. Existing earlier mail-integration tests are not C01 conformance.