JEP Profiles and Interoperability

4.1. Profile Categories

A profile MAY belong to one or more of the following categories:¶

• trust profile: actor identifiers, key resolution, actor/key binding, algorithm policy, revocation, and historical validity;¶

• acceptance profile: audience, freshness, challenge-response, replay-related mechanisms, acceptance-domain rules, or single-use authority;¶

• credential or attestation profile: credentials, presentations, certificates, remote-attestation evidence, or equivalent evidence;¶

• archival profile: receipt, archive, retention, custody, redaction, selective disclosure, or long-term verification context;¶

• chain profile: dependency, delegation, termination, causality, responsibility, or graph interpretation;¶

• policy profile: domain, organizational, legal, regulatory, or deployment-specific evaluation.¶

A profile category does not grant authority. It identifies which semantics the profile owns.¶

4.2. Explicit Profile Selection

The active profile set MUST be explicit to the verifier.¶

A profile MAY be selected by:¶

• verifier configuration;¶

• an API validation request;¶

• a transport or application binding;¶

• archive metadata;¶

• a registered signed extension when the profile requires signed profile intent.¶

A verifier MUST NOT silently infer a trust or acceptance profile solely from:¶

• the syntax of who;¶

• the presence of a DID, certificate, credential, token, or attestation reference;¶

• the presence or absence of aud;¶

• the presence of a nonce-like extension;¶

• a failed attempt to validate under another profile.¶

For example, a DID-shaped who value does not by itself select the DID/VC profile.¶

A deployment MAY define a deterministic mapping from an input context or identifier form to a profile, provided that the mapping is explicitly configured or published before validation and is reported as part of the validation context. Such a mapping is explicit profile selection, not silent inference.¶

A verifier MUST NOT choose a different profile merely because validation under the initially selected profile failed.¶

If a profile requires the producer's profile choice to be cryptographically bound to the event, the profile MUST define a signed extension carrying that choice.¶

The validation result SHOULD identify the active profile.¶

A verifier MAY apply multiple profiles internally. For an interoperable conformance claim, an otherwise ad hoc combination SHOULD be represented by a named composed profile with its own identifier. If no composed identifier exists, the implementation SHOULD report the component profiles in profile-specific result metadata and MUST NOT imply that one constituent profile represents the entire combination.¶

4.3. Profile Versioning

A profile identifier MUST identify one defined semantic version of the profile.¶

A materially different profile semantic contract SHOULD use a new profile identifier or version. Implementations MUST NOT silently reinterpret an older profile identifier using newer incompatible rules.¶

The :0 identifiers defined by draft-wang-jep-profiles-00 are historical JEP-Core 0.6 profile seeds. This revision defines :1 identifiers for the JEP-Core 0.7-aligned profile families below.¶

The :1 identifiers in this Experimental Internet-Draft are provisional identifiers. They are not IANA-registered identifiers.¶

4.4. Profile Composition

Multiple profiles MAY be active for one validation request.¶

Unless a composed profile explicitly specifies another rule:¶

• required checks are the union of the checks required by all active profiles;¶

• algorithm acceptability is the intersection of the policies imposed by active profiles that define an algorithm policy;¶

• all active audience requirements MUST be satisfied;¶

• all active freshness and challenge requirements MUST be satisfied;¶

• all required actor-binding requirements MUST be satisfied;¶

• all required critical extensions MUST be processed.¶

One profile MUST NOT weaken a JEP-Core requirement or a stricter requirement of another active profile unless the composed profile is explicitly defined as a new profile with its own identifier and security analysis.¶

If active profiles impose irreconcilable requirements, the verifier MUST NOT report successful validation. It SHOULD report an indeterminate overall status and a profile-specific conflict error unless an independently required check has deterministically failed.¶

Profile composition MUST NOT silently change the semantics of historical events.¶

4.5. Profile-Specific Checks

Profiles MAY define validation checks beyond the JEP-Core check identifiers.¶

A profile-specific check identifier SHOULD be collision-resistant, for example:¶

jep-profile:did-vc:1#credential_status
jep-profile:rats:1#attestation
jep-profile:blockchain-anchor:1#anchoring

A profile-specific check MUST NOT reuse the name of a JEP-Core check with a different meaning.¶

A verifier MUST NOT report an unperformed profile-specific check as pass.¶

6.1. Core Boundary

JEP-Core does not mandate a nonce, challenge, sequence number, counter, ledger, or transport mechanism.¶

JEP-Core requires idempotent acceptance: the same Event Identity MUST NOT apply the same acceptance effect more than once within one acceptance domain.¶

An acceptance profile MAY add stronger properties, including:¶

• current liveness;¶

• server-issued challenge freshness;¶

• request ordering;¶

• bounded freshness windows;¶

• single-use authority;¶

• transaction uniqueness;¶

• monotonic ordering;¶

• ledger-backed consumption.¶

6.2. Profile-Defined Mechanisms

An acceptance profile MAY require:¶

• receiver-issued nonce;¶

• sender-generated nonce;¶

• challenge-response;¶

• sequence number;¶

• transaction identifier;¶

• trusted timestamp;¶

• audience-bound token;¶

• monotonic counter;¶

• ledger position;¶

• previous-event commitment.¶

Such a mechanism SHOULD be carried in a registered JEP extension, a transport binding, or a profile-defined external object rather than added as a new JEP-Core top-level member.¶

6.3. when and Freshness

The JEP when member is actor-declared event time. A profile MAY evaluate a freshness window using when, but MUST NOT present when alone as trusted wall-clock evidence.¶

If trusted time is required, the profile MUST define the external timestamp, receipt, archive, transparency, challenge, or other evidence that establishes the required property.¶

6.4. Audience

A profile MAY require aud.¶

When aud is required, the profile MUST define:¶

• acceptable audience syntax;¶

• matching rules;¶

• whether multiple audiences are supported;¶

• whether audience is part of replay isolation;¶

• failure behavior for absent or mismatched audience.¶

The presence of aud does not by itself enforce access control.¶

6.5. Acceptance Result

Profile-specific freshness, audience, challenge, or authorization checks are additional requirements for the requested acceptance context.¶

They do not replace the Core distinction among:¶

• accepted;¶

• already_accepted;¶

• rejected;¶

• indeterminate.¶

A valid retry of an already accepted Event Identity MUST NOT be transformed into a cryptographic failure merely because the profile also uses a nonce or challenge mechanism.¶

A profile that consumes a nonce, challenge, reservation, or similar single-use value SHOULD define how the consumed value is associated with Event Identity. After an Event Identity has been accepted, repeat delivery of the same signed event SHOULD be recognizable as already_accepted rather than treated as a new authority-consumption attempt. Reuse of the same profile-specific value with a different Event Identity MAY fail the relevant profile check.¶

A profile that defines single-use authority MUST distinguish consumption of that authority from Core idempotent acceptance of an event.¶

7.1. Identifier

jep-profile:did-vc:1

7.2. Scope

This optional profile family defines how JEP deployments may use Decentralized Identifiers [DID-CORE] and Verifiable Credentials [VC-DATA-MODEL] as identity or credential evidence.¶

DID and VC support remains optional for JEP-Core.¶

A concrete profile instance MUST identify the DID methods, credential formats, proof formats, status mechanisms, and trust rules it supports. The family identifier alone is not sufficient to make every DID method or credential format interoperable.¶

7.3. DID Actor Binding

When a DID is used as who, the concrete profile MUST define:¶

• supported DID methods;¶

• DID document resolution;¶

• verification-method selection;¶

• controller or equivalent binding rules;¶

• historical key validation;¶

• caching and freshness of DID resolution;¶

• deactivation or revocation handling;¶

• failure behavior.¶

actor_binding MAY be reported pass only when the active profile has bound the verified signing key to the claimed who.¶

7.4. Credential Use

A JEP event MAY reference credential evidence by digest, URI, presentation reference, archival reference, or another profile-defined reference.¶

Credential evidence MAY support claims about role, affiliation, qualification, authorization scope, certification, or other attributes.¶

Credential validity is separate from JEP-Core event validity. A valid credential does not make the substantive JEP claim true, and a valid JEP event does not make a credential claim true.¶

A concrete DID/VC profile SHOULD expose credential evaluation using a profile-specific check such as:¶

jep-profile:did-vc:1#credential_status

If a credential is required only for policy rather than actor/key binding, its result MUST NOT be reported as actor_binding.¶

7.5. Privacy

DID resolution and credential presentation can create correlation and disclosure risks. Profiles SHOULD minimize identifiers and claims, avoid unnecessary credential embedding, and define selective-disclosure or access-controlled evidence mechanisms where appropriate.¶

8.1. Identifier

jep-profile:x509:1

8.2. Scope

This optional profile family defines how X.509 certificates and Internet PKI concepts [RFC5280] may be used to bind a claimed JEP actor to a signing key.¶

A concrete profile MUST define:¶

• certification-path validation rules;¶

• trust anchors;¶

• name-to-actor mapping;¶

• key-usage and extended-key-usage requirements;¶

• certificate-status or revocation processing;¶

• certificate validity for real-time and archival validation;¶

• algorithm policy;¶

• historical validation behavior.¶

A certificate path that validates cryptographically does not by itself establish actor_binding: pass. The profile's name-to-actor mapping MUST also succeed.¶

Domain, regulatory, organizational, or legal conclusions remain policy results rather than intrinsic properties of X.509 or JEP-Core.¶

9.1. Identifier

jep-profile:oauth-oidc:1

9.2. Scope

This optional profile family defines how OAuth 2.0 [RFC6749] or OpenID Connect [OIDC-CORE] context may be referenced when validating a JEP event.¶

Such evidence MAY describe:¶

• authorization context;¶

• client identity;¶

• resource server;¶

• subject;¶

• consent or grant context;¶

• token audience;¶

• token-binding or proof-of-possession evidence.¶

A concrete profile MUST define the token or assertion format, issuer trust, audience rules, lifetime rules, status or revocation behavior where applicable, and binding between the authorization artifact and the JEP event.¶

An OAuth or OpenID Connect artifact does not by itself prove that an external action was authorized, lawful, completed, or policy-compliant.¶

Unless the profile explicitly uses the artifact to bind the JEP signing key to who, authorization-context validation MUST NOT be reported as actor_binding.¶

A profile MAY define a profile-specific check such as:¶

jep-profile:oauth-oidc:1#authorization_context

10.1. Identifier

jep-profile:rats:1

10.2. Scope

This optional profile family defines how remote-attestation evidence, including evidence modeled using the RATS architecture [RFC9334], may be used in JEP validation.¶

Attestation evidence MAY support claims about:¶

• runtime environment;¶

• device identity;¶

• secure enclave or trusted execution context;¶

• software measurement;¶

• model execution environment;¶

• tool invocation environment.¶

A concrete profile MUST define evidence format, appraisal policy, verifier trust, freshness, reference values, endorsement handling, and binding between the attested environment and the relevant JEP actor, signer, or event.¶

The profile SHOULD report attestation evaluation through a profile-specific check such as:¶

jep-profile:rats:1#attestation

Attestation does not establish the substantive correctness of a judgment.¶

11.1. Identifier

jep-profile:local-iam:1

11.2. Scope

This optional profile family defines how an enterprise or local identity and access-management system may bind local actor identifiers to signing keys.¶

A concrete profile MUST define:¶

• actor namespace;¶

• key registry or key-discovery mechanism;¶

• actor/key binding;¶

• role and group interpretation where used;¶

• revocation;¶

• historical validation;¶

• algorithm policy;¶

• audit export behavior;¶

• acceptance-domain boundaries where applicable.¶

Local authorization or role membership is not automatically a portable or global authorization conclusion.¶

12.1. Identifier

jep-profile:hjs-archive:1

12.2. Scope

This optional profile family defines how HJS-like systems may receive, store, archive, redact, selectively disclose, and preserve JEP events and evidence.¶

An archival profile MAY define:¶

• receipt records;¶

• receipt time;¶

• archive time;¶

• evidence custody;¶

• retention policy;¶

• redaction policy;¶

• selective disclosure;¶

• long-term verification context.¶

HJS-like systems MUST NOT redefine JEP-Core Event Identity, Event Hash, signature semantics, J/D/T/V semantics, or validation-check meanings.¶

12.3. Event Identity and Artifact Binding

An archive receipt that identifies the logical event SHOULD record Event Identity.¶

An archive receipt that asserts custody or preservation of an exact signed artifact SHOULD additionally bind the Event Hash.¶

Thus:¶

Event Identity -> which JEP event
Event Hash     -> which exact signed artifact was archived

An archive MUST NOT silently replace one with the other.¶

12.4. Time and Evidence Boundary

Receipt time and archive time are distinct from JEP when.¶

An archival profile MAY provide stronger external time evidence, but that evidence MUST be described according to the mechanism actually used.¶

Receipt presence alone does not establish substantive truth, legal effect, complete logging, or actor authority.¶

A profile MAY expose archival evaluation through a profile-specific check such as:¶

jep-profile:hjs-archive:1#archival_integrity

13.1. Identifier

jep-profile:jac-chain:1

13.2. Scope

This optional profile family defines how JAC-like systems may compose JEP events into dependency, delegation, termination, verification, causality, responsibility, or workflow graphs.¶

JEP-Core defines atomic signed statements. Chain interpretation belongs to the chain profile.¶

A JAC-like profile MUST NOT redefine:¶

• JEP Event Identity;¶

• JEP Event Hash;¶

• JEP J/D/T/V semantics;¶

• JEP signing semantics;¶

• Core validation checks.¶

13.3. References

A chain edge referring to a logical JEP event SHOULD use Event Identity.¶

A chain profile MAY additionally pin an Event Hash when the exact signed representation matters.¶

A JEP reference does not by itself prove causality, endorsement, authorization, completeness, or responsibility.¶

13.4. Chain Result

A chain result SHOULD expose chain_integrity separately from JEP-Core validity.¶

A concrete chain profile MUST define, where applicable:¶

• edge types;¶

• resolution rules;¶

• observed-log assumptions;¶

• complete-log assumptions;¶

• cycle handling;¶

• delegation-scope interpretation;¶

• termination-cascade interpretation;¶

• verification-path interpretation;¶

• causal interpretation;¶

• failure behavior.¶

Legal, moral, regulatory, or organizational responsibility remains a policy determination unless an explicitly selected policy profile defines the required evidence and rules.¶

14.1. Identifier

jep-profile:blockchain-anchor:1

14.2. Scope

This optional profile family defines how an exact JEP signed artifact may be anchored in a distributed ledger, transparency log, timestamp service, or similar external system.¶

Because anchoring ordinarily commits to exact bytes, the object anchored SHOULD be the Event Hash or another profile-defined digest of the exact signed artifact, not Event Identity alone.¶

A concrete profile MUST define:¶

• anchoring system;¶

• digest algorithm;¶

• inclusion or commitment proof;¶

• confirmation or finality rule, where applicable;¶

• timestamp semantics, if any;¶

• verifier procedure;¶

• historical-verification behavior;¶

• failure behavior.¶

A profile MAY expose this through a profile-specific check such as:¶

jep-profile:blockchain-anchor:1#anchoring

Anchoring may support existence, ordering, timestamp, or non-equivocation evidence according to the selected system. It does not prove that the JEP claim is true, authorized, lawful, complete, or externally effective.¶

15.1. Identifier

jep-profile:ai-actor:1

15.2. Scope

This optional profile family defines actor-identifier and binding conventions for AI-native actors, including:¶

• model actors;¶

• agent actors;¶

• tool actors;¶

• service actors;¶

• workflow actors;¶

• session actors;¶

• human-agent composites;¶

• organization-agent composites.¶

A concrete profile MUST define:¶

• actor identifier syntax;¶

• actor lifecycle;¶

• signing-key ownership, control, or attestation model;¶

• session or deployment binding where relevant;¶

• key rotation and revocation;¶

• historical validation;¶

• algorithm policy.¶

An AI actor identifier does not prove internal model state, intent, understanding, sentience, competence, correctness, or factual truth.¶

Where an AI actor is operated on behalf of another principal, the profile MUST NOT infer delegated authority merely from operator, deployment, or model identity. Delegated authority requires the applicable delegation, authorization, or mandate evidence.¶