This document describes the security assumptions and threat model of the OpenClaiming Protocol.

Security Goals

Authenticity

A claim must be provably issued by the entity that signed it. This is achieved through asymmetric cryptography.

Integrity

The contents of a claim must not be modifiable without invalidating the signature. This is ensured by signing the canonicalized JSON representation of the claim.

Verifiability

Any party should be able to verify a claim without contacting the issuer. Verification requires only the claim and the issuer's public key.

Decentralization

Claims should not rely on centralized registries. Claims may be published anywhere.

Trust Model

OpenClaiming does not impose a global trust authority. Instead, trust is determined by the verifier.

Verifiers decide which issuers to trust, which claims to accept, and how to resolve public keys.

Identity Model

Identifiers used in iss, sub, and stm fields are opaque strings interpreted by applications. The recommended format is:

<ecosystem>:<chain>:<type>:<value>

iss and sub must be non-empty strings. URI format (https://, did:, evm:, etc.) is recommended for globally unambiguous identifiers. In closed systems, simpler strings are acceptable. Extensions may impose stricter identifier requirements.

Identifiers are NOT keys. Keys use data URLs or HTTPS URLs for key material.

Key Ownership

Claims are authenticated through public-key cryptography. The issuer must control the private key corresponding to the public key used for verification.

Public keys may be published through well-known endpoints, identity documents, application APIs, or blockchain registries.

Key Resolution Semantics

If a key is a remote URL, its value is resolved at verification time. This implies:

• Claims using remote keys may change validity over time
• Key rotation may invalidate previously valid claims
• Verifiers MUST NOT modify the canonicalized payload based on resolved keys

Canonicalization Security

To prevent signature inconsistencies across languages, OpenClaiming uses RFC 8785 JSON Canonicalization.

This ensures deterministic key ordering, normalized number formats, and consistent serialization. Without canonicalization, different implementations could produce different byte sequences for the same JSON document.

Replay Attacks

Replay protection is an application concern, not a protocol requirement. Systems that need nonce or sequence guarantees should include them in the stm payload, which is covered by the signature. The optional nbf and exp fields provide time-bounded validity when needed.

Key Rotation

Issuers should periodically rotate signing keys. Recommended practices include publishing multiple keys simultaneously, marking older keys as deprecated, and allowing verification for historical claims.

Verifiers should support multiple keys per issuer.

Revocable vs Non-Revocable Claims

Revocable Claims

Claims using remote key references (e.g. HTTPS URLs) are revocable. If the remote key material changes, previously valid signatures may become invalid. This means the key reference format itself encodes revocability intent: choose a URL key when you want revocability, choose a data:key/... inline key when you want permanent non-repudiation.

Non-Revocable Claims

Claims using embedded keys (e.g. data:key/...) are non-revocable. They remain verifiable indefinitely, assuming cryptographic assumptions hold.

Summary

Other revocation approaches include claim expiration, issuer-maintained revocation lists, and blockchain anchoring.

Signature Algorithms

Version 1 recommends:

ECDSA P-256
SHA-256

These algorithms are widely supported. Future versions may support Ed25519, Schnorr signatures, and multisignature schemes.

Publishing Security

Claims may be distributed through untrusted channels. Because claims are cryptographically signed, transport security is not strictly required for verification. However, HTTPS is recommended when claims are served from web endpoints.

Privacy Considerations

OpenClaims are typically public artifacts. Issuers should avoid embedding sensitive personal data unless explicitly required.

Possible privacy-preserving approaches include hashing identifiers, referencing external encrypted data, and limiting claim lifetime.

Denial of Service

Verifiers should validate claim size and structure before performing expensive cryptographic operations. Suggested limits include maximum claim size, maximum nesting depth, and maximum statement payload size.

Malicious Issuers

The protocol does not prevent malicious issuers from signing false claims. Trust decisions must be made by the verifier. Applications may implement reputation systems or allowlists.

Chilling Effects

In decentralized systems, signed claims create cryptographic accountability. If an issuer signs conflicting claims, the signatures themselves serve as evidence. This discourages dishonest behavior without requiring centralized enforcement.

Actions Execution Model

Actions may require:

• multiple approvals (multisig)
• contract-level authorization
• time delays before execution

Even valid signatures may not result in execution. Execution depends on quorum rules, contract logic, role permissions, and time delays.

Summary

OpenClaiming provides a minimal cryptographic primitive:

Signed statement → verifiable by anyone

The protocol intentionally leaves policy decisions to applications.