§ NEW · Unified Identity Architecture
@dosfi.ai — The Secure Identity Fabric
One identity. One login origin. Cryptographically hardened across DOSFI.ai, MeshInfer.AI, MeshNativeExchange, DOSFI Academy, DOSFI University, mesh-native apps, agents, enterprise nodes, and every 20-node mesh participant. This is not an email service. It is the identity fabric woven into every system.
F.1
What the identity fabric is — and is not
The @dosfi.ai Identity Fabric is a single, cryptographically-hardened identity layer. Every principal in the Distributed Intelligence Stack — users, agents, devices, mesh nodes, and enterprise organizations — is issued an identity by one authority: the DOSFI Identity Service at identity.dosfi.ai.
There are no sub-systems with their own login. There are no separate identity stores per platform. There is no re-registration when moving between DOSFI, MeshInfer, Academy, or University. One identity creation event propagates everywhere, immediately and atomically.
What this is not
@dosfi.ai addresses are identity tokens — not email addresses. There is no webmail, no IMAP/POP3, and no general-purpose inbox. System notifications are outbound-only from authenticated DOSFI services. No passwords are ever entered outside
identity.dosfi.ai.Identity principals
F.2
Identity creation — the full provisioning sequence
Identity creation is a single atomic event that propagates across all five systems in under 500 ms. No manual provisioning step is required on any downstream platform.
User identity creation
sequence
Browser / App identity.dosfi.ai All five systems
│ │ │
│── POST /signup ───────────►│ │
│ { email, display_name } │ │
│ │── generate username@dosfi.ai
│ │── generate UserID (uuid4)
│ │── issue Ed25519 keypair (stored securely)
│ │── sign UserID certificate (24h TTL, auto-renew)
│ │ │
│ │── PROPAGATE ────────────►│
│ │ event: user_created │
│ │ { user_id, email, │
│ │ identity: username │
│ │ @dosfi.ai } │
│ │ ┌─────┴──────────────────┐
│ │ │ Each system registers │
│ │ │ the identity via its │
│ │ │ OIDC service webhook │
│ │ └────────────────────────┘
│◄── 201 Created ───────────│
│ { identity: username@dosfi.ai,
│ access_token (15 min),
│ refresh_token (30 days) }What propagates to each system at creation
Device binding — required before node participation
sequence
Device (daemon) identity.dosfi.ai
│ │
│── generate Ed25519 keypair │
│ (in OS Keychain/Keystore/ │
│ WebCrypto — private key │
│ never leaves device) │
│ │
│── POST /devices/bind ─────────►│
│ { user_id, pub_key, │
│ device_type, platform, │
│ device_fingerprint_hash } │
│ │── verify UserID token
│ │── issue DeviceID (did:mesh:{hash})
│ │── sign DeviceCert (Ed25519, 24h TTL)
│◄── { device_id, device_cert } ─│
│ │
│ Store device_cert securely │
│ → used for mTLS in G.3 │F.3
Identity propagation — cross-system consistency
The DOSFI OIDC token is the single credential that all five systems accept. It is never re-issued per-platform. All system-specific authorizations are claims embedded within the token — not separate sessions.
Token claim structure
json
// DOSFI OIDC Access Token — decoded payload
{
"sub": "usr_a1b2c3...", // UserID
"identity": "alice@dosfi.ai",
"org_id": "org_acme_prod", // null for personal accounts
"device_id": "did:mesh:abc123", // null if no device bound
"node_id": "node_f9a3e2b1...", // null if no active node
"subscription_tier": "growth", // developer|startup|growth|enterprise
"privacy_policy": "mesh_ok", // local_only|mesh_ok|cloud_ok
"enrolled_courses": ["msi-101", "msi-102"], // DosfiAcademy claims
"certification_tier": "professional_architect", // DosfiUniversity claims
"agent_ids": ["agnt_home..."], // deployed agents
"routing_permissions": ["local", "mesh"], // derived from subscription_tier
"iat": 1751808000,
"exp": 1751808900, // 15-min TTL
"iss": "https://identity.dosfi.ai",
"aud": ["meshinfer.ai", "meshnativeexchange.com",
"dosfiacademy.com", "dosfiuniversity.com"]
}How each system uses the token
No platform-specific sessions
Navigating from MeshInfer.AI to DosfiAcademy.com to DosfiUniversity.com involves zero additional login events. The OIDC token is presented by the browser (HttpOnly cookie, domain-locked) and verified by each platform independently against the DOSFI JWKS endpoint. The user is never prompted to log in again.
F.4
Identity verification — per-request enforcement
Every API call, inference request, DIU event, and node heartbeat is verified against the DOSFI OIDC token. Verification is synchronous, cryptographic, and never cached beyond the token TTL.
Verification steps — every request
sequence
Request arrives at any system boundary
│
├─ 1. Extract Bearer token from Authorization header or HttpOnly cookie
│
├─ 2. Fetch current JWKS from identity.dosfi.ai/.well-known/jwks.json
│ (cached up to token exp; invalidated on key rotation event)
│
├─ 3. Verify JWT signature (Ed25519) against matching kid in JWKS
│ ✗ invalid sig → 401 Unauthorized; log to AuditLog (action: auth_failure)
│
├─ 4. Verify iat, exp, iss, aud claims
│ ✗ expired → 401; client must refresh via refresh_token
│ ✗ wrong aud → 403; token not intended for this system
│
├─ 5. Check device_id claim (if node operation)
│ ✗ device_id missing or not registered → 403
│ ✗ node_id mismatch → 403 + AuditLog (action: node_id_mismatch)
│
├─ 6. Enforce privacy_policy claim (if inference request)
│ local_only + route ≠ local → 403 (privacy_policy_violation)
│
├─ 7. Enforce subscription_tier claim (if routing / feature access)
│ tier insufficient → 402 (subscription_upgrade_required)
│
└─ 8. Proceed with request; all events attributed to sub + org_idIdentity verification across all 20 nodes
| Token presentation | Every task dispatch envelope from the Coordinator includes the requester's identity token (encrypted, node-bound). The node daemon verifies the token before decrypting the prompt. |
| Node cert verification | On every heartbeat, the Coordinator verifies the heartbeat signature against the DeviceID-bound Ed25519 public key stored at registration. Mismatched signature → immediate node eviction + AuditLog. |
| mTLS (node ↔ Coordinator) | All node-Coordinator communication uses mTLS. The client certificate is the DOSFI-signed DeviceCert. Expired certs (24h TTL) are auto-renewed; renewal failure → node enters "cert_expired" state and stops receiving tasks. |
| Verification sampling | 2% of all completed inference tasks are re-dispatched by the Coordinator as verification tasks. The result hash is compared against the original. Hash mismatch = identity-bound reputation penalty + investigation flag. |
F.5
Identity revocation — immediate, cascading, irrevocable
Revocation is the most critical identity operation. The DOSFI Identity Service propagates a revocation event to all five systems within 5 seconds. Every principal downstream of the revoked identity is simultaneously invalidated.
Revocation cascade
identity-chain
REVOKE UserID: usr_a1b2c3
│
├─ access_token invalidated immediately (added to revocation list)
├─ refresh_token revoked — no new access tokens issuable
├─ DeviceID → DeviceCert revoked — mTLS connections dropped within 5 s
│ └─ NodeID removed from routing pool immediately
│ └─ DIU wallet: pending unsettled events held 24h for review
│ └─ settled DIU is final and accessible post-review
├─ AgentIDs revoked — agent signing key invalidated
├─ OrgID membership revoked (if member) — org policies no longer apply
├─ DosfiAcademy session invalidated — content access blocked
└─ DosfiUniversity session invalidated — exam tokens voidedRevocation triggers and actors
Single revocation point
Revoking a UserID at identity.dosfi.ai is the only action required to fully deactivate a principal across all five systems, all mesh nodes, all agents, and all enterprise contexts. There is no need to manually invalidate sessions in each downstream system.
F.6
Identity recovery — verified, phased, audited
Recovery flow
sequence
User requests recovery → identity.dosfi.ai/recover
│
├─ 1. Email ownership verification
│ → one-time signed link (15-min TTL, single-use) sent to registered email
│ → link click proves domain ownership; no password requested
│
├─ 2. MFA verification (if enrolled)
│ → TOTP or WebAuthn passkey challenge
│ → Required for accounts with active mesh nodes or enterprise org membership
│
├─ 3. Recovery scope selection
│ → Recover session only (new tokens, existing devices intact)
│ → Recover + revoke all devices (new tokens + all DeviceIDs invalidated)
│ → Full recovery (all of above + new Ed25519 keypair issued)
│
├─ 4. New tokens issued
│ → New access_token (15 min) + refresh_token (30 days)
│ → Propagated to all five systems via user_recovered event
│
└─ 5. Recovery event written to AuditLog
{ action: "identity_recovered", user_id, scope, timestamp }Recovery constraints
| MFA-gated operations post-recovery | Re-linking mesh nodes, re-deploying agents, and accessing enterprise org admin functions all require fresh MFA challenge after recovery, even within the same session. |
| NodeID post-recovery | Existing NodeIDs are suspended for 1 hour post-recovery (safety window). Nodes auto-resume if no anomaly is detected. Manual resume available via Coordinator admin. |
| DIU wallet | DIU wallet access is restored immediately on successful recovery. Pending unsettled DIU remains in held state until the node safety window clears. |
| No recovery without email access | If the registered email account is also compromised, recovery requires identity.dosfi.ai support. This is a deliberate security property — no backdoor recovery path exists. |
F.7
Privacy tier enforcement — structural, not policy
Privacy tiers are claims in the DOSFI identity token. Every system in the stack enforces them structurally — before any network I/O, not as a logging filter applied after the fact.
Privacy tier definitions
| local_only | Inference executes exclusively on the requester's own device. No prompt data leaves the device. AbortController fires before any mesh or cloud dispatch attempt. Enforced synchronously in the SDK before any outbound call. |
| mesh_ok | Inference may execute on peer mesh nodes within the same OrgID's permitted routing pool. Prompts are end-to-end encrypted (AES-256-GCM, ephemeral session key per task). Peer nodes see only ciphertext. |
| cloud_ok | Inference may fall back to cloud providers when local and mesh capacity is insufficient. Cloud providers receive the plaintext prompt under their own data processing agreements. |
Enforcement architecture — three layers
Privacy is enforced at three independent layers, each of which must be defeated for a violation to occur:
| Layer 1 — SDK (client-side) | Before any network call, the SDK reads the privacy policy from the token. For local-only requests, the SDK verifies a local runtime is available and executes locally — the Coordinator is never contacted. No network dispatch can fire. |
| Layer 2 — Gateway (server-side, synchronous) | On every request, the Gateway evaluates the privacy policy claim from the token. If the policy forbids the requested route (e.g., local-only with a non-local route, or mesh-ok with a cloud route), the request is rejected with a 403 before any dispatch. |
| Layer 3 — Node daemon (node-side, before decryption) | Before decrypting the task envelope, the node verifies the requester's privacy policy. If the node's local configuration conflicts with the requester's policy (e.g., a local-only node receiving a cross-org task), the node NACKs the task without decrypting it. The plaintext result is encrypted before transmission. |
F.8
Identity-bound compute metering & DIU economics
Every metering event, DIU spend record, DIU issuance event, and settlement log carries the full identity chain of the requesting identity and serving node. There is no anonymous inference in the Distributed Intelligence Stack.
Identity fields in every metering event
Every metering event carries the full identity chain of both the requester and the serving node. The requester fields include the user identity, org ID, subscription tier, and privacy policy. The serving node fields include the node ID, device ID, owner identity, and DIU wallet reference. Economic fields record the DIU spend and issuance amounts. All fields are required and verified — there is no anonymous inference in the Distributed Intelligence Stack.
Identity-bound DIU spend rules
| Spend attribution | DIU spend is always debited from the requester's OrgID wallet (or personal wallet for solo users). The identity in the token is the billing identity — not the caller's IP or API key. |
| Spend cap enforcement | If subscription_tier == "developer", spend is capped at 500 DIU/month. Exceeding the cap blocks dispatch (402). Cap is checked synchronously at the Gateway using the token's subscription_tier claim. |
| Overage | Growth/Enterprise tiers may configure overage: additional DIU debited beyond plan cap at overage rate. Overage is attributed to the identity, not the API key. |
Identity-bound DIU issuance rules
| Issuance attribution | DIU is always issued to the NodeID's owner UserID DIU wallet. If the node is org-operated, DIU flows to the org wallet (OrgID-bound). |
| Sybil prevention | A single UserID cannot own an unbounded number of NodeIDs simultaneously (enforced by Identity Service). This prevents artificial reputation inflation via self-dealing. |
| Self-dealing prevention | When the requester is also the serving node owner, the quality multiplier is capped (no elite bonus for self-served tasks). |
F.9
Cross-system identity flow map
topology
┌────────────────────────────────────────────────────────────────────────────┐
│ DOSFI IDENTITY SERVICE │
│ identity.dosfi.ai · OAuth 2.0 + OIDC │
│ │
│ Authorities: UserID · DeviceID · NodeID · AgentID · OrgID │
│ Endpoints: /signup · /devices/bind · /agents/deploy · /recover │
│ Protocols: Ed25519 JWT · DPoP (RFC 9449) · mTLS · PKCE │
└──────────────────────┬─────────────────────────────────────────────────────┘
│ OIDC token propagated to all systems
┌────────────────┼────────────────────────────────────────┐
│ │ │
▼ ▼ ▼
┌──────────────┐ ┌────────────────────────────────────────┐ ┌──────────────┐
│ DOSFI.ai │ │ MeshInfer.AI │ │ MeshNative │
│ │ │ │ │ Exchange │
│ Runtime │ │ Gateway → verifies sub, device_id, │ │ │
│ Scheduler │ │ node_id, privacy_policy │ │ DIU wallet │
│ Identity │ │ Router → enforces subscription_tier │ │ debited by │
│ gate │ │ Meter → attributes spend to sub │ │ org_id from │
│ Privacy │ │ Issuer → attributes issuance to │ │ token │
│ model │ │ node owner sub │ │ │
│ Storage │ │ Settlement → carries full identity │ │ Issuance │
└──────────────┘ │ chain in every log record │ │ credited to │
└────────────────────────────────────────┘ │ node_id │
│ owner sub │
┌───────────────────────────────────────────────────── └──────────────┘
│ │
▼ ▼
┌──────────────────────────┐ ┌────────────────────────────┐
│ DosfiAcademy.com │ │ DosfiUniversity.com │
│ │ │ │
│ sub → student account │ │ sub → candidate profile │
│ enrolled_courses → gate │ │ certification_tier → gate │
│ Lab environments tied │ │ Architect claims added │
│ to sub; DIU metering │ │ to token on exam pass │
│ in SDK labs uses same │ │ Enterprise org certs │
│ identity + wallet │ │ scoped to OrgID claim │
└──────────────────────────┘ └────────────────────────────┘
↕ All 20 Mesh Nodes
┌────────────────────────────────────────────────────────────────────────────┐
│ MESH NODE LAYER (20 nodes) │
│ │
│ Each node: │
│ ├─ Presents DeviceCert (DOSFI-signed Ed25519) on mTLS connect │
│ ├─ Verifies incoming task token against DOSFI JWKS before execution │
│ ├─ Enforces privacy_policy claim before decrypting prompt │
│ ├─ Signs heartbeats with DeviceID Ed25519 private key │
│ ├─ Attributes all earned DIU to NodeID → owner UserID wallet │
│ └─ Writes settlement + health events with full identity metadata │
└────────────────────────────────────────────────────────────────────────────┘
F.10
Agent identity security
Agents are first-class identity principals. Each deployed agent receives a dedicated @dosfi.ai identity and is authorized to invoke MeshInfer inference under its owner's privacy and tier policy.
Agent identity binding
| AgentID format | agentname@dosfi.ai (personal) · agentname@company.dosfi.ai (enterprise) |
| Deployment gate | Agent deployment requires MFA confirmation from the owning UserID. No agents can be deployed without explicit human authorization. |
| Inference authority | Agents inherit the owner's subscription_tier and privacy_policy claims. An agent cannot request routing or privacy tiers exceeding those of its owner. |
| Signing | Every alert, summary, and inference result produced by an agent is signed with the agent's Ed25519 private key. Recipients can verify the signature offline using the published agent public key at identity.dosfi.ai/agents/{agentname}. |
| Revocation | Owner can revoke any agent identity at identity.dosfi.ai/agents. Revocation propagates to all five systems within 5 s. All in-flight agent inference requests are cancelled. |
Agent DIU accounting
| Spend attribution | Agent inference spend is debited from the owner UserID's DIU wallet. Agents do not have independent wallets. |
| Spend visibility | The metering event records both the AgentID and the owner UserID, so per-agent spend can be reported separately in the usage dashboard. |
| Audit | Every agent action is written to AuditLog with agent_id and owner_user_id. Agents cannot perform unattributed operations. |
F.11
Enterprise identity — org-scoped namespaces
Org namespace provisioning
sequence
Enterprise admin identity.dosfi.ai All five systems
│ │ │
│── Hardware MFA challenge ─────►│ │
│◄── challenge signed ───────────│ │
│ │── provision OrgID namespace:
│ │ company.dosfi.ai
│ │── create admin@company.dosfi.ai
│ │── issue org root Ed25519 keypair
│ │── register org DIU wallet (OrgID-bound)
│ │ │
│ │── PROPAGATE ────────────►│
│ │ event: org_created │
│ │ { org_id, admin_id, │
│ │ org_namespace } │
│◄── org provisioned ───────────│ │Enterprise permission mapping — across all systems
Cross-org request boundary
| Default | All inference requests from an OrgID are isolated to that org's routing pool. Cross-org task dispatch is blocked at the Gateway. |
| mesh_ok override | Org admin can enable mesh_ok policy at the org level. This allows any org member's requests to be served by any mesh node — still encrypted end-to-end. |
| Cryptographic enforcement | Org boundary is enforced by the OrgID claim in the OIDC token. Forging an org boundary crossing requires forging an Ed25519-signed JWT — computationally infeasible. |
F.12