<Ian> Scribe: Ian
Rouslan: Payment Method Manifest
- allows us to authenticate payment apps and allow payment
method owners to delegate authority to payment app
distributors
... we would like to go to FPWD
... we have implemented PMM in Chrome...it is being used by Tez
(India) and Samsung Pay
... Chrome looks for a payment method manifest (by using a
header)
... there have been some concerns about leakage between payment
method identifier and manifest
... we decided a year ago to go with HTTP Link header
... The contents of the payment method manifest are JSON
... contains different values including
"supported_origins"
... this tells Chrome which payment app origins can fulfill
this payment method
... note that "*" value means "any origin"
... this could be useful for open payment methods
AdrianHB: What is the behavior if you get no response?
Rouslan: Denial
Manash: Does manifest file cover both mobile and web apps?
Rouslan: Yes
Mountie: Is "Localhost" supported?
Rouslan: We started by not
supporting localhost; we heard people wanted it, but there are challenges
in supporting it all the time so we may treat this as
a flag that developers can turn on to support localhost
... Another bit of information in the manifest: a list of
default applications
... though are URLs to web app manifests
... Final, supported_origins is a list
... (where "origin" means scheme, domain name, port if
non-standard)
... this is useful for use cases such as an organization that
certifies payment apps
[IJ thinks that Masterpass is in this category]
[Rouslan shows a Web app manifest]
Rouslan: in the case of android
payment apps, the fingerprint is used to authenticate the
payment app
... We got some interesting feedback based on deployment
experience:
Rouslan: Caching needs will differ
Manu: Has anyone talked about putting these manifest files on a CDN?
Rouslan: We've not thought about it but could be done I guess.
AdrianHB: Do you respect redirects?
Rouslan: No.
... we want to be as strict as possible
... your CDN could be non-redirecdting
... Questions
Nick: Can a fingerprint apply to multiple versions of an app?
Rouslan: Yes, in android pay store
Manu: +1 to going to FPWD
... who else is going to use this?
Dongwoo: Samsung
Sachin: MasterCard
NickTR: No objections to moving towards FPWD
<scribe> ACTION: NickTR to help get Payment Method Manifest to call for consensus
Cyril: We have several payment
methods. We built two for two general types of Credit
Transfers: Payer-initiated and payee-initiated.
... the third is specific to the PSD2 context
... each payment method defines data sets (based on data models from
other standards)
... payer-initiated credit transfer raises a security issue -
fraud might lead to wrong merchant account number.
... so payee-initiated intends to address this concern
... payee gets a token and allows the merchant to use a token
to initiate payment
... there are still issues (e.g., token needs to be sent
quickly, otherwise risk of double spending of amount in the
account)
... but a bigger issue right now is whether there is support
from banks for this type of API
... so with these issues in mind, in PSD2 context we have
another payment method (PISP) that leverages relationships and
validations that exist in the PSD2 ecosystem
... the PISP payment is a simpler data flow
... but primarily the big benefit is that the merchant IBAN is
not sent over the Internet
... there are different flows that we can imagine (e.g., at which
moment user authentication takes place)
... the PSD2 bank APIs will be open APIs, so we can experiment
with different flows
... there are several open bank APIs efforts (e.g., Open bank
in UK, STET, Berlin Group)
... next in the presentation: Matt will show experimentation by
Worldpay
MattS: We updated our three
payment methods and then decided to do some
experimentation
... In the UK we have an open banking API
... the API will be available for production use in Jan
2018
... the API is not yet PSD2-compliant, but they do plan to do
that by adding 2-factor auth
... Worldpay is an acquirer / processor; we help merchants
accept payments from shopper
... there's no place in the PR API that acknowledges
processors. So it's an interesting question for us to see
whether we can use PR API to increase conversions
... we considered the three payment methods in conjunction with
the open banking API
... we could have also implemented our own payment method (and
had we done that, we would have used a payment method manifest)
... for this experiment we chose the open banking API, which
supports a split authentication and execution
... we also tried an implementation that does not use PR
API
... since PR API not entirely deployed
[Demo]
<Jalpesh:> is it ok to take the video of the demos, when presented in the room?
<Matt:> Yes.
Matt: In demo of traditional
flow: pick a bank, identify yourself, choose an account,
confirm details, and payment confirmed
... In version with payment app: You open the sheet, choose
account, push the "Pay" button
... then another screen appears (you are in a payment
app)
... at the moment it's difficult to differentiate that you are
in a payment app
... this is important
... we would likely show N registrations (one per bank)
AdrianHB: Could you skip a step in practice if you just have your own bank?
MattS: Yes, depends on
registration
... What you saw today suggests that the user experience
between "without PR API" and "with PR API" is very similar
today; the "with PR API" will need to be improved
[Review of the payload]
Matt: The open banking API does
not use ISO 20022, so there is some challenge in mapping
data from the credit transfer spec (which refers to ISO 20022). The Open Banking API would
like the delivery address.
... the most important reason is fraud mitigation....e.g.,
compare cardholder address with shipping address.
... but the payment app does not receive shipping address (via Payment Handler API)
... there's also a concern that payeeAccountNumber could be
tampered with
... that's the primary motivation behind the PISP payment
method design
[Discussion of signatures]
Cyril: Worldwide PKI is hard to
achieve
... PISP is easier to achieve (maybe 100 PISPs in europe)
<AdrianHB> The need for delivery address as input to the UK Open Banking API suggests we should find a way to solve issue 123.
[MattS walks through various mappings between w3c data model and Open Banking]
Matt's observations:
Matt's suggestions for WG next steps:
AdrianHB: ILP is for
internetworking different payment networks
... for payment request, focus is on standards, not
internetworking: addressing, reconciliation, proof of
payment
... payment method identifier is interledger
... request data includes address, amount, condition,
data
... we have an addressing scheme that endeavors to make it
possible to address any account in any ledger
... the hierarchical approach assists routing
... We used a normalized amount (64-bit unsigned integer)
... and we have a "scale" based on the receiving account
address
... so scale for USD is 2; scale for bitcoin is 8
... finally, last two pieces are condition and data
... when the payee sets up a payment request, the payee
attaches the condition to the payment request. Data is used to provide
integrity protection
Manu: What org manages the hierarchy?
AdrianHB: Ecosystem-defined
Manu: How do you avoid name collisions?
AdrianHB: Because of the way a
protocol works, you can't claim to be someone you are not
without proper crypto
... There is a whole spec on addressing
... very little of this as specified has gone beyond the
Community Group
... the condition is a sha256 hash of the fulfillment
... payee has a secret
... sha-256(payment data + secret) = fulfillment
... sha-256(fulfillment) = condition
... payer gets back a proof
of delivery of payment (useful for reconciliation)
... the fulfillment is common across nodes; to help with
certainty that payment has been delivered
[Demo]
AdrianHB: As merchant I can verify that the fulfillment matches the condition, so I know that the payment has been delivered.
Keyur: Who is responsible for converting between currencies?
AdrianHB: As the sender, I can go to the network to get quotes (and choose least expensive mediator based on, e.g., conversion rates)
oyiptong: Rationale for encrypted
card is PCI DSS compliance
... lots of horror stories about PCI DSS compliance
... It's hard to become PCI-DSS compliant and EVEN HARDER to
maintain compliance
... review of study done by Verizon on breaches and lapses in
security
... summary: it's difficult and costly to remain
compliant
... but PCI-DSS compliance is pretty useful; it enforces some
good practices
... it's good for merchants to reduce scope
... for merchants there are three main compliance levels we
care about: SAQ A, SAQ A-EP, and SAQ D
[Olivier looks at the eligibility criteria of each, whether ASV scan is required, penetration test required, and number of questions]
SAQ A: 22 questions
SAQ A-EP: 191 questions
SAQ D: 329 questions
oyiptong: Basic Card used as-is
would require SAQ A-EP.
... in the tokenization task force we have looked at a
journey:
[Olivier shows different flows and PCI impact]
oyiptong: One option is for the
merchant to provide a key through PR API. We could use trusted
third parties to generate the key, which could be validated by
the processor
... Instead of the merchant providing the key, the merchant can
designate a key provider and the browser can fetch the key (and
cache it)
[Demo]
oyiptong: note that the data is encrypted (otherwise similar to basic card)
[oyiptong shows payment request data and payment handler service worker registration]
Summary:
oyiptong: Here is my ask!
... I think it's worthwhile implementing this directly in the
browser
... if it's treated like basic card, it will help increase
security and make PR API mainstream
IJ: One proposal to increase security is to have the user agent (or payment app) fetch the key rather than having the merchant pass it directly.
Jenan: We recently released our
integration with PR API. We solve this problem with same
tooling.
... Stripe PR API initiates payment request from an
iframe.
... that solves PCI scope for Stripe merchants
... we further add value beyond mere encrypted blobs
... So we don't think this adds value to Stripe merchants since
we solve for it.
... furthermore, you can't encrypt the CVC per PCI rules (I
think)
... one answer to that is potentially not do client-side
encryption but encryption is merely posting data to a
server...in essence replicating our API
... our experience is that we've seen calcification in the past
when multiple parties have had to agree to a single API
... we have preferred to keep an evergreen approach
oyiptong: Thanks! Regarding
implementation by using an iframe - it is possible to use an
iframe...but the value here is if browsers implement.
... I think this would compete with Stripe's implementation;
that's a fair point
... on your second point (not encrypting CVV)...I thank you can
encrypt it but not store the CVV
NickTR: I am not aware of requirement not to encrypt; but you can't store it
CyrilV: This means that when I
use my card with a merchant for the first time, the card data
is encrypted (and could be stored for use each time with that
processor)
... that might scale well because the number of processors will
be small
... so this seems interesting to me.
Manu: +1 to encrypted card
payment method
... would be great if we didn't do basic card at all
... We could deprecate Basic Card at some point
Marcos: Maybe, but there are a million systems out there
mweksler: Think of the conceptual
framework of nothing leaving the browser unencrypted
... we should be able to get the data out of the browser
without exposing it
jean-yves: +1 to Encrypted card proposal
shift4sms: +1 for Encrypted
Card
... and would be great to deprecate basic card as much as
possible
... regarding CVV...you can encrypt it and technically even
store it pre-auth
... the only 2 things I would add to the data method is the
expiration date (e.g., to ensure card is valid for a reservation
three months from now) and the other bit of data
is the 8-digit prefix; some people do routing based on card
bin
... PCI-DSS is evaluating how secure iframes are
etienne: +1 to encrypted card
Giulio: A couple of questions -
what is the additional work required of the browser?
... I also note that tokenization and encryption might
co-exist
oyiptong: The problem of tokenization is that we need to standardize the communication between servers.
Ian: Regarding what the browser does - it would optionally fetch key, then encrypt in CPU
MattS: Why not extend this beyond basic card to allow encryption of any payload?
<nicktr> is having an allergic response to 250000 key exchange ceremonies with each merchant
AdrianHB: An alternative approach
is pass in a certificate (not just a public key) and for the
certificate to be the identify of the merchant. You would as a
merchant to have a signing cert; and you could give private key
to your processor
... the idea is that when the payment handler gets the request
and looks at the cert, they see that the origin of the cert and
the merchant is the same
... there may be additional options as well
jenan: To reiterate - I think
it's important to distinguish security from PCI
compliance.
... I'd love to see a concrete proposal regarding the
cert
... and to hear from browsers whether they are interested in
implementing this
... I think the proposal as it stands today doesn't solve
security....
... unless there is some presentation of the source of the
encryption key to the user, or some sort of whitelisting, or
some way to know who is doing the encrypting, it's not
materially better than today
<dlongley_> also, don't have to use the public key from the merchant's certificate to encrypt, could use the issuing certificate's public key (either presumably the PSP or explicitly indicated)
<jenan> also: would be useful to answer in finality what the "saq-a v. saq-a-ep" implications of encrypted cvc (etc) are. We could be interested in something that provided that security and where there was interest by browsers to implement
<shift4sms> Re: Encrypted card. Some concern on pub key served by merchant site cannot be trusted -sites can be hacked creating a man-in-the-middle hole. We’ve discussed this quite a bit internally (@Shift4). Without a payment app and merchant “certificate like” authority, not much effort should be given to plugging “site hacked” hole because a hacker can do pretty much anything, with or without man in middle. Simply changing payment method from encrypted ... PKI man in middle attack and just as effective.
NickTR: I am hearing there is strong support in the room for looking more into this payment method
<manu> scribe: manu
JamesAnderson: Mastercard, joined for a
number of reasons - we care about ubiquitous usage, simplified
contextual user experience, security with scale...
... This means we care about tokenization.
... We're trying to make the ecosystem secure... dynamic
payload... that's a big part of network tokenization.
... We're trying to reinvigorate 3DS... consumer auth
protocol... answers the question: is this the user? There was a
1.0 of 3DS, but it was no longer fit for purpose.
... We went through 3-year effort to make it fit for purpose
now... got to 3DS 2.0 - bringing this to W3C, gives us benefit
of security at scale.
... There are standardized already, wanted to bring them into
W3C... not onto the Demo.
Manash: What we did in the last
3-4 months - we looked at how you create a good UX... leverage
wallets that are already out there, built it on top of payment
request.
... We have a demo - AirBnB experience... basic card, custom
payment method... what if the PR API can say I support all
wallets that can return network-based tokens. In terms of discovery,
all those that become a standard payment method will discover
it.
... When I click "book", I see all apps that support standard
network token payment method... I click pay and can pay.
... J Crew have already implemented Payment Request API... and you've added an
item... checkout now supports PR API
... Network tokens could be standard payment method... it'll
show masterpass as a standard mechanism... lowers the merchant
implementation costs... makes it very standardized for
discovery.
... Why are we doing this? There are gaps with Basic Card...
it's not secure, increases PCI scope, bad UX - CVC... any bad
steps hurts conversion ratio.
... one in six transactions will be declined. If merchant wants
something more secure, they can do custom payment method.
... You could integrate with
alipay, samsung pay, apple pay, etc. Apple Pay only sends back
transaction ID -
... Network tokens fix this issue... multiple different native
apps can send back standard tokens back to merchant...
... Sachin will go through network token specs... what other
partners can move forward and help w/ token spec?
<scribe> scribe: Ian
Sachin: Walking through the
Tokenized Card Payment draft. Keys will need to be
certified
... I would like to discuss that further
... when the TSP gets a request for tokenized card, they
encrypt it with public key and that they have seen in the
past
... they have already onboarded the entity
[We review the request and response data]
Sachin: Note that the response
distinguishes display data v. token data
... Encrypted Tokenized Card ensures your PCI DSS status
shift4sms: What happens when the PAN is compromised? Are the tokens that were issued also compromised?
Sachin: That risk remains
... you can just deactivate token
James: Issuer can also send a new PAN that maps to existing tokens
AdrianHB: It is possible to request only encrypted tokens?
Manash: Let me do a recap:
Sachin: We were thinking of adding encryption on top of tokenization as a PR API extension
jalpesh: What is the meaning of the token expiration date?
Sachin: Each TSP can decide what
it should be
... what we have tried to do from this is distinguish "display
content" from "payload"
Jalpesh: I bring it up because in a tokenization world, expiration data may not be relevant. So why display it from a user experience perspective?
mweksler: How does this relate to card on file? This seems mostly useful for one-time payments
Manash: I think there are two
layers
... right now card-on-browser is stored as basic card
... browsers could move to tokenized card.
... for merchants who have card on file - networks have a
product that assists merchant to convert Card on File to
tokenized payments; but I think that's outside w3c scope
NickTR: Acquirers also can do this
mweksler: I think it would be great to figure out a way to onboard cards but also with respect to card-on-file processing
NickTR: I think the use case we need to solve for is enrollment
Keyur: There is also some
one-time use data in the response
... (cryptogram)
... that's already in the spec
AdrianHB: I have a suggestion
around nomenclature. I suggest avoiding the word "card"
... in the future the exchange could be same but without
card
Sachin: +1
Manash: +1
shift4sms: +1 on deprecating “card”
[Robert Reany slides on 3D Secure]
Robert: 3DS has been reinvented
in 2.0 (and now 2.1)
... I think that there is a good opportunity for what is being
to discussed her to help user experience, even as we recognize
that there is an extant 40-year old ecosystem. Regulators are imposing
2-factor authentication on banks
... on every transaction (or must decline)
... in some markets it will be required
... e.g., in India 2-factor is required for pretty much every
transaction
... we are trying to work with the reserve bank....since there
is more data available (FIDO, phone data)
... and you can safely improve transactions without
step-up
... that's the sort of dialog we have to have with
regulators
... another story in PSD2
... strong auth + risk-based assessment + risk-based auth
... my big message is "don't create a new great user experience
without considering the regulatory expectation"
Brian: The D refers to
Merchant/Acquirer domain + interoperability domain (networks) +
issuer domain
... "frictionless" risk-based authentication
... FIDO auth should be part of the data package - auth has
already occurred and we don't need to step up
Opportunities:
Brian: how do we enable scale and streamline the entire end-to-end ecosystem?
Manash: What is 3DS 2.0 going to be important? One
reason is regulatory requirements. if the merchant is using
PR API they would also expect the browser or payment app to
handle the 3DS 2.0 requirements....
... if that DOESN'T happen, each merchant would have to deal
with it individually
... so for international adoption of PR API we need to take
into account 3DS 2.0 and in a manner that is scalable
... as next steps, there is a design session during the
Wednesday breakouts
... it would be GREAT to have browsers in the room for that
chat
... and also merchant reps in the room to have an informed
discussion of relation of 3DS 2 to various payment methods
Manu: What modifications are you expecting to make to payment request to support 3DS?
Manash: We will go into detail
tomorrow
... instead of just returning basic card payload
weiler: When talking about the information you are collecting, do you have a full list of data you want? A lot of these things are fingerprinting...how do you fall back if we succeed in limiting fingerprinting?
Brian: Most of the data relates
to the data already being sent back to the menrchant
... we will go into details tomorrow and look at data
protection
Weiler: What is the option if user does not want to share data?
Sachin: Likely decline or step up
The conversation continued on 8 November in a breakout on 3DS.
<nicktr> scribe: nicktr
Ian: Let's talk about
branding
... this is super important for adoption
... about a year ago, we started a merchant adoption
workforce
... we identified 4 priorities:
Ian:
... Time for the visual identity
...question: what is the goal?
... to be another button amongst a sea of buttons? No
... What we need is something analagous to the RSS logo
... we want it to scale across sites and platforms. The identity is not
shown in the slides - still
not cleared by legal
... here are some iterations
... please don't take pictures
[Ian shows images]
The HTML5 logo rollout experience will be
instructive. If there is support for the logo,
next we would finalize the identity and palette of
images, buttons, FAQ
... legal clearance
... Comms strategy from W3C staff
... Suggestion is to unveil during CR e.g. Jan 18
... But we need member support to drive adoption
<sachinahuja> Reminds me of a transport logo or this transport logo.
Ian: Discussion - do we like it? Does it look similar to other things? Should it be a trademark? Trademark could affect licensing
????: is the concern that a rogue polyfill might use the logo (or not)
Ian: We weren't thinking of a rogue polyfill. The question is whether we want to have some authority to ensure there is a consistent and trusted user experience.
manu: we don't have this anywhere
else
... by which I mean we don't enforce usage/conformance
AHB: we had logos but they weren't policed
Ian: that is correct
shift4sms: trademarking is important
CyrilV: we had something similar in France. We used a "sharealike" license
ian: HTML5 logo is CC-by 3.0 unported.
Ken: I personally like the idea
of a logo, but I don't like this - it looks like crossed
arms
... but it would be good to align to something visually similar
to NACHA, for example, and mutually support each other's
APIs
... My own perspective is that the symbol needs to deliver on
something
Ian: Historically we have not allocated resources to police W3C logos (other than the main W3C logo).
<Magda1> *now we're going to start seeing it everywhere*
Ian shows black background logo - 15 likes in the room
Ian shows white "cut out" logo - 14 likes
Ian: does anyone really hate this?
<Zakim> manu, you wanted to wonder why we don't try to integrate w/ HTML5 "logos"
Ian shows HTML5 turned into a dollar sign.
Ian: I was told not to mess with
the brand
... also we're not in that HTML5 space anymore
Magda: we need lots of difference colours, formats
oyiptong: scalability is an
issue (that is: it should work when very small)
... one seems more scalable (black bg)
Ian: I record Sachin really not liking it
Sachin: these are very generic and call to mind transit
keyur: can this be cobranded? It's going to be powered by browsers
Ian: Interesting question. Question to Microsoft?
????: Realistically it would be used just next to some other brand components
adrianHB: square not round
please
... expectation is that this stands for a specific kind of
experience
... it's more subtle than a big logo, it's more a cue
matt: Should this be "www payments"
instead of "web payments"?
... I wonder whether we have decided to be web payments
formally
Ian: We have not decided on a
name but we did talk about it in the merchant adoption
taskforce
... for a while we were going to call it payment request, but
then "web payments" emerged
... we haven't made a formal decision
... Thanks for the feedback.
[We extend our thanks to Stephanie from the Microsoft Design team who did this work]
AdrianHB: let's move things around on the agenda and do next meetings
Ian: TPAC 2018 takes
place in Lyon from 22-26 October next year.
... it feels like we need at least one F2F before then
... and it feels like we probably ought to meet in Asia
<Magda1> *+1 Bali*
Ian: we could co-locate with Money2020 China?
AdrianHB: what time frame do people want?
(crickets)
AdrianHB: we should be looking at going to CR for Payment Handler Q2 next year and we have new payment methods to look at
Ian: I don't think we need to tie this to the charter renewal
AdrianHB: should we leave a gap between charter and F2F?
nicktr: we hope to recharter by end of Feb 18
AdrianHB: sounds like March to May window
Vincent: avoid school holidays in April please
Manash: end of March feels good. May sounds too late
Ian: anyone want to offer a venue in Asia?
oyiptong: we have an office in Singapore - let me investigate
Ian: we also have a host in China
ken: in the payments world, our T&E is planned a year in advance and we plan from May. So March would be good
<scribe> ACTION: nicktr, AdrianHB and Ian to work up a proposal on the F2F location
<Magda1> +1 for encryption to hot topics list
AdrianHB: does anyone want to dig into any specific topics?
nicktr: let's do data privacy and encryption
npdoty: yes, leaks incognito,
but also whether you have specific cards which could be used
for fingerprinting
... is the specification going to explicitly limit this or just
rely on implementations
manu: has PING done any analysis on shipping address leakage?
npdoty: I haven't looked at that in particular. The implicit mitigation is that it only occurs when the payment sheet is visible on address and limiting to top level browsing context
AdrianHB: the big challenge with canMakePayment is that there's no user-interaction or hints. The mitigation is velocity
npdoty: can you mention any more detail?
AdrianHB: It's already there in
the Apple Pay implementation. The purpose is to streamline the
payment process so merchants don't call paymenbt methods that
would need registration or introduce friction
... the sticky issue is whether the specification should
comment on the velocity
... I think you only get one shot with canMakePayment
npdoty: would it be useful to find out if the consumer can support paymentRequest?
mattSaxon: because the ecosystem is complex with many payment methods, it's very challenging
npdoty: it's the driveby nature of this feature that makes it problematic.
AdrianHB: unfortunately we don't have the implementers but there was a bug
npdoty: there was also a problem with iterating iframes. I don't know whether that was resolved
Ian: I don't think we know.
AdrianHB: I think we need implementers here in the room.
(break)
Ian: Patent Advisory Group will
need to be launched given Visa patent disclosures
... these work by asking each participants to put forward
people to join the group to review the patents that have been
disclosed and/or excluded
... the next thing you will see is invitations to join the
group
Manu: did they disclose then join?
nicktr: no, the other way around
AdrianHB - I propose we break for the day
nicktr: thank you everyone for a
great couple of days
... three potential breakouts: encryption, HTTP API and IETF,
signatures
