Membership Card Protocol
Protocolo de Identidade
Empresa
Detalhes
Licença 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
Status de Dev 🧪 Alpha
Proprietário Relationality Lab
Órgão de Governança 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.
Ano de Início 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
Financiamento Not stated by the project.
Última Investigação 29 de out. de 2026
Protocolo de Identidade Atributos
Origens 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
Banco de Dados Arbitrum One registry contract (a mutable pointer per card, press authorizations) plus append-only logs on IPFS; wallet services hold encrypted keyrings
Linguagem 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 Dados 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
Suporte Móvel Designed for it: mobile SDKs are listed as done and sub-card keys are held in device secure storage; there is no finished app
Suporte 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
Aplicativos Nativos None yet: the frontend app is listed as not done
Termos 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
Fundos
Baseado Em 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
Permissões 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
Autenticação e Identidade 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 Armazenamento 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
Interoperabilidade 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
Portabilidade de Dados 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
Governança e Tomada de Decisão 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
Maturidade / Padronização do Protocolo 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
Padrões de Identidade None adopted: its own card and policy model, not W3C DIDs
Métodos DID Suportados
Gestão de Chaves 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 Credenciais 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 Verificação 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
Recursos de Privacidade 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 Autenticação 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 Revogação 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 Suportados People, communities and organisations through cards, and services such as presses; any holder of a card key
Tipos de Carteira/Cliente Wallet services that hold encrypted keyrings and messaging endpoints, with web and mobile SDKs; anyone may run one
Mecanismos de Recuperação 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
Conformidade / Regulamentações
Protocolos de Troca de Credenciais 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 Troca de Credenciais - Lista
Estrutura de Confiança 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 Custo Low-cost writes: presses pay roughly $0.005 per card and may choose to charge for cards; no token
Resistência à 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
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.