A: by using URI as in the attached example iframe_bad_uri.html
but this approach may have following disadvantages
1. AdBlockers may refuse such links
2. Internet filters may filter out such link requests as potential injury.
3. Mobile browsers may have browser specific char limits for URI requests.
4. History may contain such link.
Go sure you you use attribute tags for iframe to enable full screen mode as in following example
<iframe src="***your_link/software/html5.html" -ms-allowfullscreen -webkit-allowfullscreen -moz-allowfullscreen allowfullscreen height="100%" width="100%"></iframe>
B: or by using window.name object as in the attached example iframe_good_name.html
A: by using URI as in the attached example popup_bad_uri.html
same disadvantages as by IFRAME way above
B: or by using window.name object as in the attached example popup_good_name.html
src="/software/html5.html" .... window.name = *****
Passed password gets immediatelly deleted from window.name variable in final html5.html page.
This approach can be very well used to open page in same tab by setting "var openinsamewindow = true;".
The example for POPUP-TAB is working at least until actual IE Edge v44.18362.1.0 (07.07.19) even in interdomain situation, where in old popup examples IE Edge has emptied window.name variable, so this popup_good_name.html is relative safe to use even in modern IE Edge for interdomain scenarios.
All the approaches above ensure that logon data gets passed to server in asymmetric encrypted form even in HTTP only scenario which makes it even secure if your environment was DNS attacked or hackers gained access to your private certificate, since servers public/private key pair gets regenerated on every HTML5 server start and has no relations to the private key used for HTTPS protocol.
Since HTML5 v6.39 it is possible to pass data in POST method by reusing logon ticket system "/socket.io/LPW" but remember that unlike IFRAME/POPUP-TAB code passing data by POST is insecure, firstly because users could see all passed data in browsers developer mode anyway, and second because if used HTTP protocol or HTTPS certificate was compromised, or environment was DNS attacked, this POST method doesn't provide any extra security to avoid future data leaking. Take also example on attached postdata.html to bind it into your actual environment. However when ever it is possible avoid POST method usage, if you really count on security.
PS: the attached examples may need extra modifications for your needs so treat it accordingly as code of practice.
To download *.html examples click on it with RIGTH mouse and then choose from context menu "Save as.."