Open Publication Namespace Claims v0.1.0

Source: namespace-claims/index.md

Open Publication Namespace Claims v0.1.0

Status

Draft

Overview

Open Publication Namespace Claims v0.1.0 defines how a publisher can claim authority over a urn:pub: namespace in a distributed way while making mass-grabbing expensive and reversible.

The goal of this specification is to let any participant claim a namespace without requiring a global central registrar, while still giving agents and publication hosts a way to evaluate whether the claim is active, challenged, or abandoned.

This version specifies:

• the claim object for a urn:pub: namespace
• proof models for distributed namespace control
• activation, challenge, renewal, and expiry states
• anti-hoarding rules for unverified namespace claims
• the minimum information a host or registry must publish for a claim

This version does not specify:

• a single mandatory blockchain, DNS provider, or identity provider
• a mandatory payment rail or staking mechanism
• how a publication host resolves published documents over HTTP
• how document versions are ordered inside a namespace

Terminology

The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals.

Relationship to Other Specifications

This specification depends on Open Publication URNs for the definition of the urn:pub: namespace structure.

This specification is intended to complement Open Publication Protocol by defining who is authorized to publish under a namespace.

Concepts

Namespace

A namespace is the <namespace> segment of a family URN:

• urn:pub:<namespace>:<name>

This specification governs authority over that namespace segment.

Claimant

A claimant is the actor attempting to activate or renew authority over a namespace.

Claim Proof

A claim proof is verifiable evidence that a claimant controls an external identity or resource that can anchor a namespace claim.

This version supports three proof classes:

• did
• domain
• key

Active Claim

An active claim is a namespace claim that is currently valid and may authorize publication under that namespace.

Unverified Claim

An unverified claim is a provisional namespace claim that has not yet presented strong external proof such as a verified domain or DID-backed proof.

Challenge

A challenge is a published objection asserting that a namespace claim is invalid, abandoned, or conflicting.

Claim Model

Each namespace claim MUST describe at least:

• namespace
• claim_id
• claimant
• proof_type
• proof
• status
• claimed_at
• expires_at

Optional fields MAY include:

• renewed_at
• challenge_url
• superseded_by
• metadata

Claim States

A claim MUST be in exactly one of the following states:

• pending
• active
• challenged
• expired
• revoked
• transferred

State meanings:

• pending: a provisional claim exists but is not yet active
• active: the claim currently authorizes publication under the namespace
• challenged: the claim is under dispute and SHOULD NOT be treated as final
• expired: the claim lapsed due to non-renewal or non-use
• revoked: the claim was invalidated by its governing registry or host
• transferred: the claim was replaced by a successor claim

Distributed Claim Proofs

This specification allows any participant to claim a namespace if they can present a verifiable proof accepted by the observing host or registry.

DID Proof

A claimant MAY prove control of a DID, such as:

• did:web:example.com
• did:key:z6Mk...

A DID proof SHOULD bind the namespace claim to a DID-controlled verification method or signed challenge.

Domain Proof

A claimant MAY prove control of a DNS domain by publishing a challenge record or a well-known hosted proof.

Domain proof is recommended when the namespace is derived from or obviously associated with a public internet identity.

Key Proof

A claimant MAY prove control of a public key by signing a claim challenge.

Key proof is the minimal decentralized proof model, but by itself it is the weakest defense against namespace squatting unless paired with additional claim friction.

Namespace Activation Rules

• A namespace MUST NOT have more than one active claim at a time within a single observing registry or host.
• A claim MUST remain pending until the observing system has validated its proof and any required challenge window has passed.
• A claim MAY become active after successful proof validation and challenge settlement.
• A claim with stronger proof SHOULD take precedence over a conflicting claim with weaker proof.

Proof strength ordering for this version is:

• domain or did:web
• other did
• key

An implementation MAY refine this ordering, but it MUST do so transparently and consistently.

Anti-Hoarding Rules

This specification requires publication systems to impose friction on namespace claims that lack strong external proof.

Strongly Verified Claims

Claims backed by domain proof or an equivalent externally anchored did proof:

• MAY be activated without strict quota limits
• SHOULD still expire if abandoned for a sufficiently long period
• SHOULD be renewable with lightweight proof refresh

Unverified or Weakly Verified Claims

Claims backed only by a bare key proof or an equivalent weak proof:

• MUST have a short pending or probation window
• MUST expire automatically unless renewed
• MUST be subject to a per-claimant quota
• SHOULD require demonstrable use, such as publication activity, within a bounded time window
• SHOULD be easy to challenge and reclaim if abandoned

Recommended baseline limits for weak claims:

• no more than 3 concurrently active weak claims per claimant
• automatic expiry within 30 days unless renewed
• mandatory publication activity within 14 days of activation

These values are informative defaults. Implementations MAY choose different thresholds if they preserve comparable anti-hoarding pressure.

Challenge and Reclaim

• An implementation SHOULD provide a public challenge mechanism for active and pending claims.
• A challenge SHOULD include the challenged namespace, the challenged claim ID, the challenger identity, and a reason.
• A challenged claim MAY remain active temporarily, but agents SHOULD treat it as disputed.
• An expired or revoked claim MAY be reclaimed by a new claimant after any required cooling-off period.
• A transferred claim MUST point to its successor claim record.

Renewal and Activity

• A claim MUST have an explicit expiry time.
• An active claim MAY be renewed by its claimant before expiry.
• A claim SHOULD be considered abandoned if it has neither been renewed nor used to publish or maintain documents within the implementation-defined activity window.
• Implementations SHOULD publish enough claim metadata for third parties to distinguish active namespaces from abandoned ones.

Minimal Published Claim Record

An observing registry or publication host that publishes claim information SHOULD expose, at minimum, the following fields for each claim:

• namespace
• claim_id
• claimant
• proof_type
• status
• claimed_at
• expires_at

Additional fields MAY include:

• proof
• renewed_at
• challenge_url
• published_document_count

Example Claim Record

{
  "namespace": "ilowe",
  "claim_id": "claim-01JXYZ123ABC",
  "claimant": "did:web:ilowe.me",
  "proof_type": "did",
  "proof": "https://ilowe.me/.well-known/did.json",
  "status": "active",
  "claimed_at": "2026-03-23T21:10:00Z",
  "expires_at": "2027-03-23T21:10:00Z"
}

Security Considerations

• Namespace claims are only as strong as their proof verification.
• Weak proofs without quotas or expiry invite large-scale squatting.
• Strong proofs without expiry invite permanent abandonment.
• Implementations SHOULD prefer proofs tied to durable external control, such as domains or DIDs with a clear rotation story.

Open Questions

• Should a future version define a canonical challenge record format?
• Should a future version require a minimum cooling-off period before namespace reclaim?
• Should a future version standardize a claim signature envelope?