Daemonet DigitalID · holder-controlled credential direction
Proof,
not profile.
Your identity should be something you can prove—not something every company gets to keep. DigitalID is Daemonet’s product direction for receiving a signed claim from a legitimate issuer, holding it under your own keys, and presenting only what a service actually requires.
Product design—not a current identity-verification service. The preview issues no credential, verifies no person, and discloses no information.
Identity without the identity warehouse
Stop copying the same person into every organization.
Passports, licenses, face images, addresses, tax identifiers, and signatures are repeatedly uploaded into unrelated databases. Every copy adds employees, contractors, retention rules, breach exposure, and another place the person cannot meaningfully control.
DigitalID’s goal is to make the reusable object a signed result of an accepted verification—not another reusable bundle of the raw documents.
Here is everything we collected.
- Upload the original evidence again
- Create a permanent provider account
- Reuse one customer identifier everywhere
- Retain fields unrelated to the transaction
- Ask the person to trust every copy forever
Here is the fact this interaction requires.
- Name the verifier and claim issuer
- Bind the presentation to one holder and request
- Reveal only approved claims or fields
- Expire and revoke under explicit policy
- Keep unrelated relationships unlinkable where possible
Five roles. No universal authority.
A signature is meaningful only when every role is explicit.
DigitalID cannot be “Daemonet says this person is real.” A relying service chooses trusted issuers, claims, assurance, freshness, and retention for one purpose. The issuer remains accountable for the claim it signed.
Keeps the credential
Controls the holder key, storage, approval, recovery, and each presentation.
Person or organizationExamines source evidence
Runs the accepted document, record, in-person, or institutional validation process.
May have legal retention dutiesSigns exact claims
Names the assurance, validity, holder binding, status policy, and authority behind the result.
Never implicitly trustedRequests the minimum
Defines the accepted issuers and decides whether one presentation satisfies its service policy.
Destination remains authoritativeActs for the holder
Would match eligible credentials, explain the request, obtain approval, create the presentation, and retain a disclosure receipt.
Product directionA disclosure ceremony—not an upload form
See the requester, purpose, claim, retention, and consequence before anything leaves.
The preview below demonstrates the intended decision shape only. It uses no wallet, credential, issuer, status registry, server request, or cryptographic proof.
NON-TRANSACTIONAL PREVIEW
What should an identity request feel like?
Choose a claim, choose how much the hypothetical presentation would reveal, review the complete boundary, and inspect the local-verification result.
The target issuance and presentation model
Verify with an accepted authority. Take custody of the signed result.
The verifier may need to process real identity evidence. The user should know what is processed, which claims are issued, what must be retained, and how the credential expires or is revoked before beginning.
- 01
Choose a verifier
Select an authority accepted for the required claim and jurisdiction.
- 02
Present source evidence
Send documents or records directly to the verifier under its declared policy.
- 03
Issue exact claims
The named issuer signs holder-bound claims, assurance, validity, and status policy.
- 04
Hold under your key
Store the credential in a trusted Daemon, hardware device, or owner-controlled recovery path.
- 05
Approve one presentation
Bind the minimum disclosure to one requester, nonce, purpose, and short validity.
- 06
Verify without surveillance
Let the service check locally when policy permits; use online status only when explicitly required.
HONEST RETENTION CLAIM
“Nobody stores your identification” is not credible. A verifier may process raw documents and may be legally required to retain evidence. The defensible goal is to stop copying those documents into every later service and expose the verifier’s retention before consent.
Holder-bound and request-bound
A credential file should not work like a screenshot anybody can replay.
A useful presentation would prove control of the holder key, bind the audience and nonce, carry only approved claims, expire quickly, and respect current issuer and credential status. A copied object without the holder key should not authorize a new presentation.
Mechanism not selected
Separately signed claims, derived credentials, selective-disclosure signatures, zero-knowledge proofs, and one-time presentations have different security and interoperability costs.
No zero-knowledge claim todayCorrelation defense not specified
One permanent identifier would let unrelated organizations merge records. Pairwise identifiers need a reviewed derivation, rotation, recovery, and issuer-linkability model.
No unique-human trial claim todayPrivacy/freshness tradeoff open
Short credentials, lists, accumulators, rotating tokens, or online checks expose different information and failure behavior.
No production status registry todayTruth changes
Assurance, expiration, revocation, and recovery are part of the credential—not footnotes.
Self-asserted preferences, verified contact control, document checks, in-person verification, employee status, and government records do not carry the same confidence or lifetime. The relying service chooses the minimum adequate assurance.
Say how the claim was established.
Self-asserted, contact-controlled, document-checked, person-matched, in-person, or institutionally issued are different facts.
Never turn one old check into permanent truth.
Residence, employment, professional status, document validity, and one-time events need appropriate lifetimes.
Compromise and changed status must converge.
Issuer error, fraud, suspended license, replaced credential, or holder-key loss must invalidate future presentations.
Replace the holder key—do not resurrect it.
Another trusted device, re-verification, hardware recovery, or later quorum paths can reissue authority while the old key is revoked.
One claim, several Daemonet systems
Identity, access, payment, storage, and the entrance remain separate.
DigitalID should compose with other Daemonet pillars only where destination policy explicitly asks. Payment never becomes identity; identity never reveals purchase history; storage never becomes issuer authority.
VIRTUAL FRONT DOOR
Request one claim at the entrance.
Reveal only services available under the chosen identity, capability, or entitlement.
Open the Front Door → DAEMONPAYCombine a claim with a portable right.
Require identity only when a service policy needs it; keep settlement and identity histories separate.
Explore DaemonPay → POCKET DIMENSIONProtect holder material without making storage the holder.
Encrypted placement may later support credential backup, but storage nodes never become issuers or recovery voters.
Open Pocket Dimension →Managed verification without a global identity owner
1Man may later sell verification operations. It cannot become the person.
A future managed offer could coordinate selected verifiers, issuer infrastructure, status, policy APIs, portal integration, and audit evidence. Every issuer, verifier, retention duty, jurisdiction, plaintext processor, and recovery path would remain visible.
Credential + presentation custody
Holder keys, approved disclosures, local receipts, personas, recovery choices, and revocation requests.
Customer-controlledClaim-specific authority
Source evidence processing, assurance decision, exact claims, signing keys, validity, retention, and revocation.
Named and policy-scopedRelationship decision
Accepted issuers, required claims, purpose, retention, and whether a valid presentation opens the service.
Destination-controlledOptional operations provider
May later host bounded verification or issuer machinery under an explicit contract; no universal identity database or operator impersonation key.
Not active in private alphaWhat DigitalID is not
Minimal disclosure is not permission to make identity claims vague.
The system must protect pseudonymous participation and ordinary anonymous use. A credential is a capability for relationships that need one—not a demand that every person speak under a government name.
Jurisdictions and relying services decide which named issuers and claims they recognize.
A mandatory permanent identifier would become a cross-service tracking beacon.
Any biometric processing requires a named verifier, exact purpose, retention, security, legal basis, and alternative path.
Network metadata, issuer knowledge, disclosed fields, service policy, and real-world contracts can still identify or correlate a holder.
A hostile kiosk can capture the display, keystrokes, or transaction. High-risk disclosures need a trusted display or authenticator.
Finance, healthcare, employment, government, and travel still require current law, contracts, controls, records, and independent review.
Your identification is not somebody else’s inventory
Prove what matters.
Keep custody of the rest.
The next engineering step is a reviewed credential, issuer-trust, status, disclosure, receipt, and recovery specification—not a signup form pretending an Ed25519 key is legal identity.
No current Daemonet or 1Man endpoint issues government, age, residency, professional, uniqueness, or legal-identity credentials.