🚫 REL-ID SDK: Device Activation Flow Without Verify Auth Challenge

🧭 Overview

If the REL-ID Verify Auth challenge is not set up on the server or disabled for a user group, the SDK automatically uses a fallback path to activate a new device. This ensures that users can still register and authenticate new devices securely.

📥 Initial Trigger

1. User attempts to log in from an unregistered device.
2. SDK recognizes it's a new device.
3. SDK evaluates available device activation methods.
4. addNewDeviceOptions is triggered, the SDK will present only fallback options in the event payload:

🔄 Sample Payload (No Verify Option)

{
  "newDeviceOptions": ["Add New Device using Fallback"],
  "challengeInfo": [
    { "key": "description", "value": "Verify your identity to activate this device." }
  ]
}

✅ Developer Action

Your app must read the contents of newDeviceOptions and invoke the fallback API fallbackNewDeviceActivationFlow accordingly.

Example Logic (Pseudocode)

if (newDeviceOptions.includes("Add New Device using Fallback")) {
    RdnaClient.fallbackNewDeviceActivationFlow();
}

🔁 Fallback Activation Flow

🧩 Steps

🧩 Similarity to First-Time Activation

Once the fallback flow begins, the additional device activation flow mirrors the first-time activation flow.

✅ The user will go through all configured challenges, including:

• Password or OTP verification
• Biometric or LDA consent (getUserConsentForLDA)

✅ Benefits

• Ensures device activation without relying on push notification infrastructure.
• More resilient in offline, enterprise, or restricted connectivity environments.

🧠 Developer Notes

• Always handle addNewDeviceOptions dynamically.
• Do not assume Verify Auth will be available.
• Build robust UI to handle fallbackNewDeviceActivationFlow as primary flow if needed.