B

SDOP

Self-Service Device Onboarding Portal · RFC v3.1
Draft RFC v3.1 · 2026-02-09 Zero Trust

Problem Statement

Bell's retail fleet is 80% unmanaged devices. Existing Arcot machine registration uses a proprietary WebSocket model incompatible with Okta. There is no scalable mechanism to distribute Bell CA certificates to unmanaged endpoints — which is required to activate Okta Userless Device Signal (UDS).

SDOP Solution

A "Pull" model where authenticated Store Managers download and install Bell-signed X.509 certificates via a web portal. SDOP acts as a Registration Authority, orchestrating PKI issuance, Okta Verify binding, and lifecycle state — without requiring MDM.

Logical Architecture — Authoritative Reference
Clients
🖥️
Windows
POS / WS
TPM 2.0 (Phase 2)
💻
macOS
Device
Secure Enclave
📱
iOS
Device
.mobileconfig
🤖
Android
Device
PKCS#12 + QR
🏪
Shared
Workstation
Multi-user UDS
Access
Auth Boundary — Okta
🔐
Okta Dashboard
Primary path
🌐
InfoPoint
Portal
Deep link
🔗
Direct URL
sdop.bell.ca
SDOP Core
🏛️
SDOP Web App
RA · OIDC RP · Control Plane
📋
Device Registry
Lifecycle state · Dealer scope
📊
Audit Log
/ SIEM
Structured events
⚖️
Enrollment
Governance
Risk classification
Services
🆔
Okta IdP
MFA · Risk · UDS · Verify
🔏
Bell Retail PKI
Intermediate CA · HSM · CRL/OCSP
Authz Boundary — Bell IT
🏢
InfoNet
Roles · Dealers · Entities
🛡️
SiteMinder
AuthN · AuthZ (Retail Apps)
Authentication Boundary (Okta)
Device Trust Boundary (SDOP + UDS)
Authorization Boundary (SiteMinder + InfoNet)
⚠ No single component crosses all trust boundaries

① User Identity

Established by Okta via OIDC Authorization Code flow. MFA and risk-based controls enforced. Identifier format: dealerid.userid. SDOP never authenticates users directly.

② Device Trust

Established by SDOP + Okta UDS. Requires valid Bell certificate + OS trust + Okta Verify binding + registry ACTIVE state. All four signals must be present.

③ Business Authorization

Enforced by SiteMinder + InfoNet. Evaluated dynamically per request using current entitlements. Never embedded in certificates or tokens.

Enrollment Flows
Click a flow to expand its step-by-step sequence. All flows require SDOP as system of record.
🙋
Self-Service Enrollment
Low-risk · No approval required
1
User accesses SDOP from the target device — enforced to prevent cross-device cert download
2
Redirected to Okta OIDC — Authentication + MFA enforced. Identity = dealerid.userid
3
SDOP resolves dealer ID and entity scope from InfoNet. Validates Store Manager / Retail Admin role
4
User enters a friendly device label (required). SDOP evaluates low-risk vs high-risk classification
5
SDOP requests cert from Bell Retail Intermediate CA. Key generated server-side in volatile memory (Phase 1)
6
OS-specific installer payload delivered (PKCS#12 / .mobileconfig / .ps1). CA bundle included
7
Okta Verify binding completed → Device Registry record created → State → ACTIVE
🏢
Managed Enrollment
MSP/IT Service Desk · Always approval-based
1
Bell IT creates a Managed Enrollment Authorization Window (AWID) — scoped to channel, dealer, brand, device count, time window
2
SDOP generates a signed installer bundle (no embedded secrets) + an enrollment token bound to the AWID
3
Token delivered to MSP (CGI, Staples IT, etc.) via secure out-of-band channel
4
MSP executes installer on target device, supplying token at runtime. No user auth required during install
5
SDOP validates token + window scope + time + quota. Quota decremented, cert issued, device → ACTIVE
6
Accountability attributed to Bell IT issuer of window, not installer operator. Full audit trail
🌱
Bootstrap Enrollment
New store onboarding · Temporary trust
1
Bell IT creates a Bootstrap Enrollment Authorization (dealer-scoped, brand-scoped, device-count limited, short-lived)
2
Bootstrap installer delivered via secure out-of-band channel. Device enters BOOTSTRAP-TRUSTED state
3
Access is restricted to initial provisioning functions only. Not associated with any user identity
4
First retail user authenticates via Okta from the bootstrap device. SDOP detects BOOTSTRAP-TRUSTED state
5
User completes standard SDOP registration + Okta Verify binding. Device transitions to ACTIVE
6
⚠️ Silent or automatic promotion to Active is forbidden. Bootstrap trust never persists beyond initial onboarding
Governance Decision Matrix
Risk classification determines approval requirements. All flows are fully auditable.
Scenario Classification Approval Outcome
Device Lifecycle States
Trust is granted only in ACTIVE state. Lifecycle state is authoritative over certificate validity alone.
⬜
Unenrolled
No trusted device record exists
⏳
Enrolling
Enrollment in progress; trust not yet granted
🌱
Bootstrap
Temporary trust for new store setup only
✅
Active
Trusted device — normal operating state
⏸️
Suspended
Temporary hold — investigation or admin action
🚫
Revoked
Trust permanently invalidated. Cannot restore.
⌛
Expired
Certificate lifetime exceeded. Re-enrollment required.
Permitted State Transitions
Forbidden: BOOTSTRAP→ACTIVE without user auth. REVOKED→ACTIVE. EXPIRED→ACTIVE without re-enrollment.
FromToCondition

Revocation Triggers

Device inactivity · Dealer termination · Lost/stolen report · Security investigation · Policy violation · Certificate expiration · Explicit admin action

Enforcement Behavior

Automated revocations near real-time. Manual revocations executed immediately. Revocation always results in denial of downstream access. Certificate state is subordinate to device lifecycle state.

PKI & Certificate Model
Two-tier CA hierarchy. Cryptographically isolated from Corporate Internal PKI.
🔒
Bell Retail Root CA
Offline · Air-gapped · Never accessible to SDOP
⚠ Root CA private key never exposed
▼
🏭
Bell Retail Intermediate CA (Issuing)
HSM-backed · FIPS-aligned · CRL + OCSP · Isolated from Corporate PKI
▼
📜
Device Certificates
CN = Random UUID · No dealer/user info · Non-exportable where supported · 5-year validity
Phase 1 Server-Assisted Key Generation
Key generationServer-side (volatile memory only)
Memory handlingImmediate zeroization + locking
DeliveryPKCS#12 · Single-use token
InstallationNon-exportable where supported
Sunset trigger≥85% HW keystore OR 18mo post-launch
StatusTransitional — mandatory deprecation
Phase 2 Device-Native Key Generation
WindowsTPM 2.0 (EK/AIK attestation)
AppleSecure Enclave (DeviceCheck / App Attest)
AndroidHardware-backed Keystore attestation
Key exportPrivate key never leaves device
Protocol evolutionEST or equivalent (PKCS#12 not required)
StatusTarget state
Certificate Profile
Subject CN<Random-UUID>
OURetail-Unmanaged
OBell Canada
Key UsageDigital Signature
Extended Key UsageClient Authentication
Custom Policy OIDRetail-Unmanaged-Device
Validity Period5 years (cryptographic)
Dealer/User in cert?❌ Never — by design
Audit Association (Device Registry)
Certificate serial✓ Recorded
Cert fingerprint✓ Recorded
SDOP device UUID✓ Recorded
Dealer ID at issuance✓ Recorded
Entity scope✓ Recorded
Enrollment method✓ Self / Managed / Bootstrap
Issuer context✓ User or auth window
Timestamps✓ enrolled_at · last_seen_at
Protocol Selection Rationale
PKCS#12 selected because it is the only option enabling CA trust bootstrap on unmanaged devices — prerequisite for Okta UDS.
Capability SCEP EST PKCS#12
Threat Model
8 identified threats. Defense-in-depth: compromise of any single signal must not result in persistent or unbounded access.
Arcot vs SDOP
SDOP is not merely a replacement — it is a necessary architectural evolution that preserves Arcot's security intent under modern constraints.
Category
Arcot (Legacy)
SDOP (Proposed)

Why Arcot Cannot Be Extended

Extending Arcot to support CA certificate distribution and OS-level trust would require introducing a new device bootstrap, installer delivery, lifecycle, and recovery framework within a legacy component not designed for this purpose — duplicating Okta functionality and fragmenting device trust ownership.

What SDOP Preserves

Arcot's security intent is fully preserved: dealer-scoped device trust, entity isolation, and cryptographic device identity. SDOP replaces static hardware-derived identifiers with registry-enforced, lifecycle-managed equivalent boundaries.

OS Detection & Payload Handling
SDOP detects client OS via user-agent and generates the appropriate installer payload. Accessing SDOP from the target device is enforced to prevent cross-device certificate misuse.
Windows Payload
Signed PowerShell Script
Security Properties
Store TargetLocalMachine (OS-level)
SigningBell-approved code-signing cert
Key generationServer-side volatile memory (Phase 1)
Non-exportable✓ Enforced
Execution scopeLocal device context only
Okta VerifySystem-level device binding
Behavioral Guarantees
Certificate installed only on the executing device — cannot be silently reused elsewhere
LocalMachine store required for Okta Verify system-level device binding
Phase 2: TPM 2.0 with EK/AIK attestation validation
Download token is single-use and bound to authenticated session
macOS / iOS Payload
Apple .mobileconfig Profile
Profile Properties
PayloadTypecom.apple.security.pkcs12
CA bundleRetail Root CA included
Profile signingSigned + integrity-protected
User consentInstallation bound to user consent
MDM requiredNo — native platform handling
Phase 2Secure Enclave (DeviceCheck / App Attest)
Behavioral Guarantees
Platform-native certificate handling without MDM enrollment requirement
CA trust chain established in system keychain — enables Okta UDS detection
Configuration profile cannot be forwarded and installed cross-device without user consent flow
Signed profile ensures integrity between generation and installation
Android Payload
PKCS#12 (.pfx) + QR Password
Security Properties
FormatRaw .pfx file
Password scopePer-enrollment, never embedded
Password deliveryQR code (shoulder-surf prevention)
Password displayShown once only
Target storeAndroid user credential store
Phase 2Hardware-backed Keystore attestation
QR Password Flow
SDOP generates a unique password per enrollment — never reused
Password displayed as QR code on SDOP screen — user scans with separate device
Manual password entry on Android device during PKCS#12 import
Step-by-step guidance provided in SDOP UI for correct installation
Payload Delivery Controls (All OS)
🎟️
Single-Use
Each download link valid once
⏱️
Short-Lived
Token expires rapidly after generation
🔒
Session-Bound
Tied to authenticated OIDC session
📋
Abort on Failure
Failed delivery = enrollment aborted
Success Metrics
SDOP is considered successful when device trust coverage exceeds 90%, Arcot workflows are fully eliminated, and no material security regressions occur.
≥90%
Device-Trusted Authentication Rate
▸ Target within 6 months of launch
<5min
Average Device Enrollment Time
▸ From SDOP access to registered
<15min
Mean Time to Revocation (Automated)
▸ <4 hours for manual revocation
-40%
Enrollment-Related Support Tickets
▸ vs Arcot baseline
Security Metrics
Operational Metrics
Glossary
Key terms and definitions from the SDOP RFC v3.1