Catenor Protocol#

02 — Terminology#

Defines the canonical vocabulary used throughout Catenor Protocol Draft v0.1.

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

1. Purpose#

Catenor relies on precise separation between concepts that are often conflated in identity and authorization systems.

This document defines the canonical meaning of those concepts.

Where a term is inherited from an external standard, Catenor uses that term consistently with the external standard and adds Catenor-specific semantics only where explicitly stated.

The most important separations are:

Subject                != Account
Canonical Identity     != Provider Identity
Credential             != Database Row
Relationship           != Capability
Issuer                 != Credential
Signature Validity     != Claim Truth
Authority              != Authentication
Policy Decision        != Execution Authorization
Public Verification Key != Private Financial Account Binding

2. Actor#

An Actor is any entity capable of participating in an action or protocol interaction.

In Catenor Draft v0.1, first-class actor categories are represented as Subjects:

HUMAN
ORGANIZATION
AGENT

An Asset is not an Actor by default.

3. Subject#

A Subject is an actor represented within Catenor.

A Subject MAY be:

Human
Organization
Agent

A Subject may hold credentials, control verification methods, have account bindings, participate in relationships, receive capabilities, delegate authority, and appear in policy decisions.

A Subject is identified canonically using a Catenor DID.

4. Canonical Subject#

A Canonical Subject is the stable protocol representation of a Subject across changing accounts, providers, credentials, keys, networks, and execution environments.

Example:

did:catenor:8f0c92...

The Canonical Subject is not recreated merely because:

a wallet changes
an authentication provider changes
an identity-verification provider changes
a key rotates
an application changes
a network changes

The canonical identity persists while surrounding bindings and evidence evolve.

5. Human#

A Human is an individual person represented as a Catenor Subject.

Example:

did:catenor:human-a

The human-readable suffix is informative only. Production identifiers MUST remain opaque.

6. Organization#

An Organization is a non-human organizational actor represented as a Catenor Subject.

Examples may include:

company
fund
trust
SPV
association
institution
foundation
partnership

Catenor does not require one legal form.

7. Agent#

An Agent is an autonomous or semi-autonomous software actor represented as its own Catenor Subject.

An Agent:

has its own canonical identity
may have its own verification methods
may have its own account bindings
may receive delegated capabilities
may participate in policy evaluation
may be audited independently

An Agent MUST NOT simply impersonate its principal.

8. Principal#

A Principal is a Subject on whose behalf another Subject, commonly an Agent or authorized Human, may act.

A Principal does not automatically transfer all of its authority to the acting Subject.

Authority must be delegated explicitly.

9. Asset#

An Asset is a resource, object, right, or external entity over which a Subject may hold rights or exercise authority.

In Draft v0.1:

Asset != Catenor Subject

by default.

A future specification MAY define a dedicated asset-identifier model.

10. Resource#

A Resource is the target or scope of a Capability, Delegation, Policy, or Decision.

A Resource may be:

a Catenor Subject
an Asset
an external system resource
a contract/function target
an organizational scope
another protocol-defined object

11. Decentralized Identifier (DID)#

A DID is a Decentralized Identifier as defined by W3C DID Core.

Catenor proposes the method:

did:catenor

with identifiers shaped conceptually as:

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

12. Catenor DID#

A Catenor DID is the canonical Catenor identifier of a Subject.

Example:

did:catenor:8f0c92d7e5f04e40...

The Catenor DID:

MUST NOT be directly derived from PII
MUST NOT embed an implementing company/provider/tenant name
represents the Subject rather than the onboarding system

13. Method-Specific Identifier#

The Method-Specific Identifier is the portion following:

did:catenor:

Example:

did:catenor:8f0c92...
            └─────── method-specific identifier

Its final encoding and bit length are not yet frozen.

14. DID URL#

A DID URL extends a DID with additional components such as a fragment.

Example:

did:catenor:organization-a#assertion-key-1

The fragment identifies something associated with the DID, such as a Verification Method.

It is not a second Subject.

15. DID Document#

A DID Document is the public/resolvable document describing verification state associated with a DID.

It MAY contain:

verification methods
controllers
verification relationships
service endpoints where appropriate

It MUST NOT be treated as the location for private identity evidence or private financial account bindings.

16. DID Resolver#

A DID Resolver is a component that accepts a DID and returns the authoritative DID resolution result.

Conceptually:

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

The persistence mechanism behind the resolver is not yet frozen.

17. Authoritative DID State#

Authoritative DID State is the protocol state from which the current DID Document and related resolution metadata are derived.

It may be persisted using different technical architectures.

The protocol MUST distinguish authoritative DID state from mutable application caches.

18. Verification Method#

A Verification Method is public cryptographic verification material associated with a DID.

Example identifier:

did:catenor:organization-a#assertion-key-1

A Verification Method normally identifies:

the method identifier
its controller
its type
its public verification material

19. Controller#

A Controller identifies the DID authorized to control a Verification Method.

Example:

"controller": "did:catenor:organization-a"

Controller does not automatically mean:

financial account
legal owner
database administrator
execution account

20. Verification Relationship#

A Verification Relationship describes the purpose for which a Verification Method is authorized.

Examples from DID semantics include concepts such as:

assertionMethod
authentication

A public key merely appearing in verificationMethod does not necessarily authorize every possible use.

21. Assertion Method#

An Assertion Method is a Verification Method authorized to make assertions on behalf of a DID.

Credential issuance is an assertion use case.

22. Credential Assertion Key#

A Credential Assertion Key is private key material whose corresponding public Verification Method is authorized for credential assertions.

The private key remains protected in Secure Key Management.

Under the Financial Security Profile, it MUST NOT be the same private key as the Financial Execution Key.

23. Authentication Key#

An Authentication Key is key material used to prove control/authentication for a Subject.

Authentication and credential assertion are conceptually distinct purposes.

24. Delegation Key#

A Delegation Key is key material authorized for creating or signing delegation-related assertions where the applicable profile uses dedicated delegation key material.

The final relationship between Delegation Keys and DID verification relationships is not yet frozen.

25. Recovery Key / Recovery Material#

Recovery Key or Recovery Material refers to cryptographic material or mechanisms used to recover, rotate, or replace compromised or unavailable verification methods.

Recovery MUST preserve the Canonical Subject rather than silently create a new identity.

26. Financial Execution Key#

A Financial Execution Key is private key material used to authorize financial or execution-layer transactions.

It is separate from the public Catenor credential-assertion identity layer.

Under the Financial Security Profile:

Credential Assertion Key
!=
Financial Execution Key

using cryptographically distinct private-key material.

27. Secure Key Management System#

A Secure Key Management System is an implementation component that protects private key material and performs or authorizes cryptographic signing operations.

Catenor does not mandate one implementation technology.

Private keys MUST NOT be ordinary fields in a general operational database.

28. Account#

An Account is an external account, address, identifier, or execution context associated with a Subject.

An Account is not the Canonical Subject.

29. Account Binding#

An Account Binding is a verifiable association between a Catenor Subject and an external Account.

Conceptually:

did:catenor:human-a
        ↔
external account

Account Bindings are private by default.

30. Account Control#

Account Control is evidence that a Subject or authorized actor controls an external Account.

One conceptual method is:

challenge
   ↓
account signs
   ↓
signature verified
   ↓
control established

The final Account Control Proof format is not yet frozen.

31. External Identifier#

An External Identifier is an identifier from outside the native Catenor identifier model.

Examples include:

external DID
authentication subject identifier
provider-specific user identifier
external account identifier

An External Identifier may be bound to a Catenor Subject without replacing the Canonical Subject.

32. Identity Evidence#

Identity Evidence is private or controlled information used to establish facts about a Subject's real-world identity.

It may include verified identity-provider outputs or other trusted evidence.

Identity Evidence:

may participate in Subject Continuity
MUST NOT directly generate the Catenor DID

33. Identity Verification Provider#

An Identity Verification Provider is an external evidence source or service that verifies identity-related facts.

The provider is an implementation dependency, not part of Catenor's canonical identifier format.

34. Provider Reference#

A Provider Reference is an identifier assigned by an external Identity Verification Provider.

It is private operational state.

A Provider Reference MUST NOT become the canonical Catenor DID.

35. Canonical Subject Registry#

The Canonical Subject Registry is the conceptual private layer that maps a Canonical Subject to private provider references, bindings, and continuity state.

Example:

did:catenor:human-a
        │
        ├── provider ref A
        ├── provider ref B
        └── private Account Binding

The storage architecture is implementation-specific.

36. Identity Vault#

An Identity Vault is the private storage role for sensitive identity material or references.

It may contain or reference:

PII
legal identity evidence
provider evidence
provider references
authorized disclosure metadata

It is separate from the public DID Resolution Layer.

37. Subject Continuity#

Subject Continuity is the process of determining whether newly presented identity evidence corresponds to an existing Canonical Subject.

Conceptually:

new evidence
    ↓
private matching
    ↓
same Subject?
  /          \
YES           NO
 ↓             ↓
reuse DID      create new DID

38. Continuity Match#

A Continuity Match is a result indicating that two independently presented records correspond to the same Canonical Subject.

The exact result envelope and confidence model are not yet frozen.

Sensitive matching inputs SHOULD remain private.

39. False Merge#

A False Merge occurs when the continuity process incorrectly treats two distinct real-world Subjects as the same Canonical Subject.

This is a critical Subject Continuity security failure.

40. False Duplicate#

A False Duplicate occurs when the continuity process incorrectly creates a second Canonical Subject for a real-world Subject that already has one.

This undermines canonical identity continuity.

41. Credential#

A Credential is a claim or set of claims about a Subject.

Not every credential is necessarily a Verifiable Credential unless it conforms to the applicable W3C and Catenor credential requirements.

42. Verifiable Credential (VC)#

A Verifiable Credential is a cryptographically protected credential based on the W3C Verifiable Credentials model.

A VC generally involves:

Issuer
Credential Subject
claims
validity
status where applicable
cryptographic proof

43. Credential Subject#

The Credential Subject is the entity described by the claims in a credential.

In Catenor, it is commonly identified using:

did:catenor:<id>

A Credential Subject is not necessarily the same actor as the Holder presenting the credential.

44. Issuer#

An Issuer is a Catenor Subject that issues a Verifiable Credential.

Catenor adds a critical semantic rule:

An Issuer must possess valid authority to issue the applicable credential type within the applicable scope.

Issuer is an actor.

Issuer is not a credential.

45. Issuer Authority#

Issuer Authority is the Capability authorizing a Subject to issue one or more credential types within defined scope and constraints.

Example conceptual action:

ISSUE_CREDENTIAL

46. Issuer Authorization#

Issuer Authorization is the verifiable grant that establishes Issuer Authority.

It MAY be represented by a Verifiable Credential or equivalent authority object.

47. Authorize-Issuer Capability#

The Authorize-Issuer Capability is authority to grant Issuer Authority to another Subject.

Conceptually:

AUTHORIZE_ISSUER

This is distinct from:

ISSUE_CREDENTIAL

A Subject able to issue credentials does not automatically gain authority to authorize other Issuers.

48. Holder#

A Holder is the entity that possesses and may present one or more Verifiable Credentials or derived proofs.

Holder and Credential Subject may be the same entity, but Catenor does not assume they are always identical.

49. Verifier#

A Verifier is an actor or component that evaluates a Verifiable Credential, Verifiable Presentation, authority proof, or related evidence.

A security-relevant Verifier must evaluate more than signature validity when authority, status, trust, or scope matter.

50. Proof#

A Proof is the cryptographic proof attached to or associated with protected data.

For a signed credential, proof establishes at minimum:

authorship
integrity

Proof validity does not independently establish claim truth or Issuer Authority.

51. Proof Purpose#

Proof Purpose indicates the authorized purpose for which the referenced Verification Method was used.

Credential issuance commonly uses:

assertionMethod

52. Verifiable Presentation (VP)#

A Verifiable Presentation is a contextual presentation of credentials or derived proofs to a Verifier.

Canonical distinction:

VC
= reusable credential

VP
= contextual proof package

Catenor favors minimum necessary disclosure.

53. Selective Disclosure#

Selective Disclosure is a mechanism that allows a Holder to reveal only the information required by a Verifier or Policy.

Catenor supports the principle but does not yet freeze one cryptographic selective-disclosure mechanism.

54. Credential Status#

Credential Status is lifecycle state relevant to whether a credential may currently be accepted.

Conceptual states include:

ACTIVE
SUSPENDED
REVOKED
EXPIRED
SUPERSEDED

The technical status mechanism is not yet frozen.

55. Revocation#

Revocation is the transition after which a credential, capability, delegation, key, or other authority object must no longer authorize current actions.

Revocation does not erase historical existence.

56. Evidence#

Evidence is information supporting a claim, admission, relationship, capability, policy decision, or continuity determination.

Evidence may be sensitive and SHOULD remain private when disclosure is unnecessary.

57. Credential Vault#

A Credential Vault is the conceptual private encrypted storage role for full signed credentials.

A Credential Vault is not the public DID Resolution Layer.

58. Relationship#

A Relationship describes a connection between a Subject and another Subject or Resource.

Canonical conceptual form:

subject
predicate
object

Example:

Human A
OFFICER_OF
Organization B

Relationship does not inherently mean permission.

59. Predicate#

A Predicate is the relationship type connecting the Subject to the Object.

Example:

OFFICER_OF

The canonical Relationship vocabulary is not yet frozen.

60. Capability#

A Capability describes authority to perform a specific action against a Resource under defined constraints.

Conceptually:

subject
action
resource
constraints
validity
delegability

61. Action#

An Action is the operation a Capability or Policy concerns.

Examples are illustrative only.

The canonical Catenor action vocabulary is not yet frozen.

62. Constraint#

A Constraint narrows the scope of a Capability, Delegation, Policy, or authorization.

Constraints MAY include:

amount
time
jurisdiction
resource
credential type
function
execution target
delegation depth

63. Delegation#

Delegation is an explicit transfer of a bounded subset of authority from one Subject to another.

Fundamental invariant:

delegated authority
⊆
delegator authority

64. Delegator#

A Delegator is the Subject granting bounded authority to another Subject.

A Delegator must possess both:

the authority being delegated
+
permission to delegate it

where delegability is required.

65. Delegate#

A Delegate is the Subject receiving delegated authority.

A Delegate receives authority without becoming the Delegator.

66. Delegability#

Delegability indicates whether a Capability may itself be delegated.

Holding a Capability does not automatically imply Delegability.

Delegability must be explicit.

67. Delegation Credential#

A Delegation Credential is a Verifiable Credential or future conforming authority representation encoding bounded Delegation.

The current working wire shape is defined in DATA-MODEL-BASELINE.md.

68. Authority#

Authority is the valid power of a Subject to issue a claim, perform an action, authorize another Subject, or delegate a Capability within defined scope.

Authority is not inferred merely from identity or authentication.

69. Authority Grant#

An Authority Grant is a verifiable act that gives a Subject a Capability or authority role.

An Authority Grant may be represented by a credential or other future conforming authority object.

70. Authority Chain#

An Authority Chain is the verifiable sequence of grants and delegations explaining why a Subject possesses the authority required for an action.

Example:

Trust Anchor
    ↓
Issuer Authorization
    ↓
Organization A
    ↓
Delegation
    ↓
Agent A

Every relevant edge must remain valid.

71. Trust Anchor#

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

Catenor does not claim that cryptography creates initial trust from nothing.

Trust Anchors are established through an Admission process.

72. Initial Trust Anchor#

An Initial Trust Anchor is a Trust Anchor admitted at the establishment or bootstrap of a Trust Domain.

The informal term Genesis may be used in explanatory material, but normative specifications SHOULD use Initial Trust Anchor or Trust Anchor Admission.

73. Trust Anchor Admission#

Trust Anchor Admission is the process by which a candidate Subject becomes an accepted Trust Anchor.

Conceptually:

candidate
   ↓
external evidence
   ↓
admission policy
   ↓
verification
   ↓
proof of key possession
   ↓
admission decision

74. Admission Policy#

An Admission Policy defines the verified conditions a candidate must satisfy to become a Trust Anchor or obtain another admission-controlled role.

No universal Admission Policy is frozen.

75. Admission Record#

An Admission Record is the auditable output documenting an Admission decision and relevant commitments/references.

The current Trust Anchor Admission Record shape is defined in DATA-MODEL-BASELINE.md.

76. Proof of Key Possession#

Proof of Key Possession is cryptographic evidence that the candidate controls the private key corresponding to a published or proposed Verification Method.

This does not by itself prove legal authority or trustworthiness.

77. Trust Domain#

A Trust Domain is the contextual environment within which Trust Anchors, Issuers, credentials, authority chains, evidence sources, and Policies are accepted.

Catenor does not define one universal global trust list.

Different Trust Domains may make different trust decisions while remaining protocol-conformant.

78. Trust#

Trust is contextual acceptance of an authority, evidence source, credential, or verification process under a Trust Domain's rules.

Catenor distinguishes trust from cryptographic validity.

79. Cryptographic Validity#

Cryptographic Validity means that a cryptographic proof verifies correctly against the required public verification material.

It does not mean the protected claim is true or authorized.

80. Claim Truth#

Claim Truth means that the factual assertion represented by a claim accurately reflects reality.

Catenor does not treat signature validity as sufficient proof of Claim Truth.

81. Policy#

A Policy is a set of conditions governing whether a requested action is permitted under a Trust Domain's identity, authority, credential, and contextual rules.

A Policy consumes verified facts.

82. Policy Evaluation#

Policy Evaluation is the process of evaluating a Policy against verified inputs and context.

Where a Policy is deterministic, the same policy version and verified inputs SHOULD produce the same Decision.

83. Decision#

A Decision is the output of Policy Evaluation.

Minimum authoritative outcomes are:

ALLOW
DENY

Additional outcomes may include:

INDETERMINATE
REQUIRES_REVIEW
ERROR

They MUST NOT silently become ALLOW.

84. Policy Decision#

A Policy Decision states whether an action is authorized under Catenor identity, authority, and policy semantics.

It is not equivalent to execution-layer authorization.

85. Execution Authorization#

Execution Authorization is the separate technical authorization determining whether a specific key, account, wallet, or execution system may perform an operation.

Canonical distinction:

Policy Decision
!=
Execution Authorization

86. Confidential Verification Environment (CVE)#

A Confidential Verification Environment is an execution environment or protocol mechanism used to evaluate sensitive inputs while limiting unnecessary disclosure.

A CVE must provide security properties appropriate to its threat model, such as:

input confidentiality
execution integrity
secret isolation
controlled output
data minimization

Catenor does not mandate one implementation technology.

87. Confidential Computing#

Confidential Computing is the technical class of mechanisms used to protect data during processing.

Catenor may be implemented using different mechanisms, including trusted hardware, cryptographic multi-party techniques, zero-knowledge systems, or hybrid approaches.

88. Data Minimization#

Data Minimization is the principle of disclosing only the information necessary for a specific verification or Policy.

Canonical principle:

Private evidence in. Minimum necessary verifiable fact out.

89. Minimized Result#

A Minimized Result is a derived fact or Decision that reveals less information than the underlying evidence.

Example:

AGE_OVER_THRESHOLD = true

rather than revealing exact date of birth.

90. Operational Database#

An Operational Database is mutable/queryable implementation storage used to index protocol state and support application operations.

It is not itself cryptographic authority.

Canonical principle:

database
= locate/query

signed proof
= prove authorship/integrity

authority chain
= prove authorization

91. Index#

An Index is an operational projection that allows efficient lookup of relationships, credentials, capabilities, Subjects, or other data.

An Index MUST NOT silently replace underlying proofs in security-critical decisions.

92. Status Layer#

The Status Layer is the conceptual component exposing current or historical lifecycle status for credentials, bindings, keys, delegations, or related objects.

The exact technical architecture is not frozen.

93. Audit Event#

An Audit Event is a security-relevant lifecycle event recorded for later inspection or historical verification.

Examples include:

SUBJECT_CREATED
ACCOUNT_BOUND
KEY_REVOKED
CREDENTIAL_ISSUED
CREDENTIAL_REVOKED
DELEGATION_CREATED
POLICY_EVALUATED
TRUST_ANCHOR_ADMITTED

The final event vocabulary is not frozen.

94. Audit Log#

An Audit Log is the ordered or append-oriented collection of Audit Events.

The persistence/anchoring mechanism is not yet frozen.

95. Commitment#

A Commitment is a cryptographic representation that can later be used to demonstrate consistency or bind a record to underlying data without necessarily publishing that data.

The exact commitment mechanisms are not yet frozen.

96. Evidence Commitment#

An Evidence Commitment is a Commitment to private evidence used in a verification, Admission, or Decision.

It allows an audit trail to reference evidence without publishing the evidence itself.

97. Historical Verification#

Historical Verification is the process of determining whether credentials, keys, Issuers, Delegations, or Policies were valid at a specific historical point in time.

Examples:

Was key K active at time T?
Was credential C revoked before time T?
Was Issuer I authorized at time T?
Which Policy version applied?

98. Key Rotation#

Key Rotation is the process of replacing an active Verification Method or key with another while preserving the Canonical Subject.

Key rotation MUST NOT silently create a new Subject.

99. Key Revocation#

Key Revocation is the lifecycle action marking a Verification Method or key as no longer authorized for future use.

Historical verification may still need to establish that the key was valid earlier.

100. Profile#

A Profile is a named set of Catenor requirements applicable to a specific class of implementation or security context.

Draft profile concepts include:

Core
Authority
Confidential Verification
Financial Security
Historical Verification

101. Financial Security Profile#

The Financial Security Profile is the Catenor profile applying stronger requirements to regulated, high-value, treasury, or financial execution contexts.

A key rule is:

Credential Assertion private key
!=
Financial Execution private key

102. Conformance Target#

A Conformance Target is a protocol role for which an implementation claims conformance.

Examples include:

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

103. Reference Implementation#

A Reference Implementation is an implementation demonstrating one way to satisfy Catenor requirements.

It does not define the protocol.

If reference implementation behavior conflicts with normative specification text:

The normative specification takes precedence.

104. Normative#

Normative text defines requirements required for conformance.

Normative requirement terms appear using BCP 14 keywords such as:

MUST
MUST NOT
SHOULD
SHOULD NOT
MAY

105. Informative#

Informative text explains, illustrates, motivates, or provides examples.

Informative material does not override normative requirements.

106. Frozen Decision#

A Frozen Decision is a protocol semantic decision explicitly approved in CANONICAL-DECISIONS.md.

A documentation or implementation agent MUST NOT silently reopen a Frozen Decision.

107. Draft Shape#

A Draft Shape is the current approved working JSON/object representation preserved in DATA-MODEL-BASELINE.md.

It may be refined through review but MUST NOT be silently replaced.

108. Open Wire Format#

An Open Wire Format is a concept whose semantics are approved but whose final normative JSON/wire representation is not yet frozen.

An agent MUST NOT invent a final normative shape for an Open Wire Format without explicit review.

109. Canonical terminology rules#

Catenor specifications SHOULD use the following canonical terms.

Use:

Canonical Subject
Account Binding
Verification Method
Credential Assertion Key
Financial Execution Key
Subject Continuity
Identity Verification Provider
Canonical Subject Registry
Credential Vault
Identity Vault
Issuer Authority
Authorize-Issuer Capability
Relationship
Capability
Delegation
Authority Chain
Trust Anchor
Trust Anchor Admission
Trust Domain
Policy
Decision
Confidential Verification Environment
Operational Database
Historical Verification

Avoid ambiguous replacements such as:

user identity
master wallet
root wallet
permission flag
magic issuer
admin authority
central identity
database truth

unless a detailed document explicitly defines them.

110. Canonical shorthand#

The following shorthand is permitted in informative text:

DID
VC
VP
CVE
PII

Normative documents SHOULD define the full term on first use.

111. Informal term: Genesis#

Genesis MAY be used in educational or implementation material to describe the establishment of the first Trust Anchor.

Normative protocol documents SHOULD prefer:

Initial Trust Anchor
Trust Anchor Admission

This prevents the protocol from depending on blockchain-specific "genesis" semantics.

112. Final terminology principle#

Catenor terminology exists to preserve separation of concerns: identity identifies the Subject; credentials express claims; authority explains power; delegation transfers bounded power; policy evaluates verified context; execution remains separately controlled.