Membership Card Protocol
Protocolo de Identidad
Empresa
Detalles
Licencia No licence file was found in the repository (checked 2026-10-29); the project describes itself as free to use and open source . https://github.com/davidgljay/membership_card_protocol
Estado de Desarrollo 🧪 Alfa
Propietario Relationality Lab
Órgano de Gobierno Relationality Lab (author and operator today). Designed governance, per the project: RootPolicyBody (4-of-5; policy registration and logic upgrades), PressRegistryBody (4-of-5; press authorization and revocation) and DnsGovernanceBody (M-of-N, bootstrapped 1-of-1; the mcard:// namespace), all with on-chain quorum keys; the materials do not state that any body has convened
País Not stated by the project.
Año de Inicio 2026
Stack TypeScript services and SDKs; Rust contracts on Arbitrum Stylus; Arbitrum One; IPFS; ML-DSA-44 (FIPS 204) and secp256r1 signatures; ML-KEM message encryption; AES-256-GCM
Financiamiento Not stated by the project.
Última Investigación 29 oct 2026
Protocolo de Identidad Atributos
Orígenes A way for people who build community to share resources and build trust: membership credentials issued by communities themselves rather than by a platform, private by default, with proof of standing that does not depend on a central identity provider
Base de Datos Arbitrum One registry contract (a mutable pointer per card, press authorizations) plus append-only logs on IPFS; wallet services hold encrypted keyrings
Lenguaje de Consulta None. A card is found by deriving its registry address, keccak256 of its public key, then fetching its log from IPFS and decrypting it with a key derived from the same public key
Formatos de Datos A normative canonical serialization (spec Appendix A) with published conformance and versioning test vectors; card documents and log entries are encrypted JSON on IPFS; mcard:// URLs for offers
Soporte Móvil Designed for it: mobile SDKs are listed as done and sub-card keys are held in device secure storage; there is no finished app
Soporte Web A web SDK is listed as done, and a browser authentication flow (a request routed through CHAPI, or a future browser-native API) is specified; no finished frontend app
Aplicaciones Nativas None yet: the frontend app is listed as not done
Términos Described as free to use and open source, but no licence file is published; presses pay a minimal fee, roughly $0.005, to create a card and may charge for cards
Fondos
Basado En Arbitrum One (Stylus contracts, the RIP-7212 secp256r1 precompile); IPFS; ML-DSA-44 and ML-KEM post-quantum cryptography; passkeys and YubiKey backups; optional OHTTP
Permisos Press registry writes require an on-chain press authorization; issuing under a policy requires holding a press sub-card of that policy; anyone may run a wallet service and verify cards
Autenticación e Identidad Cards rather than accounts: a holder generates their own keypair on accepting a card, and the card's address is keccak256 of its public key. The master key stays cold; day-to-day signing uses device-held sub-card keys registered to it. A holder's cards are designed not to be linkable to one another
Modelo de Almacenamiento Hybrid: registry pointers on Arbitrum One; encrypted append-only logs on IPFS (AES-256-GCM, content key derived from the card's public key); keyrings held encrypted by wallet services and replicated across a federation
Interoperabilidad Its own credential design: the specification names no DIDs and lists a W3C Verifiable Credential compatibility layer only among future items . Wallet-to-site requests are routed through CHAPI. The README says a verifier is available as an npm module and a Python library; an npm package named membership-card-verifier (version 0.0.1, 2026-07-12) exists but nothing links it to the project, and no Python package was found, so neither is confirmed
Portabilidad de Datos Cards are addressed by public key on a registry contract and logs sit on IPFS, so a card can be read by anyone holding its public key; keyrings are encrypted blobs replicated across wallet services, and the holder can recover them independently of the primary service via a YubiKey backup
Gobernanza y Toma de Decisiones Protocol changes are designed to go through on-chain quorum bodies (see Governing Body); the site invites partners to take part in its governance, and today decisions rest with the author
Madurez del Protocolo / Estandarización Draft specification v0.4, "In Review", with conformance and versioning test vectors; not submitted to any standards body; mainnet contracts deployed; no independent audit yet
Estándares de Identidad None adopted: its own card and policy model, not W3C DIDs
Métodos DID Soportados
Gestión de Claves Passkey-encrypted master keys held in a keyring stored by the wallet service; sub-card keys in device secure storage (Secure Enclave or TPM) for routine signing; master keys used only to create sub-cards and rotate keys; rotation is deliberate, never automatic
Tipos de Credenciales Cards: signed credentials defined by a policy (membership, roles, sub-cards, press authorizations), with typed fields and predicates and a three-digit update code for each log entry
Método de Verificación A verifier walks the chain of cards from the presented key back to a trusted root, checking each signature, that the issuer was authorized by policy, and that no revocation applies; signatures are ML-DSA-44, and press registry writes are verified on-chain with secp256r1
Funciones de Privacidad Private by default: card content is encrypted on IPFS and readable only with the card's public key; a holder's cards are designed to be unlinkable; messages are end-to-end encrypted; optional OHTTP hides the requester's IP from the wallet service. The registry pointer and its updates are public on-chain
Métodos de Autenticación A wallet signs a statement or request with a card satisfying a predicate; the user approves each request, and a confirmation code ties the browser session to the signed response
Mecanismo de Revocación Log entries with codes 800-999 revoke a card (quiet 8xx, loud 9xx) with an effective date; revocations cannot be erased, and standing is restored by issuing a successor card; presses can be revoked by the press registry body
Tipos de Agentes Soportados People, communities and organisations through cards, and services such as presses; any holder of a card key
Tipos de Billetera/Cliente Wallet services that hold encrypted keyrings and messaging endpoints, with web and mobile SDKs; anyone may run one
Mecanismos de Recuperación A YubiKey-based backup with a 72-hour window in which any registered cancellation credential can abort recovery, with notifications sent on all configured channels; recovery is independent of the primary wallet service. Guardian-quorum social recovery is a future item
Cumplimiento / Regulaciones
Protocolos de Intercambio de Credenciales The protocol's own signing and authentication request flow (CHAPI routing, a direct fetch, optional OHTTP) and its card-offer messages; no OpenID4VC or DIDComm
Protocolos de Intercambio de Credenciales - Lista
Marco de Confianza Chains of policy-defined cards back to a trusted root; the card protocol's presses sign only for policy adherence; a governance board is designed to update the protocol and address violations such as fraud
Modelo de Costos Low-cost writes: presses pay roughly $0.005 per card and may choose to charge for cards; no token
Resistencia a la Censura Moderate by design, unproven in practice: anyone can run wallet services and presses must be authorized on-chain, but press authorization is revocable by a governance body and the system depends on Arbitrum One and IPFS availability
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.