<scribe> Scribe: Ian
https://rawgit.com/w3c/webpayments-crypto/gh-pages/
[Ian summarizes]
https://w3c.github.io/webpayments-methods-tokenization/index.html
https://github.com/w3c/webpayments-methods-tokenization/issues
https://github.com/w3c/webpayments-crypto/issues
https://github.com/w3c/webpayments-methods-tokenization/issues/42
Is it required? Is it sensitive?
IJ: One use case is "no shipping address"
Roy: Another use case is cardholder shipping items to other people?
https://github.com/w3c/webpayments-methods-tokenization/issues/40
Rick: I think that the billing address and cardholder name are needed (for merchant if not for schemes)
Simon: +1
MWeksler: +1
IJ: Should either be encrypted?
Rick: I think it does not need to be encrypted.
PROPOSED: To update tokenized card payment spec to add billing address and cardholder name as non-sensitive
SO RESOLVED
<scribe> ACTION: Ian to update the tokenized card payment spec for cardholder name and billing address and close issues 40 and 42
<trackbot> 'Ian' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., IFSF-EFT-WG-Lead, ijacobs).
https://github.com/w3c/webpayments-methods-tokenization/issues/38
Simon: I would say "+1" included; not sensitive
Ian: See tentative conclusion that we do not need it because "since PAR is being returned with the Auth response, as long as acquirers and PSPs pass it along to the merchant, we should be OK."
Rick: +1 to inclusion
... might need some description of what the PAR value is
... doesn't need to be encrypted
IJ: For reference - tokenization spec at EMVCO section 9.1 (page 73)
PROPOSED: Add PAR to the spec
<scribe> ACTION: Ian to add PAR definition to the tokenized card response data and close issue 38
<trackbot> 'Ian' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., IFSF-EFT-WG-Lead, ijacobs).
Ian: I am not going to close 38, but draw attention to the edit
Rick: Token reference ID
... allows them to store a reference to a token, and they can
get dynamic data for the same payment token
IJ: Should we not have a cardNumber and only ever a reference?
Rick: Actual token may be stored by another party (e.g., PSP)
<SimonMC> EMVCo definition: Token Reference ID A substitute for the Payment Token that does not expose information about the Payment Token or the underlying PAN.
IJ: Why do we need a token? IS there always a token reference?
Rick: You need the actual token for authorization
IJ: There are two questions for me - is there a reference? Does everyone use the reference equally?
Mweksler: Yes, the question is -
if one is sufficient, why do we need both?
... I think we should either have the token or only the
reference
Rick: This is a healthy
debate...are we going to allow merchants to be able to request
dynamic data following a PR API ?
... if they have tokens on file, they might want to do a
merchant-initiated request.
mweksler: Don't make the merchant to back through the browser for a merchant-initiated transaction
IJ: What if we only return the token reference ID
[Roy departs]
Rick: The token reference ID
alone is insufficient for authorization. You ALSO need (or your
PSP needs) the token.
... token reference ID is useful for both dynamic data and for
card-on-file payments
... for future payments
IJ: Is token ref ID OPTIONAL?
Rick: Yes.
PROPOSED: Include token reference ID as OPTIONAL non-sensitive
Rick: +1
Simon: +1
<scribe> ACTION: Ian to add Token Reference ID as optional non-sensitive data
<trackbot> 'Ian' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., IFSF-EFT-WG-Lead, ijacobs).
https://github.com/w3c/webpayments-methods-tokenization/issues/41
IJ: Could the token reference ID be used by third parties?
Rick: No; still need the card credentials
Mweksler: Unlike basic card,
tokens can be merchant scoped
... how to get a token that only the car rental company can
use?
... this requires some additional handshake
... e.g., I got this token that I received and want this the
merchant to have a token
... can merchant A get a reference that merchant B can use?
IJ: Do we need to be clearer
about our expectation for which domain is the token
requestor?
... is this related to Token Requestor ID?
Simon: Depends on
circumstance
... e.g., if you are a front-end for 1 million stores, you
would not want 1 million Token Requestor IDs.
... You can also use a token to request another token
... there is a process by which Merchant A can authorize
Merchant B to get a token
... how it works is implementation specific.
... e.g., Expedia provides its token to Hotel A. Hotel A
generates a token request to get their own token...
... including data to show that Expedia is authorizing this
IJ: What is the extra data? Does it need to come through PR API or the tokenization spec?
Rick: I am hearing 2 asks:
1) What is the train of trust between parties that request tokens.
scribe: e.g., merchant needs
token but it's being requested through the browser.
... we might not know who the merchant of record is
... in the scenario where the aggregator passes the token, the
cryptogram usually suffices for the third party
<SimonMC> Token request with Payment token. See 8.1.1.2 of EMVCo framework
Ian summary:
- Token requestor id should be part of the request data
- To address token sharing, one needs token and cryptogram so that party B can request a token for their own authorization needs (and party A wants them to do so)
Simon: As to what is required for
authorization to get a token from another token that's not
defined in the tokenization spec
... +1 to adding token requestor ID to request data
<scribe> ACTION: Ian to add Token Requestor ID to request data.
<trackbot> 'Ian' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., IFSF-EFT-WG-Lead, ijacobs).
https://github.com/w3c/webpayments-methods-tokenization/issues/41
26 June
Simon: Ok
<Ken> +1 either
<matt_d> +1 26th
IJ: Anyone want to review the encryption or tokenization spec?