You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One of the purposes of manifests is to provide a "security promise" to the invoking application. However, this is not very useful for payments where the client/wallet (whatever it is made of) has one or more "secure keys" for authorization, and particularly not for native payment handlers like G-Pay for Android which is also used for non-Web payments. Why is that? Well, for systems based on "secure keys" the integrity of the payment application is primarily of interest to the issuer of such keys.
ServiceWorker based payment handlers would rather deal with issue this through installation of trusted browser code by the issuer.
In addition, the manifest adds delays to the start of the application and due to timing restrictions in PaymentRequest.show() typically have to be done in advance which further complicates system design.
My proposal is adding an optional parameter to canMakePayment(booleanignoreManifest).
An obvious a side effect would be that multiple payment handlers for a specific payment method would not work if the parameter is set to true. Given the lack of standardization of payment handlers I don't think that will be of major importance. Ideally, the applications could have an option to disregard the ignore option. That is, enforcing it.
If you compare this to current payment systems (practically all of them), the validity of authorizations is dealt with by other parties than merchants.
The text was updated successfully, but these errors were encountered:
One of the purposes of manifests is to provide a "security promise" to the invoking application. However, this is not very useful for payments where the client/wallet (whatever it is made of) has one or more "secure keys" for authorization, and particularly not for native payment handlers like G-Pay for Android which is also used for non-Web payments. Why is that? Well, for systems based on "secure keys" the integrity of the payment application is primarily of interest to the issuer of such keys.
For native payment handlers there is another system which is way more useful than manifests known as "platform attestations" (https://developer.android.com/training/articles/security-key-attestation).
ServiceWorker
based payment handlers would rather deal with issue this through installation of trusted browser code by the issuer.In addition, the manifest adds delays to the start of the application and due to timing restrictions in
PaymentRequest.show()
typically have to be done in advance which further complicates system design.My proposal is adding an optional parameter to
canMakePayment(boolean
ignoreManifest)
.An obvious a side effect would be that multiple payment handlers for a specific payment method would not work if the parameter is set to
true
. Given the lack of standardization of payment handlers I don't think that will be of major importance. Ideally, the applications could have an option to disregard the ignore option. That is, enforcing it.If you compare this to current payment systems (practically all of them), the validity of authorizations is dealt with by other parties than merchants.
The text was updated successfully, but these errors were encountered: