JEP Conformance and Test Suite

3.1. Independent Checks

JEP-Core 0.7 does not define cumulative validation levels. A conforming validator reports independent checks.¶

Core-defined checks are:¶

• syntax¶

• cryptographic¶

• event_identity¶

• reference_integrity¶

• extension_processing¶

Trust- or acceptance-profile checks include:¶

• actor_binding¶

• freshness¶

• audience¶

Companion or external checks include:¶

• chain_integrity¶

• policy¶

A check status is one of:¶

• pass¶

• fail¶

• not_checked¶

• not_applicable¶

• unsupported¶

• indeterminate¶

An implementation MUST NOT report an unperformed check as pass.¶

3.2. Overall Status

For the requested validation mode and profile, the overall status is one of:¶

• valid¶

• invalid¶

• indeterminate¶

valid means that all required checks passed or were not applicable. invalid means that at least one required check failed. indeterminate means that no required check failed but at least one required check is unsupported or indeterminate.¶

3.3. Validation Modes

The initial validation modes are:¶

• archival¶

• acceptance¶

• chain¶

• policy¶

Archival validation is repeatable and MUST NOT consume acceptance state.¶

Acceptance validation includes JEP-Core Event Identity and idempotent acceptance semantics plus any profile-required actor-binding, freshness, audience, or challenge checks.¶

Chain and policy modes invoke companion or external semantics. A Core implementation MUST NOT present a chain or policy result as an intrinsic JEP-Core property.¶

4.1. JEP-Core-0.7 Producer

A producer conforms to JEP-Core-0.7 Producer if it supports:¶

• I-JSON-compatible event construction as defined by RFC 7493 [RFC7493];¶

• a stable id for each event instance;¶

• all required top-level Core members;¶

• J/D/T/V verb-specific Core requirements;¶

• JCS canonicalization of the unsigned event as defined by RFC 8785 [RFC8785];¶

• signature generation under at least one declared signature conformance class;¶

• algorithm-tagged digest strings;¶

• ext and ext_crit semantics.¶

A conforming producer MUST NOT reuse one Event Identity (who,id) for different unsigned event content.¶

4.2. JEP-Core-0.7 Verifier

A verifier conforms to JEP-Core-0.7 Verifier if it supports:¶

• duplicate JSON member rejection;¶

• Core field and verb-specific validation;¶

• Event Identity validation;¶

• JCS canonicalization as defined by RFC 8785 [RFC8785];¶

• signature verification under at least one declared signature conformance class, using RFC 7515 [RFC7515] where that class is JWS-based;¶

• Event Hash calculation;¶

• independent validation checks;¶

• structured validation-result objects;¶

• unknown critical-extension rejection;¶

• archival validation mode.¶

A Core verifier MUST NOT require an optional identity, credential, attestation, blockchain, AI-platform, agent-framework, challenge, transport, chain, or policy profile.¶

4.3. JEP-Core-0.7 Acceptance Processor

An implementation claiming JEP-Core-0.7 Acceptance Processor conformance MUST additionally support:¶

• a stable acceptance-domain definition;¶

• detection of conflicting Event Identity reuse;¶

• sufficient acceptance state for the claimed acceptance lifetime;¶

• atomic or equivalent first-acceptance processing;¶

• accepted, already_accepted, rejected, and indeterminate outcomes;¶

• separation of repeated valid delivery from invalid event content.¶

The same Event Identity MUST NOT apply the same acceptance effect more than once within one acceptance domain.¶

4.4. JEP-Extension-0.7 Processor

An extension processor conforms to JEP-Extension-0.7 Processor if it can:¶

• locate extension objects under ext;¶

• process identifiers named by ext_crit;¶

• fail extension_processing for unknown critical extensions;¶

• ignore unknown non-critical extensions where permitted;¶

• detect conflicting critical extensions;¶

• preserve JEP-Core member semantics.¶

4.5. JEP-Baseline-Ed25519-JWS-JCS-0.7

This document defines an interoperable baseline conformance class named JEP-Baseline-Ed25519-JWS-JCS-0.7.¶

It requires:¶

• I-JSON-compatible JSON as defined by RFC 7493 [RFC7493];¶

• RFC 8785 JCS canonicalization [RFC8785];¶

• detached JWS Compact Serialization as defined by RFC 7515 [RFC7515];¶

• the fully specified JOSE alg value Ed25519 defined by RFC 9864 [RFC9864];¶

• Ed25519 signature processing as defined by RFC 8032 [RFC8032];¶

• algorithm-tagged sha256 digest strings;¶

• Event Hash calculation over the full signed event object including sig.¶

For this baseline, the JWS Payload is exactly the JEP Signing Payload: the UTF-8 octets of the RFC 8785 JCS-canonicalized unsigned event.¶

The protected JOSE header MUST contain:¶

{
  "alg": "Ed25519"
}

A kid parameter MAY be present. If present, kid MUST be carried in the protected header. Additional protected parameters MAY be present when allowed by the active trust profile. A verifier MUST process every critical JOSE header parameter that it is required to understand under RFC 7515.¶

This baseline uses the ordinary base64url-encoded JWS Payload semantics of RFC 7515. Producers MUST NOT use b64:false for this conformance class.¶

The JWS Signing Input is exactly:¶

ASCII(
  BASE64URL(UTF8(JWS Protected Header))
  || "."
  || BASE64URL(JEP Signing Payload)
)

The top-level JEP sig member MUST contain the detached JWS Compact Serialization form:¶

BASE64URL(UTF8(JWS Protected Header))
|| ".."
|| BASE64URL(JWS Signature)

The middle payload segment is empty only in the transmitted detached serialization. During verification, the verifier reconstructs the signing input using the exact JEP Signing Payload. Base64url segments MUST use the RFC 7515 encoding rules, including omission of = padding and absence of whitespace.¶

The JWS Compact Serialization has no unprotected JOSE header. This baseline therefore does not permit security-relevant signature parameters to be carried outside the protected header.¶

Conformance vectors for this baseline MUST publish:¶

• the complete unsigned event;¶

• the exact JEP Signing Payload bytes, encoded in a transport-safe form;¶

• the protected-header JSON;¶

• the protected-header base64url segment;¶

• the detached sig string;¶

• the resulting full signed event;¶

• the Event Hash;¶

• the expected validation result.¶

A producer is not required to serialize semantically equivalent protected header JSON into identical bytes outside a vector that explicitly claims byte-for-byte reproduction. A verifier MUST verify the exact protected-header segment carried by the JWS.¶

This baseline is a conformance-class requirement, not a restriction on JEP-Core algorithm agility.¶

4.6. Profile-Specific Conformance

A profile MAY define additional conformance classes. Such classes MUST state:¶

• which validation checks are required;¶

• which checks are optional;¶

• which identifiers, credentials, or evidence are required;¶

• which algorithms are accepted or prohibited;¶

• whether freshness, audience, challenge-response, nonce, counter, sequence, ledger, or other replay-related mechanisms are required;¶

• how unsupported or indeterminate evidence is reported;¶

• any acceptance-domain requirements.¶

Profiles MUST NOT redefine JEP-Core Event Identity, Event Hash, J/D/T/V, signing-payload, or Core check semantics.¶

4.7. Historical Decoder Capability

Support for pre--07 JEP draft encodings is OPTIONAL and is not part of JEP-Core-0.7 conformance.¶

An implementation advertising a historical decoder MUST name that decoder explicitly. It MUST NOT select a historical decoder by first failing JEP-Core 0.7 validation and then inferring an older draft format solely from field presence.¶

Historical signed events MUST NOT be rewritten or silently upgraded.¶

5.1. Valid Archival Example

{
  "status": "valid",
  "mode": "archival",
  "profile": "jep-core-0.7",
  "conformance_class": "JEP-Core-0.7 Verifier",
  "event_identity": {
    "who": "did:example:agent-789",
    "id": "urn:uuid:018f4f8d-7c63-7c2e-9b43-4ef657eec1c0"
  },
  "event_hash": "sha256:...",
  "checks": {
    "syntax": "pass",
    "cryptographic": "pass",
    "actor_binding": "not_checked",
    "freshness": "not_checked",
    "audience": "not_checked",
    "event_identity": "pass",
    "reference_integrity": "not_applicable",
    "extension_processing": "pass",
    "chain_integrity": "not_checked",
    "policy": "not_checked"
  },
  "warnings": [],
  "errors": []
}

5.2. Safe Retry Example

{
  "status": "valid",
  "mode": "acceptance",
  "profile": "jep-core-0.7",
  "event_identity": {
    "who": "did:example:agent-789",
    "id": "urn:uuid:018f4f8d-7c63-7c2e-9b43-4ef657eec1c0"
  },
  "event_hash": "sha256:...",
  "checks": {
    "syntax": "pass",
    "cryptographic": "pass",
    "event_identity": "pass"
  },
  "acceptance": {
    "outcome": "already_accepted",
    "effect_applied": false
  },
  "warnings": [],
  "errors": []
}

5.3. Signature Failure Example

{
  "status": "invalid",
  "mode": "archival",
  "profile": "jep-core-0.7",
  "event_identity": {
    "who": "did:example:agent-789",
    "id": "urn:uuid:018f4f8d-7c63-7c2e-9b43-4ef657eec1c0"
  },
  "event_hash": null,
  "checks": {
    "syntax": "pass",
    "cryptographic": "fail",
    "event_identity": "not_checked",
    "reference_integrity": "not_checked",
    "extension_processing": "not_checked"
  },
  "warnings": [],
  "errors": [
    {
      "code": "ERR_SIGNATURE_INVALID",
      "check": "cryptographic",
      "message": "The signature does not verify over the JEP Signing Payload."
    }
  ]
}

5.4. Result Requirements

A conformance result object MUST distinguish:¶

• overall status;¶

• requested mode;¶

• active profile;¶

• Event Identity when available;¶

• Event Hash when calculated;¶

• independent checks;¶

• acceptance outcome when acceptance mode is requested;¶

• warnings;¶

• errors.¶

The event_identity member reports the (who,id) values asserted by the parsed event. Its presence in a result does not by itself establish signature validity, actor binding, authority, freshness, or non-conflicting historical use of that Event Identity.¶

The event_identity check reports only the JEP-Core Event Identity checks actually performed, including conflicting reuse detection when identity state is available. It MUST NOT be used as a substitute for cryptographic or actor_binding.¶

Similarly, an event_hash member reports the digest calculated for an exact signed artifact. Its presence does not establish actor binding, substantive truth, authorization, policy acceptance, or external effect.¶

An error object SHOULD contain a JEP failure code, the associated check when applicable, and an explanatory message.¶

A result MUST NOT contain a cumulative validation level.¶

5.5. Acceptance Outcome Consistency

When mode is acceptance, the result MUST contain an acceptance object once the acceptance processor has produced an outcome. The outcome and overall status MUST be consistent as follows:¶

accepted means all checks required by the active acceptance context passed or were not applicable and the acceptance effect is applied for the first time.¶

already_accepted means the event is valid for the active acceptance context but the same Event Identity has already applied that effect in the same acceptance domain.¶

rejected means at least one required validation check failed.¶

indeterminate means no required validation check failed, but the acceptance processor could not complete a required determination because required evidence, implementation support, durable state, or atomicity guarantees were unavailable.¶

effect_applied MUST be true only for accepted. A verifier MUST NOT report already_accepted as a cryptographic or syntax failure.¶

For non-acceptance modes, the acceptance member SHOULD be absent unless a companion result format explicitly carries a separately labeled acceptance observation.¶

6.1. Minimal Event Schema Seed

The following schema is a structural seed. It intentionally does not attempt to encode every JEP semantic rule.¶

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://jep.org/schemas/jep-event-0.7.schema.json",
  "title": "JEP-Core 0.7 Event",
  "type": "object",
  "required": ["jep", "id", "verb", "who", "when", "what", "sig"],
  "properties": {
    "jep": { "type": "string", "const": "1" },
    "id": {
      "type": "string",
      "minLength": 1,
      "description": "Non-empty ASCII Event ID; semantic validation is performed by the Core validator."
    },
    "verb": { "type": "string", "enum": ["J", "D", "T", "V"] },
    "who": { "type": "string", "minLength": 1 },
    "when": { "type": "integer" },
    "what": {},
    "aud": {},
    "ref": {
      "oneOf": [
        { "type": "string" },
        { "type": "object" }
      ]
    },
    "ext": { "type": "object" },
    "ext_crit": {
      "type": "array",
      "items": { "type": "string" },
      "uniqueItems": true
    },
    "sig": {
      "oneOf": [
        { "type": "string" },
        { "type": "object" }
      ]
    }
  },
  "allOf": [
    {
      "if": { "properties": { "verb": { "const": "D" } } },
      "then": {
        "properties": {
          "what": {
            "type": "object",
            "required": ["delegatee", "scope"]
          }
        }
      }
    },
    {
      "if": { "properties": { "verb": { "const": "T" } } },
      "then": {
        "required": ["ref"],
        "properties": {
          "what": {
            "type": "object",
            "required": ["termination_scope"]
          }
        }
      }
    },
    {
      "if": { "properties": { "verb": { "const": "V" } } },
      "then": {
        "required": ["ref"],
        "properties": {
          "what": {
            "type": "object",
            "required": ["verification_scope", "result"]
          }
        }
      }
    }
  ]
}

The schema does not make nonce a Core field. A nonce or equivalent mechanism MAY appear inside a registered extension or profile-defined object.¶

6.2. Typed JEP Event Reference Seed

A logical JEP event reference SHOULD use Event Identity:¶

{
  "type": "jep:event",
  "value": {
    "who": "did:example:actor-123",
    "id": "urn:uuid:018f4f8d-7c63-7c2e-9b43-4ef657eec1c0"
  }
}

An exact signed artifact MAY additionally be pinned:¶

{
  "type": "jep:event",
  "value": {
    "who": "did:example:actor-123",
    "id": "urn:uuid:018f4f8d-7c63-7c2e-9b43-4ef657eec1c0"
  },
  "hash": "sha256:..."
}

The value identifies the logical event. The optional hash identifies an exact signed artifact.¶

8.1. Valid Core Event Vectors

The suite SHOULD include:¶

• valid/J-basic.json¶

• valid/D-basic.json¶

• valid/T-basic.json¶

• valid/V-basic.json¶

• valid/event-reference-logical.json¶

• valid/event-reference-exact-artifact.json¶

8.2. Syntax and Core-Field Vectors

The suite SHOULD include:¶

• invalid/invalid-json.json¶

• invalid/duplicate-member.json¶

• invalid/missing-id.json¶

• invalid/invalid-id.json¶

• invalid/missing-what.json¶

• invalid/unknown-verb.json¶

• invalid/invalid-timestamp.json¶

• invalid/D-missing-delegatee.json¶

• invalid/D-missing-scope.json¶

• invalid/T-missing-ref.json¶

• invalid/T-missing-termination-scope.json¶

• invalid/V-missing-ref.json¶

• invalid/V-missing-verification-scope.json¶

• invalid/V-missing-result.json¶

8.3. Cryptographic Vectors

The suite SHOULD include:¶

• invalid/invalid-signature.json¶

• invalid/signature-over-wrong-payload.json¶

• invalid/unsupported-signature-alg.json¶

• invalid/prohibited-signature-alg.json¶

• invalid/alg-key-type-mismatch.json¶

• invalid/alg-profile-mismatch.json¶

• invalid/canonicalization-failed.json¶

• invalid/canonicalization-version-unsupported.json¶

8.4. Event Identity and Delivery Vectors

Event Identity behavior is stateful. A single isolated JSON event cannot by itself demonstrate conflicting reuse or prior acceptance.¶

The suite SHOULD therefore include stateful sequence manifests such as:¶

• stateful/event-identity-retransmission.json¶

• stateful/event-identity-resign-same-content.json¶

• stateful/event-id-conflict.json¶

• stateful/same-id-different-who.json¶

A stateful manifest SHOULD declare the identity or acceptance state visible to the harness, the ordered steps, and the expected result for each step.¶

Example:¶

{
  "name": "event-id-conflict",
  "mode": "acceptance",
  "profile": "jep-core-0.7",
  "acceptance_domain": "example-domain-a",
  "initial_state": "empty",
  "steps": [
    {
      "input": "stateful/fixtures/J-first.json",
      "expected_status": "valid",
      "expected_checks": {
        "event_identity": "pass"
      },
      "expected_acceptance": {
        "outcome": "accepted",
        "effect_applied": true
      }
    },
    {
      "input": "stateful/fixtures/J-conflicting-reuse.json",
      "expected_status": "invalid",
      "expected_checks": {
        "event_identity": "fail"
      },
      "expected_error_codes": ["ERR_EVENT_ID_CONFLICT"],
      "expected_acceptance": {
        "outcome": "rejected",
        "effect_applied": false
      }
    }
  ]
}

The second event in the example uses the same (who,id) but different JCS-canonicalized unsigned event content.¶

The suite SHOULD also verify:¶

• retransmission of byte-identical signed content;¶

• re-signing of identical unsigned content with the same Event Identity;¶

• use of the same id string under a different who;¶

• conflicting reuse of one Event Identity with different unsigned content.¶

Conflicting reuse MUST produce ERR_EVENT_ID_CONFLICT.¶

A valid repeated event MUST NOT be reported as a cryptographic failure.¶

8.5. Acceptance Vectors

Acceptance behavior is also stateful. The suite SHOULD include:¶

• stateful/accept-first.json¶

• stateful/accept-safe-retry.json¶

• stateful/accept-state-unavailable.json¶

• stateful/accept-atomicity-unavailable.json¶

• a concurrent first-delivery test¶

A safe-retry sequence SHOULD demonstrate that the first valid delivery yields accepted with effect_applied: true and a later valid delivery of the same Event Identity in the same acceptance domain yields already_accepted with effect_applied: false.¶

If required acceptance state is unavailable, the result MUST NOT claim a fresh accepted outcome. It MUST be indeterminate or rejected when an active profile explicitly requires fail-closed rejection.¶

If required atomicity cannot be provided, the implementation MUST NOT claim accepted. When represented as a JEP failure code, the suite SHOULD exercise ERR_ACCEPTANCE_ATOMICITY_UNAVAILABLE.¶

The concurrent first-delivery test SHOULD submit multiple equivalent deliveries of the same Event Identity against one acceptance domain and assert that exactly one state-changing acceptance effect is applied. All other valid deliveries MUST be reported without a second effect, normally as already_accepted.¶

Nonce, challenge, sequence-number, counter, ledger, or similar replay tests belong to the profile that requires that mechanism and MUST NOT be presented as universal JEP-Core requirements.¶

8.6. Reference Vectors

The suite SHOULD include:¶

• logical Event Identity resolution;¶

• exact-artifact hash success;¶

• exact-artifact hash mismatch;¶

• Event Identity mismatch;¶

• unresolved references when a requested check requires resolution.¶

8.7. Extension Vectors

The suite SHOULD include:¶

• known critical extension success;¶

• unknown critical extension failure;¶

• unknown non-critical extension tolerance;¶

• extension schema failure;¶

• conflicting critical extensions.¶

8.8. Canonicalization and Hash Vectors

The suite SHOULD include:¶

• equivalent JSON inputs producing identical JCS bytes;¶

• UTF-16 property-order edge cases required by JCS;¶

• numeric serialization edge cases allowed by I-JSON/JCS;¶

• full signed Event Hash calculation;¶

• unsigned JEP Signing Payload calculation;¶

• proof that changing sig can change Event Hash without changing Event Identity.¶

8.9. Companion and External Check Vectors

Chain and policy fixtures MAY be included for integration testing, but they MUST identify the companion profile or external evaluator that owns the semantics. They MUST NOT be labeled as Core-only conformance failures.¶

8.10. Historical Compatibility Vectors

If a product advertises a historical pre--07 decoder, the suite SHOULD include:¶

• explicit historical decoder selection;¶

• historical signature verification without rewriting bytes;¶

• refusal to silently fall back from 0.7 based solely on field presence.¶

9.1. J-basic

{
  "jep": "1",
  "id": "urn:uuid:018f4f8d-7c63-7c2e-9b43-4ef657eec1c0",
  "verb": "J",
  "who": "did:example:agent-789",
  "when": 1742345678,
  "what": {
    "claim": "approve-result"
  },
  "sig": "PLACEHOLDER_DETACHED_JWS"
}

9.2. D-basic

{
  "jep": "1",
  "id": "urn:uuid:018f4f8d-8ad2-7baf-b752-e529e79bc88a",
  "verb": "D",
  "who": "did:example:human-123",
  "when": 1742345681,
  "what": {
    "delegatee": "did:example:agent-789",
    "scope": "summarize-document",
    "constraints": ["no-external-send"]
  },
  "sig": "PLACEHOLDER_DETACHED_JWS"
}

9.3. T-basic

{
  "jep": "1",
  "id": "urn:uuid:018f4f8d-91c1-7d50-8f7a-c7b0fd8d95d0",
  "verb": "T",
  "who": "did:example:human-123",
  "when": 1742345690,
  "what": {
    "termination_scope": "delegation"
  },
  "ref": {
    "type": "jep:event",
    "value": {
      "who": "did:example:human-123",
      "id": "urn:uuid:018f4f8d-8ad2-7baf-b752-e529e79bc88a"
    }
  },
  "sig": "PLACEHOLDER_DETACHED_JWS"
}

9.4. V-basic

{
  "jep": "1",
  "id": "urn:uuid:018f4f8d-a1d5-7633-9b6c-63d4928819e2",
  "verb": "V",
  "who": "did:example:verifier-123",
  "when": 1742345700,
  "what": {
    "verification_scope": "cryptographic",
    "result": "pass"
  },
  "ref": {
    "type": "jep:event",
    "value": {
      "who": "did:example:agent-789",
      "id": "urn:uuid:018f4f8d-7c63-7c2e-9b43-4ef657eec1c0"
    },
    "hash": "sha256:..."
  },
  "sig": "PLACEHOLDER_DETACHED_JWS"
}