JEP Profiles and Interoperability
draft-wang-jep-profiles-00

Network Working Group                                         Y. Wang
Internet-Draft                                             Independent
Intended status: Experimental
Expires: November 5, 2026                                      May 4, 2026

                    JEP Profiles and Interoperability
                    draft-wang-jep-profiles-00
Status of This Memo

   This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on November 5, 2026.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Revised BSD License text as described in Section 4.e of the
   Trust Legal Provisions and are provided without warranty as described
   in the Revised BSD License.

Table of Contents

   1        Introduction
   2        Profile Principles
   1        A profile MUST NOT redefine JEP-Core event verbs.
   2        A profile MUST NOT redefine JEP-Core signature, event hash, or core
   3        A profile MAY define actor identifier forms.
   4        A profile MAY define key-resolution mechanisms.
   5        A profile MAY define credential, attestation, authorization, archival,
   6        A profile MUST declare security and privacy considerations.
   7        A profile MUST declare whether it affects validation levels.
   8        A profile MUST define failure mappings to JEP failure codes or
   9        A profile SHOULD be independently implementable.
   10       A profile SHOULD avoid making global legal, policy, or factual
   3        Trust Profile Model
   4        DID / VC Profile
   5        X.509 / PKI Profile
   6        OAuth / OIDC Authorization Context Profile
   7        RATS / Attestation Profile
   8        Local IAM Profile
   9        HJS Archive and Privacy Profile
   10       JAC Chain Profile
   11       Blockchain Anchoring Profile
   12       AI Actor Profile
   13       Profile Registration Template
   14       Security Considerations
   15       Privacy Considerations
   16       IANA / Registry Considerations
   17       Initial Profile Set

JEP Profiles and Interoperability
Trust Profiles and Optional Interoperability Bindings for JEP
draft-wang-jep-profiles-00

Author: Yuqiang Wang  
Intended status: Experimental  
Companion draft: draft-wang-jep-judgment-event-protocol-06

---

Abstract

This document defines optional trust profiles and interoperability
bindings for the Judgment Event Protocol (JEP). JEP-Core defines the
neutral event protocol. This document defines how actor identifiers,
keys, credentials, authorization context, attestations, archival systems,
and chain systems can be bound to JEP events without changing JEP-Core
semantics.

The profiles in this document are optional. A JEP-Core implementation
MUST NOT require support for DID, VC, X.509, OAuth, RATS, blockchain
anchoring, HJS, JAC, or any specific AI platform or agent framework.

---

Companion Drafts

This draft depends on draft-wang-jep-judgment-event-protocol-06.
Conformance classes, schemas, test vectors, and reference-validator
behavior are defined in draft-wang-jep-conformance-00.

1. Introduction

JEP-Core defines signed judgment events. It intentionally does not
define a global identity, credential, authorization, attestation, legal,
or archival framework.

Operational deployments require profile-specific rules for resolving
actors, binding signing keys, checking credentials, applying
authorization context, validating attestations, preserving archival
evidence, and composing chains. This document provides a structured
profile model and optional profiles.

---

2. Profile Principles

Profiles MUST follow these principles:

1. A profile MUST NOT redefine JEP-Core event verbs.
2. A profile MUST NOT redefine JEP-Core signature, event hash, or core
   validation-level semantics.
3. A profile MAY define actor identifier forms.
4. A profile MAY define key-resolution mechanisms.
5. A profile MAY define credential, attestation, authorization, archival,
   or chain rules.
6. A profile MUST declare security and privacy considerations.
7. A profile MUST declare whether it affects validation levels.
8. A profile MUST define failure mappings to JEP failure codes or
   profile-specific codes.
9. A profile SHOULD be independently implementable.
10. A profile SHOULD avoid making global legal, policy, or factual
    determinations unless it explicitly defines evidence rules.

---

3. Trust Profile Model

A JEP trust profile defines how a verifier resolves and evaluates
identity, key, actor-binding, algorithm, revocation, and historical
validity.

A trust profile specification MUST define:

- profile identifier;
- supported actor identifier forms;
- supported key identifier forms;
- key discovery mechanism;
- binding rules between who and signing keys;
- accepted algorithms;
- downgrade policy;
- key rotation handling;
- revocation handling;
- historical validation rules;
- credential or attestation dependency, if any;
- privacy considerations;
- failure-code mapping;
- conformance requirements.

A trust profile MAY define profile-specific extensions, but those
extensions MUST NOT redefine JEP-Core semantics.

---

4. DID / VC Profile

4.1 Profile Identifier

jep-profile:did-vc:0

4.2 Scope

This optional profile defines how JEP events MAY interoperate with
Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs).

DID and VC support is OPTIONAL. JEP-Core implementations MUST NOT require
DID or VC support.

4.3 DID Binding

When who is a DID, the profile MUST define:

- supported DID methods;
- DID document resolution process;
- verification method selection;
- key controller rules;
- historical key validation;
- DID document caching;
- DID method failure handling;
- revocation or deactivation handling.

A verifier MUST reject a JEP event under this profile if the signing key
cannot be bound to who according to the resolved DID document and
profile policy.

4.4 VC Binding

A JEP event MAY reference a VC by:

- digest;
- URI;
- embedded object;
- Verifiable Presentation reference;
- HJS archival reference.

A VC MAY support claims about:

- actor role;
- organizational affiliation;
- authorization scope;
- certification;
- delegation capability;
- compliance status;
- human reviewer qualification;
- tool or model certification.

VC validity MUST be evaluated separately from JEP event validity. A valid
VC does not automatically make a JEP event valid. A valid JEP event does
not automatically make a VC claim true.

4.5 Validation Impact

A verifier under the DID/VC profile SHOULD map successful DID and
credential checks to Level 2 actor-binding or Level 4 policy validation,
depending on the credential role.

Credential-expired, credential-revoked, issuer-untrusted, or
presentation-invalid conditions MUST be reported as profile failures.

4.6 Security and Privacy

DID resolution may reveal correlation metadata. VC references may reveal
sensitive role, employment, certification, or authorization information.
Digest references may be vulnerable to confirmation or dictionary
attacks.

---

5. X.509 / PKI Profile

5.1 Profile Identifier

jep-profile:x509:0

5.2 Scope

This optional profile defines how X.509 certificates and PKI
infrastructure MAY be used to bind who to a signing key.

5.3 Requirements

The profile MUST define:

- certificate chain validation;
- name-to-actor binding;
- key usage and extended key usage requirements;
- revocation checking;
- certificate validity at event time;
- archival validation behavior;
- algorithm policy;
- trust anchors.

5.4 Validation Impact

Successful certificate and actor binding checks MAY support Level 2
actor-binding validation. Domain, regulatory, or organizational checks
remain Level 4 policy validation.

---

6. OAuth / OIDC Authorization Context Profile

6.1 Profile Identifier

jep-profile:oauth-oidc:0

6.2 Scope

This optional profile defines how OAuth or OIDC context MAY be referenced
by JEP events.

OAuth or OIDC artifacts MAY support claims about:

- authorization context;
- client identity;
- resource server;
- subject;
- consent or grant context;
- token-binding evidence.

6.3 Boundary

A JEP event referencing OAuth context does not by itself prove that the
underlying action was authorized. Authorization interpretation is
profile-specific and policy-dependent.

---

7. RATS / Attestation Profile

7.1 Profile Identifier

jep-profile:rats:0

7.2 Scope

This optional profile defines how remote attestation evidence MAY be
referenced by JEP events.

Attestation evidence MAY support claims about:

- runtime environment;
- device identity;
- model execution environment;
- secure enclave or trusted execution context;
- software measurement;
- tool invocation environment.

7.3 Boundary

RATS evidence supports environment claims. It does not prove the factual
correctness of a judgment.

---

8. Local IAM Profile

8.1 Profile Identifier

jep-profile:local-iam:0

8.2 Scope

This optional profile defines how enterprise identity and access
management systems MAY bind local actor identifiers to signing keys.

The profile MUST define:

- local actor namespace;
- key registry;
- role mapping;
- group or permission mapping;
- revocation handling;
- historical validation;
- audit export format.

---

9. HJS Archive and Privacy Profile

9.1 Profile Identifier

jep-profile:hjs-archive:0

9.2 Scope

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

HJS manages:

- receipt records;
- archive-time metadata;
- retention policy;
- redaction policy;
- selective disclosure;
- privacy policy;
- evidence lifecycle;
- long-term verification context.

HJS is a companion archive/privacy/evidence profile over JEP-Core, not
a replacement protocol for JEP-Core.

HJS MUST NOT redefine JEP-Core event semantics, signature semantics,
event hash semantics, validation levels, or failure codes.

9.3 Receipt and Archive Times

HJS MAY add receipt time, archive time, or evidence custody metadata.
These times are distinct from JEP when.

9.4 Privacy

HJS deployments SHOULD minimize disclosure and support access-controlled
evidence stores, redacted logs, digest references, audience-bound
disclosure, or selective-disclosure mechanisms.

---

10. JAC Chain Profile

10.1 Profile Identifier

jep-profile:jac-chain:0

10.2 Scope

This optional profile defines how JAC-like systems MAY compose JEP events
into causality chains, responsibility chains, delegation paths,
verification paths, and workflow accountability graphs.

JAC is a companion causality/accountability-chain profile over
JEP-Core, not a replacement protocol for JEP-Core.

JAC MUST NOT redefine:

- JEP event object;
- JEP signature semantics;
- event hash semantics;
- validation levels;
- failure-code semantics.

10.3 Causal Boundary

A JEP reference does not by itself imply causality. JAC defines causal
interpretation over JEP events.

A JAC chain result MUST declare:

- observed-log assumption;
- complete-log assumption, if any;
- chain reconstruction method;
- causal edge types;
- termination interpretation;
- verification-scope interpretation.

10.4 Validation Impact

JAC chain reconstruction MAY support Level 3 chain validation. Legal or
organizational responsibility remains Level 4 policy validation.

---

11. Blockchain Anchoring Profile

11.1 Profile Identifier

jep-profile:blockchain-anchor:0

11.2 Scope

This optional profile defines how JEP event hashes MAY be anchored in a
distributed ledger or transparency mechanism.

Blockchain anchoring is OPTIONAL and MUST NOT be required for JEP-Core
conformance.

11.3 Boundary

Anchoring may support timestamping or non-equivocation evidence. It does
not prove the content of a JEP event is true, lawful, complete, or
policy-compliant.

---

12. AI Actor Profile

12.1 Profile Identifier

jep-profile:ai-actor:0

12.2 Scope

This optional profile defines actor-identifier conventions for AI-native
actors, including:

- model actors;
- agent actors;
- tool actors;
- service actors;
- workflow actors;
- session actors;
- human-agent composites;
- organization-agent composites.

The profile MUST define how a signing key represents, controls, or
attests to an AI actor.

12.3 Boundary

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

---

13. Profile Registration Template

A profile registration SHOULD include:

- profile identifier;
- profile name;
- profile version;
- description;
- supported JEP-Core version;
- actor identifier forms;
- key resolution method;
- credential or attestation dependencies;
- algorithm policy;
- validation-level impact;
- failure-code mapping;
- security considerations;
- privacy considerations;
- change controller;
- reference implementation or test vectors, if available.

---

14. Security Considerations

Profiles can expand the trust surface. A malicious or poorly specified
profile can cause actor misbinding, algorithm downgrade, credential
overclaim, excessive disclosure, or false policy conclusions.

A profile MUST NOT present profile validity as global truth unless it
defines external evidence rules.

---

15. Privacy Considerations

Profiles can introduce sensitive identifiers, credentials, roles,
organization relationships, location data, execution measurements, or
workflow metadata. Profiles SHOULD support data minimization, digest
references, access-controlled evidence, redaction, and selective
disclosure.

---

16. IANA / Registry Considerations

This draft requests or anticipates registries for:

- JEP trust profile identifiers;
- JEP optional profile identifiers;
- JEP profile conformance classes;
- profile-specific failure codes;
- profile-specific verification scopes.

---

17. Initial Profile Set

Initial optional profiles:

| Profile | Identifier | Status |
|---|---|---|
| DID/VC | jep-profile:did-vc:0 | Optional |
| X.509/PKI | jep-profile:x509:0 | Optional |
| OAuth/OIDC | jep-profile:oauth-oidc:0 | Optional |
| RATS | jep-profile:rats:0 | Optional |
| Local IAM | jep-profile:local-iam:0 | Optional |
| HJS Archive | jep-profile:hjs-archive:0 | Optional |
| JAC Chain | jep-profile:jac-chain:0 | Optional |
| Blockchain Anchor | jep-profile:blockchain-anchor:0 | Optional |
| AI Actor | jep-profile:ai-actor:0 | Optional |

---

Author's Address

Yuqiang Wang  
Email: signal@humanjudgment.org  
URI: https://github.com/hjs-spec

v0.6 Direct Upgrade Note

This document is part of the JEP v0.6 draft set. The v0.6 set directly
incorporates standardization structure, interoperability profiles,
conformance artifacts, schemas, signed test vectors, invalid cases, and
multi-language validator seeds without changing the JEP-Core narrow-waist
semantics.

draft-wang-jep-profiles-00                  Expires November 5, 2026                 [Page 1]