FAN
Identity ProtocolsA self-sovereign key-based authentication protocol using Sovereign PassKeys and a custom DID method (did:fan) that enables passwordless authentication across websites without storing any private key material on servers. Agents host signed DID documents for users; authentication uses JWE-encrypted challenge-response verified via JWS signatures. Designed as foundational identity layer for the Collaborative Technology Alliance ecosystem and the broader prosocial/regenerative technology movement. Integrates with GreenCheck for proof-of-humanity .
Híbrido Comunidade Risco de captura baixo
Links
Detalhes
Licença AGPL
Status de Dev Released
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
Ano de Início 2023
Stack TypeScript/JavaScript, HTTP over TLS 1.3, JWE/JWS, JSON/JSON-LD/CBOR
Financiamento Community, Donations
Última Investigação 15 de jan. de 2026
Identity Protocol Atributos
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