<a href="#security"></a>.

<h2 id="security">

Security and Privacy Considerations

<p>

This specification includes a number of mechanisms to mitigate security

threats and support user privacy:

</p>

<ul data-link-for="PaymentRequest">

<li>The <a>PaymentRequest</a>'s <a>show()</a> method needs to

<a>triggered by user activation</a>. This reduces the ability to

surprise the user by triggering an unexpected request for payment.

</li>

<li>Interfaces are <a data-cite=

"WEBIDL#dfn-available-only-in-secure-contexts">available only in a

secure context</a>, to reduce the possibility that credentials will be

acquired and transferred through insecure communication protocols.

</li>

<li>A <a>top-level browsing context</a> needs to explicitly grant an

<a>iframe</a> access to the <a>PaymentRequest</a> interface via the <a>

allowpaymentrequest</a> attribute. This prevents embedded third-party

content from accessing the interfaces of the <cite>Payment Request

API</cite> without permission from the <a>top-level browsing

context</a>.

</li>

<li>In the definition of <a>canMakePayment()</a> the Working Group

seeks a balance between user experience and data protection. As

defined, <a>canMakePayment()</a> provides the party that calls the API

with information about the user's environment. To reduce the potential

for abuse, implementers plan a number of mitigations, including

rate-limiting <a>canMakePayment()</a> calls from the same origin.

</li>

<li>A user agent can limit matching (in <a>show()</a> and

<a>canMakePayment()</a>) to <a>payment handlers</a> from the same

<a data-cite="rfc6454#section-3.2">origin</a> as a URL <a>payment

method identifier</a>. User agents can also use information provided by

a <a>payment method</a> owner to match <a>payment handlers</a> from

other origins.

</li>

</ul>