Virtual Front Door · Daemon Portal + visitor-held authority
A website can display information.
A Daemon Portal can receive people.
Give an organization one persistent entrance for public information, private services, support, trials, payments, and communication. The portal proves what it is; the visitor chooses what authority to present; the destination still decides what opens.
The guided preview makes no network request and grants no access. A complete managed Front Door is not currently offered.
One door, many entrances
The entrance keeps its identity even when the machinery behind it moves.
A persistent service identity can appear through a public domain, private Daemonet name, invitation, QR code, kiosk, or application. Branding and presentation may change; the service key, owner policy, entitlements, and trusted relationships do not have to become properties of the current host.
Public arrival is not authorization. A private visitor does not become an organization member merely because they can load the entrance.
ARRIVE THROUGHPublic domainPrivate Daemonet nameInvitation or QRPhysical kiosk
PERSISTENT SERVICE IDENTITY
Daemon Portal
Brand · policy · service directory · exact requests
The entrance is stable. Hosts are replaceable.SEE ONLYPublic visitor viewCustomer servicesEmployee workspaceOne temporary task
A workflow—not a wall of controls
Arrive. Present only what is needed. Leave the control plane.
The Front Door is a sequence of bounded decisions. The visitor first chooses an entrance, then presents no authority or one exact authority, reviews the request, and receives either a direct handoff or a visible stop.
- 01ArriveChoose the entrance
- 02PresentNo identity or one exact proof
- 03ReviewSee the requested authority
- 04HandoffOpen direct or stop visibly
Interface preview — explore the ceremony without generating a key, contacting 1Man, or opening a service.
Daemon Identity
Identity is a portfolio of bounded authorities—not one account that owns the person.
Daemonet already separates device, profile, browser-session, service, payment, and recovery keys. A future person-facing identity experience must preserve that separation instead of hiding a master credential behind a friendly avatar.
A Daemonet identity is not automatically a legal identity, public profile, social graph, or universal username. External credentials still need named issuers, verification policy, expiry, revocation, and a reason to be requested.
DEVICE KEYRepository implemented
This device can sign for itself.
Private material stays on the device. Existing owner authority approves enrollment and removal.
Not a person dossierPROFILE MEMBERSHIPRepository implemented
This device belongs to this exact relationship.
Signed membership and local policy decide which private names and services may appear.
Not global account membershipBROWSER CARDRepository implemented
This browser may request these exact services.
A locally generated browser key receives bounded, revocable service scope after owner approval.
Not permanent network identitySERVICE PASS OR RIGHTRepository implemented
This holder may perform this bounded action.
Destination passes and portable entitlements can bind service, device, time, use count, and issuer policy.
Not application superuser authorityPERSONA + IDENTITY VAULTProduct direction
Share a chosen claim without synchronizing a life.
Reusable forms, selective disclosure, cross-device personas, and credential presentation require a dedicated vault and issuer model.
No current universal identity serviceThe portal asks. Your Daemon decides.
Request the fields the service requires—not everything that might become useful later.
The visitor should see who is asking, what is required, what is optional, how long it will be retained, and which action the disclosure enables. The organization receives only the approved response under its own legitimate record obligations.
ILLUSTRATIVE REQUESTExample Workshop
- Required
- Valid workshop entitlement
- Optional
- Display name for the room
- Not requested
- Device inventory · address · contacts
- Retention
- Entitlement event under organizer policy
Named requester
The service proves its stable identity before asking the visitor for authority.
Exact purpose
A request identifies the service, action, audience, duration, and retention claim.
Local consent
The visitor reviews and signs from their chosen device or approved temporary session.
No magical proof
Age, residency, professional, or legal claims require real credential issuers and verification rules not yet defined by this product page.
Introduction is not application transport
The front door coordinates the entrance. It does not silently become every room behind it.
The portal page itself always has an explicit host. When it opens an owner-controlled private service, the default Verified Access path returns a signed, short-lived record and leaves the application path. Optional Hub or future managed portal hosting would be a separately selected byte-carrying service with its own limits and disclosure.
Default contract: 1Man may authenticate, check its managed entitlement, and sign the route. It does not approve the visitor for the application, inspect the opened service, or provide a fallback proxy.
One entrance, composable services
Build a relationship one bounded capability at a time.
The complete vision combines several independent systems. Each can mature, be replaced, or remain absent without turning the portal into a universal super-application.
ACCESSFOUNDATION BUILT
Open one exact service
Use profile policy, member windows, destination-issued passes, Browser Cards, trials, or portable entitlements.
Destination remains authoritativeDAEMONCHATDIRECT DEMO BUILT
Speak without making the portal the conversation
Fresh-key private rooms demonstrate direct text, calls, and files with bounded coordination.
No managed support desk yetDAEMONPAYPROTOCOL BUILT
Pay at the moment of value
Merchant settlement evidence and merchant-issued rights remain separate from portal hosting and application access.
Private-alpha collection remains offNOTIFICATIONSPRODUCT DIRECTION
Address the relationship, not a device inventory
Scoped channels, user-controlled delivery policy, encrypted store-and-forward, quiet hours, and portable inboxes need a dedicated delivery protocol.
No universal inbox service todayQUEUES + APPOINTMENTSPRODUCT DIRECTION
Leave the tab without losing the place
A bounded queue or appointment right could survive a browser session and notify an authorized endpoint later.
Requires durable application policySTAFF + AIPRODUCT DIRECTION
Route a request without granting the desk everything
Human and AI roles need explicit sources, disclosure, retention, escalation, action limits, and auditable authorization.
AI never becomes recovery authorityA recognizable entrance for every relationship
Same foundation. Different door policy.
A portal can be public, private, invitation-only, identity-gated, entitlement-gated, or limited to one temporary action. Industry language never overrides the technical and legal evidence required for that use.
Marketing outside. Exact tools inside.
Public information, sales, customer support, partner access, and employee applications under separate policies.
Own the channel and the entrance.
Releases, memberships, commissions, private previews, portable rights, and direct audience relationships.
Authorize the case—not the company.
Present one product right, relevant diagnostics, one file, or temporary remote access that expires with the task.
One right before, during, and after arrival.
Tickets, check-in, schedules, time-limited access, announcements, checkout, and follow-up.
Design for access without inventing compliance.
Forms, queues, language support, appointments, and credential presentation require operational controls, accessibility work, and independent review.
A professional entrance without a platform company.
An independent developer, consultant, or creator can compose documentation, support, access, and payments around infrastructure they control.
Managed convenience without identity custody
1Man can operate selected plumbing. It cannot become the visitor or the organization.
Today, 1Man implements accountless enrollment, Browser Card sessions, exact service resolution, entitlement integration, verified naming, and temporary coordination. A complete managed Front Door would be a later, separately contracted service—not an implied expansion of Verified Access.
Owns the entrance
Service identity, brand, policy, staff roles, requested information, customer relationship, applications, and legitimate records.
AuthoritativeOwns what they present
Device keys, personas, capabilities, entitlements, disclosure decisions, approved endpoints, and revocation choices.
AuthoritativeOperates bounded coordination
Enrollment transport, managed facts, signed route records, verified names, and explicit entitlement checks.
No identity or normal byte custodyWould be an explicit application role
Hosting, queues, AI, notifications, analytics, backups, or staff tools would declare plaintext, metadata, retention, export, and availability boundaries.
Not active in private alphaThe honest security boundary
A front door can narrow trust. It cannot abolish endpoints, people, or physics.
Security claims must describe the exact portal, identity, credential, route, and application mode. “Universal” describes portability of the relationship—not guaranteed reachability or a globally verified human identity.
It may capture keystrokes, screens, downloads, or alter a transaction. Short sessions and trusted authenticators reduce exposure; they cannot make the display honest.
The portal must identify AI, expose its sources and retention, and keep medical, legal, financial, recovery, revocation, and destructive authority behind explicit approval.
Delivery depends on power, connectivity, permission, valid authority, provider availability, and at least one approved device reconnecting.
A signed statement is only meaningful under a policy that trusts its named issuer, subject, scope, validity, and revocation source.
Public pages and any managed application features have real operators and metadata. Their byte-carrying role must be explicit rather than hidden inside “control plane.”
Missing identity, revoked rights, unavailable Tor, invalid TLS, failed policy, or an unsupported route cannot quietly select a weaker entrance.
The internet as a place you can enter
Build the entrance.
Keep the relationship.
Start with one stable service identity, one public view, one owner-approved private service, and one revocation test. Add chat, commerce, notifications, or managed operations only when each role has an explicit authority and data boundary.
The current portal is an accountless enrollment and exact-service access surface—not the complete organization Front Door described on this page.