See also: IRC log
https://github.com/w3c/webpayments-methods-tokenization/wiki/encrypted_card
<oyiptong> https://github.com/w3c/webpayments-methods-tokenization/wiki/encrypted_card
oyiptong: Data is Basic Card, but encrypted
[oyiptong walks through flow diagram]
oyiptong: Payment handler
contacts vault provider, gets a key, encrypts card, and sends
back to the merchant.
... the merchant can save the encrypted data (if it
wants)
... The request data for this spec would add a couple beyond
Basic Card
oyiptong: the first new param is
valueProviderURL to contact the vault
... the data that is encrypted is the Basic Card response
... response data is cardholderName, suffix,
encryptedCardData
... "suffix" is important to merchant as it can be shown to the
user (for card on file)
<oyiptong> https://github.com/w3c/webpayments-methods-tokenization/wiki/encrypted_card#tokenization-use-case
[Tokenization use case]
https://github.com/w3c/webpayments-methods-tokenization/wiki/encrypted_card#tokenization-use-case
oyiptong: In this use case, the
payment app can request a token; that token is returned to the
merchant
... for example, Braintree does this
... if gets a token, that is used instead of
encryptedCardData
IJ: Why do encryption instead of
directly going to tokenization?
... the encryptedCardDat is sent to the vault provider and
storing that
Sachin: SO we are encrypting the
data for the vault...
... what is the benefit of sending the encrypted blob to the
gateway?
mweksler: Benefit of encrypted
card is to avoid PCI scope
... How do we get the card details from the browser into a
pic-trusted environment without going through the merchant?
keyur: Communication between
payment handler and backend would be completely dependent on
the (independent) payment app
... from w3c payment request perspective, we should not go into
detail about how payment handler communicates with backend
mweksler: that is not something that the specification defines. what we are trying to define is to be able to handle this case within PR API
Sachin: The two proposals are (1) encrypted card and (2) token...I think introducing the "vault" is a source of confusion.
Michel: I don't mind renaming it...want to make clear it is not in PCI scope and not the merchant
IJ: Can we talk about first flow
first?
... Could we change "vault" (which implies storage) to
"keyProvider"?
oyiptong: It's outside scope of
W3C on how merchant charges the card...the parties here are
just shown as an illustration
... the keyProvider or vault could even be the merchant with a
separate infrastructure just for keys
Keyur: "Payment Handler Backend"
also ok
... some payment handlers have authentication. If someone wants
to implement user authentication, those payment apps have their
own user experiences
... what I'm thinking is that the payment handler scope is what
we need to define here.
... the payment handler can provide a payment response
... can also provide "add card" inside the payment handler
IJ: My understanding is that the proposal is to use web standards to get a key from an identified origin.
Keyur: Network call may not be necessary; key may be available on the device.
oyiptong: I am hearing that the payment app is outside PCI scope, and as long as it returns an opaque thing, the merchant is outside PCI scope
IJ: How would the payment app get opaque information without more information from the merchant?
keyur: suppose airbnb invokes
payment request, and payment handler that is launched has 2
cards
... the payment handler has its own navigation screen and could
prompt user to add card
mweksler: The user has a card in
chrome form fill, for example. We want the card to be usable by
the merchant....but only as basic card
... the question is "what should Airbnb pass to PR API so that
it is eventually able to launch the brains tree handler and
send info to braintree in order to use it."
... airbnb says "I use braintree" and what I get back needs to
be usable by braintree.
keyur: That was part of gateway
params (expressing preferences of provider)
... once you pass through preference to PR API....
... this could be used for payment app matching
<Zakim> Ian, you wanted to say Ian is hearing more abstraction
IJ: Reminder - we are not doing
gateway params
... focused on encrypted cards
Sachin: Thanks for the
clarification
... I want to think about it more...the merchant can say "These
are the processors I like"
... I think term "vault" threw us off...let's focus on
processors
IJ: Is it isomorphic to refer to a key provider or a processor?
oyiptong: I don't think the spec should dictate that the key provider and the processor must be the same entity
What are the use cases for key providers?
* Via the web
* on a device
scribe: how should they be identified?
Oyiptong: URL works in both cases
Three use cases:
- third party key provider
- merchant running server that is pci controlled
- on device key storage
<oyiptong> +1
IJ: Why conflate with tokenization?
oyiptong: I wanted to show that
there's a way to do this if we wanted to (re: token back)
... we may want to do this because some processors implement
tokenization this way...and they might be able to migrate to
this at lower cost
Sachin: I think it makes more
sense to manage these two as separate specs
... I think we should address encrypted card and network tokens
separately for now
... and later see if we want to merge
oyiptong: there are a few ways we could identify how to do the encryption
q
https://github.com/w3c/webpayments-methods-tokenization/wiki/encrypted_card#discussion-encryption
oyiptong: three approaches:
through the public key in the TLS certificate of the vault provider if a manifest is not found or the parameter is not found in the manifest
through a Web App Manifest parameter on the vault provider's origin, specifying a public key and list of ciphers as defined by WebCrypto
through a public key provided as part of the PaymentMethodData dictionary
Oyiptong: Payment method manifest is on key provider origin; compared to merchant-provided key
Sachin: I like the manifest
approach the best
... first, it's clean and clear
... second, it means the key provider needs to do something to
comply with the w3c spec
keyur: The API from where we get the key from the key provider, could that have metadata for the encryption?
oyiptong: That could be a way to
get the key...there could be a way to do an exchange
... e.g., what ciphers are available
IJ: What level of granularity does the merchant need?
Sachin: If there is a standard, then both parties follow the standard
mweksler: A few thoughts
... if we prescribe something in the standard about encryption,
we need to keep it up to date
... ideally the standard would remain silent on exactly what
encryption algorithm to use
... secondly, I think the merchant has less responsibility what
encryption mechanism to use
... it's between the payment handler and the key provider
... it's up to them to negotiate which cipher to use
... that was one of the appealing components of using TLS,
which allows for lists
IJ: Seems like using certificates adds benefit of third party certification (if you buy that)
keyur: When we handle PCI data,
we want both pipe and data encryption
... if the public certificate can act like a public key and we
can do encryption with that, that's good
mweksler: +1 to the extra layer
of encryption
... we can do closer to end to end that way
... I think certs do add value..let us use existing standards
to check certs are valued, climb up the ladder, consider cert
revocation, etc.
oyiptong: Certs are used for
integrity, confidentiality, and authenticity
... the chain helps with authenticity
... for integrity, we use digital signatures (outside of the
scope of this proposal)
... for confidentiality, I guess TLS uses this slightly
differently - it uses public key encryption to do the cert
exchange, and then uses a generated cert for symmetric
encryption of inflight comms
... we lose that with a public key
IJ: My understanding is that based on experimentation, you'll come back at the end of the month
Keyur: I did update this:
https://github.com/w3c/webpayments-methods-tokenization/wiki/Network-Tokens
https://w3c.github.io/webpayments-methods-tokenization/index.html
"Tokenized Card Payment"
---> https://github.com/w3c/webpayments-methods-tokenization/wiki/Network-Tokens
19 Sep