<scribe> Scribe: Ian
IJ: Any agenda additions?
[None]
https://github.com/w3c/src/issues/7
IJ: Where are the transaction types defined?
Clinton: Within that document there's a section on tokenization (is it section 6?)
6.4 Payment Token Transactions
Jalpesh: Maybe the terminology of "transaction type" is misleading. What I meant is that the payload can change (e.g., disbursement v. authorization)
Clinton: Another aspect to that that is probably important is that some transaction types don't have cardholder participation.
Jalpesh: What I'm referring to here is "cardholder present" transactions
Tomasz: Let me clarify from SRC
API spec perspective...there we have an enumeration
(TransactionType) with about 5 values
... they are largely based on the tokenization document
... but we decided to be more specific in SRC...see section
2.3
---
• PURCHASE
• BILL_PAYMENT
• MONEY TRANSFER
• DISBURSEMENT
• P2P
---
Jalpesh: I would make this parameter optional.
Proposed:
- Include transactionType with this enumeration informatively; refer to EMVCo spec for authoritative values
- Rationale: Payload may change according to transaction Type
SO RESOLVED
<scribe> ACTION: Ian to update the payment method
<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/src/issues/8
https://github.com/w3c/src/issues/8#issuecomment-497032812
IJ: Any updates from Jonathan or Ken?
Jonathan: The question is - is
there a need to have a flag in the request data (in Mastercard
system)?
... I think this is potentially useful for some
implementations; in our implementation I don't think that we
don't need a specific flag for the token usage in the
request.
Jalpesh: I had clarified that for Visa's implementation, we would make use of the (optional) flag
Tomasz: I was wondering how this
maps onto the SRC API?
... we don't have this parameter explicitly on the API in
1.0
Jalpesh: I understand that. But for our initial implementations, we will support this capability implicitly.
Tomasz: My question is more
related to the approach here. When we define a parameter that
is not explicitly defined in the SRC API.
... how will they map onto the API?
Clinton: Good point. I'm reading issue 8. I am hearing Jalpesh request a boolean.
Jalpesh: The default in my view
is "guest"
... I agree with them that needs to be on the (SRC)
roadmap
... question is how to map back to the SRC system...agree with
them.
Clinton: I think there's opportunity to do more at a later date.
IJ: I am hearing three paths possible (1) do nothing (2) boolean (3) more complex algorithm
Clinton: I had highlighted that
within the tokenization spec we have token requestor id and
token requestor type...I was thinking that at a spec level,
having token requestor id OR usage/requestor type would be
valuable. But I am not hearing uptake of this at this
time.
... those could be valuable in the future.
PROPOSED: cardOnFile boolean
(default false).
... for future compatibility
Jonathan: Something to add to the description: (1) optional flag and (2) some implementations may not make use of it.
IJ: Can we characterize this as an implementation optimization?
Clinton: When we think about the
time frame of these things, at the time of the request, whoever
is making the request for the token...will that party know who
is fulfilling the token provisioning?
... do I know which system this will be fulfilled by?
Jalpesh: No. This scenario is the
DPA is making a request. I could be in a guest checkout flow or
adding a card to a merchant account.
... SRC system selection happens at a later time.
Clinton: These optional
values...how would a merchant be able to make a decision about
whether they are necessary to specify?
... would a merchant use the feature if the merchant does not
know what the capabilities are on the other end.
Jalpesh: A merchant could decide
whether to use based on the SRC systems the merchant chooses to
support.
... in a scenario where the merchant knows it's a card add
flow, merchant might populate the value, and the merchant might
know the value could change. The value may not change, but it
could.
Tomasz: We may support the same feature but not through the flag.
Jalpesh: With or without the flag, SRC systems could do this optimization; Visa would like explicit option.
IJ: Does merchant need to say "I support these TSPs?"?
Jalpesh: I think
supportedNetworks suffices.
... I support proposal
<stpeter> +1
Clinton: No objection
Jonathan: No objection
SO RESOLVED
<scribe> ACTION: Ian to update the SRC description with a cardOnFile boolean and corresponding characterization
<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/src/issues/10
"How keys are exchanged (during onboarding or at other times) to enable the encryption of part of the payload is outside the scope of this payment method."
Proposed: That edit and close issue 10
Jalpesh: +1
Tomasz: +1
clinton: +1
<scribe> ACTION: Ian to close issue 10
<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/src/issues/11
https://github.com/w3c/src/issues/11#issuecomment-500448333
Jalpesh: I am looking at Tomasz's points. I am hearing two things:
- one object is for UX and display
- one object is for processing
scribe: what I was talking about
was panBIN and panExpirationMonth...
... does the user experience require panBin in practice?
... for display purposes
Tomasz: I think there are use
caes.
... consumer only knows BIN; they don't know bin range or last
four
... I think we need to display the obfuscated PAN data.
Jalpesh: I'm not sure we need
panBin, panExpirationMonth, panExpirationYear
... this is a question about what data to send back to the
merchant
Tomasz: When you look at the Payload definition (in SRC API)..it does not included masked card information.
IJ: You need some subset of MaskedCard in a response to the merchant
<scribe> ACTION: Ian to move masked consumer information outside of the encrypted payload
<trackbot> 'Ian' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., IFSF-EFT-WG-Lead, ijacobs).
IJ: I am hearing Jalpesh say we don't need all six things of MaskedCard
Clinton: I think what we need to
do is articulate more clearly which data is going where.
... some data may be used within DCF, some data may go all the
way through to the merchant.
Jalpesh: The w3c spec is only for what the merchant (or gateway) gets back
https://github.com/w3c/src/wiki
====
Response data
- Identification (srcCorrelationId)
- Encrypted blob
- Displayable blob
"Payload"
https://github.com/w3c/src/issues/15#issuecomment-499862289
IJ: Should we just refer to "Payload" and be mildly informative?
Tomasz: +1
Jalpesh: +1
IJ: Where does assurance data
go?
... sibling?
Tomasz: Yes, sibling.
IJ: Any others?
Tomasz: Event history, and also custom output data. I think we need to think more about mapping them to the DPA or not?
<scribe> ACTION: Tomasz to add two issues about event history and custom output data in response data.
<trackbot> Error finding 'Tomasz'. You can review and register nicknames at <https://www.w3.org/Payments/WG/track/users>.
https://github.com/w3c/src/issues/16
How do we refer to assurance data in the response?
Tomasz: You also referred to
issue 15.
... I would like to leave it open or even create a new related
issue....
... we have a challenge in that both payment request and SRC
can provide shipping address.
IJ: See https://github.com/w3c/payment-handler/issues/337
Tomasz: Good!
26 June