From bug 1572461, we created a policy of how we govern permission for prompt created from third-party context.
This should be extended and we need to check case by case of all prompts/dialogs from third party to see how we want to govern them.
Currently:

• Notifications, vibration, persistent-storage: denied in third party
• Camera, microphone, screen, geolocation: using feature policy to delegate permission from the first party (FWIW Chrome changed to use permission delegation for the most of permissions)
• Others: using the third party.

FWIW, it seems Microsoft restricted registerProtocolHandler to top-level browsing contexts and Chrome team does agree(?) with this idea.

I am not quite sure if DOM: Security is a correct component if someone else finds it inappropriate, feel free to move

Do we need a policy for it? Isn't this more of a thing that might be decided in the respective specs on a case-by-case basis?

I see this bug more for decisions made in the past that we might want to revisit, so:

1. Do we have a list of all end user prompts that can be created by content?
2. For each:
   1. Have we recently evaluated whether it makes sense to allow a third-party to create it?
   2. If it does not, can we restrict it to first-parties?

(But also, if there's a way to make it complicated for prompts to be created by third-parties, we should do that as well.)

I think that it makes sense to ask whether prompting from a third-party context is ever permissible without any form of engagement, for instance. I'd be happy to make that a blanket policy. Requiring a first party (or all parties in a chain) accede to requests seems like a similarly good policy.

It might pay to try to identify what the prompt governs and align any policy with that. It seems like the division between the groups in comment 0 could align with "capabilities" vs. "information".

While we generally regard access to geolocation as a capability we grant, it's primarily information that is being passed (persisting the permission is a capability, so it's not cleanly delineated). Access to notifications or storage are capabilities and so can't be transferred trivially via postMessage or URL parameters, so they are something we naturally have more control over. As pure information can be easily transferred from a first-party to a third-party we might be less protective of permissions like that. Capabilities are something we might want to be more careful about transferring.