Re: [w3ctag/design-reviews] Modal window (#427)

@dbaron my original thinking was that this would simply be a new platform API that would ultimately replace `window.open` however it seems that limiting invocation of this feature to specific contexts (payment, auth etc) may be a good way to alleviate some of the privacy and security concerns.

Therefor, perhaps rather than making the API available to Window it could be limited to same-origin workers only in specific contexts.

This would require that APIs used for other use-cases adopt the same pattern as the payment APIs whereby a calling context calls a use-case a specific API (e.g. credentials API) and if the service behind the API is from another origin (as opposed to the UA itself) the worker for that service is invoked. If the worker requires some UI it is able to invoke a modal window.

i.e. As a reminder of how PR API and PH API interact:

 - The calling context (merchant.example) invokes PR API and specifies the properties of the payment service it wishes to invoke (supported payment methods etc)
 - The UA, possibly through user interaction, possibly based on user defined defaults, determines that it must invoke a Payment Handler from bobpay.xyz
 - The UA invokes the worker that is installed from bobpay.xyz by emitting an event that the worker is listening for.
 - The worker is able to call the modal window API but only from inside the event handler

@rsolomakhin @marcoscaceres are we on the same page?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/427#issuecomment-557503598