Re: [Minutes] 7 July task force of the Web Authentication and Web Payments Working Groups

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.
>