- From: Gerhard Oosthuizen <goosthuizen@entersekt.com>
- Date: Fri, 7 May 2021 06:27:25 +0000
- To: Ian Jacobs <ij@w3.org>, Web Payments Working Group <public-payments-wg@w3.org>
- Message-ID: <DB9PR06MB75932F99733D7AF475735235B1579@DB9PR06MB7593.eurprd06.prod.outlook.com>
Hi Team, Some comments from my side on: * https://github.com/w3c/secure-payment-confirmation/blob/gh-pages/scope.md Ideally we can address most of them via email, and then discuss the more unclear items in our meeting. (For the suggestions the team is comfortable with, I'll then update/edit the sections in the scope document. Just want to first get your input before going off and making changes) Each bulleted header links to the relevant section in scope.md document: * Introduction * Should we perhaps already mention that this is to improve ecommerce checkout, and that Cross Domain (from merchant to issuer) and the fact that the merchant gets more control over the UX in a checkout. This is to separate this from This will help readers to differentiate it from Delegated Auth (parallel industry concept), which has the same goals, but the Identity is transferred to the merchant side? * Unique Features: * If suggest we focus on the 3 primary features (perhaps mention the others as secondary) * Controlled Display, focused on Payments * Even if we allow frictionless, the customer is in control of the display, aided by the browser. The Issuer and Merchant cannot 'skip the sheet' * Cryptographic Proof * Third Party domain enablement (so called from separate division) * Regarding the other listed features * Streamlined UX: We should restate. The need for SPC is actually because Fido is not optimized for payments today. So would not lead with that * Phishing Resistant: Suggest removing this. This is a core Fido benefit. If we use fido we'll get it. But we should not be bound by it. * Simpler Front-end: Seems to discuss controlled display and Third party combination. As mentioned, we can consider splitting this into the two sections. * Protocols and Systems Helping to Guide Requirements * For Open banking, we might want to state that this is specifically focused on the PISP use-cases (payments) * Add Secure Remote Commerce (ClickToPay) to this list * User Stories * We need to add the scenario's for Unenrollment/delinking/ updates * E.g. Alice closes one of her cards / Alice closes the account with the bank / * The bank would like to change the logo & description on Alice's card * In authentication and Enrollment, we should Indicate the extra auth step for Fido Auth * Other things can happen during a transaction. Do we indicate the cancel & Timeout option/logic/cases * Add the scenario where merchant does not support SPC. The Bank obviously does (that's why they created the credentials). So when the redirect happens to them (e.g. via 3DS or Open Banking OAuth2 redirect) the bank will want to execute SPC in their own context * Browser Behaviour / Enrollment * When does credential creation ask for a user authentication event? E.g. if credential already exists / is linked a second time / is unlinked / is created new? * Is there scenarios' where credentials may not exist? * Browser Behaviour / Transaction * If there are more than one credential that match * Should we not offer some selection by the user (especially if they are * Could the user select a 'default' in the browser * What if one of them has been 'activated' for frictionless flow. Should that be auto-selected based on some order/type (e.g. first single factor, then multifactor). * Other * Should we be specific about the fields and structure of the cryptogram? * If SPC runs inside Iframes, which permissions will be required to allow this? * Preferences * Who determines what is allowed? Or is that browser & customer permission? * If we have preferences the assertion should include it? * Other notes * Should we note the 3 classic types of payments that SPC trying to address to ensure we cover the scenario's (card Pull, Card Push, Account Push?) * Should we define if we include/exclude the actors in the payment. * Person-to-person vs Person to Merchant * Right now focus is solely on merchant, which might be right. But we should then state this. * Should we expand on the linking between the data objects/entities (linking between a Credential and a Payment token) * For Future * Discoverability of tokens on a domain (similar to Fido Level 2?) Chat again soon, Gerhard
Received on Friday, 7 May 2021 06:27:42 UTC