Catenor Protocol#

00 — Overview#

An open protocol for canonical identity and verifiable authority.

Status: Draft v0.1
Protocol: Catenor Protocol
Proposed DID Method: did:catenor
License: Apache License 2.0

1. Purpose#

Catenor Protocol defines a vendor-neutral model for establishing and maintaining canonical subjects, verifiable credentials, relationships, capabilities, delegation, authority chains, subject continuity, and policy-based decisions across applications, networks, wallets, organizations, agents, and financial systems.

Catenor is designed around a simple premise:

A wallet is an account. It is not the identity of the subject controlling or using it.

The protocol therefore separates:

subject identity
from
accounts

claims
from
authority

relationships
from
capabilities

cryptographic validity
from
truth

policy decisions
from
transaction execution

Catenor does not define one centralized identity database and does not require one specific blockchain, cloud, wallet provider, identity-verification provider, confidential-computing system, or settlement network.

It defines the protocol semantics that allow implementations to reason about identity and authority in an interoperable way.

2. Core thesis#

Catenor starts from four principles:

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

A subject may change:

wallet
authentication provider
network
identity provider
role
credential set
signing key
execution environment

without necessarily becoming a new subject.

The canonical identity remains stable while its bindings, credentials, roles, and authority evolve over time.

3. The problem Catenor addresses#

Modern digital and financial systems frequently identify actors using account identifiers:

0x9a...
external network address
email address
user ID
OAuth subject
identity-provider applicant ID
API key
agent wallet

These identifiers answer:

Which account is this?

They do not necessarily answer:

Which canonical subject is this?

Nor do they answer:

Is this the same subject previously verified elsewhere?
Which organization may this human represent?
Which authority was granted to this agent?
Who issued the credential?
Was that issuer authorized to issue it?
Can that authority be delegated?
Was the credential still active at the time of an action?
Which evidence was used?
Which policy produced the decision?

Catenor defines a model for answering these questions without collapsing identity, credentials, authority, and execution into a single system.

4. Protocol scope#

Catenor defines semantics for:

Canonical Subjects
Catenor DIDs
DID Documents
Verification Methods
Account Bindings
Subject Continuity
Verifiable Credentials
Verifiable Presentations
Credential Status
Issuer Authority
Relationships
Capabilities
Delegation
Authority Chains
Trust Anchors
Trust Anchor Admission
Policy Evaluation
Decisions
Confidential Verification
Audit Events
Historical Verification
Key Purpose Separation
Recovery and Rotation

5. Out of scope#

Catenor does not attempt to directly provide:

KYC services
KYB services
identity-document verification
wallet custody
blockchain settlement
cloud storage
key custody
confidential-computing infrastructure
banking infrastructure
asset registries
legal determinations
regulatory approval

Implementations may integrate such systems.

Those integrations do not become part of the protocol merely because one reference implementation uses them.

6. Normative foundations#

Catenor is designed to compose established open standards rather than replace them.

The protocol builds on concepts from:

W3C Decentralized Identifiers
W3C Verifiable Credentials
W3C Verifiable Presentations
W3C Data Integrity

Catenor adds protocol semantics above those foundations for:

canonical subject persistence
subject continuity
issuer authority
relationship graphs
capability semantics
delegation
authority-chain verification
trust-anchor admission
confidential verification
policy evaluation
historical auditability

Catenor does not redefine these external standards unless an explicit Catenor extension or profile says otherwise.

7. Canonical subjects#

A Canonical Subject is the stable protocol identity representing an actor.

Initial subject classes are:

HUMAN
ORGANIZATION
AGENT

An organization may represent a company, fund, trust, SPV, association, institution, or other organizational actor.

An agent is an autonomous or semi-autonomous software actor.

Each canonical subject is identified by a Catenor DID:

did:catenor:<opaque-id>

Example:

did:catenor:8f0c92d7e5f04e4096f1...

The identifier belongs to the subject, not to the company, application, provider, or wallet that first onboarded the subject.

8. DID ownership and implementation neutrality#

A Catenor implementation MUST NOT embed the name of the implementing company or tenant in the canonical subject identifier.

Preferred:

did:catenor:8f0c92d7e5f04e40...

Not preferred:

did:catenor:company-a:12345
did:catenor:tenant-b:67890

An external DID MAY be linked to the canonical Catenor subject.

Example:

did:catenor:8f0c92...
        │
        ├── did:web:example.com
        ├── did:key:z6Mk...
        ├── external account A
        └── external account B

External identifiers are bindings or linked identifiers. They do not replace the canonical Catenor DID within a Catenor-native trust domain.

9. Identifier generation#

Catenor identifiers are opaque and SHOULD be generated from cryptographically secure, high-entropy randomness.

secure random value
        ↓
encoding
        ↓
did:catenor:<opaque-id>

Catenor identifiers MUST NOT be directly derived from:

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

Fundamental distinction:

PII
↓
may participate in private subject matching

PII
↓
MUST NOT directly generate the canonical DID

10. Subject continuity#

Subject Continuity answers:

Does newly presented identity evidence correspond to an already-existing canonical subject?

Subject Continuity may be needed when a subject changes wallets, providers, networks, applications, or signing infrastructure.

The canonical Catenor identity is provider-independent.

11. Account bindings#

An Account Binding links a canonical subject to an external account or execution identifier.

Examples include an blockchain execution address, external network address, bank-account reference, application account, agent wallet, authentication account, or external DID.

did:catenor:subject
        │
        ├── account A
        ├── account B
        └── account C

An account binding means:

this account is bound to this canonical subject
under a defined purpose and status

It does not mean:

account = identity

12. Verification methods#

A Catenor DID Document exposes public verification methods used to verify cryptographic actions associated with a subject.

Example:

{
  "id": "did:catenor:8f0c92...",
  "verificationMethod": [
    {
      "id": "did:catenor:8f0c92...#assertion-key-1",
      "controller": "did:catenor:8f0c92...",
      "type": "Multikey",
      "publicKeyMultibase": "z6Mk..."
    }
  ],
  "assertionMethod": [
    "did:catenor:8f0c92...#assertion-key-1"
  ]
}

A verification method identifies which key is controlled by which subject for which verification purpose.

13. Key-purpose separation#

Catenor distinguishes cryptographic purposes.

A subject may use different cryptographic keys for:

credential assertion
authentication
delegation
recovery
financial execution

These purposes SHOULD NOT be collapsed into one universal private key.

Under the Financial Security Profile, credential assertion keys and financial execution keys MUST use cryptographically distinct private-key material.

14. Verifiable Credentials#

A Verifiable Credential (VC) is a cryptographically protected claim.

Example claims:

IDENTITY_VERIFIED
KYC_VERIFIED
AGE_OVER_21
OFFICER_OF
OWNS
AUTHORIZED_TO_SIGN
AUTHORIZED_TO_DISTRIBUTE

A credential signature establishes:

authorship
+
integrity

It does not independently establish:

truth
issuer authority
continued validity
policy acceptance

15. Issuers#

An Issuer is a subject authorized to issue one or more credential types within a defined scope.

An issuer is not itself a credential.

Issuer
= did:catenor:issuer-a

Issuer authority may be represented by a credential or equivalent verifiable authority record.

Trust Anchor
      ↓
Issuer Authorization Credential
      ↓
Subject A
      ↓
may issue
KYC_VERIFIED

A Catenor Subject MAY act as an Issuer if a valid authority chain grants that subject the capability to issue the applicable credential type within the applicable scope.

16. Issuer delegation#

Issuer authority may itself be delegated when explicitly authorized.

Trust Anchor
      ↓
authorizes
Organization A
      ↓
may AUTHORIZE_ISSUER
for KYC credentials
      ↓
authorizes
Identity Provider B
      ↓
issues
KYC_VERIFIED

A subject that may issue a credential does not automatically gain the authority to authorize other issuers.

Delegability MUST be explicit.

delegated issuer authority
⊆
delegator issuer authority

17. Credential verification#

A verifier MUST evaluate more than the cryptographic signature when the credential is security-relevant.

A credential can be cryptographically valid while still being unauthorized, expired, revoked, outside issuer scope, or outside policy scope.

18. Verifiable Presentations#

A Verifiable Presentation (VP) is a contextual presentation of one or more credentials or derived proofs.

Credential
= reusable signed claim

Presentation
= minimum proof package for a particular verifier / action

Catenor encourages minimum necessary disclosure.

19. Relationships#

A Relationship describes how subjects or resources are connected.

Canonical conceptual form:

subject
predicate
object

Example:

Human A
OFFICER_OF
Organization B

Relationships do not automatically imply capabilities.

20. Capabilities#

A Capability describes what a subject is authorized to do.

A capability may define:

action
resource
constraints
validity
delegability

Example:

{
  "action": "CREATE_DISTRIBUTION",
  "resource": "did:catenor:organization-b",
  "constraints": {
    "maxAmount": 100000,
    "currency": "USD"
  }
}

21. Delegation#

Delegation transfers a bounded portion of authority from one subject to another.

Fundamental rule:

delegated authority
⊆
delegator authority

Delegation may be constrained by resource, credential type, jurisdiction, time, amount, function, contract, or delegation depth.

22. Authority chains#

An Authority Chain is the verifiable sequence of authority grants explaining why a subject is allowed to perform or delegate a particular action.

Trust Anchor
      ↓
Issuer / Sponsor Authorization
      ↓
Organization A
      ↓
Delegation
      ↓
Agent B
      ↓
Requested Action

The final subject's signature is not sufficient on its own.

23. Trust anchors#

A Trust Anchor is a subject or authority root accepted by a trust domain as an initial source of authority.

Cryptography cannot create trust from nothing.

A signature can prove that a key signed a claim. It cannot inherently prove that the signer should be trusted.

24. Trust Anchor Admission#

A subject SHOULD NOT become a trust anchor merely because it deployed software.

Admission may evaluate organizational identity, legal authority, governance, control-person verification, key possession, key-management policy, external credentials, or institutional evidence.

25. Trust domains#

A Trust Domain is the policy and trust context within which subjects, issuers, credentials, and authority chains are evaluated.

Different trust domains may trust different issuers.

Trust Domain A
trusts Issuer X

Trust Domain B
does not trust Issuer X

Catenor does not define one global issuer whitelist.

Trust is contextual.

26. Policy evaluation#

A Catenor Policy describes the verified conditions required for an action.

Example:

Action:
INVEST

Requires:
KYC_VERIFIED
AML_CLEAR
ACCREDITED_INVESTOR
OFFERING_OPEN

The policy consumes verified facts.

27. Decisions#

A Decision is the result of evaluating a policy against verified context.

Minimum outcomes:

ALLOW
DENY

Implementations may also represent:

INDETERMINATE
REQUIRES_REVIEW
ERROR

These additional states MUST NOT silently become ALLOW.

28. Policy decision is not transaction authorization#

Catenor separates:

"Should this action be allowed?"

from:

"Can this key execute this transaction?"

A secure implementation may require both policy approval and separate execution authorization.

29. Confidential verification#

Sensitive evidence may need to be evaluated without disclosure.

Catenor defines a Confidential Verification Environment (CVE).

private evidence
        ↓
confidential verification
        ↓
minimum necessary result

Example:

PRIVATE
date of birth
passport evidence
private credential
corporate document

        ↓

CVE

        ↓

MINIMIZED RESULT
AGE_OVER_21 = true
AUTHORIZED = true
SAME_SUBJECT = true

30. Confidential-computation technologies#

Catenor does not mandate one confidential-computation mechanism.

Possible implementations include:

Trusted Execution Environments
Multi-Party Computation
Zero-Knowledge proof systems
hardware-backed secure enclaves
hybrid mechanisms

Not every Catenor operation requires confidential computation.

31. Data minimization#

Catenor encourages disclosure of the minimum information required by a policy.

Private evidence in. Minimum necessary verifiable fact out.

32. Storage model#

Catenor does not mandate a database architecture.

An implementation may use relational databases, document databases, distributed databases, tamperproof databases, blockchain registries, private object storage, or credential vaults.

33. Database vs cryptographic evidence#

A mutable database row is an index, not the final authority proof.

database
= locate

credential
= prove authorship / integrity

authority chain
= prove authorization

status
= prove current validity

34. Credential and identity privacy#

Catenor implementations SHOULD support private storage of sensitive credentials, provider references, identity evidence, organizational documents, private relationships, and private policy inputs.

Public systems should receive only data required by their role.

35. Auditability#

Examples of security-relevant events:

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

These events form the verifiable history of a subject and its authority relationships.

36. Historical verification#

A system may need to answer:

Was this credential valid at time T?
Was this issuer authorized at time T?
Was this key active at time T?
Was this delegation revoked before the action?
Which policy version applied?

Catenor defines a Historical Verification Profile for implementations preserving sufficient authoritative history.

37. Revocation#

A valid signature may remain cryptographically valid after associated authority has been revoked.

signature valid?    YES
credential revoked? YES

→ credential MUST NOT authorize a current action

38. Recovery and rotation#

Key rotation MUST NOT silently create a new canonical subject.

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

The identity remains did:catenor:ABC.

39. Agent identity#

An agent is a first-class subject.

did:catenor:agent-opaque-id

An agent SHOULD NOT impersonate its principal.

Instead:

Organization
      ↓
Delegation Credential
      ↓
Agent

The agent has its own identity, verification methods, account bindings, delegated capabilities, and audit trail.

40. Implementation architecture#

This architecture is informative, not mandatory.

41. Vendor neutrality#

The core specification MUST remain vendor-neutral.

It may refer to roles such as:

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

Reference implementations may map these abstractions to concrete technologies.

42. Reference implementations#

A reference implementation demonstrates one way to satisfy the specification.

It does not define the specification.

If reference code conflicts with normative protocol text, the normative specification takes precedence.

43. Conformance#

Catenor conformance is explicit.

An implementation declares its:

protocol version
conformance target
supported profiles
cryptographic profiles

Detailed rules are defined in 01-CONFORMANCE.md.

44. Security invariants#

Core invariants include:

wallet != identity
provider ID != identity
PII != DID seed
database row != authority proof
valid signature != truth
relationship != capability
issuer != automatically authorized issuer
credential authority != financial execution authority
delegated authority <= delegator authority
revoked credential != active authority

45. Fail-closed behavior#

For security-relevant actions, missing required proof SHOULD NOT become authorization.

signature invalid
→ DENY

issuer authority unresolved
→ DENY / INDETERMINATE

credential status unavailable
→ DENY / INDETERMINATE

authority chain incomplete
→ DENY

required private evidence unavailable
→ DENY / REQUIRES_REVIEW

46. Privacy model#

Catenor privacy separates:

canonical identifier
public verification material
private credentials
private evidence
minimum presentations
policy decisions

The DID itself should not contain PII.

47. Trust model#

Catenor distinguishes:

cryptographic trust
issuer trust
authority trust
evidence trust
policy trust
execution trust

These are different layers.

48. Open protocol model#

Catenor is intended to be an open protocol.

Protocol conformance does not require each implementation itself to be open source unless a future profile says otherwise.

49. Specification structure#

specification/
├── 00-OVERVIEW.md
├── 01-CONFORMANCE.md
├── 02-TERMINOLOGY.md
├── 03-CORE-MODEL.md
├── identity/
├── credentials/
├── authority/
├── policy/
├── privacy/
├── audit/
└── security/

50. Schemas and test vectors#

The intended progression is:

Specification
      ↓
Schema
      ↓
Test Vector
      ↓
Conformance Test
      ↓
Implementation

51. Protocol maturity#

Draft v0.1 is intentionally incomplete.

Open areas include:

exact did:catenor resolution mechanism
method-specific identifier encoding
cryptographic suites
credential-status mechanism
subject-continuity matching profiles
public anchoring model
policy schema
capability vocabulary
delegation depth
recovery model
historical-state storage
conformance test suite

52. Design philosophy#

Catenor favors:

explicit authority
over implicit privilege

portable identity
over wallet-bound identity

minimum disclosure
over unnecessary data exposure

verifiable claims
over mutable database assertions

scoped delegation
over unbounded access

open standards
over vendor lock-in

53. Canonical flow#

54. Central invariant#

The canonical subject should remain stable while accounts, credentials, roles, keys, providers, and execution environments change around it.

Authority is not inferred from identity.

Authority must be:

issued
scoped
verifiable
delegable only when authorized
revocable
auditable

55. Summary#

Catenor defines a protocol in which:

a subject has a canonical identity
accounts bind to that identity
credentials describe verifiable claims
relationships describe connections
capabilities describe permitted actions
delegations transfer bounded authority
authority chains explain why authority exists
trust anchors establish initial trust
policies consume verified facts
decisions produce explicit outcomes
confidential verification protects sensitive evidence
audit history preserves lifecycle context

The protocol does not assume that one company, one wallet, one blockchain, one identity provider, or one database should own the subject's identity.

56. Guiding principle#

Identity should persist. Authority should be explicit. Evidence should be verifiable. Disclosure should be minimal. Execution should remain separately controlled.