Skip to content

HTTPS considerations. #283

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: gh-pages
Choose a base branch
from
Open

HTTPS considerations. #283

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
34 changes: 34 additions & 0 deletions index.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1669,6 +1669,15 @@ <h2>
</li>
</ol>
</li>
<li>If the security properties of <var>newContext</var> are
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems overly vague. Maybe @domenic can suggest better wording for this? It might be a simple as saying "not a secure context" or something link that.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's unclear from @rsolomakhin's text whether insecure HTTP pages are rejected or not. Invalid certificates will fail a navigation, so that would happen before this step.

If the intent is to disallow insecure HTTP, then the wording would be newContext's active document's relevant settings object is contextually secure.

unsatisfactory (e.g., invalid certificate), then:
<ol>
<li>Reject <var>promise</var> with <a>SecurityError</a>..
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

editorial: two periods after SecurityError.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
<li>Reject <var>promise</var> with <a>SecurityError</a>..
<li>Reject <var>promise</var> with <a>SecurityError</a>.

</li>
<li>Abort these steps.
</li>
</ol>
</li>
<li>Let <var>client</var> be the result of running the
<a data-cite="!SERVICE-WORKERS#create-windowclient-algorithm">create
window client</a> algorithm with <var>newContext</var> as the
Expand Down Expand Up @@ -2078,6 +2087,31 @@ <h2>
</li>
</ul>
</section>
<section>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This whole section doesn't feel right in this spec.

<h2>
HTTPS
</h2>
<ul>
<li>The user agent may block mixed content (e.g., non-HTTPS or
scripts) on the payment handler page.
</li>
<li>If the SSL certificate of the payment handler page is not valid
(e.g., self-signed), the user agent may cancel the payment.
</li>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that is inconsistent with the algorithm definition, which forces abort. I suggest changing this to MUST.

<li>If the web-page is known to be malicious (e.g., a phishing page
according to a safe browsing database), the user agent may cancel the
payment.
</li>
<li>If the payment handler page redirects to a non-HTTPS scheme
origin, the user agent should cancel the payment.
</li>
</ul>
<p>
The user agent should provide rationale to the payment handler
developers (e.g., through console messages) and may also inform the
user to help avoid confusion whenever these mitigations happen.
</p>
</section>
</section>
<section id="display" class="informative">
<h2>
Expand Down