sorry to hear that
https://lists.w3.org/Archives/Public/public-payments-wg/2017Nov/0035.html
<scribe> Scribe: Ian
https://github.com/w3c/webpayments-methods-tokenization/wiki/Generalisation-of-Encrypted-Card
MattS: Olivier presented
Encrypted Card idea that was specific to Basic Card
... we observed during TPAC that encryption would be generally
useful for other payment methods
... for example, encrypting the merchant IBAN to avoid MITM
attacks
... or for network tokenization (as Sachin and Keyur
explained0
... we organized a breakout session during TPAC week
... we explored 2 routes....
1) What changes might be needed for PR API?
scribe: I think there's a possible pattern that might require no changes to PR API
(See https://github.com/w3c/webpayments-methods-tokenization/wiki/Generalisation-of-Encrypted-Card)
2) What changes might be limited to payment apps to avoid PR API?
scribe: We don't know how we will
do signatures in JSON
... I think we have concluded that JOSE from the IETF is the
best way
... it does make the JS opaque, but it seems to be the best
standard available
... I need to extend the proposal to say how we will do
encryption and signatures
https://github.com/w3c/webpayments-methods-tokenization/wiki/Generalisation-of-Encrypted-Card
https://github.com/w3c/webpayments-methods-tokenization/wiki/Generalisation-of-Encrypted-Card
mattS: What I've done online is to write the proposal and use an issue to tackle reviews
https://github.com/w3c/webpayments-methods-tokenization/issues/22
MattS: Has anybody reviewed it?
[Nobody yet]
Sachin: Am interested would be happy to walk through
Jalpesh: Also interested
... two areas - how would signatures work and mitigate the MITM
attack?
MattS: I may have to clarify how
encryption and signing affect different things
... suggest people raise issues in github
https://github.com/w3c/webpayments-methods-tokenization/issues
Jalpesh: Would merchant send both public key and signature, and the browser would both (1) validate and (2) encrypt response?
MattS: I realize the proposal
does not include the necessary flow (who does what when, such
as signing)
... Both request and response are intended to be signed
... I need to clarify that
Jalpesh: How does onboarding
happen?
... what is also unclear is how easy it is for the public key
to be distributed the implementation
MattS: The general idea is that
the distribution of the public key ... it will be put on the
merchant site and effectively distributed via the merchant's
site
... you can validate that the public key is coming from an SSL
endpoint...chain of trust is apparent
<CyrilV> during breakout discussion, Vincet told us that LEI will be generalised in the next years and implies a public key certification
MattS: you can't put the key on a different domain because one of the implementation details is: to verify the signature you verify it comes from a site you understand, and you would (2) check the public key against the signature signed with the private key
Jalpesh: Suppose the merchant
signs the public key using a private key.....
... you are saying that each data object can be signed
separately using the private key
... if I look at the proposal it makes sense that you sign the
payload so that the mediator can verify the signature
... the question is: how is this public key being stored in the
payment method?
MattS: The public key is on the
domain of the merchant
... the reason it's a relative path is so that it's accessible
from merchant.com/public.pem
Jalpesh: My thinking is..if the
user visits example.com
... rather target.com
... I click on the Pay button
... suppose that target.com is hacked
MattS: This proposal does not
address that.
... if someone goes to target-malicious.com it's the
responsibility of the user to detect that.
Jalpesh: But if
target-malicious.com has a valid cert...and they could have
their own public key signed with their own private key
... and payload goes to the wrong merchant.
MattS: Correct. The assumption is
that people understand what site they are visiting.
... Standard TLS protection is valid and usable
Jalpesh: Issue is, e.g., public wifi
MattS: Then the cert would be for "target-malicious.com"
Cyril: [on PKI and LEI]
... certs will be valid
... Matt's proposal is interesting in this context because the
system could provide the user a validation versus a real
PKI
<Zakim> Ian, you wanted to say browsers can help here
IJ: I think browsers can help identify bad actors over time
Cyril: Vincent also has ideas for LEI extensions
IJ: I suggest we add an issue about "bad site" and the limits of what we are trying to secure.
Jalpesh: What protection are we adding with encryption?
MattS: Malicious browser extension, or JS insertion into the cache...this is about protecting against browser vulnerabilities rather than site vulnerabilities.
Jalpesh: This gets legit merchant PCI exemption; that is what it solves:
IJ: How about a FAQ at the bottom
MattS: +1
... The encryption and signature are solving different
things:
- signature stops MITM
- encryption addresses PCI-DSS
scribe: so I may split these proposals
Jalpesh: Signature doesn't quite stop MITM; it only stops "man in the browser"
<jalpesh> Productive conversation; got an internal conflict today so dropping off.
https://github.com/w3c/webpayments-methods-tokenization/wiki/Tokenized-Card
<CyrilV> l have to drop off. sorry
IJ: What was your experience and what do we need to update in the spec?
Sachin: We are working on experimentation
Manash: What we are trying to do
is do tokenization as done in the physical world.
... you can use any wallet with a POS.
... there is no custom integration with different digital
wallets
... the POS knows what payload it will receive from any wallet;
this has enabled scale
... we want to do the same with PR API
... related to that, what we are doing is building a prototype
where we would use the Capital One wallet that would have a
network token based payload
... it would be sent to the merchant (Worldpay)
... at a high level the merchant will say they accept
"masterpass" (for the time being) and expect a standard
token
... later we would use a W3C standard payment method
... we would work with other partners (e.g., Apple Pay) to see
whether they can work in the same environment without changing
anything
IJ: Time frame?
Manash: We are aiming to do this
before the next FTF meeting (e.g., Jan/Feb 2018)
... we'd like to showcase a prototype during the next FTF
meeting
https://github.com/w3c/webpayments-methods-tokenization/wiki/Tokenized-Card
https://w3c.github.io/webpayments-methods-tokenization/index.html
IJ: I updated the spec based on your previous round
Sachin: There have been
substantial changes since then
... let's walk through it
https://github.com/w3c/webpayments-methods-tokenization/wiki/Tokenized-Card
scribe: the idea is to keep the
payment method simple
... provide EMV-like security constract
... the payment app talks to the TSP
... token is then encrypted (per MattS)
... the key is shared by the party that initiated the
request
... the key has to be onboarded to the TSP
... if you look at the end of the page, you'll see a
diagram
... the only additional bits we need are (1) key provider
URL
https://w3c.github.io/payment-handler/#the-paymentrequestevent
"and any associated payment method specific data."
<Zakim> Ian, you wanted to ask about 3DS and to ask about payment handler data
Ian: Anything going to be necessary in response data for 3DS flow?
Sachin: The 3DS cryptogram takes
the same space as the @@
... 3DS might not be payment method, but a layer like
encryption
marconi: In this flow, is the
handler or the mediator the token requestor?
... will you have a single token usable across merchants?
Sachin: The merchant is not
specific to a merchant, but is specific to a TSP
... whether a token is reusable across merchants will depend on
TSP
... the dynamic data is requested/provided per transaction
marconi: Are these DSRP transactions?
Sachin: Yes.
IJ: What is DSRP?
Marconi: Digital Secure Remote Payment
https://w3c.github.io/webpayments-methods-tokenization/index.html
https://github.com/w3c/webpayments-methods-tokenization/blob/gh-pages/index.html
Proposed: Add Sachin as co-editor
+1 from Ian
<MANASH_MC> +1
<alyver> +1
<scribe> ACTION: Sachin to do a pull request on network tokenization spec
<trackbot> Created ACTION-70 - Do a pull request on network tokenization spec [on Ahuja Sachin - due 2017-11-28].
Sachin: I will update the wiki today and do a PR after that
Ian: Staging?
Manash:
1) We update the spec
2) We discuss the spec at the right time with the full WPWG
3) We do a FPWD and begin to engage with other participants
scribe: in parallel we start working on timing of prototype development
Ian: Any volunteers to review the update?
<alyver> +1 to add my name a checkbox on Sachin's issue.
+1 to add my name to a checkobx
Ken: I anticipate Clinton or someone in our team will review
28 November