Extensions define standardized claim types for common use cases. They extend the OpenClaiming Protocol while preserving its core structure and security model.

Overview

Extensions are top-level fields whose values are arrays of OpenClaim objects.

{
  "ocp": 1,
  "payments": [ ... ],
  "actions": [ ... ]
}

Each entry is a nested OpenClaim.

Design Principle

Extensions are not raw data structures. They are:

first-class signed claims with standardized semantics

This means every extension entry:

• can be independently verified
• can use its own signing format (fmt)
• can have its own keys and signatures
• follows the same trust model as the base protocol

Why Extensions Use Nested OpenClaims

Each extension entry is a full OpenClaim to preserve:

1. Uniform security

Every entry supports:

• multisignature (key, sig)
• canonicalization (for ES256)
• time bounds (nbf, exp)
• replay protection (nce)

2. Independent verification

Each extension claim can be extracted, cached, transmitted, and verified on its own.

3. Consistent semantics

4. Multiple formats

Each nested claim defines its own fmt, allowing mixing of ES256 and EIP712 within the same document.

Structure

{
  "ocp": 1,
  "<extension_name>": [
    {
      "ocp": 1,
      "fmt": "...",
      "iss": "...",
      "sub": "...",
      "stm": { ... },
      "key": [ ... ],
      "sig": [ ... ]
    }
  ]
}

Format (fmt)

Each extension claim defines its own signing format.

Supported formats (v1)

Default

If fmt is omitted, "fmt": "ES256" is assumed.

ES256 vs EIP712

ES256 (default)

• Uses RFC 8785 canonical JSON
• Supports full JSON structures: long strings, arbitrary JSON, nested structures
• Suitable for servers, APIs, Qbix communities, off-chain validation

EIP712

• Uses fixed typed structs — no JSON canonicalization
• Limited to basic types: address, uint256, bytes32, bytes, bool
• Used for smart contracts, on-chain verification, gas-efficient execution

Important Constraint

EIP712 claims are not fully extensible. They must map to a predefined schema with fixed struct definitions and type-converted identifiers. Therefore:

Only standardized extensions define EIP712 mappings.

Standard Extensions (v1)

OpenClaiming defines two standard extensions:

Payments Extension

The payments extension defines spending authorizations.

Semantics

A payment claim authorizes a payer (iss), an asset (sub), a set of acceptable recipients, a maximum cumulative amount, and a replay / capacity bucket. It does not define how the payment must be executed.

Example (ES256)

{
  "ocp": 1,
  "payments": [
    {
      "ocp": 1,
      "iss": "community",
      "sub": "token",
      "stm": {
        "recipients": ["alice"],
        "max": "1000000",
        "line": "1"
      },
      "key": ["data:key/es256;base64,..."],
      "sig": ["BASE64_SIGNATURE"]
    }
  ]
}

Example (EIP712)

{
  "ocp": 1,
  "payments": [
    {
      "ocp": 1,
      "fmt": "EIP712",
      "iss": "evm:56:address:0x...",
      "sub": "evm:56:token:0x...",
      "stm": {
        "chainId": "56",
        "verifyingContract": "0x...",
        "recipients": ["evm:56:address:0x..."],
        "max": "3000000",
        "line": "7"
      },
      "key": ["data:key/eip712,evm:56:address:0x..."],
      "sig": ["0x..."]
    }
  ]
}

Notes

• recipients is a set, not a single destination
• execution may choose one or more recipients
• different contracts may interpret the claim differently

Actions Extension

The actions extension defines execution authorizations.

Semantics

An action claim authorizes an authority (iss), a target (sub), a contract call, and execution rules (quorum, fraction, delay). It represents intent to execute, not guaranteed execution.

Execution Model

invoke → endorse → quorum → execute

Execution depends on: signatures, contract roles, quorum rules, and delays.

Example (EIP712)

{
  "ocp": 1,
  "actions": [
    {
      "ocp": 1,
      "fmt": "EIP712",
      "iss": "evm:56:address:0xAuthority",
      "sub": "evm:56:address:0xControl",
      "stm": {
        "chainId": "56",
        "verifyingContract": "0x...",
        "contract": "evm:56:address:0xTarget",
        "method": "a9059cbb",
        "params": "000000...",
        "minimum": "2",
        "fraction": "5000000000",
        "delay": "3600"
      },
      "key": [
        "data:key/eip712,evm:56:address:0xSigner1",
        "data:key/eip712,evm:56:address:0xSigner2"
      ],
      "sig": [
        "0x...",
        "0x..."
      ]
    }
  ]
}

Notes

• actions may not execute immediately
• contracts may impose additional rules
• valid signatures do not guarantee execution

Multisignature

All extensions use the same multisig model:

"key": [ ... ],
"sig": [ ... ]

• each sig[i] corresponds to key[i]
• signatures are validated independently
• duplicates do not count twice
• threshold depends on application or contract

Execution Flexibility

Extensions define authorization, not execution. Execution may be handled by:

• OpenClaiming contract
• Community contracts
• Income contracts
• Governance systems

Different systems may interpret the same claim differently, within its constraints.

Extensibility

New extensions may be defined. However:

• ES256 extensions are fully flexible
• EIP712 extensions must define fixed schemas

Summary

Extensions provide structured, standardized claims while preserving the core OpenClaim model.

• extensions are nested OpenClaims
• each claim defines its own format (fmt)
• ES256 supports full JSON flexibility
• EIP712 supports efficient on-chain execution
• payments and actions are the standard extensions
• execution is determined by the verifying system

OpenClaim = universal signed statement
Extensions = standardized semantics
Formats    = for execution environments