User Onboarding

🧭 Who is a "User" in REL-ID?

In REL-ID, a user is an individual who is registered with the enterprise system and interacts with REL-ID through a mobile or web application. Each user is uniquely identified by a user ID (typically an enterprise-defined login ID or username).

A user in REL-ID is tightly bound to:

A mobile device (trusted endpoint)
A secure identity (based on biometrics, password, PIN, or pattern)
A session managed securely through the REL-ID SDK and backend services

👥 User Onboarding in REL-ID

User onboarding in REL-ID is a two-phase process:

📘 Phase 1: User Enrollment

Enrollment is the process of creating the user identity in the REL-ID system. It can be initiated in two ways:

🛠️ Backend Enrollment (Admin-led)

Step	Description
User ID Creation	Enterprise system provisions user (LDAP, CRM, API)
Credential Setup	Optional setup of PIN/password
Policy Mapping	Device count, LDA options, KYC type are assigned

🙋 Self-Enrollment (User-led via SDK)

Step	Description
User launches app	App starts SDK and calls `initialize()`
User enters details	App collects email, phone, or custom ID
App calls enroll API	Triggers backend workflow to provision user
SDK handles onboarding	SDK proceeds with activation flow after enrollment is successful

📌 Outcome: User is now registered but still needs to activate the device.

🤖 Agent-based Enrollment (Trusted Device or Agent App)

In this mode, the enrollment is handled via a trusted device or agent that is already authenticated in the REL-ID ecosystem.

Step	Description
Agent logs in	Agent device is authenticated via REL-ID SDK
User data is entered	Agent collects user’s basic details (name, phone, email, ID, etc.)
Agent calls `enrollUser` API	Sends request to REL-ID backend to register user via secure session
Activation instructions shown	Device activation details (code, OTP, link) are shared with the new user

📌 Outcome: User is registered and receives activation information to onboard on their own device.

🔐 Phase 2: User Activation

Activation is the SDK-driven flow where the device is trusted and the user identity is verified using a challenge-response mechanism.

🔁 Supported Onboarding Challenges

During activation, the SDK may issue one or more of the following challenges:

Challenge Type	Triggered Event	Follow-up Action
OTP verification	`getActivationCode`	App collects OTP → `setActivationCode()`
KYC workflow	`onHandleCustomChallenge`	App captures ID & selfie
Biometric consent	`getUserConsentForLDA`	App calls `setUserConsentForLDA()`
Credential setup	`getPassword`	App collects password → `setPassword()`

📌 Outcome: On successful completion of challenges, the SDK emits onDeviceActivated.

🔁 Re-Activation / Multi-Device Support

Users can repeat activation on new devices.
Enrollment is one-time.
SDK enforces admin-configured policies on device trust, reuse, and limits.

📦 Onboarding States

The onboarding state determines whether users must go through an interactive onboarding workflow. This is configured via the Gateway Manager under user profile settings.

State	Description
`ONBOARDED`	Users must complete the full onboarding challenge flow. After onboarding, they must proceed through the User Activation process.
`CREATED`	Users bypass the onboarding workflow and can directly initiate the User Activation process. Useful for pre-verified or admin-imported users.

💡
Tip: Choose the onboarding state and method based on your user experience goals and compliance requirements.

🔄 Summary Table

Aspect	Enrollment	Activation
Who initiates	Admin or SDK (self-enrollment)	SDK (triggered by `initialize()`)
Main goal	Register user in REL-ID system	Bind user to secure device
Challenge involved?	Optional KYC or OTP	Yes – varies by enterprise policy
Handled by	Backend API or mobile SDK	SDK + App UI + Backend orchestration