#!RFC-AI/2;id=33;draft=7;v=0.7.0;status=draft;lang=en;dir=auto;theme=chatgpt-mono;sha256=8c2529b9ca36bf59590fcd9699fa795ee929c17e20c10bf8dba6c55cad645d6d
For easier reading, view RFC-AI documents using RFC-AI Reader software.

RFC-AI 33 — AI WORKER COMPOSITE IDENTITY, PROVIDER SELECTORS AND UNIQUE NICKNAMES
STATUS: DRAFT 7 — CEO REVIEW REQUIRED; NOT APPROVED OR ACTIVE; NO REGISTRY IMPLEMENTED
DATE: 2026-11-02 UTC | EDITORIAL ID: PROVISIONAL, pending RFC-AI 9 registry reconciliation
SCOPE: AI workers for organizations adopting the framework; not a human-person identifier standard
RELATED: RFC-AI 4, 6, 9, 28, 31, 32, 34, 35, 36; current private Corporate Extension nickname evidence.

ABSTRACT
Identify a worker with exactly four required fields, type + provider + selector + account. Assign one optional, unique human-readable nickname to refer to exactly that registered combination. Keep optional providerUID solely as a potential future verification clue. Do not invent an additional corporation field or mandatory worker GUID. Use simple, hard-coded logic; no AI judgment in registration, collision resolution, permissions, or contact assembly.

1. WORKER IDENTITY CONTRACT — AGREED CEO DESIGN DIRECTION
1.1 JSON instance fields are: type (required), provider (required), selector (required), account (required), nickname (optional until assigned), providerUID (optional). A complete registered worker MUST have exactly one canonical 4-tuple (type, provider, selector, account). That tuple is its worker ID; it is NOT a concatenated unescaped string, hash, nickname, opaque GUID, access token, session ID, or provider model name.
1.2 type MUST be "Chat" or "API" in this draft. Future types require an RFC amendment, not a worker's arbitrary invention. provider is the exact registered provider/service name, for example "ChatGPT.com". selector is the provider-specific service/function selection, for example "image-to-video", "music", or the empty string "" if no provider-specific selector exists. "work" and "chat" describe working-modes, not selector values. account is the canonical identifier for the user's account within that provider. Missing type/provider/selector/account keys are invalid. selector MUST be present and MAY be exactly the empty string "" for a provider without a separate function selector; type, provider and account MUST be nonempty. A blank selector is a valid key value, not a missing key. Do not store passwords, API tokens, browser cookies or recovery secrets as account.
1.3 Identity JSON example (illustrative, not a live assignment):
{
  "type": "Chat",
  "provider": "ChatGPT.com",
  "selector": "",
  "working-mode": "work",
  "account": "owner@example.invalid",
  "nickname": "Alex",
  "providerUID": null
}
1.4 The example nickname "Alex" is exclusively reserved for the existing CEO-designated ChatGPT founder in this corporation, not a generic entitlement. The actual identity tuple must be verified against the CEO's approved private registry before binding; a sample RFC never creates a worker, authorizes an account or validates a provider session.
1.5 The four fields together identify the worker even when providerUID is absent. providerUID, if supplied, is only a possible later cross-check; no provider-controlled ID is mandatory or automatically trusted as proof. nickname is a SECOND unique index resolving to the SAME four-field worker ID, not a fifth component of it.

2. CANONICAL COMPARISON WITHOUT HIDDEN ID FIELDS
2.1 The fixed registration service defines one provider-name catalog and selector catalog, with documented exact spelling. Input aliases (e.g., host capitalization) resolve through an explicitly reviewed mapping; do not guess arbitrary provider equivalence. Unicode input MUST be valid UTF-8 and bounded; reject control characters, leading/trailing whitespace, path separators in filesystem labels and ambiguous values before saving. Display casing may be preserved separately from canonical comparison; do not silently merge distinct accounts.
2.2 account comparisons use the registered provider's documented identifier behavior. For email-like identifiers, domain case may be normalized when that provider expressly supports it; do not silently strip dots, plus tags or case-fold the local part based on assumptions. Until an account comparison rule is established, exact bounded account text is required and ambiguous duplicates are held for human resolution. Protect full account values from broad worker-facing display and telemetry.
2.3 Each tuple MUST have a single registry entry. A second registration with the same tuple returns that same existing entry or a recorded duplicate request; it MUST NOT create a new worker. Distinct selectors intentionally create distinct worker identities, even when type/provider/account match. A provider model version, UI tab, browser profile or changing conversation ID is session context, not part of the four-field identity.
2.4 Identity tuple changes (account rename, provider migration, selector reclassification) require an explicitly authorized migration linking old and new tuples, rechecking ownership and permissions, and preserving historical references. Do not silently overwrite or merge identities. A retired identity MUST NOT automatically be reassigned while historical evidence or permissions remain attached.

3. UNIQUE NICKNAME REGISTRY AND PRE-ONBOARDING
3.1 One nickname MUST resolve to exactly one active or reserved worker identity, through a centrally serialized registry. No two active workers may share the same canonical nickname, regardless of provider or selector. Workers have no right to assign, rebind, or self-approve their nickname.
3.2 The CEO or duly authorized onboarding role MAY reserve a nickname before onboarding. A reservation records intended nickname, approving human instruction reference, scope, reservation UTC, and whether the tuple is not yet bound. A reservation is not an authenticated worker and grants no permissions. Binding requires the complete four-field tuple plus a verified authorized registration transaction. Recheck exclusivity at bind time.
3.3 Existing reservation: "Alex" remains assigned only to the CEO-designated founder identity. If another worker requests the same root name, the simple central allocation rule uses "Alex A", "Alex B", "Alex C" ... "Alex Z", "Alex AA" and onward, ordered by original successful allocation, without changing or recycling prior assignments. The same pattern applies to any duplicated root nickname. The CEO may assign a distinct nickname before onboarding; a pre-reserved name is skipped by automatic allocation.
3.4 A nickname is an intuitive reference for humans and for GetWorkerContinuity, but never credentials or authorization. A claimed "Alex" in a message, URL, DOM field, filesystem filename, or model output is NOT proof of the corresponding authenticated worker.
3.5 Nickname renames require authorized action, preserve the historical alias mapping without granting the alias to another worker, and do not modify the tuple. Registry commit, collision check and alias/reservation entry MUST be atomic or serialized. Failure midway must not yield two workers with one nickname; concurrent, offline or disconnected registrars must fail closed or reconcile through the designated central owner.
3.6 Unnamed, pre-onboarding and decommissioned workers may be represented internally by the four-field tuple and explicit registration state, not a fabricated unique nickname. A nullable nickname must not be displayed to humans as a false unique name. No additional corporation ID or GUID is needed for this design; storage boundaries and authenticated access still isolate deployments.

4. AUTHENTICATION, PRIVACY AND PROVIDERUID
4.1 Registered identity is not authentication. The framework MUST verify the connecting session using an authorized channel, authenticated account binding and eligible role. providerUID, when available and independently verified against a trusted provider claim, MAY strengthen the check but MUST NOT silently replace the four-field ID or grant extra permissions. A self-asserted providerUID is merely untrusted data.
4.2 No employee, worker or founder gets CEO authority simply by selecting ChatGPT.com, entering a matching email, obtaining a nickname, controlling a browser profile, or possessing a continuity document. Authorization is decided independently by RFC-AI 28 and 32.
4.3 Identity records are private; common training templates and public RFCs MUST use synthetic/example.invalid accounts. Worker contact documents MUST minimize or mask account strings for recipients without a need to know. Never publish secrets, private recovery material, session cookies, provider tokens or personal contact details.
4.4 Provider unavailable, changed account label, missing UID, multiple authenticated sessions, lost nicknames, conflicts in legacy worker GUID data and suspected impersonation must produce an explicit state (UNVERIFIED / CONFLICT / BINDING_REQUIRED), not an invented successful verification.

5. SIMPLE-LOGIC REGISTRATION AND LOOKUP
5.1 REGISTER: validate type/provider/selector/account; normalize ONLY according to a registered documented rule; under exclusive registry transaction check tuple collision; check nickname reservation/exclusivity; commit tuple and one nickname mapping atomically; return exact registered tuple, nickname, observed revision and receipt. No AI-generated identifier or probability-based match.
5.2 RESERVE_NICKNAME: authenticate authorized human; apply collision-free A/B/C sequence and immutable allocation ordering; record pending reservation, human authority reference, expiry only if human policy defines one. Do not silently recycle.
5.3 LOOKUP_BY_ID requires all four fields. LOOKUP_BY_NICKNAME accepts a unique exact registered nickname and returns a tuple only after caller authorization. RESOLVE_SESSION additionally verifies the actual provider/account binding; it MUST NOT trust user-supplied JSON alone.
5.4 Persist registry decisions in one named authoritative private location under RFC-AI 34; keep revision, audit, lineage and recovery history separately. Schema validation MAY use JSON Schema 2020-12, supplemented by registry uniqueness and transaction checks; schema validity alone cannot prove uniqueness or user identity.

6. REQUIRED DESIGN/ACCEPTANCE EXERCISES
6.1 Two identical four-tuples cannot create separate workers; two different selectors can; duplicate nickname collision follows oldest-first suffix allocation; Alex reservation is immutable without authorized CEO change.
6.2 Reservation before contact, concurrent registration, restart during save, case/alias ambiguity, Unicode, expired/offline reservation, A-Z/AA overflow and historical alias re-use are tested.
6.3 A spoofed nickname/providerUID or claimed ChatGPT account without authenticated binding confers no access. Identical browser tabs do not create phantom workers. A changed account cannot inherit old permissions by name coincidence.
6.4 Historical event attribution remains possible after nickname rename and tuple migration; privacy filtering hides account details from unauthorized workers; registry source revision and audit receipts are independently read back.
6.5 All tests identify outcomes and exact observed source identities. Only the CEO can approve an RFC edition or release gate; drafting this RFC does not register or authenticate anyone.

7. PRIOR ART AND ADAPTATION
7.1 Google Cloud Workforce Identity Federation advises uniqueness, immutability and non-reuse of principals; we intentionally use the CEO-approved four-field composite instead of adding a corporate GUID and mitigate its mutability with strict migration/history rules: https://docs.cloud.google.com/iam/docs/best-practices-workforce-identity-federation
7.2 OpenTelemetry distinguishes provider, agent, model and conversation IDs; keep session/context identity separate from our four-field worker identity: https://opentelemetry.io/docs/specs/semconv/gen-ai/
7.3 JSON Schema structural validation supplies syntax checking, not transaction uniqueness or authentication: https://json-schema.org/draft/2020-12/json-schema-validation
7.4 Existing private Corporate Extension Master Nickname Registry records Alex/Jack reservations and suffix rules; this RFC preserves the applicable CEO policy without inheriting any unaudited assertion of live deployment.

8. DEPENDENCIES / DAVG / STATUS
8.1 Requires editorial RFC-AI 9 registry allocation, source reconciliation, authorized identity bindings, concurrency tests, data protection and separate live deployment authorization. Existing older worker GUID references are legacy historical data and must not be destroyed or treated as the new tuple until verified reconciliation.
8.2 DAVG critical risks: an email/account may be renamed or reused; selectors might be ambiguous; spoofing a nickname can impersonate a founder; browser sessions are not provider attestations; naming can leak PII; concurrent registration can allocate duplicates. Mitigations are explicit above. Open integration question: which authenticated connector claims can verify each provider at contact; return UNVERIFIED until tested.
8.3 DESIGN ONLY. No production code, populated registry, migration or permission change is authorized by this draft. Subsequent approved editions control implementation.


DAVG DESIGN CORRECTION — 2026-11-02 UTC (DRAFT; SEE RFC-AI 37)
CANONICAL CLARIFICATION (CEO): the unique worker ID remains exactly type + provider + selector + account. selector MUST exist and MAY be the empty string ""; it is part of identity, but working-mode is an OPTIONAL, non-key field. Its exact JSON name is "working-mode", not any alternate key. ChatGPT.com with blank selector may operate under "work" or "chat" without creating another Alex. nickname is a unique human-readable second index for that same tuple; providerUID is optional verification-only. Neither mode, model version, browser tab, conversation ID nor provider profile can add a fifth identity component. RFC-AI 37 owns modes and observed capabilities. Record mode on each execution/session record rather than overwriting historical identity. Account rename or recovery requires verified migration, not provider-inferred equality. Tests: blank/missing selector distinct; same ID in both modes; distinct selector creates new ID; nickname collision blocks; 2 concurrent registrations return same tuple.


DOCUMENT CLASSIFICATION — RFC-AI RESEARCH-FIRST RECONCILIATION (2026-11-02T20:28:09.285Z)
DOCUMENT CLASS: STANDARD — TECHNICAL STANDARD DRAFT
This document contains normative technical format, protocol, security, interface, or evidence contract detail for its defined subject. The detail is an intended Standard rather than evidence that software has been built or deployed. Legacy software and its records are background research only; no RFC-AI component is implemented.
DAVG judges future objectives and observed results, rather than presuming legacy implementation or declaring these drafts active. CEO approval and independently observed operational evidence are still required for any future activation.


## HISTORICAL FAILURE EVIDENCE — RESEARCH ONLY; NOT AN RFC-AI IMPLEMENTATION
Historical context: Session/provider identity and nickname were conflated with a verified human/worker authorization binding.
Historical reports have mixed evidence quality; verify primary facts before adopting a claimed root cause. Preserve source provenance and do NOT operationalize retired legacy policies as current RFC authority.

## MUST-DESIGN CRITERIA — CEO-DIRECTED PROPOSED FUTURE SYSTEM
MUST-33-UTC: Any current UTC datetime, timestamp, deadline, source-freshness comparison, expiry, or chronological identifier MUST obtain current time through GetUTCDateNow() or its approved typed Time Interface result. AI workers and application code MUST NOT read a host local clock directly for corporate decisions. The Time Interface owns actual synchronization, drift detection, freshness evidence and explicit uncertain-clock handling; a stored expiration alone never proves clock correctness. This is a future design obligation, not an implemented service.

MUST-33-01: MUST distinguish the four-part worker identity tuple and nickname from authenticated worker possession; no identity string establishes permission.
MUST-33-02: MUST bind provider/account/selector/actual session through authorized authentication and check current role/resource permissions separately; recovery requires explicit rebind.

IMPLEMENTATION STATUS: Entire RFC-AI system NOT IMPLEMENTED. Historical systems are independent past research material; no test or existing service may be counted as implementing this RFC-AI.


## ADDITIONAL MUST-DESIGN CRITERIA — 2026-11-02 (PROPOSED, NOT IMPLEMENTED)
Historical trigger: legacy materials repeatedly confused authored progress, scripts and document content with real observed execution; this is research evidence, not proof of any new RFC implementation.
MUST: Separately verify asserted worker identity, authenticated session, role qualification examination and assignment authority; claimed expertise and nickname never confer privilege.
MUST consider the concrete literal behavior of competent AI workers and enforce required hard safeguards by simple, separately running Interface logic where an actual boundary exists. MUST not delegate Interface internal details back to this guiding document. MUST preserve the requirement in relevant top-level objectives.txt and independently verify that future implementation satisfies it. New requirements here remain draft, not live controls.

## DESIGN AMENDMENT 2026-11-03 — IDENTITY VERSUS EXECUTOR
REQ-AI-33-ID-001: Corporate four-field worker identity, nickname, provider session, execution host, privileged executor, human principal and target machine MUST be separately typed and independently verified. A remembered nickname cannot authorize a tool.
REQ-AI-33-ID-002: Continuity uses current authenticated worker identity, Context uses independent real runtime and machine observations, Assignment comes LAST with authenticated human objective and owner epoch; historical sessions MUST NOT be promoted into current facts.
REQ-AI-33-ID-003: Credentials, provider entitlements and temporary grants MUST be scoped, expiring, revocable and verified at protected execution, preferably using maintained workload identity mechanisms where appropriate.

DESIGN CORRECTION IDENT-11 — Corporate worker, session, machine and authority as different identities
RATIONALE: The actual AI may run remotely while its tools execute on Alpine and the CEO uses another machine. A nickname or listed connector is not an authenticated session.
REQUIRED FUTURE BEHAVIOR: The future identity Standard MUST type corporate worker ID, provider session/workload, actual tool executor host, user's observed device, selected assignment target, human principal and delegated authority separately. Each requires its own provenance and TTL. Current organizational position and machine context SHOULD be observed before any assigned target overlay is added to the optional Assignment section of ONE contact document. Credentials MUST be narrow, revocable and verified at the actual protected effect; an observed host or tool does not imply permission.
ADVERSARIAL DESIGN ACCEPTANCE: Provide a worker on remote AI, shell running Alpine and unobserved CEO laptop. Context must label these separately and mark laptop UNKNOWN. Attempt an operation using nickname-only authority and reject it.
SCOPE: Draft future design and test contract; NOT installed RFC-AI software.