https://lists.w3.org/Archives/Public/public-payments-wg/2017Nov/0042.html
Sachin: I updated the tokenization wiki
https://github.com/w3c/webpayments-methods-tokenization/wiki/Tokenized-Card
scribe: total now comes from PR API
scribe: second change is
supportedTokenTypes
... at masterpass we have a single token type, but others might
have different ones
jalpesh: We might want to keep
this simple
... Could remote config also include the crypto type?
Sachin: Good point
... so perhaps not a transaction element but more closely tied
to onboarding
Jalpesh: Merchant could choose a different profile when requesting credentials.
Sachin: that profile would be disambiguated by the key provider profile
Jalpesh: Yes, perhaps. The encryption key cannot be done at transport; that breaks security
Sachin: Key provider onboarding might include more than key, then
jalpesh: For this spec you might
want to keep TSP specifics out
... from merchant to payment handler, I am hearing that there
is no cryptogram type AND no encryption key in the
request
... all that is implementation specific and suggest it is
stored in remote profile
sachin: Suppose you have a
payment handler that talks to 2 TSPs
... the relationship with each TSP would involve a profile with
the details.
... that's an implementation detail between TSP and payment
handler
Jalpesh: Right, a payment handler might have (1) a profile wrt a merchant and (2) different relationships with different TSPs.
Sachin: +1
MattS: The difficult part for me
to understand is this: how does the merchant process all the
fields? For example, in the tokenized card there is a
"TRID".
... that's not defined; how does it get passed to the payment
network by the merchant?
Sachin: The fields specific to
the token requestor will be passed to the entity integrated to
the requestor
... the key provider will do the onboarding to the TSP
... they will have connectivity between the two
... suppose Worldpay is the key provider. They are responsible
for passing information to the TSP
Keyur: The key provider can be a
PSP.
... they have the private key to decrypt info...could be any
payment processor
... they need to pass the TRID in their authorization
message
... when it comes to mastercard, we know who the token provider
is
... we have our own TSP and could interact with other Token
Service Providers
Jalpesh: I understand MC's
implementation. But Visa, we don't require TRID to flow through
the transaction, so requiring it might not be the right thing
to do
... so from a spec perspective we need to think about what is
an implementation detail
... it might be useful as an example but some fields may not be
required in some implementations
Sachin: I am hearing TRID should
not be required element; ok
... what we may have to do is say if TRID is present must be
passed
... Second thing I am hearing is about onboarding of key
provider with TSP and that's outside of scope of this spec
Jalpesh: Yes, key provider is outside scope. The requirement should be that key is remote lookup
MattS: I see some display data is duplicated. Is that intentional?
Sachin: Data in some cases is dynamic (e.g., date) and it's not for display
MattS: Ok, thanks
IJ: Maybe field names could further emphasize the distinction (e.g., staticExpiryMonth or displayableExpiryMonth)
MattS: +1
Sachin: Want to keep display data unencrypted
MattS: +1
... From a dev point of view, different names will be more
descriptive (since spec may not be present when coding)
Jalpesh: We provide guidance to developers about what to display.
MattS: I don't think we mandate display of data; these are hints
IJ: +1 to MattS; I think these are hints
Sachin: If this is encrypted, I think you won't have anything other than the displayData to display
MattS: Agree; this is just about
developer-friendly names
... "lastFour"
... that would suggest it is four digits .. I am wondering
whether we should say "maskedCard"
... Maybe "maskedAccount"
Ian: Is it just the four digits or does it include the asterisks
Sachin: My understanding is that we were just providing the "suffix" and the card number length
MattS: I have heard use cases for masking the middle of a card (though I've not seen in practice)
Jalpesh: I sort of agree with MattS's proposal...let's do something generic like "displayLabel"
MattS: So it would include asterisks?
Jalpesh: +1 to including
asterisks in the string. Let's just make it easy to say "this
is how to display the card info"
... makes life easier for merchants
... you don't need to do the math
Sachin: We are assuming the
merchant will be happy displaying what we suggest.
... my preference is to give them the minimum data and let them
display it however they want.
MattS: The problem with giving
bare minimum is the challenge of displaying
... asterisks could be replaced by the merchant
oyiptong: As a merchant we want
flexibility; there may also be i18n concerns
... I prefer "suffix" or "prefix"
Ian: recommendedDisplay and minimalDisplay
<Zakim> Ian, you wanted to propose something
<MattS> I agree mine is poor for i18n, we would need a reserved unicode string
Ian: Reason to use minimalDisplay is to ensure key information from network perspective is not lost
Jalpesh: I suggest cryptogram be optional for this scenario: dynamic CVV
Manash: Could basic card handle dynamic CVV?
Sachin: I don't think so
Jalpesh: Basic Card has a
different construct; encrypted card is also different from
tokenized card
... we have three levels of security where tokenization is the
only framework that enables token transport
Manash: I agree, but consider the
merchant POV - suppose I say I only support Visa cards; at the
end of the flow there is a payment handler
... the payment handler plans to generate a basic card
payload...technically, the payment app could work with a
service provider
... and in the basic card payload the PAN and expiry date and
name are anticipated; in that sense I could replace that data
with dynamic data
Jalpesh: But the spec is very
different.
... I agree merchant's might want to keep transparent, but
issue would be exposing to replay attacks
Sachin: Let's take this up on
basic card....and focus here on tokenization
... if it turns out that tokens can be consumed in basic card
flow, that's a separate conversation
Jalpesh: +1
Sachin: Do we want to introduce dynamic CVV here?
Jalpesh: I think you have...token type
Sachin: fair enough
Jalpesh: Let's be sure what we do
is not network specific
... the processing specs may be very different
... the gateways and processors may have their own fields
Sachin: I will make changes in the next day or so and will let people know. I can start to port to the HTML version after that.
Manash: Worldpay, Cap One, and MC
working on a prototype built on network tokenization
... we are targeting something by march
https://github.com/w3c/webpayments-methods-tokenization/wiki/Generalisation-of-Encrypted-Card
https://github.com/w3c/webpayments-methods-tokenization/issues/22
MattS: Anybody new to this
proposal?
... what I changed since last time:
1) Split it into 2
<Ken> +1 OBO Angela Hauser new representative for AXP
2) Added bits about using JOSE for encryption
3) Add mention of LEI as an option for registration of an entity in the ecosystem (Vincent Kuntz suggestion)
MattS: The top part of the
proposal is about encryption of the RESPONSE
... I think it aligns, therefore, with what we have discussed
here
... second part of the wiki is about leaving some response data
unencrypted.
... the third part of the proposal has to do with signatures
(to avoid tampering)
... there are some use cases where you would use only
encryption and some signature only, but also some both
... My question to the group - I would like feedback!
... this is intended to apply to multiple payment methods
<oyiptong> +1
MattS: Do people like the general idea?
<alyver> +1
MattS: specific comments on the proposal?
Ian: +1
Jalpesh: I sort of agree that
encryption should be a core feature
... the only reason why I am skeptical about is what
incrementally are we adding
... if you build a generic encryption framework, there are only
2 or 3 questions:
- is key from transport or remote?
MattS: You can do a minimal general set and add other features to payment methods
Jalpesh: So the basic framework might define how encrypted payload works...and tokenized card would extend the framework for that framework and build upon it?
MattS: You don't have to build upon it
Ian: +1 to building an extensible framework
MattS: Good test case - does it work for tokenized card?
<alyver> Re: naming - we should stop referring to it as "encrypted card", and perhaps "Payment Method Encryption"
https://github.com/w3c/webpayments-methods-tokenization/issues/22#issuecomment-347580183
<oyiptong> +1 to alyver's comment
Jalpesh: Yes, let's see if we can make it work for basic, tokenized
Sachin: =1
... +1
... I will review before next call
MattS: Regarding naming, this is
not called encrypted card.
... this is a generalization of encryption
Ian questions:
1) What are we encrypting?
scribe: just the details or every field of the payment request response?
MattS: Proposal is to encrypt the entire PAYMENT HANDLER RESPONSE
<Ken> +1
2) in my mind the "partial encryption' is confusion and rather it's "Give me an encrypted response BUT ALSO send me N fields unencrypted"
{
supportedMethods: "https://example.com/bobpay",
data: { ...request data goes here...},
responseEncryptionKey: {...key of merchant or processor...},
returnUnencrypted: {property1, property2}
}
IJ: My proposal is that the merchant determines what data to NOT encrypt (that is, a subset of the payment method response data)
Ken: I support the overall
proposal (without addressing technical details)
... additional proposals
1) clarify the specifics of payment instrument v. payment method and be clear about where encryption is applied
2) point-to-point or end-to-end encryption
scribe: are we looking at the
entire flow of data holistically?
... it could be helpful to put in commentary about how this is
positioned against tokenization..does it supplement or
stand-alone?
MattS: Regarding the last point,
my view is that this complements tokenization
... and we've not yet envisioned all the use cases
[Digital signatures]
MattS: You can't have signature
in data
... you want some flexibility so that participants in the path
way can add data outside the signed data
IJ: List of commitments to review by the 5 December call?
<oyiptong> +1
<sachinahuja> +1
<marconi> +1
(Thanks)
Ken: I will add issues
IJ: Let's do editorial pass after 5 Dec
MattS: +1
5 December
agenda will be revised encryption thing with comments from people and review of Sachin's update.