HomeDocumentation

Protocol Examples

Design Philosophyvs Other StandardsProtocol SpecSecurity ModelProtocol ExamplesImplementationsOverviewPaymentsActionsMessagingEVM Blockchains

Practical examples of how OpenClaiming may be used. These examples illustrate common real-world flows.

Example 1 — Domain Identity Claim

A domain may publish claims linking identities.

Claim: example.com claims alice@example.com controls @alice on another platform

json
{
  "ocp": 1,
  "iss": "https://example.com",
  "sub": "alice@example.com",
  "stm": {
    "linked_account": "@alice"
  },
  "key": [
    "data:key/es256;base64,MIIB..."
  ],
  "sig": ["BASE64_SIGNATURE"]
}

Publication: https://example.com/.well-known/openclaim.json

Example 2 — Community Membership

An organization publishes membership records.

Claim: Community X claims Alice is a moderator

json
{
  "ocp": 1,
  "iss": "https://community.example",
  "sub": "https://users.example/alice",
  "stm": {
    "role": "moderator"
  },
  "exp": 1750000000,
  "key": [
    "https://community.example/.well-known/openclaim.json#keys"
  ],
  "sig": ["BASE64_SIGNATURE"]
}

Example 3 — Capability Delegation

A user delegates permission to another user.

Claim: Alice allows Bob to publish to stream Y

json
{
  "ocp": 1,
  "iss": "evm:1:address:0xAlice...",
  "sub": "evm:1:address:0xBob...",
  "stm": {
    "permission": "publish",
    "resource": "streamY"
  },
  "key": [
    "data:key/es256;base64,MIIB..."
  ],
  "sig": ["BASE64_SIGNATURE"]
}

Example 4 — Server Observation

A server signs an observation about a system state.

Claim: Server A claims latest hash of stream Z is H

json
{
  "ocp": 1,
  "iss": "https://serverA.example",
  "stm": {
    "stream": "Z",
    "latest_hash": "H"
  },
  "key": [
    "https://serverA.example/.well-known/openclaim.json#keys"
  ],
  "sig": ["BASE64_SIGNATURE"]
}

Multiple servers may independently sign observations. Conflicting claims reveal dishonest actors.

Example 5 — Cross-Domain Identity

Two domains may confirm a shared identity.

Claim: siteA claims user123 equals siteB user456

json
{
  "ocp": 1,
  "iss": "https://siteA.example",
  "sub": "https://siteA.example/user123",
  "stm": {
    "same_as": "evm:1:address:0xSiteB..."
  },
  "key": [
    "data:key/es256;base64,MIIB..."
  ],
  "sig": ["BASE64_SIGNATURE"]
}

Example 6 — Blockchain Anchoring

Claims can be anchored to blockchains. Instead of storing full JSON, systems may store:

text
hash(OpenClaim)

Benefits include timestamped proof, tamper resistance, and public auditability. The claim itself remains off-chain.

Example 7 — Session Authentication

Applications may issue claims representing active sessions.

Claim: Server claims session key K belongs to user Alice

json
{
  "ocp": 1,
  "iss": "https://auth.example",
  "sub": "https://users.example/alice",
  "stm": {
    "session_key": "PUBLIC_KEY"
  },
  "exp": 1712003600,
  "key": [
    "https://auth.example/.well-known/openclaim.json#keys"
  ],
  "sig": ["BASE64_SIGNATURE"]
}

Clients can present signed requests using the session key.

Example 8 — Intercloud Attestations

Distributed nodes may publish claims about system state.

json
{
  "ocp": 1,
  "iss": "https://nodeA.example",
  "stm": {
    "object": "X",
    "hash": "H"
  },
  "key": [
    "data:key/es256;base64,MIIB..."
  ],
  "sig": ["BASE64_SIGNATURE"]
}

Dishonest nodes are exposed if their signatures contradict each other.

Example 9 — Multi-Signature Claim

A claim signed by multiple parties using different key types.

json
{
  "ocp": 1,
  "iss": "https://org.example",
  "sub": "https://users.example/bob",
  "stm": {
    "approved": true
  },
  "key": [
    "data:key/es256;base64,MIIB...",
    "data:key/eip712;base64,0xSigner..."
  ],
  "sig": [
    "BASE64_DER_SIGNATURE",
    "0xHEX_EIP712_SIGNATURE"
  ]
}

Example 10 — Multi-Step Execution (Actions)

A governance action requiring multiple approvals before execution.

json
{
  "ocp": 1,
  "actions": [
    {
      "ocp": 1,
      "iss": "evm:56:address:0xAuthority",
      "sub": "evm:56:address:0xControlContract",
      "stm": {
        "contract": "evm:56:address:0xToken",
        "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..."
      ]
    }
  ]
}

This maps to a ControlContract flow: invoke → endorse → quorum → execute. Execution is NOT guaranteed immediately — quorum and delay conditions must be met.

Claim Bundles

Multiple claims may be distributed together.

json
{
  "claims": [
    { ... },
    { ... },
    { ... }
  ]
}

Bundles may be used for identity profiles, organization records, and capability sets.

Verification Flow

text
Receive claim
↓
Canonicalize JSON (without sig)
↓
Resolve keys
↓
Verify each signature against corresponding key
↓
Check time constraints
↓
Apply extension-specific logic
↓
Accept or reject claim

Real-World Scenarios

OpenClaiming is applicable in many environments: identity systems, decentralized networks, access control systems, blockchain integrations, reputation systems, and distributed collaboration platforms.

Summary

OpenClaiming provides a minimal primitive: a cryptographically signed statement. From this simple building block, systems can implement identity assertions, permission delegation, system attestations, and decentralized trust models.