Is it OK to rely on JavaScript for this embedded form? If JS is not available, should we just fall back to linking to the Zendesk form?

IMO, yes I think it would be fine to rely on JS, if we need to. We could also consider that the "Get help" link takes you to a Special:EmailAuthHelp form that doesn't require any JS, though.

In which repo should this embedded form feature live? In EmailAuth, even though it's WMF-specific? In WikimediaMessages? Somewhere else?

I'd probably place it in EmailAuth with a feature flag.

How can we reuse the Zendesk API key setting that is currently specific to the ReportIncident extension?

I misremembered about this, sorry. We currently submit tickets to Zendesk without authentication (this is essentially what the Zendesk site form allows for anyway). In T381089, we started discussing the use of OAuth tokens to avoid rate limiting issues.

In T399742#11012886, @kostajh wrote:

Is it OK to rely on JavaScript for this embedded form? If JS is not available, should we just fall back to linking to the Zendesk form?

IMO, yes I think it would be fine to rely on JS, if we need to. We could also consider that the "Get help" link takes you to a Special:EmailAuthHelp form that doesn't require any JS, though.

@Tgr do you have any thoughts on this proposal, or concerns about how this would work with the authentication stack -- specifically, about having the form submission that creates the Zendesk ticket associated with the not-yet-fully-logged-in user who hasn't made it past the EmailAuth token stage?

How do you prove that the Zendesk email is legit? Two approaches that come to mind:

1. When the user reaches the EmailAuth screen, generate a proof token (could be a JWT with the username in it or whatever - incidentally, we are adding JWT generation support to MW core). Create a special page which verifies the token. The EmailAuth screen would prefill the Zendesk email (could be just a mailto: link, could interact with the ContactPage extension, etc) that includes a link to Special:EmailAuthVerify/<token>, and T&S staff can click it to validate.
2. When the user reaches the EmailAuth screen, tag their session, then link them to Special:EmailAuthHelp which will use the session to validate the claim and send an email to Zendesk. T&S staff would validate the sender.

Things to be careful about: email address spoofing (only relevant in the second scenario), attacker choosing similar username to the target (can be avoided by us generating the link T&S would use for 2FA reset).

We could either put it in WikimediaEvents (not a great place but the rest of the Wikimedia-specific EmailAuth logic is already there), or make it non-Wikimedia-specific (ie. do not hardcode Zendesk).

In T399742#11037889, @Tgr wrote:

We could either put it in WikimediaEvents (not a great place but the rest of the Wikimedia-specific EmailAuth logic is already there), or make it non-Wikimedia-specific (ie. do not hardcode Zendesk).

Or jump the gun and create a catch-all extension for Wikimedia-specific hooks (we talked about that a few times before). I filed T401939: Create a Wikimedia* extension for site customizations about that.