<nicktr> https://github.com/w3c/webpayments/wiki/2020-TPAC-WPWG-agenda
<Ian> Please review the W3C Antitrust Guidance.
[Ian Jacobs slides on agenda background]
[slide 2] - Agenda
ian: our hypotheses on
streamlining checkout have changed
... and we learned a lot from experimentation and
implementation
... here's my take on our hypotheses
... 1) moving data storage from merchant to browser
... (participants that there is value here esp for guest
checkout)
... but we have not seen many payment apps beyond the
"*Pays"
... 2) a single "Buy button" would remove the "Nascar effect"
and that would be valuable
... but this didn't pan out - users and providers want the
brands
... and controlling the ordering of apps/methods on the page
remains critical
... 3) standards would encourage diversity of payment
apps
... but the cost of creating UX seems to be a real barrier
[we are at slide 7]
4) supporting a variety of authentication flows would be enough
scribe: but interest in WebAuthn
and other related topics has grown
... and privacy changes in the browsers are triggering
conversations about authentication use cases.
... handing over authentication to another group might not be
enough
[slide 10]
ian: so we'd like to present some
revised hypotheses
... A) Payment Request provides some value "as-is"
... B) There is high value in providing low-friction flows for
strong authentication
... C) There is value in providing zero-friction pathways for
risk assessment (but cognisant of user privacy
implications)
AdrianHB: we need to be aware of
payment method *and* payment values - the risk assessment that
is appropriate for low-value is not the same
... and so balancing friction and privacy is challenging
ian: there is a potential workstream associated with each of these
[slide 11]
ian: D) guest checkout
facilitation is valuable but we may have to do it differently
(and we will discuss tomorrow)
... E) to help with adoption, we may want to reduce the
complexity of the APIs/specifications to make them more
useful/easier to implement
[slide 13]
ian: we want to move payment
request forward to rec
... and we want to talk about new features and how to handle
them
... we are going to talk about Secure Payment
Confirmation
... WPSIG is going to talk about zero-friction risk assessment
and it may come back to the working group in the future
... we are going to hear about use cases from a number of
different payment systems
[slide 15]
ian: SRC demos tomorrow
... we would like to present some prioritisation on Thursday
(good luck Chairs)
... it would be good to have a plan
... and we need to start looking ahead to charter renewal (or
otherwise) at the end of 2021
NickTR: Thanks for putting that together, Ian
[Danyao Wang and Benjamin Tidor slides]
Danyao: Problem statement: enable
strong auth during checkout that works at scale for all payment
methods across all merchants
... Four design principles:
1) Great consumer experience (fast, low-friction)
2) Each of adoption for merchants and issuers
3) Satisfy PSD2 SCA including dynamic linking
4) Privacy preserving by default
Danyao: For scalability:
1) Want one credential that works across all merchants
2) Don't want merchants to have to have out-of-band agreements with financial institutions
3) No redirect or iframe for usability and privacy
Danyao: SPC Is basically a combination of FIDO and PR API
(Ian referred to this earlier as "coupling the APIs")
Danyao: The pilot use case that
we describe here is to leverage WebAuthn as low-friction 3DS2
step-up. It does not involve stored credentials, to make it
easier to test with a traditional checkout form.
... API superpowers are two-fold:
1) Cryptographic binding of transaction details into the authentication assertion
2) Merchants can exercise payment credential owned by the issuer (the RP). In vanilla WebAuthn, this would not be possible. Only possible in PR API context
Danyao: We are shipping this experience in Chrome 86 on MacOS, available for origin trial.
[Demo by Benjamin Tidor]
Benjamin: User selects or enters
instrument before SPC is invoked.
... In enrollment flow (0) user is authenticated through
something like OTP (1) FIDO authentication credential is
enrolled with the issuing bank and (2) payment is
completed.
... during checkout, the user is given the option to confirm an
amount from an account to a beneficiary, and then to sign that
information using the enrolled credential
... ...so that's a good experience and the data should support
transaction confirmation use cases
Jonathan_Grossar: It's great to
have these new browser capabilities because it enables other
parties to have access to credentials, and because the browser
is displaying info for transaction confirmation. Will this
capability be available for other use cases than 3DS?
... e.g., some merchants might want to use their own
credentials, or a wallet might want to use these
capabilities.
... I'm not sure about the scalability comment since this seems
to require all banks to provide FIDO servers.
Danyao: To answer Jonathan: Yes,
this capability is available for other flows. All that's
required is for an origin to provide credentials to the browser
to prompt for authentication. The details of where the
credential ids come from is left to the use case.
... ...in some cases it might be from the merchant, or the
merchant might have to fetch them (e.g., from 3DS server)
... or a payment handler could provide them
Jonathan_Grossar: When we document the assumptions we should make clear it's not just for banks.
Chris_Wood: How do discoverable credentials (formerly, "resident keys") fit into this?
Danyao: We are aware of discoverable
credential capabilities, but we haven't yet thought deeply about how
to integrate them. But our design does not assume discoverable credentials
because (1) we want this to work with WebAuthn Level 1 and (2)
not all authenticators support discoverable credentials.
... we want to look more into this; conceptually it should work
pretty well
... To recap the demo, there are two flows: (1) Enrollment of
credential on a device with an RP (2) checkout flow
... During checkout, merchant needs to know credential ids. The
pilot leverages 3DS (PAN => credential id)
... merchant provides credential id to browser which prompts
user to authenticate
...the browser displays
transaction details, combines details into the webauthn
request, and then returns the Web payment assertion (including
signature over transaction details)
[Danyao shows flow diagram of initial proposal involving 3DS server]
Danyao: SPC experiment is "as a
payment method" but the expectation is that SPC (once it
demonstrates value) will be implemented in away to make it
available across payment methods
... Note that the dynamic random data is provided by the
issuing bank (Relying Party)
... the dynamic data is input to Web Authentication
... the browser returns information useful for transaction
confirmation in plain text, but also a signature over that
data. That allows the RP to validate the data.
[Danyao shows SPC from an API / implementation perspective]
Danyao: Contact me if you want to conduct an origin trial. The Stripe experiment is expected to run for about 8 weeks. We expect full analysis by Jan 2021. Thank you Stripe for being willing to share data on the experiment when complete.
[2021 SPC Roadmap]
Danyao: If SPC proves useful we need to:
a) Get changes to 3DS to support credential ids, etc.
b) We need real ACS to implement this
... once we have done these
things, we can make the API available to everyone.
c) Explore compatibility with Android SDK
d) Standardization and availability on other platforms
e) SPC for other payment methods....we are looking for collaborations with other partners
Danyao: looking for developer interest and browser implementer interest in SPC
NickTR: Thanks Danyao and Benjamin!
Jeff_Hodges: Where in the flow is the network data conveyed from the issuer back to whoever is putting together the challenge?
Danyao: The network data comes back from the issuer to the merchant via a new 3DS message. The merchant provides the data to browser through PR API
tomasz: Thanks for the demo; great to see this coming together. Will this be available to payment handlers as well?
Danyao: Yes.
... Payment handlers need to open a window to use
WebAuthn.....SPC could remove at least 2 clicks in a payment
handler context
... SPC today can't be used by a PH, but in the future yes.
Gerhard: Like others I am excited
by this.
... +1 for Android support!
<nicktr> +1 for android too
Gerhard: Please also consider
hybrid apps in your thinking.
... 3DS adoption may be slow. Have you explored other ways to
accelerate adoption?
Danyao: I have understood indeed
that adding a message to 3DS may require a couple of years. So
backwards compatibility is top of mind .... namely shoehorning
flow into existing messages.
... but we don't yet know exactly what this would look like. We
are having good conversations with Sameer, et al. in 3DS WG
Benjamin: We've heard from others as well that this needs to work before 3DS 2.3.
Gerhard: Does this flow support frictionless?
Danyao: Not right now, since the pilot involves step-up. But we've heard clearly that people want this to work with frictionless flows. So we will be figuring that out.
Gerhard: There are two
cryptograms (1) FIDO cryptogram and (3) 3DS cryptogram.
... It would be great to provide as input a PAN and get back
the real cryptogram. Has there been any consideration around
removing the need for an explicit AReq from the merchant if
they can get the cryptogram another way?
Danyao: I think Mastercard is
looking at getting final cryptogram via a payment handler
... Our current approach is intentionally experimental to
reduce cost on merchant but I agree PH might be next step to
combine 2 into 1
<Zakim> Ian, you wanted to ask when SPC turned from payment method to capability (wrt roadmap) and to ask about 3DS message status
ian: SPC is implemented as a
payment method - but we've heard that it's desired to work
cross-payment method
... where does this become a "capability" rather than a payment
method in the roadmap?
<Ian> Danyao: SPC-to-primitive might happen at origin exit or sooner
ian: what's the latest on the 3DS message? New message? Changes to existing message?
<Ian> Summary of impact on 3DS today and in future?
Benjamin: In the explainer
there's a note about what it looks like for a payment to
support SPC and what functionality is required.
... EMVCo is looking at what it would take to integrate into
3DS. I think there a couple of proposals under discussion
<Zakim> nicktr, you wanted to talk about implementation/adoption
nicktr: In response to a Gerhard comment...we should not be swayed by the need for change in order to produce a significant improvement.
<btidor> ++nicktr
NickTR: ...illustrating reduction in drop-off really drives home the business case.
Danyao: Thanks, Nick. Benjamin, ball in your court! :)
Tomasz: Regarding the need for
adoption by merchants...is there data about how many banks are
going to use Web Authentication?
... the proposal relies on an assumption that banks will adopt
Web Authentication over other authentication mechanisms.
Benjamin: We have heard some
positive signals from some ACS's
... even anecdotally we've heard within Stripe that having
strong authentication integrated into the platform is
attractive.
Tomasz: Issuers need to be sure of wide support otherwise there is a risk of dropoff
Benjamin: I think partly it remains to be seen. Work in 2021 will involve getting more adoption. Issuers will need to run a FIDO server but won't have to do a lot of front end development. They could use Web Authentication today but SPC will make it easier for them.
Tomasz: It would be great to see some data about issuer adoption potential
Gerhard: We've seen a lot of
interest from issuers we've spoken with. They have wanted to
know where deployed. All solutions will have a hybrid
approach....some will use SPC, some will use apps, some will
use OTP.
... but we've definitely heard interest in this for
ecommerce
AdrianHB: Regarding payment
handlers: there is a communication between the merchant and RP
(or bank). Payment handlers let you run code in the browser
from the RP. It might replace one or more backend calls. In the
3DS case, the preference was to stick to the existing merchant
and ACS (which flows via the backend). But for other payment
methods, payment handlers would definitely be a valuable
alternative.
... all the proposed architectures are going to be validated by
experimentation as we go
Ciciley: Will there be any
efforts to include fraud measurements for issuers? There is
still the concern around synthetic fraud (see synthetic fraud definition, for example).
... I recommend that your
pilot includes scenarios when someone pretends to be someone
they are not.
... what failsafes are in place to prevent those transactions
from being false positives
Danyao: Thanks for the
recommendation. This is one of the benefits of using FIDO. The
main ID & V happens at enrollment.
... after enrollment, the authentication is just checking that
the user is still in possession of the authenticator.
... There may be attacks still possible, but it's likely they
are more difficult than, e.g., just stealing a phone
number.
Ian: See FIDO White papers and ID & V work. Also, see the work of the >WebAuthN Adoption Community Group, which may be able to help out in understanding obstacles developers (e.g., of banks) face in adopting Web Authentication.
<Chris_Wood> For info: 3DS 2.1 & 2.2 handles FIDO data as a blob in the field threeDSReqAuthData - 2.1 has a 2k limit, 2.2 has a 22k limit
NickTR: I absolutely hear
Ciciley's concerns. The balance of consent, authentication,
friction, etc. is at the heart of the debate.
... the merchant business group will be another venue to hear
from merchants about priorities; talk to me about that
... when people talk to me about "what's new" in the SPC space,
the availability of (conforming) authenticators on so many
devices is really new and exciting
Danyao: Thanks for the questions
and recommendations. We welcome feedback moving forward.
... you can file issues directly on GitHub:
https://github.com/rsolomakhin/secure-payment-confirmation/issues
Benjamin: Thanks all!
ian: shout out to Marcos
Caceres; it's the middle of the night for him so he is unable to attend the meeting.
... payment request is deployed and is being used
... our plan in 2019 was to increase adoption
... the browser members of our
group have indicated an enthusiasm to move to a full
recommendation
... today we are a "candidate recommendation"
... the next step is "proposed recommendation"
... but because we have removed some unimplemented features we
need to go back through CR
... the Call for Consensus lists the changes. The first is to remove "merchant validation"
into a separate specification to be published as a note
... hasEnrolledInstrument is not shipping in two browsers so we
have moved it to a "future" version and it won't be a formal
part of v1.0
... and we continue to look at privacy implications of
hasEnrolledInstrument
... lastly we had a included an attribute to allow child frames
to implement payment request but we have deprecated it in
favour of a more general attribute from HTML5
... I wanted to call out that we had a privacy objection raised
by Sam Weiler around oversharing of address information.
... there has been discussion around this and a proposal of how
to fix, but there are no implementations of it
... but the desire is to move to
a more stable "V1" spec while continuing to work those privacy
issues
... our call for consensus ends on Monday 26th October
... there are a large number of steps to go through but our intention
(see timeline) is to reach "Recommendation" late in Q1 2021
ian: I would be interested to
hear informally from the group - this is not your formal
response
<Ian> SHOW OF HANDS SUPPORTING THE MOVE TOWARD REC?
<AdrianHB> +1
<benoit> +1
<danyao> +1
<Chris_Wood> +1
<Anne> +1
<Ciciley> +1
<Ian> IJ: Please reply to the CfC by 26 October!
<Ian> NickTR: Thanks to presenters and people who raised questions.
<Ian> ...tomorrow we'll talk more about architecture and SRC
<Ian> [ADJOURNED until 20 October]