FAN
Protocolo de Identidad
Comunidad
Detalles
Licencia 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
Estado de Desarrollo 🧪 Alfa
Detalle del Estado de Desarrollo 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)
Propietario 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
Órgano de Gobierno None (coalition led by Consensual Ventures with Collaborative Technology Alliance partner organizations; no formal governing body)
País USA (distributed team)
Año de Inicio 2023
Stack TypeScript/JavaScript (fanauthmanager app); HTTP over TLS 1.3 (protocol transport); JWE/JWS (cryptographic operations); JSON/JSON-LD/CBOR (DID document formats)
Financiamiento Donations via CTA Open Collective (fiscal host: Empowerment Works); 2024 goal: $280K as part of $28M Ecosystem Raise with close partners
Última Investigación 15 ene 2026
Protocolo de Identidad Atributos
Orígenes 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)
Base de Datos 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)
Lenguaje de Consulta N/A (DID resolution via HTTP GET to well-known paths: /fan.did for agent DIDs, /did-fan/user/{identifier}.did for user DIDs)
Formatos de Datos 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)
Soporte Móvil Yes (Android Identity Manager app v0.0.21 available as APK from git.deepnet.com; iOS app planned as next development epic)
Soporte Web Yes (web demo at fan.ngrok.app for proof-of-concept sign-up and sign-in; protocol designed for web-native HTTP/TLS integration)
Aplicaciones Nativas Android (FAN Auth Manager app, debug release v0.0.21); iOS (planned, next development phase)
Términos Free / Open source (AGPL 3.0 for implementation, CC-BY-SA for specification; no usage fees for protocol)
Fondos $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)
Basado En 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
Permisos 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.
Autenticación e Identidad 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
Modelo de Almacenamiento 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)
Interoperabilidad 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
Portabilidad de Datos 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
Gobernanza y Toma de Decisiones 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
Madurez del Protocolo / Estandarización Community Standard (published SPEC.md with did:fan method; CTA community-governed; RFC-conformant design but not formally submitted)
Estándares de Identidad 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)
Estándares de Identidad - Lista
Métodos DID Soportados 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)
Métodos DID Soportados - Lista
Gestión de Claves 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
Tipos de Credenciales 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)
Tipos de Credenciales - Lista
Método de Verificación 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
Funciones de Privacidad 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
Métodos de Autenticación 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
Mecanismo de Revocación 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
Tipos de Agentes Soportados 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)
Tipos de Billetera/Cliente 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
Mecanismos de Recuperación 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
Cumplimiento / Regulaciones 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)
Protocolos de Intercambio de Credenciales 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
Protocolos de Intercambio de Credenciales - Lista
Marco de Confianza 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)
Modelo de Costos 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
Resistencia a la Censura 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
Relaciones
Cómo se conecta esta herramienta con otras herramientas y organizaciones, según relaciones revisadas por el responsable de datos de OpenHaven. Describen cómo se conectan los proyectos, no su calidad.
- Basado en
- Se identifica mediante
- Interopera con