Focused view / embedded signing blocked since ~21 Oct 2026 — redirect to apps-d.docusign.com/authenticate has frame-ancestors that ignores frameAncestors

Environment
- Demo (developer) account b5fe314e-fdf1-4821-893f-5ce7dac2d8fc, integration key a6aa342b-4222-4dc9-9fb0-062ffae667dd
- Account settings report signingUiVersion: "2", betaSwitchConfiguration: "mandatory"
- Envelopes created from a server template; signer is an embedded recipient (clientUserId set, authenticationMethod: "none", no IDV/KBA/access code)
- Docusign JS from https://js-d.docusign.com/bundle.js, loadDocuSign(integrationKey) → signing({ url, displayFormat: 'focused' }) → mount(...)
- Chrome, host page http://bmw.localhost:8082 (local dev)

Recipient view request
{
  "returnUrl": "http://bmw.localhost:8082/vdr/folders/…",
  "email": "…", "userName": "…", "clientUserId": "…",
  "authenticationMethod": "none",
  "frameAncestors": ["http://bmw.localhost:8082", "https://apps-d.docusign.com"],
  "messageOrigins": ["https://apps-d.docusign.com"]
}

What happens
Until 20 Oct 2026 this worked: the focused view loaded and we received ready / sessionEnd: signing_complete (e.g. envelope c3e62098-9360-8784-8000-e0f6b7a814e1, completed 20 Oct 20:08 UTC).

Since 21 Oct, every session hangs on load and never emits ready. Chrome console:
Framing 'https://apps-d.docusign.com/' violates the following Content Security Policy
directive: "frame-ancestors 'self' https://demo.docusign.net". The request has been blocked.
Example envelopes: bd702729-845d-88b6-81e3-66b9f5ab158e, a7ab2935-6546-854c-818e-e0def5a1169f.

 

Redirect trace of a fresh recipient view URL (frame-ancestors per hop):

┌─────┬────────────────────────────────────────────────────────────────────┬────────────────────────────────────────────────────────────────┐
│  #  │                                URL                                 │                        frame-ancestors                         │
├─────┼────────────────────────────────────────────────────────────────────┼────────────────────────────────────────────────────────────────┤
│ 1   │ demo.docusign.net/Signing/MTRedeem/v1/…                            │ — (302)                                                        │
├─────┼────────────────────────────────────────────────────────────────────┼────────────────────────────────────────────────────────────────┤
│ 2   │ account-d.docusign.com/managed_token/v1/redeem/…                   │ 'self' (302)                                                   │
├─────┼────────────────────────────────────────────────────────────────────┼────────────────────────────────────────────────────────────────┤
│ 3   │ demo.docusign.net/Signing/StartInSession.aspx?code=…               │ — (JS redirect, adds ifd=1)                                    │
├─────┼────────────────────────────────────────────────────────────────────┼────────────────────────────────────────────────────────────────┤
│ 4   │ demo.docusign.net/Signing/?insession=1&ti=…                        │ http://bmw.localhost:8082 https://apps-d.docusign.com ✅ (302) │
├─────┼────────────────────────────────────────────────────────────────────┼────────────────────────────────────────────────────────────────┤
│ 5   │ apps-d.docusign.com/authenticate?code=…&state=…&callbackURIProps=… │ 'self' https://apps-d.docusign.com ❌                          │
└─────┴────────────────────────────────────────────────────────────────────┴────────────────────────────────────────────────────────────────┘

So our frameAncestors are honoured at hop 4, but the session is then forwarded to the new signing app's authenticate endpoint, whose CSP doesn't include the host origin. That hop can never render inside the integrator's page.

The authenticate page's config for the /sign plugin includes a classic fallback:
"baselineUrl": "https://${site}/Signing/?ti=${ti}&bailout=auth_middleware"
That fallback never runs inside the iframe, because the frame is blocked first.

Also tried
- displayFormat: 'default' (classic with Docusign JS): same block.
- Opening the recipient view URL as a full page (no iframe): works, so we've switched to redirect-based signing as a workaround.
- There's no signing-experience toggle in the demo admin console; the account's beta switch is mandatory.

Questions
1. Is this a known regression in the new signing experience rollout on demo, and is a fix planned?
2. Will the same routing reach production? If so, how should Focused View integrators embed signing, or does apps.docusign.com/authenticate get the recipient view's frameAncestors added to its CSP?
3. Is there a supported way, per account, envelope or recipient view, to keep embedded sessions on the classic Signing/ page until this is resolved?