FAN
Identity Protocol
Comunidade
Links
Detalhes
Licença Open source — AGPL 3.0 (implementation) + CC-BY-SA (specification); primary repo at git.deepnet.com/fan/; specification mirror at github.com/federated-auth-network/federated-auth-network
Status de Dev 🟢 Ativo
Detalhe do Status de Dev Alpha (Android Identity Manager app v0.0.21 released; web demo at fan.ngrok.app; GreenCheck integration near-complete; iOS app in development; specification published)
Proprietário Consensual Ventures (lead); coalition includes NooNAO, Terran Collective, Social Systems Labs, Catalist Network, and other CTA members. Specification authored by Erik Hollensbe. Key contributors: Day Waterbury, Tibet Sprague, Clay Joy Smith, Vincent Arena, A. Keala Young, Simon Grant
País USA (distributed team)
Ano de Início 2023
Stack TypeScript/JavaScript (fanauthmanager app); HTTP over TLS 1.3 (protocol transport); JWE/JWS (cryptographic operations); JSON/JSON-LD/CBOR (DID document formats)
Financiamento Donations via CTA Open Collective (fiscal host: Empowerment Works); 2024 goal: $280K as part of $28M Ecosystem Raise with close partners
Última Investigação 15 de jan. de 2026
Identity Protocol Atributos
Origins Decentralized identity / Authentication protocol (inspired by OpenSSH 2 key-pair authentication and OpenSSH Agent model; designed as alternative to OAuth/OpenID centralized authentication agent model; addresses password fatigue, database compromise risks, and Big Tech data harvesting)
Database None required on authenticating websites (by design — websites are NOT REQUIRED to store any key material, making wide-scale authentication compromise virtually impossible; DID documents fetched on demand or optionally cached per RFC 9110 caching rules)
Query Language N/A (DID resolution via HTTP GET to well-known paths: /fan.did for agent DIDs, /did-fan/user/{identifier}.did for user DIDs)
Data Formats W3C DID documents (JSON, JSON-LD, or CBOR — MIME types application/json+did, application/jsonld+did, application/cbor+did); JWS (RFC 7515 — signed identity documents and authentication responses); JWE (RFC 7516 — encrypted authentication challenges); JWK (RFC 7517 — key representation)
Mobile Support Yes (Android Identity Manager app v0.0.21 available as APK from git.deepnet.com; iOS app planned as next development epic)
Web Support Yes (web demo at fan.ngrok.app for proof-of-concept sign-up and sign-in; protocol designed for web-native HTTP/TLS integration)
Native Apps Android (FAN Auth Manager app, debug release v0.0.21); iOS (planned, next development phase)
Terms Free / Open source (AGPL 3.0 for implementation, CC-BY-SA for specification; no usage fees for protocol)
Funds $14,769 total raised (as of Feb 2025 on Open Collective); contributors include Collaborative Technology Alliance ($8K), Brad ($4.2K), Day Waterbury ($1.6K), and others; recent expenses include FAN/GreenCheck & FedID integration work ($1,500 Jan 2025, $1,000 Jan 2025)
Based On W3C Decentralized Identity Documents (DID-core); RFC 7515 (JWS), RFC 7516 (JWE), RFC 7517 (JWK); protocol inspired by OpenSSH 2 key-pair authentication and OpenSSH Agent model; GreenCheck (proof-of-humanity integration); compatible with DID ecosystem
Permissions AGPL-3.0 / CC-BY-SA (dual-licensed) — The FAN Specification v1 is © 2023 Erik Hollensbe and published under CC-BY-SA 4.0 for the specification text and AGPL-3.0 for any reference implementation code. AGPL-3.0 requires that any network-deployed derivative works make source code available to users; the Android reference app (fanauthmanager) is hosted on the FAN GitLab.
Authentication & Identity Sovereign PassKeys: user generates a cryptographic key pair; public key published in a DID document hosted by an Agent; identity format is user@domain.ext (modeled after RFC 2822 with UTF-8 identifier support and internationalized domain names); authentication is passwordless challenge-response — website encrypts random data with user's public key (JWE), user decrypts with private key and returns signed proof (JWS); no passwords or private material ever stored on websites
Storage Model Distributed by design: Agent servers host signed DID documents (JWS-wrapped) at well-known HTTP paths; authenticating websites store NO key material and NO authentication credentials; private keys stored only on user's device; DID document caching optional per RFC 9110 rules with If-Modified-Since/Last-Modified freshness checks; CDN-compatible (DID documents can be served via content delivery networks)
Interoperability High: any website can implement FAN by serving/consuming DID documents over standard HTTPS; protocol conforms to W3C DID-core, RFC 7515/7516/7517, RFC 9110; multiple DID document MIME types supported (JSON, JSON-LD, CBOR); integration with GreenCheck for proof-of-humanity; integration with FedID underway (Jan 2025 work documented); designed for CTA ecosystem adoption and broader Fediverse compatibility
Data Portability High: user identity is a DID document that can be served by any compliant Agent; Sovereign DID mode allows users to present DIDs directly without depending on any Agent at all (did:fan:_sovereign_:{identifier}); protocol designed so users maintain 'continuity, context, and control of their own data' when moving between tools
Governance & Decision Making Coalition-led: Consensual Ventures leads with CTA partner organizations; Open Collective for transparent financial management (Empowerment Works as fiscal host); specification authored by Erik Hollensbe with community review (James Tucker); team includes admins and core contributors from multiple organizations
Protocol Maturity / Standardization Community Standard (published SPEC.md with did:fan method; CTA community-governed; RFC-conformant design but not formally submitted)
Identity Standards W3C DID-core (Decentralized Identity Documents, W3C Recommendation); RFC 7517 (JSON Web Key); RFC 7515 (JSON Web Signature); RFC 7516 (JSON Web Encryption); RFC 3629 (UTF-8); RFC 5890 (Internationalized Domain Names); RFC 9110 (HTTP 1.1 Semantics); RFC 2119 (requirement level keywords)
DID Methods Supported did:fan (custom method — format: did:fan:{domain}:{identifier}; e.g., did:fan:fan.example.org:alice); Sovereign DIDs (did:fan:_sovereign_:{identifier} for agent-independent identities signed by user's capabilityInvocation keys); supports internationalized identifiers with percent-encoding (e.g., did:fan:example.com:%e7%84%a1%e7%88%b2)
Key Management User-controlled private keys on device only; private key material MUST NOT be divulged from where it is stored for any reason; recommendation to encrypt private keys with strong symmetric cipher unlockable via passphrase; Agents MAY implement private key storage for user convenience but this is explicitly not recommended; websites MUST NOT request or store private key material; Agents SHOULD expire public keys after intervals to prevent domain compromise after registration lapse
Credential Types DID documents (W3C-compliant, containing verification methods, authentication keys, capabilityInvocation keys); JWS-signed identity assertions; Sovereign PassKeys (self-sovereign key pairs acting as portable digital identities); GreenCheck proof-of-humanity claims (via integration)
Verification Method JWS signature verification: Agent signs user DID documents with keys from Agent's own authentication section; user signs authentication responses with private key corresponding to public key in their DID; website verifies both Agent signature (to trust the DID document's provenance) and user signature (to prove possession of private key); TLS certificate verification required against trusted certificate authorities
Privacy Features No passwords stored anywhere; no private key material on servers; websites store no authentication credentials (making database compromise harmless for authentication); user controls all private material; Agent is not required to use, store, or review private key material; random challenge data generated fresh for every authentication attempt (minimum 16 bytes, never reused); Sovereign DID mode enables authentication without any third-party Agent involvement
Authentication Methods JWE/JWS challenge-response (primary): website encrypts random data with user's public keys from DID authentication section (JWE), user decrypts with private key and returns signed response (JWS) containing the decrypted data and a unique attempt identifier; Sovereign DID mode (alternative): user presents DID directly signed by capabilityInvocation keys, bypassing Agent lookup; no passwords, no passphrases transmitted
Revocation Mechanism Agent-mediated: Agents SHOULD expire public keys after intervals to prevent domain compromise; DID documents have Last-Modified timestamps and authenticating websites MUST check for updated DIDs on every authentication attempt; if Agent's DID is newer than cached user DID, website MUST fetch updated user DID; websites MAY reject cached DIDs if Agent is unreachable; Sovereign DIDs can be rejected by websites at discretion
Agent Types Supported Users (interactive entities such as persons); non-interactive entities (computer programs); Agents (parties involved in authentication — host DID documents, may optionally handle private key material and authentication itself); Websites (agents requiring authentication)
Wallet/Client Types FAN Auth Manager (Android app v0.0.21 — identity generation and management); web demo (fan.ngrok.app — proof-of-concept sign-up/sign-in); any digital wallet compatible with DID documents and JWE/JWS operations; spec describes a recommended user-facing agent to intercept authentication calls and ease user experience of handling cryptographic challenges
Recovery Mechanisms Not explicitly specified in protocol (private key loss is the user's responsibility by design — this is the trade-off of self-sovereignty); Agent-based key storage mentioned as possible convenience but explicitly not recommended; Sovereign DID mode allows identity to exist independently of any Agent; new key pairs can be generated and DID documents updated via Agent
Compliance / Regulations TBD (protocol designed for privacy by default — no passwords stored, no private keys on servers, no authentication material in databases; aligns with data minimization principles of GDPR; no specific regulatory compliance certification documented)
Credential Exchange Protocols FAN protocol (custom): HTTP GET to fetch JWS-signed DID documents from well-known paths (/fan.did for agents, /did-fan/user/{id}.did for users); HTTP POST for JWS-signed authentication responses; JWE Compact Form for encrypted challenges; DID caching via RFC 9110 HTTP caching semantics; Sovereign DID exchange as alternative to Agent-mediated lookup
Trust Framework Agent-anchored trust with TLS verification: Agent's DID document at /fan.did serves as trust anchor; Agent signs user DID documents with its own authentication keys; TLS certificate verification against trusted CAs required at all steps; websites verify both Agent identity (via Agent DID) and user identity (via Agent-signed user DID); Sovereign DIDs provide trust via capabilityInvocation key signing but websites MAY reject them due to weaker trust guarantees; GreenCheck integration adds proof-of-humanity social validation layer; DNS is a trust dependency (domain re-registration noted as attack vector)
Cost Model Free for users; free for implementing websites; Agent operation costs borne by Agent operators; open source (AGPL 3.0); project funded via donations through Open Collective
Censorship Resistance Moderate: Sovereign DID mode allows authentication without any Agent dependency; however, standard mode depends on Agent availability and DNS resolution (specification explicitly notes DNS compromise as a vulnerability — domain re-registration by malicious party could compromise accounts); CDN-compatible DID document serving adds resilience; no blockchain dependency means no immutable anchor but also no blockchain overhead