Neonymic Design Decisions (5.10.2025)
This document outlines the intentional design choices made during the development of Neonymic, including where the system aligns, diverges, or intentionally ignores more established standards such as W3C Verifiable Credentials, DIDs, traditional PKI, and blockchain-based identity systems.
Philosophical Grounding
Neonymic is not designed to replace enterprise identity frameworks like SAML, OAuth, or WebAuthn. It is a pragmatic, low-barrier, cryptographic certificate system for asserting control over identity-linked attributes in federated or pseudonymous contexts.
- Be usable in community, grassroots, or airgapped settings
- Prioritize simplicity, flexibility, and hackability
- Make trust policy-based, not authority-based
Chosen Standards & Approaches
| Area | Standard | Neonymic Position |
|---|
| Signing | Ed25519 | Chosen for its speed, small key size, and wide support. |
| Serialization | JSON | Human-readable and easily canonicalized. |
| Proof-of-Control | Manual & linked artifact proof | DNS TXT, signed posts, verified links — not smart contracts or oracles. |
| Key Management | Self-managed or third-party | Leaves key handling open to user/system discretion (FIDO, PGP, etc). |
| Encrypted Fields | AES-GCM with derived keys | Certs can include private fields with deterministic encryption. |
| ZKP Support | Noir/ZK-native proofs | Optional integration for selective disclosure or attribute proofs. |
Standards Explicitly Not Used
NOTE: These statements reflect our opinion for this specific project and are not to disparage any other standards or approaches.
W3C Verifiable Credentials (VC)
Why we skipped it:
- Too heavy and complex for grassroots or community usage
- Schema sprawl and ambiguity in implementations
- JSON-LD and context resolution issues
- Heavy coupling to blockchain & wallet ecosystem
- Not friendly to systems that prioritize operational simplicity
What we took from it:
- The concept of verifiable, cryptographically signed attestations
- Idea of decentralized trust
- Use of DIDs as optional subject identifiers
Blockchain Anchors
- Adds massive complexity with little gain for most real-world use cases
- Imposes cost, requires wallet/key infrastructure
- Becomes brittle or inaccessible in offline or localized deployments
- Not needed when pubkey + proof suffices
- Immutability is not always a feature for identity
x.509/Enterprise PKI
- Requires centralized issuance chains
- Complex tooling and brittle formats (ASN.1, DER, etc)
- Not suitable for ephemeral, ad hoc, or pseudonymous use
Alignment with Decentralized Identity Ideas
| Feature | Neonymic | W3C VC/DID |
|---|
| DID Support | ✅ Optional | ✅ Core |
| Selective Disclosure | 🧪 Encrypted or ZK | ✅ (via BBS+) |
| Proof-of-Identity | ✅ Web-native (DNS, Reddit, etc) | ✅ |
| Blockchain Optional | ✅ Yes | ❌ Often expected |
| Key Rotation | ✅ Supersession model | ✅ |
Structure Rationale
JSON, not JSON-LD
- Easy to read, store, parse, and transmit
- Avoids dependency on external schemas or context resolvers
- Canonicalization is enforced in spec via field order rules
- Needed to work offline or airgapped
Certs are Immutable, Trust is Mutable
- Every cert is valid (signature-wise) forever
- Trust comes from checking:
- Supersession chain
- Proof freshness
- Local or network policy
- Lack of explicit 'un-trust'
Proofs are Not Oracles
- No trusted third-party verification engines
- Every proof must be checkable or reconstructable by the verifier
Extensibility
Neonymic is designed to be:
- Easily extended via:
subject_extensions (public, user-defined)subject_extensions_encrypted (selective disclosure)proofs (for verifiable claims, links, posts, or sigs)
- Tolerant of unknown keys: unknown attributes do not invalidate the cert
- Forward-compatible via explicit schema versioning
Trust & Revocation Philosophy
- Revocation is handled through:
- Core API (trusted network)
- Supersession (
superseded field)
- Usage & policies per node
- Trust is a layered construct:
- Local
- Federated
- Network/core
- No global trust anchor is assumed or required
Future Interop Goals
While not currently compatible, Neonymic could integrate:
- DIDComm or other DID-based routing/identity messaging
- W3C VC wrapping as a compatibility layer (if desired)
- FIDO-based authentication via user-controlled cert login portals
- Noir or other ZK systems for privacy-first verification
- Keyoxide <3
Summary
Neonymic aims to strike a practical balance between:
- Verifiability and usability
- Structure and flexibility
- Trustworthiness and autonomy
Rather than reinvent identity, it focuses on trustable pseudonymity, verifiable assertions, and human-scale systems — with just enough cryptography to make it work.
Back to Home