Catenor Protocol#

01 — Conformance#

Defines what it means for an implementation, component, or deployment to claim conformance with the Catenor Protocol.

Status: Draft v0.1
Protocol: Catenor Protocol
DID Method: did:catenor (proposed)
Normative language: BCP 14 / RFC 2119 / RFC 8174

1. Purpose#

This document defines the conformance model for Catenor Protocol.

It answers four questions:

1. What may claim to be Catenor-conformant?
2. Which requirements are mandatory?
3. Which protocol profiles may an implementation support?
4. How should conformance be declared, tested, and versioned?

Catenor is designed as a modular protocol.

An implementation does not necessarily need to implement every optional feature of the ecosystem, but it MUST accurately declare which conformance targets and profiles it supports.

2. Normative language#

The key words:

• MUST
• MUST NOT
• REQUIRED
• SHALL
• SHALL NOT
• SHOULD
• SHOULD NOT
• RECOMMENDED
• NOT RECOMMENDED
• MAY
• OPTIONAL

in Catenor specifications are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals.

Normative references:

• RFC 2119 — Key words for use in RFCs to Indicate Requirement Levels
• RFC 8174 — Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words

3. Conformance is explicit#

An implementation MUST NOT make a generic claim such as:

"Catenor compliant"

without identifying:

protocol version
+
conformance target
+
supported profiles

A valid claim should look conceptually like:

Catenor Protocol Draft v0.1
Conformance Target: Verifier
Profiles:
- Core
- Authority
- Confidential Verification

This avoids ambiguity.

4. Conformance targets#

Catenor defines conformance requirements for distinct implementation roles.

Initial conformance targets are:

Subject Manager
DID Resolver
Credential Issuer
Credential Holder
Credential Verifier
Authority Evaluator
Policy Evaluator
Confidential Verification Environment
Audit / Status Provider

An implementation MAY support more than one target.

5. Subject Manager#

A Subject Manager creates and maintains canonical Catenor subjects.

A conforming Subject Manager MUST:

✓ generate opaque high-entropy subject identifiers
✓ avoid direct derivation of identifiers from PII
✓ maintain subject lifecycle state
✓ support account bindings
✓ preserve canonical subject continuity where supported
✓ support key rotation / verification-method updates
✓ prevent silent reassignment of a DID to a different subject

A Subject Manager MUST NOT derive a Catenor identifier directly from:

name
date of birth
passport number
national identifier
email address
wallet address
identity-provider applicant ID

A Subject Manager MAY use identity evidence privately to determine whether an existing subject should be resolved.

6. DID Resolver#

A DID Resolver resolves a did:catenor identifier into its current DID Document or resolution result.

A conforming DID Resolver MUST:

✓ accept syntactically valid did:catenor identifiers
✓ reject malformed identifiers
✓ return deterministic resolution results for the same authoritative state
✓ expose verification methods required for cryptographic verification
✓ expose deactivation state when applicable
✓ distinguish resolution failure from DID deactivation

A resolver MUST NOT invent or infer verification methods that are not present in authoritative DID state.

A resolver SHOULD support historical resolution if the implementation profile claims historical verification support.

7. Credential Issuer#

A Credential Issuer issues Verifiable Credentials under the Catenor model.

A conforming issuer MUST:

✓ identify itself using a resolvable issuer identifier
✓ use an authorized verification method
✓ use an approved cryptographic profile
✓ sign the credential over the required protected content
✓ include required validity metadata
✓ include credential status information when the credential is revocable
✓ avoid embedding prohibited sensitive information in public contexts

An issuer MUST NOT treat possession of a private key as sufficient authority to issue arbitrary claims.

For authority-sensitive credentials, the issuer MUST also satisfy the applicable issuer-authority rules.

8. Credential Holder#

A Credential Holder stores or presents credentials on behalf of a subject.

A conforming holder MUST:

✓ preserve the credential's integrity
✓ preserve the issuer proof
✓ present credentials without modifying signed claims
✓ disclose only the information required by the verifier or policy where supported

A holder MUST NOT represent a modified credential as equivalent to the issuer-signed original.

A holder MAY use privacy-preserving presentation mechanisms where supported by the selected profile.

9. Credential Verifier#

A Credential Verifier determines whether a credential is cryptographically and semantically valid for a requested use.

A conforming verifier MUST NOT stop at:

signature valid

For security-relevant use, verification MUST evaluate at least:

1. credential structure
2. issuer identity
3. verification method
4. proof validity
5. proof purpose
6. validity period
7. credential status
8. issuer trust
9. issuer authority where applicable
10. scope where applicable

Conceptually:

10. Authority Evaluator#

An Authority Evaluator verifies relationships, capabilities, delegations, and authority chains.

A conforming Authority Evaluator MUST distinguish:

relationship
from
capability

It MUST NOT infer unrestricted authority solely from a relationship claim.

Example:

OFFICER_OF

MUST NOT automatically imply:

WITHDRAW_FUNDS
ISSUE_CREDENTIALS
DELEGATE_AUTHORITY

unless the applicable policy or credential explicitly grants those capabilities.

An Authority Evaluator MUST enforce:

delegated authority ⊆ delegator authority

unless a future Catenor specification explicitly defines a different rule for a specific capability type.

11. Policy Evaluator#

A Policy Evaluator receives verified facts and produces a policy decision.

A conforming Policy Evaluator MUST:

✓ identify the policy evaluated
✓ identify the requested action
✓ identify the applicable subject
✓ identify the applicable resource where relevant
✓ evaluate only trusted / verified facts for security-critical decisions
✓ produce an explicit outcome

At minimum, the outcome model MUST distinguish:

ALLOW
DENY

An implementation MAY define additional non-authoritative states such as:

INDETERMINATE
ERROR
REQUIRES_REVIEW

but those states MUST NOT be silently interpreted as ALLOW.

12. Confidential Verification Environment#

A Confidential Verification Environment (CVE) evaluates sensitive evidence without unnecessarily exposing it to public or unrelated execution contexts.

A conforming CVE MUST provide mechanisms appropriate to its threat model for:

input confidentiality
execution integrity
secret isolation
controlled output
data minimization

Where attestation is claimed, the implementation MUST clearly define:

what is attested
who verifies the attestation
which code / workload identity is covered
which trust assumptions apply

A CVE MAY be implemented using:

TEE
MPC
ZK proof systems
hardware-backed isolation
hybrid confidential-computation mechanisms

Catenor does not mandate a vendor or one specific technology.

13. Audit / Status Provider#

An Audit / Status Provider exposes lifecycle state required for historical or current verification.

It may provide:

credential status
key status
DID deactivation status
delegation status
policy version
admission status
audit commitments
historical state

A conforming provider MUST distinguish:

ACTIVE
REVOKED
SUSPENDED
EXPIRED
DEACTIVATED
UNKNOWN

where applicable.

It MUST NOT represent UNKNOWN as ACTIVE.

14. Catenor profiles#

Catenor defines profiles to group related protocol requirements.

Draft v0.1 defines the following profile model:

Catenor Core
Catenor Authority
Catenor Confidential Verification
Catenor Financial Security
Catenor Historical Verification

Profiles are additive.

15. Catenor Core Profile#

The Core Profile defines the minimum identity and credential semantics.

A Core-conformant implementation MUST support the relevant requirements for its target involving:

canonical subjects
did:catenor identifiers
DID Documents
verification methods
account bindings
Verifiable Credentials
credential verification
credential status where applicable

The Core Profile does not by itself require:

delegation
authority chains
confidential computation
financial execution
historical reconstruction

16. Catenor Authority Profile#

The Authority Profile adds:

relationships
capabilities
delegation
authority chains
trust anchors
admission
scope verification

A conforming Authority Profile implementation MUST enforce the authority constraints defined by the specification.

It MUST NOT treat a mutable database relationship as sufficient proof for security-critical authority.

17. Catenor Confidential Verification Profile#

The Confidential Verification Profile applies when sensitive evidence must be evaluated privately.

It adds requirements for:

confidential evidence handling
data minimization
controlled disclosure
confidential policy evaluation
secret isolation
attestation where claimed

It does not require all Catenor operations to occur confidentially.

Example:

public signature verification
→ may be public

DOB / KYC evidence evaluation
→ SHOULD occur confidentially

18. Catenor Financial Security Profile#

The Financial Security Profile applies to regulated, high-value, treasury, or other financial execution contexts.

It adds stronger requirements for:

key-purpose separation
execution authorization
high-value capability scope
revocation
auditability
transaction-bound decision context

For this profile:

Credential assertion keys and financial execution keys MUST use cryptographically distinct key material.

A subject MAY control both purposes, but the same private key MUST NOT be reused for both.

19. Catenor Historical Verification Profile#

The Historical Verification Profile allows a verifier to determine whether a credential, key, issuer, or delegation was valid at a specific historical point.

A conforming implementation SHOULD be able to answer questions such as:

Was verification key K active at time T?

Was credential C revoked at time T?

Did issuer I hold authority at time T?

Which policy version applied at time T?

Historical state MUST NOT be inferred solely from the current state if authoritative historical data is required.

20. Full conformance is not assumed#

Catenor does not define one universal:

"full implementation"

because different systems may act as different protocol components.

For example:

Library A
→ Core Verifier

Service B
→ Core + Authority Evaluator

Service C
→ Confidential Verification Environment

Platform D
→ Core + Authority + Confidential + Financial Security

All MAY be conforming if they accurately declare their scope.

21. Partial conformance#

An implementation MUST NOT describe itself as conforming to a profile if it intentionally omits a MUST requirement of that profile.

It MAY instead state:

Catenor-compatible
experimental implementation
partial implementation
prototype

provided the unsupported requirements are clearly disclosed.

22. Conformance statement#

A conforming implementation SHOULD publish a machine-readable conformance statement.

Draft example:

{
  "protocol": "Catenor",
  "version": "0.1-draft",
  "implementation": "Example Verifier",
  "conformanceTargets": [
    "CredentialVerifier",
    "AuthorityEvaluator"
  ],
  "profiles": [
    "Core",
    "Authority"
  ],
  "didMethods": [
    "did:catenor"
  ],
  "cryptoProfiles": [
    "catenor-crypto-v1"
  ],
  "status": "experimental"
}

23. Conformance statement fields#

protocol#

"protocol": "Catenor"

Identifies the protocol family.

For Catenor conformance claims, this value MUST be:

Catenor

unless a future specification defines a canonical URI instead.

version#

"version": "0.1-draft"

Identifies the protocol version against which conformance is claimed.

A production implementation MUST NOT claim conformance without identifying a version.

implementation#

"implementation": "Example Verifier"

Human-readable name of the implementation.

This field does not grant protocol authority or certification.

conformanceTargets#

"conformanceTargets": [
  "CredentialVerifier",
  "AuthorityEvaluator"
]

Lists which protocol roles the implementation claims to implement.

Every listed target MUST satisfy the mandatory requirements for that target and the declared profiles.

profiles#

"profiles": [
  "Core",
  "Authority"
]

Lists supported Catenor profiles.

An implementation MUST NOT list a profile if it intentionally violates a MUST requirement of that profile.

didMethods#

"didMethods": [
  "did:catenor"
]

Lists DID methods supported by the implementation.

For Catenor Core conformance, support for did:catenor is expected unless the implementation target does not perform DID operations.

cryptoProfiles#

"cryptoProfiles": [
  "catenor-crypto-v1"
]

Lists the cryptographic profiles implemented.

The exact identifier format will be finalized in the Catenor Crypto Profile specification.

status#

"status": "experimental"

Describes implementation maturity.

Draft values may include:

experimental
beta
production
deprecated

This field is informational.

It MUST NOT be interpreted as proof of security.

24. Conformance and security certification are different#

A conforming implementation is not automatically:

secure
audited
certified
legally compliant
regulator-approved
production-ready

Conformance means:

The implementation follows the protocol requirements it claims to support.

It does not mean:

The implementation is free from vulnerabilities or legally suitable for every use case.

25. Conformance and trust are different#

Catenor protocol conformance does not make an issuer trusted.

Example:

Issuer X
implements Catenor correctly

does not imply:

Verifier Y trusts Issuer X

Issuer trust is established through:

trust anchors
admission
governance
policy
external evidence

not through software conformance alone.

26. Conformance and truth are different#

A perfectly conforming issuer can still issue a false claim if its evidence process is defective or malicious.

Therefore:

protocol conformance
!=
claim truth

Catenor separates:

cryptographic validity
issuer authority
evidence quality
policy acceptance

27. Vendor neutrality requirement#

A conforming Catenor implementation MUST NOT require the protocol itself to depend on a specific commercial vendor unless that dependency is explicitly part of a separately defined implementation profile.

The core protocol MUST remain expressible in vendor-neutral technical terms.

Examples:

Identity Verification Provider
Secure Key Management System
Confidential Verification Environment
Operational Database
Credential Store
Execution Environment

A reference implementation MAY map those abstractions to concrete technologies.

28. Data minimization requirement#

Implementations SHOULD minimize disclosure.

A verifier SHOULD request only the facts required for the action being evaluated.

Example:

Required:
AGE_OVER_21 = true

The verifier SHOULD NOT require:

exact date of birth

unless the exact value is necessary for the policy.

29. Key-purpose conformance#

An implementation claiming the Financial Security Profile MUST demonstrate that:

Credential Assertion Key
!=
Financial Execution Key

This means cryptographically distinct private-key material.

Separate labels for the same private key do not satisfy the requirement.

30. Status handling#

When a credential or authority status cannot be determined, security-sensitive implementations MUST fail safely.

Recommended behavior:

UNKNOWN
        ↓
do not treat as ACTIVE

A policy MAY convert UNKNOWN into:

DENY
REQUIRES_REVIEW
INDETERMINATE

but MUST NOT silently interpret it as positive authorization.

31. Errors and fail-closed behavior#

Security-critical Catenor implementations SHOULD fail closed when they cannot establish required proof.

Examples:

issuer DID cannot resolve
→ DENY / INDETERMINATE

credential status unavailable
→ DENY / INDETERMINATE

signature invalid
→ DENY

authority chain incomplete
→ DENY

confidential evidence cannot be verified
→ DENY / REQUIRES_REVIEW

Availability failures and proof failures MAY be represented differently, but neither should silently become authorization.

32. Determinism#

Where a policy is defined as deterministic, the same:

policy version
+
verified input facts
+
evaluation context

SHOULD produce the same decision.

If nondeterministic external state participates, that dependency MUST be explicitly represented in the decision context.

33. Versioning#

Catenor specifications use semantic protocol versions conceptually:

MAJOR.MINOR

Examples:

0.1
0.2
1.0

During pre-1.0 development, backwards-incompatible changes MAY occur between minor versions.

After 1.0, backwards-incompatible normative changes SHOULD require a major-version change.

34. Draft status#

A Draft specification is not considered frozen.

Implementations MUST NOT assume that:

Draft v0.1

will remain wire-compatible with:

Draft v0.2

unless explicitly stated.

35. Deprecation#

A protocol element MAY be marked:

DEPRECATED

Deprecated elements:

MAY remain supported for compatibility
SHOULD NOT be used in new implementations

A replacement SHOULD be identified where possible.

36. Test vectors#

Normative requirements SHOULD eventually have executable test vectors.

Examples:

valid DID
invalid DID
valid credential proof
tampered credential
expired credential
revoked credential
invalid issuer authority
valid delegation
delegation privilege escalation
key-purpose violation
subject-continuity duplicate

Test vectors are not yet normative in Draft v0.1.

37. Conformance test suite#

A future Catenor conformance suite SHOULD test each target/profile independently.

Conceptually:

Core
├── DID tests
├── VC tests
└── Account Binding tests

Authority
├── Relationship tests
├── Capability tests
├── Delegation tests
└── Authority-chain tests

Confidential Verification
├── privacy property tests
├── disclosure tests
└── attestation tests

Financial Security
├── key-separation tests
├── authorization tests
└── fail-closed tests

38. Self-attestation vs certification#

Draft Catenor conformance claims are initially self-attested.

A project MAY publish:

"We pass the Catenor v0.1 Core test suite."

This does not imply endorsement by Catenor maintainers.

A future governance process MAY define:

official certification
conformance badges
independent test labs
certified profiles

but no such certification program exists in Draft v0.1.

39. Reference implementations#

A Catenor reference implementation:

illustrates one implementation strategy

It does not:

define the protocol by itself

If reference code conflicts with the normative specification:

The normative specification takes precedence.

40. Specification precedence#

Unless a future specification defines otherwise, precedence is:

Normative Catenor Specification
        ↓
Normative Profile Documents
        ↓
Normative Schemas
        ↓
Normative Test Vectors
        ↓
Reference Implementations
        ↓
Examples / Tutorials

Informative examples MUST NOT override normative requirements.

41. External standards#

Catenor builds on external specifications including W3C DID and Verifiable Credentials.

An implementation claiming Catenor conformance MUST also satisfy the relevant normative requirements of those external standards where Catenor relies on them.

Catenor MUST NOT redefine an external standard incompatibly without explicitly defining a Catenor-specific extension or profile.

42. Minimal conformance summary#

A conforming Catenor implementation:

1. declares its protocol version

2. declares its conformance target(s)

3. declares its supported profile(s)

4. satisfies all applicable MUST / MUST NOT requirements

5. does not overstate partial support

6. maintains vendor-neutral protocol semantics

7. distinguishes identity from accounts

8. distinguishes relationships from capabilities

9. verifies more than signatures when authority matters

10. fails safely when required proof cannot be established

43. Guiding principle#

Conformance must describe what an implementation actually guarantees — not what it intends, markets, or approximates.