Identity + communications

DLT, OTP, SMSV, and SMVDefender

TRAI DLT and SMS stay in the AppDefender backend. The Client SDK sends a public App ID, phone, and purpose — never a PE ID, header, template, or SMS secret. Identity confidence is SMS OTP + SMSV + SMVDefender.

Two layers

Wrong path: app → SMS provider. Right path: app → SDK → API → attestation → risk → OTP → DLT → provider.

Backend: Principal Entity, header, content template, provider routing, OTP hash, Maker–Checker.
SDK: AppDefender.auth.requestOtp / verifyOtp. Public App ID only.

Client calls

AppDefender.initialize({ appId: 'CLIENT_APP_ID', environment: 'sandbox' });

const start = await AppDefender.auth.requestOtp({
  phoneNumber: '+91XXXXXXXXXX',
  purpose: 'LOGIN',
});

const result = await AppDefender.auth.verifyOtp({
  requestId: start.requestId,
  otp: '123456',
});

What the SDK must never send

PE ID is a string up to 32 characters (VARCHAR(32)), not a BIGINT and not “always 16 digits”. Jio PE IDs can be 19 digits.

PE ID, DLT password, header, or content template ID
SMS API key, SMS password, or provider secret

Risk methods

OTP on a compromised handset is not enough. The Launch Security Gate still decides ALLOW, RESTRICT, or BLOCK.

SMS OTP — server-generated code. Hash stored, plaintext is not.
SMSV — SMS verification beside the OTP.
SMVDefender — AppDefender identity verification. Never written as AppSMV.

SMVDefender

Console

Super Admin and Client Admin register PE, headers, and templates. Production activation, OTP policy, and SMS credentials go through Maker–Checker. Secrets live in a vault reference, not in Postgres plaintext and not in the SDK.

APIs: POST /v1/auth/otp/request, /resend, /verify, GET /v1/sdk/policy, /v1/admin/dlt, /v1/vendor/dlt.