https://github.com/w3c/webpayments-methods-tokenization/issues/25
asolove: There are tokens that
represent cards that have different capabilities (e.g., typed
to a transaction, attached to a merchant, reusable, etc.)
... in the past when you have received a network token you know
who you are getting from (and e.g., have an out-of-band
relationship with them0
... but here we are designing more interop where fulfillment
could be via an arbitrary payment handler
... a big issue here is to return "canMakePayment()" responses
that are USEFUL
... e.g., don't want a user to walk through whole flow only to
receive a token that can't be used, e.g., for a
subscription
... it would be useful to add request data to enable some
filtering
<keyur> +q
keyur: +1 to the idea of request
data to allow smart canMakePayment() responses
... agree we want to get a strong sense that "this is a
supported token type"
... I can work with Adam on a set of properties
IJ: Do people encounter other topics than these:
one time use v recurring use
authorized only for specific amount v variable amounts
chargeable only immediately or for any period of time in the future
attached to a specific merchant or transaction type, etc.
Keyur: there is also a partial
shipment use case
... so the token can be used for split amounts (N
transactions)
<scribe> ACTION: Keyur to begin to flesh out token chararacteric parameters for request data to help with canMakePayment() matching
<trackbot> Created ACTION-78 - Begin to flesh out parameters for request data to help with canmakepayment() matching [on Keyur Patel - due 2018-02-06].
https://github.com/w3c/webpayments-methods-tokenization/issues/27
IJ: For now this spec still feels very card-driven to me
Ken: I think input from brands so
far has been to closely align to EMVCo
... need to ensure that references are still relevant if you
make this more general
asolove: It's hard for me to
understand why we would combine this with other forms of
tokens
... if a merchant wanted to accept both types, they could just
use two PMIs.
... in particular we would not want a merchant to specify this
payment method and get back a token that could not be
useful
... the actual financial rails used in the background are very
different
... I think that merchants will want to closely align with the
rails they have
Ian: My plan is to deprioritize this issue until we get a new review by AdrianHB.
https://github.com/w3c/webpayments-methods-tokenization/issues/28
Peter: What is "EMV-like" security?
Keyur: Does use the same security
protocols
... but from a MC perspective, there's another AV generated
(through 3DS) that goes into the cryptogram
... so the cryptogram could be EITHER and EMVCo cryptogram or
an AV 3DS cryptogram
... that is what we meant by EMV-like
... the card is still tokenized per EMV
... but the cryptogram is additional authentication data
... the network can validate that once returned
IJ: We should delete generic language and be specific about dependencies
stpeter: +1. Maybe say something like "Equivalent level of security as EMV"
IJ: Or "At least
equivalent"
... Also let's clarify dependencies (e.g., number => EMVCo
spec)
https://github.com/w3c/webpayments-methods-tokenization/issues/29
"It's not clear what we mean by "a BasicCard-like payment request flow". Does this mean the flow is nice and simple (like BasicCard), that it supplements or extends BasicCard, or something else entirely?
stpeter: What is meant here?
Keyur: The intent of the phrase was that the flow of payment was similar to basic card.
IJ: Do we need to say anything?
Keyur: We can remove it; it's just meant to refer to the typical PR API flow
https://github.com/w3c/webpayments-methods-tokenization/issues/30
"With respect to "Tokenized payment credentials MUST be encrypted.: this doesn't tell the reader (and especially the implementer) very much. Encrypted between which parties? Encrypted using what
technologies? Is forward secrecy required? Is this transport security only (e.g., TLS) or also end-to-end object encryption? Etc."
stpeter: There are different
types of encryption...is it end-to-end? object encryption?
stream? ..
... it would be good to have more details about what is
meant
... I can see that may need to be worked on in parallel
Keyur: We did want it to support
asymmetric keys
... so that we get the public key and use it to encrypt the
credentials
... but we've not defined the algorithm (in the encryption
module)
... that algo needs to support both asymmetric and symmetric
encryption
https://github.com/w3c/webpayments-crypto/wiki/Encryption
stpeter: I think that's a good enough start for us; we can get feedback in FPWD
https://github.com/w3c/webpayments-crypto/issues for encryption
IJ: Keyur, could you add an issue for requirements
<scribe> ACTION: Keyur to review the encryption and digital signature proposals.
IJ: We will need to make progress
on encryption if tokenization is to depend on it.
... Why is encryption required for tokenization?
Keyur: Serves 2 purposes:
- The key will help us identify who provided the key
- The credentials are sensitive even if tokenized
IJ: What do you learn by knowing who provided the key?
Keyur: The key provider will be
signed by a network or the payment handler provider.
... so there will be some trust between key provider and the
payment handler
--> https://github.com/w3c/webpayments-crypto/wiki/Signatures Signature porposal
IJ: Would be good to clarify whether there's a dependency on signature as well
stpeter: I will look at those as well
<scribe> ACTION: Stpeter to review the encryption and signature proposals
<trackbot> Created ACTION-80 - Review the encryption and signature proposals [on Peter Saint-Andre - due 2018-02-06].
https://github.com/w3c/webpayments-methods-tokenization/issues/31
"With respect to "Token Service Providers MAY require KeyProviders to register/onboard." - register with a third-party service such a clearinghouse, with the Token Service Provider itself, or both? What is the purpose of such registration (e.g., so that the Token Service Provider can restrict its interactions to trusted entities)?"
stpeter: What is the intention
here?
... who is registering with whom?
... what is the purpose of registration? Validation of some
known entity?
... is there a public key that is registered? What's the detail
and why is this desirable?
... how does that impact the protocol flow (if at all)?
... I don't know that we need to clear this up by FPWD; more
details would be helpful.
Keyur: The public key would be
used for encryption of payment credentials.
... whether to sign the key is up to the payment app
provider
... so I think that signing of key is one way to know who the
key provider is
... some payment app providers might only accept keys from some
key providers
... but the only usage of the public key is encryption of the
payment crednetials
stpeter: So the "registration" flow might take place before hand, where the key provider registers with the payment app provider
Keyur: How key provider is
authenticated is out of scope (e.g., might be part of the key
provider URL, might be a signed key)
... e.g., one flow is for key provider to send key to payment
app provider, who signs it and sends back data to key provider,
who returns a URL
... only key provider can decrypt the payload
IJ: How should we cover this?
stpeter: It's a "MAY" already;
not clear to me yet whether this has an impact on the
tokenization spec, other than a trust relationship is
established.
... but if you receive information from an untrusted key
provider, is there an error flow?
IJ: That might be managed through canMakePayment()
stpeter: Not a show-stopper for v1
IJ: Maybe we need a FAQ on "what
level of trust is expected between key providers and payment
handler providers (or TSPs)?"
... and the API may support variability
... Any author volunteers?
https://github.com/w3c/webpayments-methods-tokenization/issues/32
What is purpose of mention of "out-of-band provisioning"?
stpeter: relates to what we were
saying...optional flow...unclear what the relationship is to
the protocol.
... I suspect there is, as above, more information to get out
of Keyur's head. :)
Keyur: I think that one reason we
have not documented how trust is established between key
provider and payment app provider
... is that it should be independent of tokenization
... we could always put a section on responsibilities / good
practices of payment handler
... see "validatePublicKey" of flow diagram
... no details provided, but some sort of trust is
established
IJ: Some clarity around diagram
and "scope of tokenization spec" could help
... Agree this is part of "clarifying scope" set of edits
https://github.com/w3c/webpayments-methods-tokenization/issues/33
What public key formats are acceptable, and any constraints?
stpeter: This might be more for the encryption/signature proposals
Ian: +1
stpeter: What is implied in terms of key length, formats, etc? to get security "as good as what EMVCo wants"
<scribe> ACTION: Ian to migrate two of stpeter's issues (33, 30) to the encryption tracker and close on the tokenization tracker.
IJ: How do good specs manage evolving crypto world?
stpeter: In the IETF we have some recommendations re: TLS (RFC 7525)
<stpeter> https://tools.ietf.org/html/rfc7525
https://tools.ietf.org/html/rfc7525
https://tools.ietf.org/html/rfc7525#section-4.3
stpeter: In that section we talk
about key length
... that will change over time
... once we have quantum crypto who knows what we'll need
... NIST also probably has a spec on this
IJ: Was the idea that RFCs point at 7525 for the latest good practice?
<keyur> I need to join other meeting .. so leaving now
stpeter: Yes
Ian: That may be good for us here, too
<mweksler> +1
<scribe> ACTION: stpeter to look into good practice around key technology selection, ideally for reference from the encryption spec (rather than rolling our own)
<trackbot> Created ACTION-81 - Look into good practice around key technology selection, ideally for reference from the encryption spec (rather than rolling our own) [on Peter Saint-Andre - due 2018-02-06].
6 February