FAN
Protocolo de Identidade
Comunidade
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 🧪 Alpha
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
Órgão de Governança None (coalition led by Consensual Ventures with Collaborative Technology Alliance partner organizations; no formal governing body)
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
Protocolo de Identidade Atributos
Origens 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)
Banco de Dados 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)
Linguagem 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 Dados 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)
Suporte Móvel Yes (Android Identity Manager app v0.0.21 available as APK from git.deepnet.com; iOS app planned as next development epic)
Suporte 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)
Aplicativos Nativos Android (FAN Auth Manager app, debug release v0.0.21); iOS (planned, next development phase)
Termos Free / Open source (AGPL 3.0 for implementation, CC-BY-SA for specification; no usage fees for protocol)
Fundos $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)
Baseado Em 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
Permissões 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.
Autenticação e Identidade 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 Armazenamento 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)
Interoperabilidade 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
Portabilidade de Dados 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
Governança e Tomada de Decisão 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
Maturidade / Padronização do Protocolo Community Standard (published SPEC.md with did:fan method; CTA community-governed; RFC-conformant design but not formally submitted)
Padrões de Identidade 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)
Padrões de Identidade - Lista
Métodos DID Suportados 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 Suportados - Lista
Gestão de Chaves 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 Credenciais 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 Credenciais - Lista
Método de Verificação 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
Recursos de Privacidade 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 Autenticação 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 Revogação 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 Suportados 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 Carteira/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 Recuperação 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
Conformidade / Regulamentações 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 Troca de Credenciais 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 Troca de Credenciais - Lista
Estrutura de Confiança 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 Custo 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
Resistência à 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
Relacionamentos
Como esta ferramenta se conecta a outras ferramentas e organizações, a partir de relacionamentos revisados pelo responsável pelos dados do OpenHaven. Descrevem como os projetos se conectam, não a qualidade deles.
- Baseado em
- Identifica-se via
- Interopera com