CNothing Authentication Standard 1.0

1. Scope and Objectives

Defines what this standard covers and what it intentionally leaves outside scope.

This standard specifies how a client backend authenticates to CNothing, how a one-time challenge is issued and consumed, how subsequent operations are bound to a validated identity, and how a client rotates its public key without changing its logical client identity.

The standard is designed for environments in which an AI agent may orchestrate requests but must never obtain the client's private key or decrypt authenticated envelopes.

This standard governs authentication, replay resistance, operation binding, and authenticated key rotation. It does not define the third party's inner application encryption model for payload confidentiality beyond the CNothing transport envelopes.

• The standard applies to registration, challenge refresh, key rotation, KV save authorization, and KV read authorization.
• The standard assumes the client private key remains under exclusive control of the client backend.
• The standard assumes CNothing holds the server-side AuthAI private key used to decrypt submitted envelopes.

2. Conformance Language

Uses normative keywords in the RFC 2119 and RFC 8174 sense.

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in RFC 2119 and RFC 8174 when, and only when, they appear in all capitals.

• A conforming CNothing server MUST implement every REQUIRED validation rule in this document.
• A conforming client implementation MUST preserve private-key custody and MUST NOT delegate envelope decryption to an AI intermediary.
• A conforming integrator SHOULD separately protect application-level payload meaning when namespace, key names, metadata, or values are sensitive.

3. Roles, Trust Boundaries, and Threat Model

Defines system actors and the minimum trust separation expected by the protocol.

4. Cryptographic Profile and Identifiers

Defines the envelope profile, identifiers, and versioning expected by conforming implementations.

All protocol envelopes in this version of the standard use version identifier `ksp1`, key agreement profile `RSA-OAEP-256`, and content encryption `A256GCM`.

• Envelope version MUST be `ksp1`.
• Client key algorithm identifier MUST be `RSA-OAEP-256/A256GCM` unless a future profile is explicitly negotiated.
• Client identities MUST be represented by a stable `client_uuid` assigned by CNothing.
• Public keys MUST be fingerprinted using a SHA-256 based fingerprint derived from the normalized public key representation.

{
  "v": "ksp1",
  "alg": "RSA-OAEP-256",
  "enc": "A256GCM",
  "key_id": "optional-key-id",
  "encrypted_key": "base64url",
  "iv": "base64url",
  "ciphertext": "base64url",
  "tag": "base64url",
  "aad": "optional-base64url"
}

5. Client Registration

Defines how a client is registered or re-associated with a previously known public key.

Registration creates or reuses a logical client record and returns a one-time challenge encrypted to the submitted client public key. The challenge is the only valid starting point for authenticated operations.

• The client public key MUST be submitted in PEM form.
• CNothing MUST normalize and validate the public key before fingerprinting it.
• If the fingerprint already exists, CNothing MAY reuse the existing client identity associated with that fingerprint.
• A successful registration MUST return the CNothing AuthAI public key, a `client_uuid`, a `challenge_id`, and a `challenge_for_client` envelope.

POST /v1/authai/register

{
  "client_public_key": "-----BEGIN PUBLIC KEY----- ...",
  "client_key_alg": "RSA-OAEP-256/A256GCM",
  "client_key_id": "optional-key-id",
  "client_label": "optional label",
  "metadata": {}
}

{
  "v": "ksp1",
  "type": "challenge",
  "purpose": "authai.operation",
  "client_uuid": "uuid",
  "challenge_id": "uuid",
  "nonce": "base64url-32-bytes",
  "issued_at": "2026-04-05T12:00:00.000Z",
  "expires_at": "2026-04-05T12:05:00.000Z"
}

6. Challenge Lifecycle

Defines the validity and revocation state machine for one-time challenges.

• Every active challenge MUST be short-lived and single-use.
• A challenge MUST be rejected if it is expired, unknown, already used, revoked, or bound to a different client.
• When CNothing issues a new active operation challenge for a client, other active operation challenges for that client SHOULD be revoked.
• Consuming a valid challenge MUST transition its server-side status from active to used before the requested operation is accepted as successful.

7. Authentication Envelope Validation

Defines the canonical authentication payload and the required validation sequence.

The authentication envelope binds a validated challenge to a specific action and request identifier. It is the mandatory gate for every operation after registration.

• CNothing MUST decrypt the submitted authentication envelope with the server-side AuthAI private key.
• The payload version MUST equal `ksp1` and the payload type MUST equal `auth`.
• The payload action MUST exactly match the endpoint being executed.
• The `client_uuid` in the envelope MUST identify an existing registered client.
• The `challenge_id` MUST reference an active challenge bound to that client.
• The SHA-256 fingerprint of the submitted nonce MUST match the stored nonce hash.
• The challenge MUST be marked used before the operation completes successfully.

{
  "v": "ksp1",
  "type": "auth",
  "action": "kv.save",
  "client_uuid": "uuid",
  "challenge_id": "uuid",
  "nonce": "base64url-32-bytes",
  "issued_at": "2026-04-05T12:00:00.000Z",
  "expires_at": "2026-04-05T12:05:00.000Z",
  "request_id": "uuid"
}

8. Authorized Operations

Defines how authenticated operations are paired with operation-specific encrypted payloads.

POST /v1/kv/save

{
  "auth_envelope": { "...": "..." },
  "data_envelope": {
    "v": "ksp1",
    "type": "kv.save",
    "namespace": "thirdparty.example.prod",
    "items": [
      {
        "key": "user/123/profile-token",
        "value": { "access_token": "..." },
        "metadata": {}
      }
    ]
  }
}

POST /v1/kv/read

{
  "auth_envelope": { "...": "..." },
  "query_envelope": {
    "v": "ksp1",
    "type": "kv.read",
    "namespace": "thirdparty.example.prod",
    "keys": ["user/123/profile-token"]
  }
}

9. Authenticated Key Rotation

Defines how a client rotates to a new public key without changing its logical client identity.

Key rotation is an authenticated mutation of an existing client identity. Rotation is not the same as new-client registration and MUST preserve `client_uuid` continuity for the rotated client.

• The request MUST be authenticated with a valid envelope built from the currently active key material.
• The requested new public key MUST be normalized and fingerprinted before acceptance.
• The server MUST reject rotation if the new fingerprint is already bound to a different client identity.
• A successful rotation MUST update the client's active public key binding in place.
• After rotation, newly issued challenges MUST be encrypted to the new client public key.

POST /v1/authai/rotate-key

{
  "auth_envelope": { "...": "..." },
  "new_client_public_key": "-----BEGIN PUBLIC KEY----- ...",
  "new_client_key_alg": "RSA-OAEP-256/A256GCM",
  "new_client_key_id": "optional-next-key-id",
  "new_client_label": "optional label",
  "metadata": {}
}

10. Error Semantics

Defines the minimum interoperable error categories exposed by the implementation profile.

• `missing_field` for absent required input members.
• `invalid_field` for syntactically malformed or semantically invalid input members.
• `invalid_public_key` for client key material that fails normalization or parsing.
• `invalid_auth_envelope` for unreadable or structurally invalid authentication envelopes.
• `challenge_not_found` when the referenced challenge does not exist or is not bound to the client.
• `challenge_expired` when the challenge lifetime has elapsed.
• `challenge_already_used` when the challenge is no longer active.
• `challenge_nonce_mismatch` when the envelope nonce does not match the stored nonce hash.
• `challenge_purpose_mismatch` when the requested action does not match the envelope semantics.
• `public_key_already_registered` when a rotation attempts to reuse another client's public key.
• `payload_invalid` for operation-specific payloads that do not satisfy structural rules.

11. Security and Operational Requirements

Captures the non-negotiable operational practices required for safe deployment.

• Client private keys MUST remain outside AI-visible memory, prompts, tool outputs, and logs.
• Servers MUST use a consistent trusted clock source when evaluating challenge expiry.
• Server implementations SHOULD record auditable registration, refresh, rotation, save, and read events.
• Operators SHOULD keep server private keys and master keys outside code-synchronized directories.
• Integrators SHOULD use an additional client-side confidentiality layer when CNothing operators must not see namespaces, keys, metadata, or values.

12. Conformance Checklist

Provides an implementation checklist for independent adopters.

• Publishes the CNothing AuthAI public key over an authenticated channel.
• Accepts client registration and returns an encrypted one-time challenge.
• Requires a valid action-bound authentication envelope for refresh, rotation, save, and read.
• Marks challenges single-use and rejects replay.
• Issues a new challenge after each successful authenticated operation.
• Encrypts read results to the active client public key.
• Supports in-place authenticated key rotation with auditability.
• Returns interoperable error codes for failed validation conditions.