Research specification · Identity draft 0.1

Know what acted, who authorized it, and why it was trusted.

OSOIX Identity is a proposed architecture for binding orbital assets, sensors, operators, missions and software to authenticated identities and narrowly scoped authority. Identity establishes accountability; it does not by itself prove that an event occurred.

Identity subjects

Spacecraft and vehicles

Stable asset identity linked to manufacturer records, ownership, operator authority, mission role and current credential state.

Sensors and payloads

Identity linked to calibration, firmware, installation context, measurement scope and trusted signing material.

Ground infrastructure

Ground stations, control systems, gateways and data services with declared service roles and jurisdictional context.

People and organizations

Operators, reviewers, regulators, service providers and customers with role-based authority rather than unrestricted account access.

Missions and events

Mission-scoped identities that bind plans, approvals, participants, assets, event records and evidence packages together.

Software and models

Versioned identity for flight software, verification rules, simulation models and decision-support systems used to derive conclusions.

Minimum credential controls

Unique subject identifier and subject type
Credential issuer identity and trust basis
Authority scopes and explicit exclusions
Validity interval and mission context
Key rotation and recovery procedure
Revocation and suspension status
Delegation chain and accountable principal
Credential and software-version provenance

Credential lifecycle

Enroll

Establish subject identity from authoritative records and verify control of the initial signing key.

Issue

Grant narrowly scoped credentials for a defined role, mission, asset or service period.

Operate

Sign telemetry, commands, reviews or evidence records only within the granted authority scope.

Rotate

Replace keys and credentials without breaking the historical chain of accountability.

Suspend

Temporarily prevent reliance when control, calibration, authorization or security state is uncertain.

Revoke

Permanently invalidate compromised, expired, transferred or unauthorized credentials.

Archive

Preserve historical identity and status evidence so past mission records remain independently interpretable.

Credential envelope · Draft 0.1

Minimum identity record

{
  "spec_version": "osoix-identity-draft-0.1",
  "subject_id": "urn:osoix:asset:...",
  "subject_type": "spacecraft",
  "issuer": "did:example:authority...",
  "controller": "did:example:operator...",
  "authority_scopes": [
    "telemetry.sign",
    "mission.participate"
  ],
  "exclusions": [
    "verification.approve",
    "settlement.authorize"
  ],
  "valid_from": "2026-08-03T00:00:00Z",
  "valid_until": "2027-08-03T00:00:00Z",
  "mission_ids": [],
  "public_keys": [],
  "status": "active",
  "status_endpoint": "urn:osoix:status:...",
  "provenance": {
    "manufacturer_record": "sha256:...",
    "registration_record": "sha256:..."
  }
}

The architecture is compatible with established PKI, hardware-backed keys, regulated credential systems and decentralized identifier methods. OSOIX should not require a proprietary identity technology where an accepted aerospace or governmental standard is more appropriate.

Current boundary

This is a research architecture, not a deployed orbital identity network or certification authority. No spacecraft, operator, regulator or customer currently relies on OSOIX credentials. The next engineering step is a test identity registry for simulated spacecraft, sensors and mission roles, including key rotation and revocation tests.