OAI v1.0 — Observed Actor Identifier Standard

1. Abstract

OAI is an open identifier standard for entities that observe, profile, or act against users, devices, and networks: trackers, fingerprinters, surveillance vendors, ad networks, data brokers, threat actors, and the sensor operators that witness them. It is edited by TunnelMind — a single-operator project intended to transition to a neutral standards body once the conditions in Section 12 are met — and adopts the CVE editorial model: free resolution, permanent canonical identifiers, signed observations. The standard exists because reporting, tooling, and research about observation infrastructure currently lack a stable citation format; an OAI-YYYY-NNNNNNN is a stable handle that humans, agents, and downstream resolvers can all share.

2. Identifier format

OAI defines two identifier forms: a canonical identifier and an optional alias. Every registered entity has exactly one canonical identifier and zero or more aliases. Aliases resolve to the canonical identifier.

2.1 Canonical form

OAI-YYYY-NNNNNNN

Formal grammar (ABNF, RFC 5234):

oai-canonical = "OAI-" 4DIGIT "-" 7DIGIT
DIGIT         = %x30-39

The canonical form is case-sensitive: all characters are uppercase except the literal digits. Lowercase or mixed-case canonical identifiers MUST be rejected.

2.2 Alias form

oai:slug

Formal grammar:

oai-alias = "oai:" alpha-num *(alpha-num / "-" / "_")
alpha-num = %x61-7A / DIGIT          ; a-z and 0-9

Aliases are case-sensitive and lowercase. An alias MUST NOT collide with another entity's alias. Aliases MUST NOT be reused after being retired.

2.3 Bounds

2.4 Reserved characters

The following characters MUST NOT appear in either form: whitespace, /, ?, #, &, =, +, %, any uppercase letter in the slug portion of an alias.

3. Scope

OAI is for entities that observe, profile, or act against users, devices, or networks in ways relevant to defensive analysis. The categories accepted in v1:

A category string is one or more dot-separated lowercase segments, each beginning with [a-z] and followed by [a-z0-9_]*. The full grammar is enforced by the v1 record schema (Section 7) at pattern: "^[a-z][a-z0-9_]*(\\.[a-z][a-z0-9_]*)+$".

4. Out of scope

The following are not registerable in v1. Each exclusion is deliberate; do not work around them.

Out-of-scope subjects are not given OAIs even on request. Issuance of an OAI to an out-of-scope subject is grounds for retraction (Section 6).

5. Stability guarantees

The canonical identifier is permanent. Once issued, an OAI:

• MUST NOT be reassigned to a different entity.
• MUST NOT be deleted from the registry.
• MUST remain resolvable for as long as the registry operates.

This is the load-bearing guarantee of the standard. External tooling, citations, and reports rely on OAI-YYYY-NNNNNNN being a stable handle. Repointing a canonical ID is a governance failure (see Section 12) and a versioning event.

Aliases are convenience-stable: they MUST resolve to the current canonical for as long as they exist, and they MUST NOT be reassigned to a different entity. An alias MAY be retired, in which case it stops resolving. Aliases are not citation-grade and SHOULD NOT appear in long-lived reports without the canonical form alongside.

6. Deprecation policy

An OAI has one of four states:

6.1 Transitions

stateDiagram-v2
  [*] --> reserved : issue_oai()
  reserved --> active : first attestation
  active --> deprecated : operator ceased / dissolved
  active --> superseded : merged into another OAI
  deprecated --> [*]
  superseded --> [*]

reserved → active requires at least one attestation (Section 10). The v1 record schema enforces this with if status=active then attestations.minItems=1.

active → superseded requires the superseded_by column to reference a valid OAI. The registry's oai_superseded_consistency CHECK enforces this invariant: a row marked superseded MUST have a target, and a row not marked superseded MUST NOT.

A canonical ID MUST NOT transition out of deprecated or superseded. Resurrection is forbidden in v1.

6.2 Deprecation headers

Resolvers MUST include Sunset (RFC 8594) on deprecated responses, set to the timestamp at which the record was deprecated. Resolvers MUST emit a 303 See Other on superseded requests, with Location set to the resolution URL of superseded_by.

7. Schema

The canonical record format is JSON-LD. Every OAI registry entry conforms to the v1 schema below; v1 is frozen at ship (Section 11).

7.1 JSON-LD context

@context: https://tunnelmind.ai/oai/context.jsonld
@type:    ObservedActor

7.2 Fields

7.3 Attestation object

{
  "sensor": "OAI-SENSOR-de-001",
  "observed_at": "2026-05-10T14:32:18Z",
  "signature": "ed25519:0x9f3a8b2e...",
  "log_index": 4827193
}

7.4 Worked example

{
  "@context": "https://tunnelmind.ai/oai/context.jsonld",
  "@type": "ObservedActor",
  "id": "OAI-2026-0000042",
  "aliases": ["oai:meta-pixel-v3"],
  "name": "Meta Pixel",
  "category": "tracker.pixel.advertising",
  "operator": "OAI-2026-0000017",
  "first_observed": "2012-10-15T00:00:00Z",
  "first_observed_by": "public-corpus",
  "last_observed": "2026-05-10T14:32:18Z",
  "last_observed_by": "OAI-SENSOR-de-001",
  "domains": ["connect.facebook.net", "www.facebook.com"],
  "fingerprint_methods": ["canvas", "webgl", "audio_context"],
  "data_sharing": ["OAI-2026-0000017", "OAI-2026-0000093"],
  "jurisdiction_notes": {
    "eu": "GDPR enforcement actions: see CNIL-2023-IR-FR-Meta-001",
    "us": "FTC consent order 2024"
  },
  "attestations": [
    {
      "sensor": "OAI-SENSOR-de-001",
      "observed_at": "2026-05-10T14:32:18Z",
      "signature": "ed25519:0x9f3a8b2e...",
      "log_index": 4827193
    }
  ],
  "status": "active",
  "schema_version": "1.0",
  "issued_at": "2026-01-12T08:00:00Z"
}

Sequence numbers in the example are illustrative; the live registry may emit different values.

7.5 Cross-reference rule

Every cross-reference to another entity (operator, data_sharing, attestations[].sensor, first_observed_by, last_observed_by) MUST be a canonical OAI or, where applicable, the literal public-corpus. Free strings are not permitted in reference fields. If the referenced entity is not yet registered, the publishing party MUST either issue an OAI for it or omit the reference. The registry is a self-referential graph; tolerating free strings in reference fields would silently break that property.

7.6 Validation

The registry validates v1 records on insert with a JSON Schema 2020-12 CHECK constraint (see supabase/migrations/005b_oai_record_schema.sql). The schema enforces:

• additionalProperties: false at the top level. v1 is frozen.
• schema_version const-locked to "1.0".
• Pattern-based validation on all OAI cross-references using the canonical and sensor regexes.
• Conditional: status=active requires attestations.minItems=1.

Application-layer validators SHOULD also validate format: date-time strictly; pg_jsonschema enforcement of date-time is implementation-dependent.

8. Resolution

The resolver answers a single endpoint:

GET https://tunnelmind.ai/id/{id-or-alias}

8.1 Behavior

8.2 Content negotiation

8.3 Cache-Control

Cache directives are set per status to amplify reads at the CDN edge.

8.4 Reserved status MUST NOT leak

Reserved identifiers are pre-issued but not yet attested. Disclosing reservation state to the public — for instance, by responding 451 instead of 404 — would reveal which entities the registry is preparing to add before the operators or affected parties have been notified. Resolvers MUST return 404 for both reserved and unknown lookups, with identical bodies and identical cache headers. The 404 body:

{
  "error": "not_found",
  "queried": "<input>",
  "standard": "https://tunnelmind.ai/oai/standard"
}

Administrators with service-role access may query the underlying registry directly; the public resolver path MUST NOT distinguish reserved from unknown.

8.5 Headers

Every response MUST include:

• Cache-Control per Section 8.3.
• Link: <https://tunnelmind.ai/oai/standard>; rel="describedby".
• ETag for client-side conditional requests.

8.6 Rate limiting

The resolver MUST NOT rate-limit. The resolver MUST NOT require authentication. OAI resolution is a public good and the registry pays the egress cost. This is load-bearing for adoption: a rate-limited or authenticated resolver cannot become the citation format.

CDN-level caching makes the cost manageable; if a single client misbehaves, the appropriate mitigation is the CDN's automated abuse handling, not standard-level rate-limit semantics.

8.7 Resolver lookup order

flowchart TD
  A[Input] --> B{match canonical regex OAI-\d{4}-\d{7}}
  B -- yes --> C[query oai_registry]
  B -- no --> D{match sensor regex OAI-SENSOR-[a-z]{2}-\d{3}}
  D -- yes --> E[query oai_sensors]
  D -- no --> F{match alias regex oai:[a-z0-9][a-z0-9_-]*}
  F -- yes --> G[query oai_registry.aliases, 301 to canonical]
  F -- no --> H[400 Bad Request]

8.8 Ancillary routes

9. Sensor identifiers

Sensors are attested observation endpoints operated by humans or organizations. They live in a separate namespace from entity OAIs.

9.1 Format

OAI-SENSOR-{cc}-{seq}

oai-sensor = "OAI-SENSOR-" 2(%x61-7A) "-" 3DIGIT

9.2 Properties

• The sequence is per country, beginning at 001.
• Sequence numbers are never reissued, never reused across sensors, even after a sensor is decommissioned.
• A retired sensor retains its identifier with status: retired. The record remains resolvable.
• A retired sensor's pubkey_ed25519 MUST NOT be accepted on new observations.
• A multi-region operator issues a separate sensor identifier under each jurisdiction. An operator running three sensors each in DE, US, and SG holds nine sensor identifiers.

9.3 Why ISO 3166-1, not airport codes

The question the sensor identifier answers is "what legal regime did this observation come from." Airport codes encode physical location; ISO codes encode jurisdiction. Jurisdictions are what agents and analysts reason about: GDPR applies to a DE sensor regardless of which datacenter hosts it.

9.4 Country codes committed at launch

The registry accepts any valid ISO 3166-1 alpha-2 code. The codes TunnelMind operates sensors under at launch:

us  de  gb  sg  jp  br  au

9.5 Resolver behavior

Sensor lookups follow the same flow as entity lookups (Section 8.7). The oai_sensors table is publicly readable on all rows by design (see migration 004b_oai_sensors.sql): the public key is required for signature verification, and operator identity is required by the transparency model.

10. Attestation model

Every observation contributing to a registry record is signed by a sensor's Ed25519 keypair and chained into a transparency log.

10.1 Signature

A sensor signs the canonical-bytes encoding of the observation payload with its Ed25519 private key. The signature accompanies the observation in the attestations[] array of the affected registry record. The corresponding public key is the pubkey_ed25519 of the sensor's oai_sensors row.

Signature encoding: ed25519:0x<hex>. Verifiers fetch the public key from the resolver at /id/{sensor-id}.

10.2 Transparency log

The transparency log lives at:

https://tunnelmind.ai/oai/log

The log MUST be append-only. Each entry binds an attestation to a monotonically increasing log_index recorded in the corresponding attestations[].log_index field. The log permits any party to verify that a published record was not silently rewritten.

Implementation of the log endpoint is deferred to a separate standards process. v1 reserves the URL and the log_index field. Consumers MUST tolerate log_index values that cannot yet be verified against a live log endpoint.

10.3 Promotion to active

A reserved record MUST NOT be promoted to active with zero attestations. The v1 record schema enforces this. The first attestation that meets the schema may trigger promotion; the registry operator (service-role only) performs the transition.

11. Versioning

OAI follows semantic versioning at the standard level, not the record level.

v1 is frozen at ship. The record schema (Section 7) has additionalProperties: false, schema_version: const "1.0". A v2 record shape requires:

1. A public RFC describing the change and its migration path.
2. A new validator gated on schema_version: "2.0".
3. A rewritten v1 validator gated on schema_version: "1.0" to preserve historical record validation.

v1 records remain valid and resolvable indefinitely after v2 ships. The standard never invalidates existing canonical identifiers.

12. Governance

12.1 Editor

TunnelMind edits the OAI registry while v1 stabilizes. TunnelMind is a single-operator project, not a foundation, not a consortium, and not a venture-backed entity. There is no board, no token, and no third-party investor with editorial influence. The editor's role is provisional; the conditions under which it transfers to a neutral host are defined in Section 12.4.

12.2 Conflict of interest

TunnelMind operates commercial products that consume the registry — notably defender-tier services that benefit from the existence of canonical identifiers for adversarial entities. To bound the conflict:

• Issuance order is determined by the open observation corpus, not by customer requests. A paying customer MAY propose registration of an entity their operations have surfaced; the proposal enters the same queue as any other and is not prioritized by payment status.
• Editorial decisions on category boundaries, scope exclusions (Section 4), and supersession events are public, recorded in oai_issuance_log, and reversible only by a versioning event (Section 11).
• The editor MUST NOT accept payment, sponsorship, or grant funding in exchange for issuance, supersession, or scope decisions. Funding that is not tied to specific identifiers is permissible and MUST be disclosed at tunnelmind.ai/oai/funding.

12.3 Continuity

The registry data, the schema, the issuance audit log, and the migration history are open: the spec document is licensed CC BY 4.0, and the registry payload (records, sequence state, and audit log) is dedicated to the public domain under CC0. A current Postgres dump and a snapshot of the resolver routing rules are publicly downloadable at tunnelmind.ai/oai/archive/ and updated at least monthly.

In the event the editor cannot operate the registry, the canonical resolver URL (tunnelmind.ai/id/) MAY be repointed to a successor neutral host with a 301 from each canonical OAI. The canonical identifier itself is unaffected by the URL move — only the resolution endpoint changes. Successor hosts MAY rebuild the registry from the public archive and serve resolution from any URL; the canonical 301 makes the legacy URL forward correctly.

12.4 Transition gate

Editorial control of the standard transitions to a neutral body when all three of the following hold for two consecutive quarters:

1. External adoption. Three or more independent organizations publish OAI identifiers in reporting, tooling, or research. Measured via referer logs on the resolver and via public citation scraping. TunnelMind's own products do not count toward the three.
2. Standards-track recognition. At least one of: an IETF draft referencing OAI, a W3C working-group adoption, a MITRE / CWE cross-reference, or an equivalent recognized standards body's citation.
3. Operational maturity. Resolver uptime of 99.9% or higher measured at the edge across rolling 90-day windows for two consecutive quarters, and zero canonical identifiers repointed.

When all three conditions hold, the editor publishes a Transition RFC. The RFC describes the proposed governance structure, candidate neutral hosts, and a handover timeline. The RFC has a minimum 90-day public comment period.

Rationale. AND across all three, not OR — adoption without recognition is a popularity signal; recognition without adoption is a paper achievement; either without operational maturity disqualifies the registry from neutral-body acceptance. Two consecutive quarters because single-quarter spikes are artifacts and six months is the floor for credible adoption. Zero canonical repointing because stable identifiers are the load-bearing property of the standard.

12.5 Editor failure modes (solo operator)

A single-operator editor has failure modes a foundation does not. The standard names them so that downstream consumers can reason about them:

• Issuance turnaround. Issuance requests are processed in batches, not in real time. The editor's published SLO for new issuance is 14 calendar days from the time a complete proposal is received. Faster turnaround is not guaranteed. Resolver availability is independent of issuance turnaround; resolution operates as infrastructure.
• Disagreement and objection. A party who disagrees with an issuance, a supersession, or a scope decision MAY submit a public objection at tunnelmind.ai/oai/objections. Objections are appended to the public record. The editor responds in writing within 30 calendar days. Objections do not block the underlying registry record from resolving while the response is pending.
• Capacity ceiling. If the registry's editorial workload exceeds what a solo operator can sustain — or if the editor's circumstances change such that they can no longer operate the registry impartially — the editor MUST invoke the Transition RFC ahead of the Section 12.4 gate. Premature transition is a recognized exit, not a failure.

These constraints are honest about scale rather than aspirational about it. The standard does not promise foundation-grade operational properties from a project that does not have them.

13. Open questions

Questions deferred to future versions or separate standards processes:

Appendix A. References

• RFC 5234 — Augmented BNF for Syntax Specifications: ABNF
• RFC 3339 — Date and Time on the Internet: Timestamps
• RFC 8594 — The Sunset HTTP Header Field
• RFC 9116 — A File Format to Aid in Security Vulnerability Disclosure (tone reference)
• ISO 3166-1 — Codes for the representation of names of countries and their subdivisions
• JSON Schema 2020-12 — https://json-schema.org/draft/2020-12/schema
• JSON-LD 1.1 — https://www.w3.org/TR/json-ld11/

Appendix B. Implementation references