Catenor Protocol#

Canonical Decisions — Baseline v0.1#

Conceptual source of truth for Catenor Draft v0.1.

All protocol specifications, schemas, tests, documentation, and reference implementations MUST remain consistent with this document unless a decision is explicitly amended.

Status: Review Draft
Protocol: Catenor Protocol
Proposed DID Method: did:catenor
License: Apache License 2.0

0. Precedence#

If another Catenor draft conflicts with this baseline:

This baseline takes precedence until the conflicting document is corrected.

Documentation authors and implementation agents MUST NOT silently reinterpret or reopen a frozen decision.

If a frozen decision appears technically inconsistent or incomplete, the correct action is:

identify conflict
        ↓
stop dependent design work
        ↓
propose explicit amendment
        ↓
review
        ↓
update baseline
        ↓
continue

1. Protocol neutrality#

Decision 1 — Catenor is an open protocol#

Catenor is structurally independent from any:

company
commercial vendor
wallet provider
identity provider
cloud provider
database provider
blockchain network
confidential-computing provider
settlement system

Core Catenor specifications MUST use vendor-neutral terminology.

Company and vendor names MUST NOT appear in core protocol documents.

External standards bodies and normative technical standards MAY be referenced where required.

Decision 2 — Core purpose#

Catenor defines protocol semantics for:

canonical identity
verifiable credentials
verifiable authority
relationships
capabilities
delegation
authority chains
subject continuity
trust admission
policy evaluation
privacy-preserving verification
auditability

Decision 3 — Core thesis#

Wallets are accounts.
Credentials are claims.
Authority is scoped.
Identity persists.

2. Canonical Subjects#

Decision 4 — First-class Subject types#

Draft v0.1 defines:

HUMAN
ORGANIZATION
AGENT

An organizational legal vehicle is modeled as an ORGANIZATION.

An autonomous or semi-autonomous software actor is modeled as an AGENT.

Decision 5 — Agents have their own identity#

An Agent MUST have its own canonical Subject identity.

An Agent MUST NOT impersonate or inherit the identity of its principal merely because the principal authorized it.

Authority flows through explicit delegation.

Decision 6 — Assets are not Subjects by default#

Assets are resources or objects of authority, ownership, or policy.

Conceptually:

Subject
= who acts

Asset / Resource
= what is acted upon

Draft v0.1 MUST NOT assume that an asset is a Catenor Subject.

A future specification MAY define an interoperable asset-identifier model.

3. Catenor DID#

Decision 7 — Native DID format#

The proposed native identifier is:

did:catenor:<opaque-high-entropy-id>

Example:

did:catenor:8f0c92d7e5f04e4096f1...

Decision 8 — Implementer identity is not embedded#

The method-specific identifier MUST NOT contain:

company name
tenant name
provider name
application name
network name

The canonical identifier must remain implementation-neutral.

Decision 9 — The DID belongs to the Subject#

The canonical DID represents the Subject.

It does not belong to the system that first:

onboarded
verified
authenticated
stored
or executed an action for

the Subject.

Protocol principle:

The Catenor DID belongs to the Subject, not to the system that first encountered the Subject.

Decision 10 — DID generation is independent from PII#

The Catenor DID MUST NOT be directly derived from:

name
date of birth
government identifier
passport identifier
email
phone
wallet address
external provider identifier

Correct model:

identity evidence
        ↓
private subject matching / continuity

NOT

identity evidence
        ↓
canonical DID generation

Decision 11 — New identifiers use high entropy#

A new Catenor DID SHOULD be generated using cryptographically secure high-entropy randomness.

The exact encoding and bit length remain an open Draft v0.1 design item.

Decision 12 — No cryptographic reverse to legal identity#

A Catenor DID is not:

encrypted PII
hash of PII
encoded legal identity

Therefore the DID itself cannot be mathematically reversed into a legal identity.

Legal identity resolution requires authorized access to private identity state.

4. DID Document#

Decision 13 — DID Documents are public/resolvable state#

A Catenor DID resolves conceptually as:

did:catenor:<id>
        ↓
DID Resolver
        ↓
Authoritative DID State
        ↓
DID Document

The persistence technology is not frozen in Draft v0.1.

Decision 14 — DID Documents contain public verification material#

A DID Document MAY expose:

canonical DID
verification methods
public verification keys
controllers
verification relationships / purposes
appropriate service endpoints
resolution/deactivation metadata

It MUST NOT expose private identity evidence merely because that evidence relates to the same Subject.

Decision 15 — Verification Method identifiers are DID URLs#

Example:

did:catenor:ABC#assertion-key-1

This is not another Subject.

It is a DID URL identifying a verification method associated with:

did:catenor:ABC

Decision 16 — Controller semantics#

A verification method controller identifies the DID authorized to control that verification method.

It does not inherently identify:

a financial account
a database administrator
a legal owner
an execution account

Decision 17 — Assertion Method semantics#

A verification method referenced by assertionMethod is authorized to make cryptographic assertions on behalf of the DID.

Credential issuance is an assertion use case.

5. Key-purpose separation#

Decision 18 — Security purposes are distinct#

Catenor distinguishes at least these conceptual purposes:

Credential Assertion
Authentication
Delegation
Recovery / Rotation
Financial Execution

These purposes MUST NOT be treated as semantically interchangeable.

Decision 19 — Credential assertion key and financial execution key are distinct#

For the Financial Security Profile:

Credential Assertion Keys and Financial Execution Keys MUST use cryptographically distinct private-key material.

Giving one private key two different labels does not satisfy this requirement.

Decision 20 — Public assertion material must not expose private financial binding#

A public credential-verification key MAY appear in the DID Document.

The Subject's financial execution account binding is private by default.

Correct separation:

PUBLIC

did:catenor:ABC
      ↓
assertion verification method
      ↓
public verification key

versus:

PRIVATE BY DEFAULT

did:catenor:ABC
      ↓
financial Account Binding
      ↓
external execution account

If an assertion public key permits derivation of an account identifier, that derived account MUST NOT be the Subject's private financial execution account under the Financial Security Profile.

6. Account Bindings#

Decision 21 — External accounts are bindings#

Accounts are represented as bindings to a canonical Subject.

Examples include:

blockchain account
authentication account
application account
agent execution account
financial account reference
external DID

Decision 22 — Account Binding does not redefine identity#

account != canonical Subject

A Subject MAY have multiple accounts simultaneously or over time.

Decision 23 — Account Bindings are private by default#

The relationship:

did:catenor:ABC
        ↔
external account

is private by default.

The external account itself may be public in its native execution environment.

What Catenor protects by default is the correlation between that account and the canonical Subject.

Decision 24 — Account-control proof does not require public correlation#

An implementation MAY prove control using a challenge-response flow:

random challenge
      ↓
external account signs
      ↓
signature verified
      ↓
binding established

A policy MAY consume a minimized result such as:

ACCOUNT_CONTROL_VALID = true

without requiring the complete binding to become public.

7. External Identifiers#

Decision 25 — Other DID methods may be linked#

A Catenor Subject MAY bind to an identifier from another DID method.

That identifier is an external binding or representation.

Within a native Catenor trust domain:

did:catenor:<id>

remains the canonical Catenor Subject identifier.

8. Identity Verification Providers#

Decision 26 — Provider abstraction#

Catenor MUST NOT depend on one identity-verification provider.

The protocol defines an abstract role:

Identity Verification Provider

Provider-specific evidence is normalized before being consumed by Catenor semantics.

Decision 27 — Provider identifier != Catenor DID#

An external provider identifier is a private reference.

It MUST NOT become the canonical Catenor DID.

9. Canonical Subject Registry#

Decision 28 — Private provider mapping#

Implementations may maintain private mappings such as:

did:catenor:ABC
        │
        ├── provider reference A
        ├── provider reference B
        ├── authentication reference
        └── private account bindings

This is private operational state.

The core protocol does not mandate its storage technology.

10. Subject Continuity#

Decision 29 — Subject Continuity is core#

Subject Continuity answers:

Does newly presented evidence correspond to a canonical Subject that already exists?

Conceptual flow:

new evidence
    ↓
normalization
    ↓
private continuity evaluation
    ↓
same Subject?
  /          \
YES           NO
 ↓             ↓
existing DID   create new DID

Decision 30 — Continuity is provider-independent#

Continuity MAY span changes in:

wallet/account
identity-verification provider
authentication provider
network
application
key material

Decision 31 — Continuity inputs remain private#

Identity evidence used for continuity SHOULD remain private.

A minimized result MAY be:

SAME_SUBJECT = true

Decision 32 — Continuity does not reconstruct the DID#

Evidence is used to locate or establish the existing canonical Subject.

It is not used to algorithmically recreate the DID.

11. Verifiable Credentials#

Decision 33 — Credential is a claim object#

A Verifiable Credential is a cryptographically protected claim.

Issuer
   ↓ signs
Credential
   ↓ describes
Subject

The Issuer is a Subject.

The Credential is not an Issuer.

Decision 34 — Sensitive full credentials are private by default#

Sensitive full credentials SHOULD be stored privately and encrypted at rest.

The conceptual storage role is:

Credential Vault

Decision 35 — Signature proves authorship and integrity#

A valid signature proves:

the protected content has not been altered
+
the corresponding private key produced the signature

It does NOT prove:

the factual truth of the claim
the issuer is trusted
the issuer had authority
the credential remains active
the claim fits the requested scope

12. Verifiable Presentations#

Decision 36 — Presentation is contextual#

VC
= reusable credential

VP
= contextual minimum proof package

Catenor SHOULD favor data minimization and selective disclosure where technically available.

13. Credential Status#

Decision 37 — Signature validity != lifecycle validity#

A credential may have:

valid cryptographic signature
+
REVOKED lifecycle state

Such a credential MUST NOT authorize a current action.

Decision 38 — Revocation preserves history#

Revoking a credential does not erase its historical existence.

Historical profiles SHOULD support verification of the period during which the credential was active.

14. Issuers#

Decision 39 — Issuer is a Subject with authority#

Any Catenor Subject type MAY act as an Issuer when a valid authority chain grants the applicable credential-issuance capability.

Catenor does not define one global hardcoded Issuer list.

Decision 40 — Issuer authority is scoped#

Issuer authority conceptually includes:

action
credential type
scope
constraints
validity
delegability

Example:

ISSUE_CREDENTIAL
type: CredentialTypeA
scope: DomainA

Decision 41 — Issuer authority may be represented by a VC#

Authorization to act as an Issuer MAY be represented through a Verifiable Credential or equivalent verifiable authority object.

The exact authority-credential schema remains to be frozen.

Decision 42 — Issuer authorization may be hierarchical#

Issuer authority may flow through multiple authorized Subjects.

Example:

Trust Anchor
      ↓
Subject A
      ↓
Subject B
      ↓
issues Credential Type X

Every edge MUST be valid.

Decision 43 — ISSUE_CREDENTIAL != AUTHORIZE_ISSUER#

These are distinct capabilities:

ISSUE_CREDENTIAL
AUTHORIZE_ISSUER

A Subject allowed to issue a credential MUST NOT automatically be allowed to authorize another Issuer.

Decision 44 — Issuer delegation is bounded#

delegated issuer authority
⊆
delegator issuer authority

Delegability MUST be explicit.

15. Relationships#

Decision 45 — Relationship describes connection#

Canonical form:

subject
predicate
object

Example:

Human A
OFFICER_OF
Organization B

A relationship does not inherently grant action permission.

16. Capabilities#

Decision 46 — Capability describes permission#

A Capability answers:

who
may perform which action
on which resource
under which constraints

Conceptual fields:

subject
action
resource
constraints
validity
delegability

Decision 47 — Relationship != Capability#

A relationship such as:

OFFICER_OF

does not automatically imply capabilities such as:

MOVE_FUNDS
ISSUE_CREDENTIAL
AUTHORIZE_ISSUER
CREATE_DISTRIBUTION

17. Delegation#

Decision 48 — Delegation cannot increase authority#

Fundamental invariant:

delegated authority
⊆
delegator authority

Decision 49 — Delegability is explicit#

Holding a capability does not automatically imply authority to delegate it.

Delegability MUST be represented explicitly.

Decision 50 — Delegation may be constrained#

Constraints MAY include:

resource
credential type
jurisdiction
time
amount
function
execution target
delegation depth

18. Authority Chains#

Decision 51 — Authority is chain-verifiable#

A security-relevant action may require verification of:

Trust Anchor
      ↓
authority grant
      ↓
delegator
      ↓
delegate
      ↓
requested action

The final Subject's signature alone is insufficient.

Decision 52 — Every relevant authority edge must be valid#

Verification may require:

credential/proof validity
issuer identity resolution
issuer authority
credential status
scope
delegation permission
time validity
resource constraints
policy compatibility

19. Trust Anchors#

Decision 53 — Trust Anchor begins a Trust Domain#

A Trust Anchor is an accepted root of authority within a specific Trust Domain.

Catenor does not claim that cryptography alone creates initial trust.

Decision 54 — Infrastructure control != Trust Anchor authority#

A Subject MUST NOT become a Trust Anchor merely because it:

deployed software
operates infrastructure
controls a database
controls a domain

20. Trust Anchor Admission#

Decision 55 — Initial authority uses Admission#

Conceptual process:

Candidate Trust Anchor
        ↓
External Evidence
        ↓
Admission Policy
        ↓
Verification
        ↓
Proof of Key Possession
        ↓
Admission Record
        ↓
Active Trust Anchor

Decision 56 — Admission is not self-asserted trust#

This is insufficient:

"I am trusted because I signed a statement saying I am trusted."

Trust Anchor Admission instead combines:

external evidence
admission policy
verification
proof of key possession
configured governance/trust

21. Trust Domains#

Decision 57 — Trust is contextual#

Catenor does not define one universal Issuer whitelist.

Different Trust Domains MAY accept different:

Trust Anchors
Issuers
credential types
evidence sources
policies

22. Policy#

Decision 58 — Policy consumes verified facts#

A policy evaluates verified claims, authority, context, and constraints.

Security-critical policy decisions MUST NOT treat unsigned mutable application state as equivalent to verified evidence.

23. Decisions#

Decision 59 — Minimum decision outcomes#

At minimum:

ALLOW
DENY

Optional states MAY include:

INDETERMINATE
REQUIRES_REVIEW
ERROR

These MUST NOT silently become ALLOW.

Decision 60 — Policy Decision != execution authorization#

Catenor determines whether an action is permitted under protocol identity, authority, and policy semantics.

A separate execution system determines whether a specific key/account may technically execute an operation.

Both layers may be required.

24. Confidential Verification#

Decision 61 — Confidential Verification Environment#

Catenor defines the abstraction:

Confidential Verification Environment (CVE)

A CVE evaluates sensitive inputs while limiting unnecessary disclosure.

Decision 62 — Sensitive evidence should not be forced public#

Sensitive identity, credential, authority, relationship, or policy evidence SHOULD be evaluated privately when public evaluation would reveal unnecessary information.

Decision 63 — CVE is technology-neutral#

A conforming CVE MAY use technical mechanisms such as:

Trusted Execution Environment
Multi-Party Computation
Zero-Knowledge proof systems
hardware-backed isolation
hybrid confidential computation

The protocol defines required properties, not one implementation vendor.

Decision 64 — Confidential computing is contextual#

Not every operation requires a CVE.

Example:

verification of a public signature over public data
→ may occur publicly

Sensitive evidence evaluation may require confidentiality.

Decision 65 — Data-minimization principle#

Private evidence in. Minimum necessary verifiable fact out.

Example:

private input:
exact date of birth

minimized output:
AGE_OVER_THRESHOLD = true

25. Storage#

Decision 66 — Storage is implementation-independent#

The core protocol does not mandate a specific:

relational database
object store
distributed database
blockchain registry
verifiable database
cloud platform

Decision 67 — Operational database is an index#

Conceptual separation:

Operational Database
= locate and query

Signed Credential
= prove authorship and integrity

Authority Chain
= prove authority

Status Layer
= prove lifecycle validity

A database row alone is not sufficient authority proof.

26. Credential Vault#

Decision 68 — Full credentials live in a Credential Vault role#

Sensitive full signed credentials SHOULD be stored in a private encrypted credential-storage layer.

Catenor calls the conceptual role:

Credential Vault

The protocol does not mandate a storage product.

27. Identity Vault#

Decision 69 — Private identity material is separate from DID state#

A private Identity Vault may store or reference:

PII
identity-verification evidence
provider references
legal identity evidence
authorized-disclosure metadata

This is distinct from the public DID Resolution Layer.

28. Public vs private baseline#

Decision 70 — Default visibility#

29. Secure Key Management#

Decision 71 — Private keys are not operational database fields#

Private keys MUST NOT be stored as general-purpose application database fields.

Implementations SHOULD use a Secure Key Management System appropriate to their threat model.

Possible technical classes include:

hardware security modules
multi-party key management
secure enclave key services
hardware signing devices
specialized signing infrastructure

30. Audit Event Log#

Decision 72 — Security lifecycle events are append-oriented#

Initial conceptual events include:

SUBJECT_CREATED
ACCOUNT_BOUND
ACCOUNT_REVOKED
KEY_ADDED
KEY_REVOKED
CREDENTIAL_ISSUED
CREDENTIAL_REVOKED
CAPABILITY_GRANTED
CAPABILITY_REVOKED
DELEGATION_CREATED
DELEGATION_REVOKED
POLICY_EVALUATED
TRUST_ANCHOR_ADMITTED
IDENTITY_DISCLOSED

Persistence and anchoring remain open design items.

31. Historical Verification#

Decision 73 — Historical state can be security-relevant#

Historical profiles SHOULD support questions such as:

Was key K active at time T?
Was credential C active at time T?
Was Issuer I authorized at time T?
Was delegation D valid at time T?
Which policy version applied at time T?

32. Recovery and Rotation#

Decision 74 — Key rotation preserves canonical identity#

Example:

did:catenor:ABC
      │
      ├── old verification method → revoked
      └── new verification method → active

The Subject remains:

did:catenor:ABC

33. W3C foundations#

Decision 75 — Catenor builds on open W3C standards#

Catenor builds on:

W3C DID Core
W3C Verifiable Credentials Data Model
W3C Verifiable Presentation semantics
W3C Data Integrity

Catenor does not replace these standards.

It adds protocol semantics for:

canonical subjects
subject continuity
account bindings
issuer authority
relationships
capabilities
delegation
authority chains
trust-anchor admission
policy evaluation
confidential-verification requirements

34. Reference implementations#

Decision 76 — Reference implementations do not define the protocol#

A reference implementation MAY select concrete technologies for:

identity verification
secure key management
confidential computation
operational storage
credential storage
execution
settlement

Those selections MUST NOT be copied into core normative protocol requirements solely because they appear in a reference implementation.

35. Open design items#

The following are explicitly not frozen.

Documentation and implementation agents MUST NOT silently invent canonical answers for them.

Open A — Method-specific identifier encoding#

Frozen:

did:catenor:<opaque-high-entropy-id>

Open:

exact bit length
exact encoding
exact generation format

Open B — Authoritative DID persistence and resolution#

Open:

authoritative state architecture
persistence mechanism
distributed/shared-state requirements
historical resolution mechanism

Open C — Cryptographic Profile#

Open:

key types
signature algorithms
hash algorithms
canonicalization
proof suites
challenge/nonce format

Open D — Credential Status mechanism#

Status and revocation semantics are frozen.

The exact technical mechanism is not.

Open E — Subject Continuity algorithm#

Semantics are frozen.

Open:

matching algorithm
provider normalization rules
confidence model
false-positive handling
false-negative handling
manual-review thresholds

Open F — Account Binding proof schema#

Control proof semantics are frozen.

The final credential/proof representation is not.

Open G — Capability vocabulary#

The model is frozen.

The canonical initial vocabulary is not.

Open H — Delegation representation#

Delegation semantics are frozen.

The final wire representation is not.

Open I — Trust Anchor Admission profiles#

Admission semantics are frozen.

No universal admission policy is frozen.

Open J — Public/shared anchoring#

Open:

whether DID state must be externally anchored
whether status must be externally anchored
whether audit commitments must be externally anchored
whether policy/admission hashes must be externally anchored

Open K — Policy language#

Policy semantics are frozen.

The language/DSL/schema and execution engine are open.

Open L — Audit persistence model#

Audit semantics are frozen.

Persistence technology is open.

36. Canonical architecture summary#

37. Public/private architecture summary#

PUBLIC / RESOLVABLE
────────────────────────────────
did:catenor
DID Document
public verification methods
public status material where applicable


PRIVATE BY DEFAULT
────────────────────────────────
PII
provider references
full sensitive credentials
DID ↔ financial-account bindings
private relationships
private capabilities
private delegations
private evidence
private policy inputs


SECURE KEY MANAGEMENT
────────────────────────────────
credential-signing private keys
authentication private keys
delegation private keys
financial-execution private keys
recovery secrets / private keys

38. Final baseline statement#

A Catenor Subject has one canonical protocol identity independent of its accounts, providers, and execution environments. Public verification material allows cryptographic claims to be verified without exposing private financial-account bindings. Credentials establish signed claims; authority chains establish whether issuers and delegators had the right to make them. Relationships describe connections, capabilities describe powers, and delegation transfers only bounded authority. Sensitive evidence remains private and is evaluated confidentially when necessary. Trust begins at explicitly admitted Trust Anchors, not at whoever operates the software.