Installation Registration & Device Enrollment
Motivation
Note 0002 and Note 0005 establish that the desktop agent authenticates using an asymmetric keypair (Ed25519) signed per request. Neither note specified how that keypair becomes associated with a customer identity at initial run.
The goal of this design: One binary, one download link, for every customer — identity is resolved entirely server-side.
Phase 1 — Single-Use Registration Code (Initial Release)
```typescript filename="registration-payload.ts"
interface RegistrationPayload {
registrationCode: string; // e.g. "REG-8XJ2-KP9A-QM71"
publicKey: string; // Ed25519 public key hex
discoveredCompanies: Array<{
companyId: string;
companyName: string;
}>;
machineMetadata: {
os: "windows";
hostname: string;
};
}
```
Multi-Company Entitlement Boundary
A single desktop application instance may have multiple company files loaded. To prevent an agent from extracting unauthorized files on the same machine:
Phase 2 — Browser-Based Device Authorization (Future)
Replace manual registration code entry with the OAuth 2.0 Device Authorization Grant (RFC 8628) flow.
Consequences
• The distributed agent artifact is 100% identical for every customer.
• Multi-company data file permissions are enforced by backend state.
• Forward-compatible upgrade path from registration codes to OAuth Device Grant.
Open Questions & Future Work
• Define exact registration code entropy, format, and expiration TTL window.
• Define revocation semantics when an installation is decommissioned.