W3C

WPWG Tokenization Task Force

30 Jan 2018

Agenda

Attendees

Present
mweksler, anthonyvc, MateenSyed, MattDetert, KeyurPatel, AdamSolove, stpeter, ChrisMarconi, Manash, Angela, CarlosArturoQuiroga, Ian, Ken
Regrets
Chair
Ian
Scribe
Ian

Contents

  1. Issue 25
  2. Issue 27
  3. Issue 28
  4. Issue 29
  5. Issue 30
  6. Issue 31
  7. Issue 32
  8. Issue 33
  9. Next meeting

Tokenization draft

Issue 25

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].

Issue 27

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.

Issue 28

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)

Issue 29

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

Issue 30

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].

Issue 31

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?

Issue 32

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

Issue 33

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].

Next meeting

6 February


Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2018/01/30 18:08:27 $