Comments (20)
+1 on @cyberphone comments. Anything that is 1) not tied to the Payment Request API and 2) not FIDO has the net effect of making of the scope explode IMHO. The neat thing about the original SPC proposal was the the use case was clear, unequivocal and single-minded in its purpose. FIDO2 + Payment Request API === a chance of success and adoption.
from secure-payment-confirmation.
For completeness: SPC as described in the explainer is only usable in an informal payment context, not a web-api context. Although explainer-SPC uses the PaymentRequest API, it is not part of a PaymentRequest flow; it's just piggy-backing on the existing infrastructure. The explainer version of SPC can't be used inside a PaymentRequest flow (e.g. a web PaymentHandler), because PaymentRequests cannot be nested (step 8 of show() - https://w3c.github.io/payment-request/#show-method).
from secure-payment-confirmation.
@stephenmcgruer Since you requested input on a pretty fundamental issue, may I as an external comment on this?
IMO, SPC is (or should at least be), a browser-built-in payment-handler, activated by the existing PaymentRequest
API for usage in payment scenarios. Personally, I would limit the scope even further by making crypto = FIDO. Going outside of this already quite challenging scope would IMO be unwise (unless it is supported by peer-reviewed, fairly complete specifications, and thoroughly tested code).
Other solutions and scenarios can presumably be supported by existing Web technologies.
In case you want to discuss this further, please use my email: [email protected].
@rsolomakhin @nickburris @btidor-stripe @jcjones
from secure-payment-confirmation.
A closely related issue...
If SPC becomes a "security framework" that only kicks in when required (like 3DS), it won't become a brand. This departs from essentially every other system out there, from PayPal to SRC:
https://www.emvco.com/emv_insights_post/introducing-the-click-to-pay-icon/
This is how I envision SPC could appear on a merchant checkout page, here supporting three different payment networks:
For Open Banking implementations, the name of the payment network would probably be something like "Pay with your Bank" .
from secure-payment-confirmation.
SPC is not an "API" it is a function.
It should only be available inside the formal PR API call for the reasons specified in #56 (comment)
I wouldn't read much into the API shape as defined in the explainer. @danyao and I agreed early on that the design for the experiments was simply a "quick and dirty" to get some data.
My mental model for PR API is that it is simply the way a website invokes a payment context. We have already made some big simplifying changes to PR API through w3c/payment-request#955 to make it more flexible. I don't believe there is a concept of a "Payment Request flow" since the browser is no longer collecting data on behalf of the website.
I imagine functions available inside the payment context being:
- User identification
- Instrument selection
- Authentication and payment confirmation (SPC)
The specific functions available and invoked inside the payment context will differ depending on how the PR was constructed. E.g.
- If a website already knows which payment credential will be used to authenticate the payment it might call PR API and pass the credential with the request but not specify a list of payment methods (similar to the API design in the explainer)
- If a website has a list of payment credentials that could be used it could call PR API and pass all of them to PR API and the browser will prompt the user to choose a payment instrument linked to one of them (assuming more than 1 has been enrolled previously).
- If a website has a list of payment methods it accepts and is unsure if any payment credentials are already enrolled it can specify the list of payment methods and the browser will prompt the user to select a payment instrument matching one of the payment methods.
- Etc.
I think we should not get too far ahead in trying to design the API shape for SPC (or start assuming it won't be part of PR API) until we have ironed out the scope and requirements a little more.
@cyberphone SPC is NOT intended to be a brand. It is an authentication and confirmation framework that can be leveraged by existing payment methods. The goal is to standardise the primitives for authN and confirmation so that this is possible.
from secure-payment-confirmation.
Thanks @adrianhopebailie
I believe you and I agree, and are just using slightly different meanings for terminology. Everything in your post I agree with except the 'theory' parts (what constitutes a payment context :D).
I have trouble explaining things here without relying on some concrete proposal, to be honest. The core of this issue was that I don't want merchants to have to switch to Payments-related web-APIs for anything other than SPC, to use SPC.
That is, if a merchant, Alice, has a HTML-based guest checkout form setup that's working for her today (so no Payments web-APIs there), she should be able to integrate SPC to get strong user authentication without needing to adopt any other Payment APIs (such as, if you'll excuse the concrete example, the use of a PaymentHandler like basic-card, Apple Pay, or Google Pay).
from secure-payment-confirmation.
@adrianhopebailie writes
SPC is NOT intended to be a brand. It is an authentication and confirmation framework that can be leveraged by existing payment methods.
This excludes a wallet which @stephenmcgruer has in private communication mentioned as likely to be a part of SPC. Does the world really need yet another framework? Wouldn't a concrete system be easier to define, deploy, and market?
A framework will be facing a virtual army of quite popular and useful mobile payment and banking applications. A Standardized, Vendor-independent, Convenient, Secure, Universal, and [potentially] Always Available alternative is (standards-wise) probably the only thing that could make a real impact in a market which currently have to cope with an ever-increasing number of "innovative" payment solutions.
from secure-payment-confirmation.
Hi all,
We discussed this at our 27 May teleconference:
https://www.w3.org/2021/05/27-wpwg-minutes#t03
(No strong feelings were expressed there.)
from secure-payment-confirmation.
@stephenmcgruer I think we are on the same page but perhaps have different ideas about HOW someone could use PR API, for example if all they want is SPC.
You said (and I agree with this):
if a merchant, Alice, has a HTML-based guest checkout form setup that's working for her today (so no Payments web-APIs there), she should be able to integrate SPC to get strong user authentication without needing to adopt any other Payment APIs (such as, if you'll excuse the concrete example, the use of a PaymentHandler like basic-card, Apple Pay, or Google Pay).
My expectation is that in this case Alice would create a new PR object but would not specify any payment methods (i.e. telling the browser she is not interested in invoking browser facilitated instrument selection or any third-party apps). She WOULD set a flag, or provide some input data (such as a list of credential IDs) that indicates she wishes to do SPC if it is available.
This creates a clean DX where any functions related to payment are part of PR API.
from secure-payment-confirmation.
To elaborate a little on the DX and UX I have in mind here.
When a merchant invokes a new payment flow they may have very little data already about who the user is and how they wish to pay (e.g. guest checkout) or they may have a lot of this data already (instruments, user id, credential ids etc).
They should invoke the PR API, providing the data they do have and indicating to the browser (via the options
argument) which browser-facilitated steps in the flow they wish to enable.
The flow, at a high level, works as follows, where the browser MAY facilitate any or none of the steps:
- Identify the payment instrument to use
- Authenticate the user
- Confirm the payment details
- Authorise the payment
The flow is a 3-party flow involving the merchant, the RP, and the user with the browser as the mediator between them.
The flow is invoked by the merchant calling PR API show()
and control is passed to the other parties by the browser as appropriate based on:
- The data provided by the merchant
- The available payment handlers installed
- The available payment instruments installed with associated SPC credentials
Control is passed to the merchant via events on the PR object, to the RP via events in the RP's payment handler and to the user via UI rendered by the browser.
My expectation is that there will be 3 ways to invoke SPC:
- By the merchant by passing the required data directly into PR constructor
- By the merchant inside an "instrumentSelected" event emitted by the PR object
- By the RP (via an API exposed inside a payment handler, or via PR API from inside an iframe the same as the merchant methods above)
Example of 1:
let details = {
total: {label: 'Total', amount: {currency: 'USD', value: '55.00'}},
secureConfirmation: {
credentialIds,
networkData
};
let options = {requestSecurePaymentConfirmation: true};
// Empty paymentMethods means skip instrument or payment handler selection
// Using PR constructor still gives us the structured payment details to use in confirmation
let request = new PaymentRequest([], details, options);
Example of 2:
let request = new PaymentRequest(methods, details, options);
// Merchant binds to instrument selection event so browser doesn't attempt to invoke payment handlers
// Instead user will be prompted to select a payment instrument from installed instruments filtered by supported payment methods
request.addEventListener('instrumentselected', async function(evt) {
const networkData = await getChallenge()
// Do SPC using the selected instrument and the challenge from the RP
const response = await evt.confirmPayment(networkData)
await response.complete('success')
});
Obviously this is very speculative but it provides some illustration of the direction I was imagining. Does it make sense?
from secure-payment-confirmation.
I would prefer to keep the API as simple as possible for a number of reasons. One of the things that I'd like to avoid is instrument selection in the browser UI, at least for now. That means the instrumentselected
event may not be a good fit.
Distinguishing between the merchant and the RP and communicating with them in different ways also appears to introduce extra complexity without a well defined benefit. Can the API communicate only to the current web page?
As for "Example 1", it seems counterintuitive to pass in 0 supported methods, but then add requestSecurePaymentConfirmation
as an option.
What do you think about an API shape like this:
new PaymentRequest(
[{
supportedMethods: "secure-payment-confirmation",
data: {credentialIds, challenge, timeout},
}],
details);
Cheers,
Rouslan
from secure-payment-confirmation.
If SPC can be called outside of PR API, then I suggest that we not follow the pattern of your example. SPC is not a payment method. It is an authentication approach. It is not a peer of GooglePay, ApplePay, SamsungPay, SRC, etc. It should be usable by them during PR API or by a payment app. It should also be usable for vanilla form-based payment flows.
from secure-payment-confirmation.
It should be usable by them during PR API or by a payment app
Could you provide more detail on how that would be accomplished?
It should also be usable for vanilla form-based payment flows.
That's what new PaymentRequest([{supportedMethods: "secure-payment-confirmation"...
accomplishes, right?
from secure-payment-confirmation.
That's what new PaymentRequest([{supportedMethods: "secure-payment-confirmation"... accomplishes, right?
Yes, except this isn't a payment request. In my mind:
- Payment Request means "Get me some payment credentials."
- SPC means "Get me some authentication credentials."
So I would not call "new PaymentRequest()" but "new SecurePaymentConfirmation()"
from secure-payment-confirmation.
SPC can also be viewed as "Get me some payment authentication credentials"
from secure-payment-confirmation.
I've mulled this over a bit and I can see the argument for non-PR API invocation of SPC.
Assuming, based on the requirements, that the SPC Credential is some implementation of the Credential
interface as defined in the Credential Management API.
It seems sensible (as suggested by @tblachowicz in #56) that a website should be able to simply call navigator.credentials.get(...)
to invoke SPC. If the request specifies that the credential type is a payment credential then that seems a strong enough signal to the browser that this is a payment context.
from secure-payment-confirmation.
Very interesting, @adrianhopebailie!
I can see the argument for non-PR API invocation of SPC
Could you help to articulate this argument succinctly please? I am wondering whether it is a gut feel / preference derived from your extensive experience in the industry (it's great to have your expertise!
a website should be able to simply call navigator.credentials.get(...) to invoke SPC
Is the suggestion to add a special case for payments in navigator.credentials.get(...)
that has its own UI and also allows execution by 3rd parties (i.e., merchant.com or psp.com creating a signature for rp.com)?
There have been some discussions of re-using PublicKeyCredential
for SPC (instead of creating a new type of PaymentCredential
) and passing the instrument icon and name at payment time instead of at enrollment time. Is this a suggestion that these parameters be passed in to navigator.credentials.get(...)
?
from secure-payment-confirmation.
My understanding is that the answer to this question is:
- We expect SPC to be implemented in Chrome with PR API in version 1.
- In the future we anticipate moving SPC away from PR API.
So I have put a label on this ("enhancement") so that we can come back to it in the future.
from secure-payment-confirmation.
SPC brings 3 things: Cryptographic proof, Payment specific display and Cross Domain ability.
From @adrianhopebailie's comments it seems that navigator.credentials.get(...)
will be able to provide a payment specific display. By design it already offers the cryptographic proof.
The uncertainty for me is around the cross-domain access. Not sure if we would be able to manage that in navigator.credentials.get(...)
.
As an account provider we would gladly use navigator.credentials.get(...)
since we're in the correct domain. But what about merchant's need to activate this from their domain? That's a payment-handler superpower... and not sure it can, or should be transferred to the Credential Management API?
from secure-payment-confirmation.
Labeled after-v1 based on 3 March 2022 WG discussion https://www.w3.org/2022/03/03-wpwg-minutes
from secure-payment-confirmation.
Related Issues (20)
- Spec: move validation of some input parameters to construction time
- Add issuer and payment system logos to transaction dialog HOT 5
- i18n Review Checklist for Secure Payment Confirmation (headed to CR) HOT 1
- Broken "Object" xref in ยง Set SPC Transaction Mode HOT 2
- language and direction metadata needed? HOT 6
- Error example contains a hardcoded string HOT 1
- Term 'monkey-patch' may not be inclusive? HOT 1
- `DOMString` for `payeeName` vs. `USVString` for other fields? HOT 1
- Add locale hint for browser UX
- Proposal: Remove User Activation requirement for authentication HOT 1
- Use lowercase values in enum HOT 11
- Register SPC-related WebAuthn extensions in IANA registry HOT 8
- Broken references in Secure Payment Confirmation
- Example of `locale` member HOT 3
- I18N problem with displayName unresolved? HOT 3
- [PING] Only allow triggering authentication from a foreground tab HOT 4
- Broken references in Secure Payment Confirmation
- Broken references in Secure Payment Confirmation
- Add Support for Cross-Device Authentication HOT 2
- Implementing a time out for fallback UX HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. ๐๐๐
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google โค๏ธ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from secure-payment-confirmation.