Catenor Protocol#

Data Model Baseline — Draft v0.1#

Purpose: Preserve the canonical data structures, JSON shapes, field semantics, and unresolved wire-format decisions already established during the design of Catenor Protocol.

This document MUST be read together with CANONICAL-DECISIONS.md.

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

0. Precedence and intent#

Catenor uses two complementary sources of truth:

CANONICAL-DECISIONS.md
= semantic source of truth

DATA-MODEL-BASELINE.md
= data-shape / object-model source of truth

If an implementation or documentation agent needs to define a protocol object:

1. check Canonical Decisions
2. check this Data Model Baseline
3. check the detailed specification for that object
4. do not invent a conflicting shape

If this document marks a wire format as OPEN, an agent MUST NOT silently finalize it.

If this document marks a shape as DRAFT, an agent MAY refine it only through explicit review.

If this document marks a field or invariant as FROZEN, dependent documents MUST preserve it.

1. Status legend#

Each object or property is classified using the following vocabulary.

FROZEN SEMANTICS#

The meaning is approved.

The exact wire representation may still evolve unless separately frozen.

DRAFT SHAPE#

The current object shape is the canonical working shape.

It may be refined, but MUST NOT be silently replaced with a different vocabulary.

OPEN WIRE FORMAT#

The concept is approved, but no final JSON/wire structure has been approved.

IMPLEMENTATION RECORD#

Useful operational data, but not itself a normative Catenor protocol object.

INFORMATIVE EXAMPLE#

Illustrates semantics without freezing the complete schema.

2. Global naming rules#

Canonical Catenor Subject identifiers use:

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

Generic examples in this document use:

did:catenor:human-a
did:catenor:organization-a
did:catenor:organization-b
did:catenor:agent-a
did:catenor:trust-anchor-a

These human-readable suffixes are examples only.

Production identifiers MUST remain opaque and high entropy.

Assets/resources use placeholders such as:

asset:resource-a

The final asset-identifier specification is outside Draft v0.1.

3. Object inventory#

4. DID Document#

Status: DRAFT SHAPE

Catenor adopts the W3C DID Document model.

Current baseline:

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

4.1 id#

"id": "did:catenor:organization-a"

Status: FROZEN SEMANTICS

Meaning:

The canonical DID described by this DID Document.

Requirements:

MUST be a valid did:catenor identifier
MUST identify the canonical Subject
MUST NOT encode PII
MUST NOT embed implementer/provider/tenant identity

4.2 verificationMethod#

"verificationMethod": [...]

Status: FROZEN SEMANTICS

Contains public verification methods associated with the DID.

A verification method is not a separate Subject.

4.3 verificationMethod[].id#

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

Status: FROZEN SEMANTICS

This is a DID URL:

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

The fragment identifies one verification method within the DID Document.

4.4 controller#

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

Status: FROZEN SEMANTICS

Identifies the DID controlling that verification method.

It MUST NOT be interpreted automatically as:

financial wallet
legal owner
database administrator
execution account

4.5 type#

"type": "Multikey"

Status: DRAFT SHAPE

Current working representation uses Multikey.

The final Catenor Crypto Profile MUST determine the supported verification-method types and key suites.

4.6 publicKeyMultibase#

"publicKeyMultibase": "z6Mk..."

Status: DRAFT SHAPE

Contains public verification material.

The corresponding private key MUST remain private.

The exact key family and encoding are part of the future Crypto Profile.

4.7 assertionMethod#

"assertionMethod": [
  "did:catenor:organization-a#assertion-key-1"
]

Status: FROZEN SEMANTICS

Identifies verification methods authorized to make assertions on behalf of the DID.

Credential issuance is an assertion use case.

4.8 Financial accounts MUST NOT appear merely because they are bound to the Subject#

Frozen invariant:

DID verification method
!=
private financial Account Binding

The DID Document MUST NOT automatically publish the Subject's financial execution account.

5. DID Resolution Result#

Status: DRAFT SHAPE

Current minimal working envelope:

{
  "didDocument": {
    "id": "did:catenor:organization-a",
    "verificationMethod": [],
    "assertionMethod": []
  }
}

This object is intentionally incomplete.

The detailed DID Method specification MUST later define:

resolution metadata
document metadata
deactivation semantics
version semantics
error representation
historical resolution behavior

Agents MUST NOT freeze those fields yet.

6. Canonical Subject Record#

Status: OPEN WIRE FORMAT

The canonical Subject concept is frozen, but no final public JSON record has been approved.

Frozen semantics:

Subject has a canonical did:catenor identifier
Subject type is HUMAN, ORGANIZATION, or AGENT
Subject lifecycle exists
Subject may have verification methods
Subject may have multiple Account Bindings
Subject may have Credentials

Agents MUST NOT invent a normative Subject JSON object before SUBJECTS.md is reviewed.

An implementation MAY maintain a private/internal Subject record.

That internal record is not automatically a protocol wire object.

7. Account Binding#

Status: DRAFT SHAPE

Current canonical working shape:

{
  "id": "binding:01",
  "subject": "did:catenor:human-a",
  "account": {
    "namespace": "<account-namespace>",
    "reference": "<network-or-system-reference>",
    "address": "<external-account-identifier>"
  },
  "purpose": [
    "financial-execution"
  ],
  "status": "ACTIVE"
}

7.1 id#

Status: DRAFT SHAPE

Identifier for the Account Binding object.

Final identifier format is not frozen.

7.2 subject#

"subject": "did:catenor:human-a"

Status: FROZEN SEMANTICS

The canonical Catenor Subject to which the external account is bound.

7.3 account#

"account": {
  "namespace": "<account-namespace>",
  "reference": "<network-or-system-reference>",
  "address": "<external-account-identifier>"
}

Status: DRAFT SHAPE

Identifies the external account.

Exact namespace/reference conventions are not yet frozen.

The account may refer to:

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

7.4 purpose#

"purpose": [
  "financial-execution"
]

Status: DRAFT SHAPE

Describes the intended purpose of the binding.

Previously discussed purposes include conceptually:

authentication
execution
financial-execution

The canonical vocabulary is not frozen.

7.5 status#

"status": "ACTIVE"

Status: FROZEN SEMANTICS, DRAFT VOCABULARY

The binding has lifecycle state.

Expected states may include:

ACTIVE
SUSPENDED
REVOKED
EXPIRED

Final vocabulary will be defined in the Account Binding specification.

7.6 Privacy invariant#

The complete mapping:

did:catenor:human-a
↔
external account identifier

is private by default.

The account identifier may be public in its native execution environment.

The Catenor correlation is not public by default.

8. Account Control Proof#

Status: OPEN WIRE FORMAT

Frozen conceptual flow:

random challenge
      ↓
external account signs
      ↓
signature is verified
      ↓
Account Binding is established

A minimized policy fact may be:

ACCOUNT_CONTROL_VALID = true

No final JSON proof object has been approved.

Agents MUST NOT silently define one as normative.

9. Provider / External Identity Binding#

Status: DRAFT SHAPE — PRIVATE OPERATIONAL STATE

Catenor separates provider-specific identities from the canonical Subject.

Working private representation:

{
  "subject": "did:catenor:human-a",
  "provider": "<provider-type-or-adapter-id>",
  "externalSubjectId": "<provider-specific-subject-reference>",
  "status": "ACTIVE"
}

This object is NOT intended to be public.

9.1 subject#

Canonical Catenor Subject.

9.2 provider#

Identifies the provider/adapter context.

The final identifier convention is not frozen.

9.3 externalSubjectId#

Private provider-specific subject reference.

It MUST NOT become the Catenor DID.

9.4 status#

Lifecycle state of the provider mapping.

Exact vocabulary is not frozen.

10. Canonical Subject Registry relationship#

Status: FROZEN SEMANTICS

Private conceptual model:

did:catenor:human-a
        │
        ├── provider reference A
        ├── provider reference B
        ├── authentication reference
        └── private Account Bindings

No public wire object is frozen.

11. Verifiable Credential — general envelope#

Status: DRAFT SHAPE

Catenor builds on the W3C Verifiable Credentials model.

Working shape:

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "<catenor-context-uri>"
  ],
  "id": "urn:uuid:<credential-id>",
  "type": [
    "VerifiableCredential",
    "<CatenorCredentialType>"
  ],
  "issuer": "did:catenor:organization-a",
  "validFrom": "2026-09-08T00:00:00Z",
  "validUntil": "2027-09-08T00:00:00Z",
  "credentialSubject": {
    "id": "did:catenor:human-a"
  },
  "credentialStatus": {
    "...": "status mechanism not yet frozen"
  },
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "<open>",
    "created": "2026-09-08T00:00:00Z",
    "verificationMethod": "did:catenor:organization-a#assertion-key-1",
    "proofPurpose": "assertionMethod",
    "proofValue": "<signature>"
  }
}

11.1 @context#

Status: DRAFT SHAPE

Uses the W3C VC context plus a future Catenor context.

The Catenor context URI is not frozen.

11.2 id#

Status: DRAFT SHAPE

Credential identifier.

Exact identifier format is not frozen.

11.3 type#

Status: FROZEN SEMANTICS

Must identify the object as a Verifiable Credential and may identify a Catenor credential subtype.

The canonical Catenor credential-type vocabulary remains open.

11.4 issuer#

"issuer": "did:catenor:organization-a"

Status: FROZEN SEMANTICS

Identifies the Subject that issued the credential.

The issuer MUST possess valid issuer authority for the credential type and scope when required by the applicable Trust Domain.

11.5 validFrom#

Status: DRAFT SHAPE

Beginning of intended validity.

11.6 validUntil#

Status: DRAFT SHAPE

End of intended validity when applicable.

11.7 credentialSubject#

Status: FROZEN SEMANTICS

Contains the Subject and claims being asserted.

At minimum, the Subject identity is represented through:

{
  "id": "did:catenor:human-a"
}

11.8 credentialStatus#

Status: OPEN WIRE FORMAT

Credential lifecycle/status semantics are required.

The exact technical status mechanism is not frozen.

11.9 proof#

Status: DRAFT SHAPE

Represents the credential's cryptographic proof.

Frozen semantics:

proof references an authorized verification method
proof purpose must be appropriate
signature protects credential content

Open:

exact cryptosuite
exact canonicalization
exact proof suite
supported key types

12. What the VC proof means#

Status: FROZEN SEMANTICS

A valid proof establishes:

authorship
+
integrity

It does NOT by itself establish:

truth
issuer trust
issuer authority
credential status
scope validity
policy acceptance

13. Relationship object#

Status: DRAFT SHAPE

Current embedded relationship representation:

{
  "type": "OFFICER_OF",
  "object": "did:catenor:organization-b"
}

When embedded under a credentialSubject:

{
  "credentialSubject": {
    "id": "did:catenor:human-a",
    "relationship": {
      "type": "OFFICER_OF",
      "object": "did:catenor:organization-b"
    }
  }
}

Conceptual model:

subject
predicate
object

Here:

subject   = credentialSubject.id
predicate = relationship.type
object    = relationship.object

14. Relationship Credential#

Status: DRAFT SHAPE

Working example:

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "<catenor-context-uri>"
  ],
  "id": "urn:uuid:<credential-id>",
  "type": [
    "VerifiableCredential",
    "CatenorRelationshipCredential"
  ],
  "issuer": "did:catenor:organization-a",
  "validFrom": "2026-09-08T00:00:00Z",
  "validUntil": "2027-09-08T00:00:00Z",
  "credentialSubject": {
    "id": "did:catenor:human-a",
    "relationship": {
      "type": "OFFICER_OF",
      "object": "did:catenor:organization-b"
    }
  },
  "credentialStatus": {
    "...": "open"
  },
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "<open>",
    "verificationMethod": "did:catenor:organization-a#assertion-key-1",
    "proofPurpose": "assertionMethod",
    "proofValue": "<signature>"
  }
}

Frozen invariant:

A Relationship Credential proves a relationship claim; the relationship does not automatically grant unrestricted capabilities.

15. Capability#

Status: DRAFT SHAPE

Recovered working shape:

{
  "subject": "did:catenor:human-a",
  "action": "CREATE_DISTRIBUTION",
  "resource": "did:catenor:organization-b",
  "constraints": {
    "maxAmount": 100000,
    "currency": "USD",
    "validUntil": "2027-01-01T00:00:00Z"
  }
}

15.1 subject#

Status: FROZEN SEMANTICS

Subject receiving/holding the capability.

When a Capability is embedded in a VC, the Subject MAY be inherited from credentialSubject.id rather than duplicated.

The final embedding rule is not frozen.

15.2 action#

"action": "CREATE_DISTRIBUTION"

Status: FROZEN SEMANTICS, OPEN VOCABULARY

Names the authorized action.

The initial canonical action vocabulary is not frozen.

15.3 resource#

"resource": "did:catenor:organization-b"

Status: FROZEN SEMANTICS

Identifies the resource/context against which the action is authorized.

A resource may be a Subject or external resource identifier depending on the capability.

15.4 constraints#

Status: FROZEN SEMANTICS, DRAFT SHAPE

Contains restrictions on the authority.

Previously established constraint concepts include:

maxAmount
currency
validUntil
jurisdiction
allowed function/action
allowed execution target
delegation depth

The final constraint schema is open.

16. Relationship vs Capability#

Status: FROZEN SEMANTICS

Example relationship:

Human A OFFICER_OF Organization B

does NOT automatically imply:

CREATE_DISTRIBUTION
MOVE_FUNDS
ISSUE_CREDENTIAL
AUTHORIZE_ISSUER

Capabilities must be explicit or explicitly derived by an applicable policy.

17. Capability embedded in a Credential#

Status: DRAFT SHAPE

Current working model:

{
  "credentialSubject": {
    "id": "did:catenor:human-a",
    "capabilities": [
      {
        "action": "CREATE_DISTRIBUTION",
        "resource": "did:catenor:organization-b",
        "constraints": {
          "maxAmount": 100000,
          "currency": "USD"
        }
      }
    ]
  }
}

The final choice between:

capability

and:

capabilities[]

for all credential types is not frozen.

Do not silently standardize it before the Capability specification is reviewed.

18. Delegation Credential#

Status: DRAFT SHAPE

Recovered semantic model:

issuer
→ delegator

credentialSubject.id
→ delegate

resource
→ authority target

actions
→ delegated actions

constraints
→ delegated limits

Current working JSON shape:

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "<catenor-context-uri>"
  ],
  "id": "urn:uuid:<delegation-id>",
  "type": [
    "VerifiableCredential",
    "CatenorDelegationCredential"
  ],
  "issuer": "did:catenor:organization-a",
  "validFrom": "2026-09-08T00:00:00Z",
  "validUntil": "2027-09-08T00:00:00Z",
  "credentialSubject": {
    "id": "did:catenor:agent-a",
    "delegation": {
      "resource": "did:catenor:organization-b",
      "actions": [
        "CREATE_DISTRIBUTION",
        "REQUEST_EXECUTION"
      ],
      "constraints": {
        "maxAmount": 100000
      }
    }
  },
  "credentialStatus": {
    "...": "open"
  },
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "<open>",
    "verificationMethod": "did:catenor:organization-a#assertion-key-1",
    "proofPurpose": "assertionMethod",
    "proofValue": "<signature>"
  }
}

Frozen invariants:

delegated authority ⊆ delegator authority
delegability must be explicit
delegation is revocable/lifecycle-aware
delegate has its own canonical identity

The exact final Delegation Credential schema remains under review.

19. Issuer Authorization Credential#

Status: DRAFT SHAPE

Issuer authority is explicit and capability-based.

Current working example:

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "<catenor-context-uri>"
  ],
  "id": "urn:uuid:<issuer-authorization-id>",
  "type": [
    "VerifiableCredential",
    "CatenorIssuerAuthorizationCredential"
  ],
  "issuer": "did:catenor:trust-anchor-a",
  "credentialSubject": {
    "id": "did:catenor:organization-a",
    "capability": {
      "action": "ISSUE_CREDENTIAL",
      "credentialTypes": [
        "CredentialTypeA"
      ],
      "constraints": {
        "jurisdiction": [
          "US"
        ]
      }
    }
  },
  "validFrom": "2026-09-08T00:00:00Z",
  "validUntil": "2027-09-08T00:00:00Z",
  "credentialStatus": {
    "...": "open"
  },
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "<open>",
    "verificationMethod": "did:catenor:trust-anchor-a#assertion-key-1",
    "proofPurpose": "assertionMethod",
    "proofValue": "<signature>"
  }
}

20. Issuer-delegation capability#

Status: FROZEN SEMANTICS, DRAFT SHAPE

ISSUE_CREDENTIAL and AUTHORIZE_ISSUER are distinct.

Working representation:

{
  "action": "AUTHORIZE_ISSUER",
  "credentialTypes": [
    "CredentialTypeA"
  ],
  "constraints": {
    "jurisdiction": [
      "US"
    ]
  }
}

Frozen rule:

Subject allowed to ISSUE_CREDENTIAL
does not automatically have
AUTHORIZE_ISSUER

Issuer authorization may be hierarchical only when this delegation/authorization authority exists.

21. Verifiable Presentation#

Status: OPEN CATENOR-SPECIFIC PROFILE

Frozen semantics:

VC
= reusable signed claim

VP
= contextual minimum proof package for a verifier/action

Catenor builds on W3C Verifiable Presentation semantics.

A generic informative envelope may look like:

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2"
  ],
  "type": [
    "VerifiablePresentation"
  ],
  "holder": "did:catenor:human-a",
  "verifiableCredential": [
    "<credential-or-derived-proof>"
  ]
}

This example MUST NOT be treated as the final Catenor VP schema.

Open:

holder binding rules
challenge/domain rules
selective disclosure mechanism
derived-proof formats
presentation proof requirements

22. Credential Status#

Status: OPEN WIRE FORMAT

Lifecycle semantics are frozen.

Expected conceptual states include:

ACTIVE
SUSPENDED
REVOKED
EXPIRED
SUPERSEDED

An inability to determine status MUST NOT silently become ACTIVE.

Current VC envelope reserves:

"credentialStatus": {
  "...": "status mechanism not yet frozen"
}

Agents MUST NOT invent a normative status-list mechanism until it is explicitly approved.

23. Trust Anchor Admission Record#

Status: DRAFT SHAPE

Working shape:

{
  "type": "CatenorTrustAnchorAdmissionRecord",
  "trustAnchor": "did:catenor:trust-anchor-a",
  "admissionPolicy": "policy:trust-anchor-admission:v1",
  "policyHash": "0x...",
  "decision": "ADMIT_TRUST_ANCHOR",
  "verificationMethod": "did:catenor:trust-anchor-a#assertion-key-1",
  "evidenceCommitment": "0x...",
  "createdAt": "2026-09-08T00:00:00Z",
  "decisionRef": "decision:admission:001"
}

23.1 type#

Identifies the record type.

Final naming is draft.

23.2 trustAnchor#

Candidate/admitted Trust Anchor DID.

23.3 admissionPolicy#

Policy identifier used during admission.

23.4 policyHash#

Commitment to the exact policy version evaluated.

Exact hash representation is not frozen.

23.5 decision#

Working positive value:

ADMIT_TRUST_ANCHOR

Final admission-decision vocabulary is not frozen.

23.6 verificationMethod#

Verification method whose possession/control was established during admission.

23.7 evidenceCommitment#

Commitment to evidence used during admission without publishing the sensitive evidence.

Exact commitment mechanism is open.

23.8 createdAt#

Admission decision time.

23.9 decisionRef#

Reference to the detailed Decision object / audit record.

Identifier format is open.

24. Trust Anchor admission is not self-certification#

Status: FROZEN SEMANTICS

Invalid:

Subject signs:
"I am a Trust Anchor"

and treats that signature alone as sufficient admission.

Required conceptually:

external evidence
+
admission policy
+
verification
+
proof of key possession
+
configured trust/governance
        ↓
Admission Record

25. Policy#

Status: DRAFT SHAPE

Current minimal working object:

{
  "id": "policy:investment:v1",
  "action": "INVEST",
  "requirements": [
    {
      "claim": "KYC_VERIFIED"
    },
    {
      "claim": "AML_CLEAR"
    }
  ]
}

25.1 id#

Policy identifier/version.

Final identifier scheme is open.

25.2 action#

Action being evaluated.

Action vocabulary is open.

25.3 requirements#

Verified conditions required by the policy.

The full expression language is open.

26. Policy semantics#

Status: FROZEN SEMANTICS

Policy consumes verified facts and context.

A security-critical Policy MUST NOT rely on mutable unsigned application state as though it were verified protocol evidence.

The final:

JSON schema
DSL
expression language
policy execution engine

remain open.

27. Decision#

Status: DRAFT SHAPE

Current working object:

{
  "policy": "policy:investment:v1",
  "subject": "did:catenor:human-a",
  "action": "INVEST",
  "resource": "asset:resource-a",
  "decision": "ALLOW",
  "evaluatedAt": "2026-09-08T00:00:00Z",
  "evidenceCommitment": "0x..."
}

27.1 policy#

Policy/version evaluated.

27.2 subject#

Canonical Subject whose action/context was evaluated.

27.3 action#

Requested action.

27.4 resource#

Target/resource of the requested action when applicable.

27.5 decision#

Minimum authoritative outcomes:

ALLOW
DENY

Optional states may include:

INDETERMINATE
REQUIRES_REVIEW
ERROR

These MUST NOT silently become ALLOW.

27.6 evaluatedAt#

Evaluation timestamp.

27.7 evidenceCommitment#

Optional/minimized commitment to the evidence/proof set used.

Exact commitment mechanism is open.

28. Decision != execution authorization#

Status: FROZEN SEMANTICS

A Catenor Decision answers:

Should this action be authorized under the applicable identity,
authority, credential, and policy semantics?

It does not automatically mean:

the execution key is technically allowed to execute a transaction

Execution authorization is a separate layer.

29. Audit Event#

Status: DRAFT SHAPE

Recovered working event shape:

{
  "type": "CREDENTIAL_ISSUED",
  "subject": "did:catenor:human-a",
  "issuer": "did:catenor:organization-a",
  "credentialId": "urn:uuid:<credential-id>",
  "timestamp": "2026-09-08T00:00:00Z",
  "requestId": "request:001"
}

29.1 type#

Event type.

Initial conceptual event vocabulary includes:

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

Final canonical vocabulary is not frozen.

29.2 subject#

Primary Subject affected by the event when applicable.

29.3 issuer#

Issuer/actor relevant to the event when applicable.

Not every event will use this field.

29.4 credentialId#

Credential reference when applicable.

29.5 timestamp#

Event time.

29.6 requestId#

Correlation identifier for the triggering operation/request.

Final identifier shape is open.

30. Audit persistence#

Status: OPEN WIRE / STORAGE MODEL

Frozen semantics:

security-relevant lifecycle changes are append-oriented
historical verification may require authoritative history

Open:

database representation
Merkle-log representation
shared-state anchoring
hash chaining
event signature format

31. Conformance Statement#

Status: DRAFT SHAPE

Current working object from the Conformance specification:

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

31.1 protocol#

Must identify Catenor.

31.2 version#

Protocol version against which conformance is claimed.

31.3 implementation#

Human-readable implementation identifier/name.

It does not imply certification.

31.4 conformanceTargets#

Declared protocol roles implemented.

31.5 profiles#

Declared Catenor profiles supported.

31.6 didMethods#

DID methods supported by the implementation.

31.7 cryptoProfiles#

Cryptographic profiles supported.

catenor-crypto-v1 is a placeholder until the Crypto Profile is frozen.

31.8 status#

Implementation maturity.

Working values:

experimental
beta
production
deprecated

This field is informational, not proof of security.

32. Key Management Reference#

Status: IMPLEMENTATION RECORD

This is not a public protocol credential.

It is an implementation-neutral operational record linking a DID verification method to protected signing infrastructure.

Working shape:

{
  "subject": "did:catenor:organization-a",
  "verificationMethod": "did:catenor:organization-a#assertion-key-1",
  "signerRef": "<secure-key-management-reference>",
  "purpose": "CREDENTIAL_ASSERTION",
  "status": "ACTIVE"
}

Frozen invariant:

The private key itself MUST NOT be stored in this operational record.

signerRef is an opaque handle to a Secure Key Management System.

33. Relationship Index Row#

Status: IMPLEMENTATION RECORD

Operational query/index model:

{
  "subject": "did:catenor:human-a",
  "predicate": "OFFICER_OF",
  "object": "did:catenor:organization-b",
  "credentialId": "urn:uuid:<credential-id>",
  "status": "ACTIVE"
}

This row is not cryptographic proof.

Frozen model:

Operational Database
        ↓ locates
credentialId
        ↓
Credential Vault / proof material
        ↓
cryptographic verification
        ↓
authority verification

34. Capability Index Row#

Status: IMPLEMENTATION RECORD

No canonical row shape is frozen.

An implementation MAY index capabilities for query performance.

Any security-critical use MUST resolve the underlying authority proof.

Do not treat the index row as the source of authority.

35. Confidential Verification Result#

Status: OPEN WIRE FORMAT

Frozen conceptual examples:

KYC_VALID = true
AGE_OVER_THRESHOLD = true
SAME_SUBJECT = true
AUTHORITY_VALID = true
ACCOUNT_CONTROL_VALID = true
ALLOW
DENY

Catenor's principle is:

Private evidence in. Minimum necessary verifiable fact out.

No universal JSON envelope for confidential-verification results has yet been approved.

The Decision object may consume or reference such results.

36. Subject Continuity Result#

Status: OPEN WIRE FORMAT

Frozen outcomes conceptually include:

SAME_SUBJECT
NEW_SUBJECT
INDETERMINATE
REQUIRES_REVIEW

Exact vocabulary and confidence representation are not frozen.

Inputs used for matching remain private.

The result MUST NOT expose unnecessary identity attributes.

37. Credential lifecycle vocabulary#

Status: DRAFT VOCABULARY

Previously established states:

ACTIVE
SUSPENDED
REVOKED
EXPIRED
SUPERSEDED

Detailed credential-status specification may refine these states.

UNKNOWN is also used at verification time to represent unavailable/undetermined status and MUST NOT be interpreted as ACTIVE.

38. Account Binding lifecycle vocabulary#

Status: DRAFT VOCABULARY

Current conceptual states:

ACTIVE
SUSPENDED
REVOKED
EXPIRED

Exact lifecycle semantics remain to be specified.

39. Trust Domain#

Status: OPEN WIRE FORMAT

Frozen semantics:

A Trust Domain defines the contextual trust/policy environment in which:

Trust Anchors
Issuers
credential types
evidence sources
authority chains
policies

are accepted/evaluated.

Catenor MUST NOT define a universal global Issuer whitelist.

No canonical Trust Domain JSON object is currently approved.

40. Public/private storage classification#

Status: FROZEN BASELINE

41. Key-purpose data model invariant#

Status: FROZEN

Never model this:

one private key
→ credential issuance
→ identity authentication
→ delegation
→ financial execution

as the implicit Catenor default.

The protocol recognizes distinct purposes.

Under the Financial Security Profile:

Credential Assertion private key
!=
Financial Execution private key

42. Private Account Binding invariant#

Status: FROZEN

Public DID state:

did:catenor:human-a
        ↓
public verification method

Private binding state:

did:catenor:human-a
        ↓
external financial account

These MUST NOT be conflated.

The fact that an external account may itself be public does not make the Catenor Subject ↔ account correlation public.

43. Issuer model invariant#

Status: FROZEN

Issuer is:

a Catenor Subject
+
valid authority to issue a specific credential type
+
scope
+
lifecycle validity

Issuer is not:

a global boolean
a hardcoded platform role
a credential itself

An Issuer Authorization Credential is evidence of authority.

44. Hierarchical Issuer model invariant#

Status: FROZEN

Valid:

Trust Anchor
      ↓ grants AUTHORIZE_ISSUER
Subject A
      ↓ authorizes
Subject B
      ↓ issues
Credential Type A

only when every edge is authorized.

Not valid:

Subject A has only ISSUE_CREDENTIAL
      ↓
Subject A authorizes Subject B

unless Subject A also has explicit authority to authorize issuers.

45. Delegation invariant#

Status: FROZEN

For every delegation:

delegated authority
⊆
delegator authority

Delegation MUST NOT create net-new authority.

46. Relationship invariant#

Status: FROZEN

A Relationship object describes:

connection

not:

permission

Permission belongs to Capability / Policy semantics.

47. Signature invariant#

Status: FROZEN

This:

Verify(publicKey, credential, proof) = true

means:

credential integrity valid
+
proof produced by corresponding private key

It does not mean:

claim is true
issuer was authorized
credential remains active
policy should accept it

48. Data model mapping to future JSON Schemas#

When object shapes are approved, this baseline should map to machine-readable schemas.

Planned schemas include:

schemas/
├── account-binding.schema.json
├── relationship.schema.json
├── capability.schema.json
├── delegation.schema.json
├── issuer-authorization.schema.json
├── policy.schema.json
├── decision.schema.json
├── audit-event.schema.json
└── conformance-statement.schema.json

Additional VC/VP schemas must remain compatible with the underlying W3C data model.

Do not generate schemas for OPEN WIRE FORMAT objects as if they were final.

49. Objects explicitly NOT frozen yet#

The following concepts MUST NOT acquire a canonical JSON shape without review:

Canonical Subject public record
final DID Resolution metadata envelope
Account Control Proof
Verifiable Presentation Catenor profile
Credential Status mechanism
Trust Domain object
Subject Continuity result envelope
Confidential Verification result envelope
final Delegation representation
final Capability constraint grammar
final Policy language
final Audit persistence/event-proof format
final Crypto Profile

50. Documentation-agent requirements#

Any documentation or implementation agent working on Catenor MUST follow this procedure.

Before defining a JSON object:

1. Find the object in this baseline.
2. Check its status.
3. Preserve frozen field names and semantics.
4. If DRAFT, refine only with explicit justification.
5. If OPEN, do not invent a normative final shape.
6. If a new field is required, identify it as a proposed amendment.
7. Never replace an established vocabulary merely for implementation convenience.

Example:

If the baseline uses:

{
  "subject": "...",
  "action": "...",
  "resource": "...",
  "constraints": {}
}

an agent MUST NOT silently replace it with:

{
  "user": "...",
  "permission": "...",
  "target": "..."
}

51. Reference-implementation separation#

Core protocol objects MUST remain implementation-neutral.

Implementation-specific identifiers, infrastructure handles, provider-specific fields, and deployment configuration belong in:

reference implementation
or
private implementation records

not in normative Catenor objects unless the protocol explicitly standardizes them.

52. Canonical data-flow summary#

53. Canonical object relationships#

Canonical Subject
    │
    ├── DID Document
    │      └── Verification Methods
    │
    ├── Private Account Bindings
    │
    ├── Verifiable Credentials
    │      ├── Relationship Credential
    │      ├── Delegation Credential
    │      └── Issuer Authorization Credential
    │
    ├── Capabilities
    │
    └── Lifecycle / Audit History

Trust Domain
    │
    ├── Trust Anchors
    ├── accepted Issuers
    ├── Policies
    └── verification requirements

Policy
    ↓ consumes
Verified claims + authority + context
    ↓
Decision

Decision
    ≠
Execution authorization

54. Final data-model baseline statement#

Catenor separates public identity-verification state from private account correlation and private evidence. A Subject is identified by did:catenor; its DID Document exposes only appropriate public verification material. External accounts are private-by-default Account Bindings. Verifiable Credentials carry signed claims. Relationships describe connections, Capabilities describe powers, Delegations transfer bounded powers, and Issuer Authorization establishes who may issue which credential types. Policies consume verified facts and authority chains to produce Decisions. Operational databases may index these objects but do not replace their cryptographic proofs.