Catenor
Catenor Protocol / Draft v0.1

Canonical identity.
Verifiable authority.

An open protocol for persistent identity, verifiable credentials, scoped authority and delegation across humans, organizations and agents.

did:catenor:<opaque-id>W3C DIDVerifiable CredentialsChain-agnostic
Core thesis

Wallets are accounts.

Credentials are claims.

Authority is scoped.

Identity persists.

Canonical subjects

One protocol. Three actor types.

Every actor in Catenor receives its own canonical identity. Authority flows through explicit delegation, not inheritance.

Human

Persistent identity

A canonical subject that persists across changing wallets, authentication providers, networks and applications.

Organization

Verifiable authority

Companies, funds, trusts and institutions with explicit roles, relationships and scoped capabilities.

Agent

Bounded delegation

Autonomous actors with their own canonical identity, acting under explicitly delegated and constrained authority.

Canonical identity

The identity persists.
The bindings can change.

A Catenor DID anchors the canonical subject. Wallets, providers, applications, authentication methods and networks remain external bindings around that subject — not the identity itself.

Real-world Subject
did:catenor:8f0c92d7e5f04e40…
Canonical Subject
opaque · high-entropy · provider-independent
WWallet
IDIdentity Provider
AUAuthentication
APApplication
NWNetwork

The subject remains.Everything around it can change.

Catenor separates canonical identity from the external systems that represent, authenticate or execute on behalf of that identity.

Design principle

The DID belongs to the subject — not to the wallet, onboarding provider, application, network or system that first encountered it. External accounts and identifiers are bindings. They may be added, rotated, revoked or replaced without silently creating a new canonical subject.

Canonicaldid:catenor

Stable protocol identity for the subject.

ChangeableExternal bindings

Wallets, providers, apps, authentication and networks.

PrivacyCorrelation is controlled

Bindings remain private by default unless disclosure is required.

Authority model

Authority should be explainable.

Every meaningful action can be traced through verifiable authority grants, capabilities, delegation and status. Every edge in the chain must be valid.

01
Trust AnchorAdmitted root of authority within a trust domain. Established through an explicit admission process, not self-assertion.
02
Authority GrantVerifiable capability to issue credentials or authorize other subjects within defined scope and constraints.
03
OrganizationReceives scoped authority through the grant. May hold relationships, capabilities, and delegation rights.
04
DelegationBounded transfer of a subset of authority. Delegated authority cannot exceed the delegator's authority.
05
AgentActs under explicitly delegated and constrained authority. Has its own canonical identity, not the principal's.
06
ActionThe permitted operation, verified through the full chain. Policy evaluates all edges before producing a decision.
Core separations
Relationship
Capability
ISSUE_CREDENTIAL
AUTHORIZE_ISSUER
Policy Decision
Execution Authorization

Relationships describe connections. Capabilities describe permissions. These are never conflated. A relationship like OFFICER_OF does not automatically grant treasury authority.

Core invariant

Delegated authority ⊆ delegator authority. Delegation cannot create authority that the delegator does not hold. Delegability must be explicit.

Privacy model

Private evidence in.
Minimum necessary fact out.

Sensitive identity, credential and policy evidence is evaluated confidentially. Only the minimum necessary verifiable result is disclosed.

PRIVATE INPUT date of birth identity-provider evidence private credential organizational document ↓ CONFIDENTIAL VERIFICATION ↓ MINIMIZED OUTPUT AGE_OVER_21 = true AUTHORITY_VALID = true SAME_SUBJECT = true ALLOW
Visibility model
Public / verifiable
DID, public keys, credential issuer references, credential status, policy hashes, decision references.
Private
Name, date of birth, government IDs, source documents, financial details, beneficial ownership evidence.
Presented minimally
Threshold facts such as AGE_OVER_21, KYC_VERIFIED, or an ALLOW decision.
Technology-neutral

Confidential verification may use TEEs, MPC, zero-knowledge proof systems, hardware-backed isolation, or hybrid mechanisms. The protocol defines required properties, not one implementation.

Key-purpose separation

Credential identity ≠ financial execution.

Catenor distinguishes cryptographic key purposes. Under the Financial Security Profile, credential assertion keys and financial execution keys must use cryptographically distinct private-key material.

Public DID state

Verification keys

Assertion, authentication and recovery keys appear in the DID Document. These prove claims and authenticate the subject without exposing financial accounts.

Private binding

Financial execution

The mapping between the canonical subject and external financial accounts is private by default and uses cryptographically separate key material.

Key purposes
Purpose
Location
Visibility
Credential Assertion
DID Document
Public key
Authentication
DID Document
Public key
Delegation
DID / Authority state
Profile-dependent
Recovery / Rotation
DID state
Profile-dependent
Financial Execution
Private binding
Private by default
Financial Security Profile

Giving one private key two different labels does not satisfy this requirement. The private-key material must be cryptographically distinct.

Open standards

Extends. Does not replace.

Catenor builds on established W3C standards and adds protocol semantics for authority, delegation, continuity and policy evaluation.

Builds on

W3C DID Core

Decentralized identifier model for canonical subjects.

W3C Verifiable Credentials

Issuer, subject, holder, verifier and credential semantics.

W3C Data Integrity

Cryptographic proof suites for credential signing.

Catenor adds
Canonical Subjects
Subject Continuity
Account Bindings
Relationships
Capabilities
Delegation
Authority Chains
Trust Anchor Admission
Policy Evaluation
Confidential Verification
Vendor-neutral

The core specification must remain independent of specific vendors, providers, blockchains or infrastructure. Reference implementations may select concrete technologies without redefining the protocol.

Protocol flow

From subject to decision.

The canonical flow from identity through credentials, authority and policy to an explicit decision.

01
SubjectA human, organization or agent with a canonical Catenor identity.
02
did:catenorOpaque, high-entropy identifier. Never derived from PII.
03
Bindings + CredentialsAccount bindings link external accounts. Verifiable Credentials carry signed claims.
04
Relationships + CapabilitiesRelationships describe connections. Capabilities describe permitted actions with constraints.
05
DelegationBounded authority transfer. Delegated authority cannot exceed the delegator's authority.
06
Authority ChainVerifiable sequence from Trust Anchor through all grants and delegations.
07
PresentationMinimum proof package assembled for the verifier and action context.
08
Confidential VerificationSensitive evidence evaluated privately when public evaluation would reveal unnecessary information.
09
Policy EvaluationPolicy consumes verified facts, authority chains, status and context.
10
DecisionALLOW or DENY. Additional states like INDETERMINATE must not silently become ALLOW.
11
ExecutionSeparate execution authorization. Both policy approval and execution permission may be required.
Core separation

Catenor determines whether an action is permitted under identity, authority and policy semantics. Execution authorization is a separate layer. Both may be required.

Catenor Protocol

Identity should persist.
Authority should be verifiable.