- From: Benjamin Tidor <btidor@stripe.com>
- Date: Mon, 20 Jul 2020 19:59:22 -0700
- To: "Blachowicz, Tomasz" <Tomasz.Blachowicz@mastercard.com>
- Cc: Danyao Wang <danyao@google.com>, Ian Jacobs <ij@w3.org>, "public-webauthn-pay@w3.org" <public-webauthn-pay@w3.org>
- Message-ID: <CAOkMxBxQoHCzHHH1qbb-F06tOWEBLhf00Fer3Go1guHbOoez1g@mail.gmail.com>
Hi Tomasz, Apologies for the very late response here -- 1. We don't believe a secure random challenge is required for the payments use case, only a unique one. We were thinking that the challenge could be derived by hashing the transaction attributes (amount, merchant, and a unique order ID that can be chosen by the merchant), which would ensure uniqueness and also serve as a way of binding these values into the cryptogram, since no alternative field is available. I believe this is similar to the way EMV cryptograms are generated (the ARQC?) where the card computes a MAC over the transaction attributes, with a counter to ensure uniqueness. The card can generate these cryptograms without needing to first communicate with the issuer and obtain a challenge. 2. In this case we would imagine using the vanilla 3D Secure flow to enroll credentials. So after the ACS authenticates the customer, it can request that the browser provision a secure payment instrument to streamline future payments, so long as the browser and device are biometric-capable. The next time the customer pays on the same browser, they would receive the upgraded biometric flow. 3. I was thinking of this in terms of 3D Secure, where the card details would be used to initiate a 3D Secure session (AReq/VEReq), which would now be carried out cooperatively with the browser. So the payment handler would need only the standard fields (the ACS URL / the CReq), plus the new SPC instrument list (I'm imagining we could extend the ARes with an extra field where the issuer could indicate which SPC instruments it will accept a signature from, and the merchant would pass this information on to the browser along with the ACS URL). Let me know if anything I've said doesn't work or doesn't make sense! ~Benjamin On Fri, Jul 10, 2020 at 6:09 AM Blachowicz, Tomasz < Tomasz.Blachowicz@mastercard.com> wrote: > Hi, > > > > Unfortunately I was not able to attend the meeting on 7th of July, so > therefore I was not able to ask my questions. I’m hoping you can help me by > providing the clarifications on the following points: > > > > 1. In order to properly generate the assertions RP must provide the > challenge i.e. secure random value that the authenticator signs. I > understand that in the proposal the assertions are going to be verified by > the issuer, so the issuer is going to be generating the challenge value. If > so, then how the value is obtained by the merchant/PSP and transmitted to > PR API? > > > > 1. From the enrolment flow I understand that the Payment Handler (?) > is registering credentials by redirecting to the issuer? I wonder how does > the PH know which issuer to register credentials for? In 3-D Secure it’s a > role od Directory Server to allow 3DS Server to identify Issuer’s ACS. I’m > missing that piece of a jigsaw in the proposed flow. > > > > 1. In the first flow the card details are key entered by the consumer > into the existing checkout form. I wonder how the card details are provided > into the PH? Do I get that right the data is simply provided into PR API? > > > > I hope my questions make sense to you. > > > > Best Regards, > > Tomasz > > > > > > > > *Tomasz Błachowicz* > > Payment API Specification Consultant > > Products and Innovation, Digital Platforms > > > > Mastercard > > Remote | Łódź, Poland > > tel +44 (20) 75132236 | mobile +48 604 746 061 > > <http://www.mastercard.com> > > > > *From:* Danyao Wang <danyao@google.com> > *Sent:* 08 July 2020 00:37 > *To:* Ian Jacobs <ij@w3.org> > *Cc:* public-webauthn-pay@w3.org > *Subject:* Re: [Minutes] 7 July task force of the Web Authentication and > Web Payments Working Groups > > > > *CAUTION**:* The message originated from an EXTERNAL SOURCE. Please use > caution when opening attachments, clicking links or responding to this > email. > > > > > > On Tue, Jul 7, 2020 at 11:44 AM Ian Jacobs <ij@w3.org> wrote: > > Hi all, > > Minutes from today’s discussion: > https://www.w3.org/2020/07/07-webauthn-pay-minutes > <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.w3.org_2020_07_07-2Dwebauthn-2Dpay-2Dminutes&d=DwMFaQ&c=uc5ZRXl8dGLM1RMQwf7xTCjRqXF0jmCF6SP0bDlmMmY&r=gGO7JtsSyntBU-GDdHDB4l3lQwFRpuFyuge3kx2OlvY&m=60YUA-t5tjMadOQ5EN93h5Kv6Irkag2afKiAVqlGZm8&s=2uPg9xslLT9hLWov7cDpt-A7_M9kuQmUvbBPZtrHNIg&e=> > > Slides from Danyao will be available shortly and linked from the minutes. > > > > Here are the slides: > https://docs.google.com/presentation/d/1MlgVNcknyzhAB0VIymoi9jW-lzzyuzAD6z2r6lAIkLM/edit#slide=id.p > <https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_presentation_d_1MlgVNcknyzhAB0VIymoi9jW-2DlzzyuzAD6z2r6lAIkLM_edit-23slide-3Did.p&d=DwMFaQ&c=uc5ZRXl8dGLM1RMQwf7xTCjRqXF0jmCF6SP0bDlmMmY&r=gGO7JtsSyntBU-GDdHDB4l3lQwFRpuFyuge3kx2OlvY&m=60YUA-t5tjMadOQ5EN93h5Kv6Irkag2afKiAVqlGZm8&s=TI23w3ZCCATIhDpU1mI0UTxTAxmeqaP_QoP-VIBvogA&e=> > > > > > Next call: 21 July > > Thank you, > > Ian > > -- > Ian Jacobs <ij@w3.org> > https://www.w3.org/People/Jacobs/ > <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.w3.org_People_Jacobs_&d=DwMFaQ&c=uc5ZRXl8dGLM1RMQwf7xTCjRqXF0jmCF6SP0bDlmMmY&r=gGO7JtsSyntBU-GDdHDB4l3lQwFRpuFyuge3kx2OlvY&m=60YUA-t5tjMadOQ5EN93h5Kv6Irkag2afKiAVqlGZm8&s=PlA1iGNP4tHRC0UrgoPCHhjFovAHqsmv2yhqi1V7ZG4&e=> > Tel: +1 718 260 9447 <(718)%20260-9447> > > > > CONFIDENTIALITY NOTICE This e-mail message and any attachments are only > for the use of the intended recipient and may contain information that is > privileged, confidential or exempt from disclosure under applicable law. If > you are not the intended recipient, any disclosure, distribution or other > use of this e-mail message or attachments is prohibited. If you have > received this e-mail message in error, please delete and notify the sender > immediately. Thank you. >
Attachments
- image/png attachment: image001.png
Received on Tuesday, 21 July 2020 03:00:18 UTC