Cross-Device Signing

Signers often open a portal link on their desktop but prefer to sign on their phone, or need to hand off to a colleague on a different device mid-session. REFRACT eSign's cross-device transfer lets a signer move to any other device without restarting the session, re-sending invitations, or bypassing OTP identity verification.

The mechanism is a one-time QR transfer token: a 256-bit random value minted on demand by the eSign portal, redeemed once, and expired shortly after. The new device must pass the same OTP identity challenge before it can access the signing session.

User Experience

On the OTP / Identity Page

When a signer opens their portal link on desktop, a "Continue on your phone" panel appears automatically alongside the identity verification form. The signer scans the QR code with their phone's camera. Their phone opens the same signing session URL. They verify their identity via OTP on the phone. Once verified, the phone becomes the active signing device and the desktop session becomes read-only.

Inside the Signing Session

After OTP verification, a "Continue on another device" button appears in the left sidebar, visible before signing begins. This lets a signer who has already verified on desktop transfer to their phone (or any other device) before completing the signature fields.

Tapping the button expands a QR panel with the same one-time token flow. The new device must complete OTP verification. Once verified, signing continues on the new device from exactly where it left off.

How the Transfer Works

Desktop (original device)              Phone (new device)
────────────────────────               ──────────────────
Portal generates QR code
  ↓ POST /api/sessions/{id}/transfer-token
  ← 256-bit one-time token
  ← QR encodes {PORTAL_URL}/api/x/{token}

                                       Scan QR → GET {PORTAL_URL}/api/x/{token}
                                         ↓ token validated & consumed
                                         ↓ vp_device cookie set
                                         ↓ redirect → /sign?t=...&g=...

                                       OTP challenge (email)
                                         ↓ POST /api/sessions/{id}/verify-otp
                                         ↓ device binding updated

                                       Signing continues on phone

Both the mint route (POST /api/sessions/{sessionId}/transfer-token) and the redeem route (GET /api/x/{token}) run on the eSign portal, hosted on REFRACT Shared Services - not on your Dispatcher.

Security Architecture

One-Time Token

Each token is:

• 256-bit random, single-use
• Stored in the eSign portal's own Azure Table Storage (vaultpdfxtokens), in REFRACT's shared portal storage account - not in your Azure subscription
• Consumed on redemption; a second scan of the same QR code fails

Device Binding

When a token is redeemed, the portal sets a vp_device cookie on the new device, scoped to the signing session:

This cookie is not readable by JavaScript. It is set after OTP verification succeeds on the new device, updating the session's device binding inside the portal's own session store.

OTP Re-Verification on the New Device

Scanning the QR code does not bypass OTP verification. The new device must complete the OTP identity challenge before it can sign. The challenge is delivered by email - the portal's OTP-send route only supports email delivery, regardless of what OTP channel a signing session's field manifest might otherwise reference.

What Is Recorded

Making and opening a transfer link are written to the session's audit trail. The portal reports each to your Dispatcher (POST /api/esign/signer-event, signed with the envelope's callback key), which appends the chained event; if your Dispatcher cannot be reached, the portal keeps the event and reports it again.

• SIGN_DEVICE_TRANSFER_CREATED ("Device Transfer Link Created") is written when the portal makes a link, at most once per device in each 10-minute window (the panel makes a fresh link every few minutes). It records the slot, the browser of the device it was made on, when it was made, and when it stops working.
• SIGN_DEVICE_TRANSFER_REDEEMED ("Signing Moved to Another Device") is written when the link is opened on the new device, before that device verifies its code. It records the slot, the new device's browser and IP address, when it was opened, and the device and time the link was made on.

Neither records the token, a code, or an email address. The code verification on the new device is not a separate event: the evidence certificate's Identity Verification table lists it as its own row, with the device that signed marked "Signing Device: Yes".

Token Expiry and Refresh

A newly minted token has a short time-to-live before it must be redeemed. The portal auto-mints a fresh token in the background as the displayed QR code approaches expiry, so the panel updates silently rather than showing a dead code. If a token is never redeemed before it expires, it simply becomes invalid; scanning it returns an error and the signer can request a new one from the same panel.

Constraints and Considerations

• One active device at a time. Once the new device completes OTP verification, the original device's verification ends: it can no longer preview, sign, or decline, and would need a new code to continue there. A device's verification also ends after 1 hour without activity or 12 hours after the code was entered. See OTP Verification.
• Transfers are not chained automatically. Moving from Desktop to Phone to Tablet requires a new QR scan and OTP verification on each incoming device.
• Session expiry is unaffected. Cross-device transfer does not extend the signing session's own TTL. If the session expires between the QR scan and OTP verification on the new device, the transfer fails and the session cannot be recovered.
• Mobile optimisation. On mobile screens, the QR panel is replaced with a Copy Link option so the signer can share the transfer URL to another device manually. The same OTP challenge still applies.

Infrastructure