Agenda. See 15 May minutes for context about issues 6, 7, 8.
Ian: Jonathan was to Investigate reliability of card type info from src metadata
Jonathan: There were two parts of
the question - is there something in the spec? Is it
used?
... on the first part, there is something in the SRC spec where
the card type could be determined, but my understanding is that
it's an optional field.
... I think we need to understand the user perspective about
importance of this, and whether it should be populated.
tomasz: We have "masked card"
object in SRC; meant to be retrieved by clients about cards
tied to user profile.
... this object has a payment card type
... there was an attempt in the SRC group to standardize values
for this field
... but we abandoned the idea due to differences across
networks
... furthermore it's optional
... so I would say "not really available"
... I think it would be hard to have logic in the browser that
relies on this
<rouslan_> +1
PROPOSED: Close issue 6 with conclusion no parameter for cardType
[No objections]
so RESOLVED
<scribe> ACTION: Ian to close issue 6 with that resolution
Ian: Jalpesh was to figure out how to describe or refer to transactionType.
Jalpesh: After discussion and
thinking through, the intention is for SRC system to identify
what payload to create
... and the transactionType is specified by the merchant (e.g.,
p2p or disbursement or whatever)
... the intent really is to identify what financial message
will be sent to the network.
(We review current text in the wiki)
Jalpesh: Should we have an
enumeration?
... if so, what values and what level of abstractions
tomasz: In SRC there is an
enumeration
... there is a set of details provided by the merchant or
dpa
IJ: Should we just reuse those values?
tomasz: Yes
Jalpesh: yes
IJ: Should we include values inline (informative only)?
Jalpesh: That's ok
tomasz: If it is publicly available, I will send Ian the list to include in the wiki.
<scribe> ACTION: Ian to update issue 7 with "yes" with values from SRC spec (if publicly available).
IJ: I looked into this.
Ken: Here's my partial and non-conclusive answer. I heard back "potentially useful" and would like more time (in Amex) to discuss
Jalpesh: Are we saying COF / Recurring / Single Use...are you saying let's define at EMVCo first?
Ken: My understanding is that EMV already defines it; we should reference that.
Clinton: There's no transaction
type in the tokenization spec.
... I think that the note you captured on issue 8 is key -
payment handler might use this bit to trigger ux
... I'm not convinced this issue is key to token generators
Jalpesh: Merchant-side UX would definitely communicate to user "one time" or "recurring'. But how would it affect payment handler / DCF experience?
<benoit_> sorry... I need to drop off early :(
Japlesh: Token usage type is an existing element in the tokenization spec...based on previous discussions....my argument is that we don't need 3 values, we just need 2
Jalpesh: Visa would find useful "one time" v. "stored"
Jonathan: But it's not part of the SRC spec.
<scribe> ACTION: Jonathan to determine usefulness of boolean about tokenUsageType within Mastercard
<trackbot> Created ACTION-121 - Determine usefulness of boolean about tokenusagetype within mastercard [on Jonathan Grossar - due 2019-06-05].
Clinton: From the EMVCo
perspective, the use cases are merchant-initiated and
user-initiated
... however, if a merchant is getting a token, the merchant can
get one as a registered token acceptor
... the other scenario is the merchant accepts a token via a
token requestor (shared token payment model)...in this case,
it's up to the token requestor to determine whether COF or
one-time, or is it intended for user-initiated or
merchant-initiated transactions
... I think for COF merchants likely to have registered with
TSP, and any token
Jalpesh: I don't think this is an EMVCo spec issue, just an implementation
IJ: Do we need a third value or make it optional?
Jalpesh: Optional should be ok.
Clinton: If you are dynamically
allocated tokens on the fly to token requestors (directly or
through aggregator), having a value to provide more context to
a TSP or an SRC system; that could be valuable.
... it's either pre-conditioned, or during transaction.
IJ: Let's fix wiki text; can we say more about use case?
Clinton: Input data suggests use
case of token requestor not being pre-registered.
... so may wish to provide token requestor ID
... in absence of token requestor ID, having parameters makes
sense
IJ: Do we need token requestor ID?
Clinton:
- Token Requestor ID (optional)
- Two other params if the first is not there: token requestor type (covers storage and who token requestor is), token usage type (cf. merchant-initiated or consumer-initiated)
Clinton: I think in absence of trid, having two others would be valuable
tomasz: I think MC needs more
time to look at these params
... from an SRC spec perspective, it's pretty open about
this
... there is a way to convey params related to tokenization of
card credentials related to transaction
... there is similarly an open object in the payload to the
DPA
... there is no strict specification regarding different
parameters regarding, e.g., trid
... if we decide to specify this in the SRC payment method,
there would be a way to map them to the SRC API.
IJ: What is a token requestor type?
Clinton: Token requestor type is a parameter that describes role (merchant, aggregator, acquirer)
<scribe> ACTION: Ken to work with Amex to determine what parameters are useful (if any) to support token usage scenarios
dynamicDataType
Ian: but that does not include token reference
Jalpesh: We do need a "reference" or "payload" flag
Clinton: The dynamicDataType is a discrete set of values
https://github.com/w3c/src/issues/14
Clinton: I think the key thing
here is that if the merchant supports a cryptogram type, they
need to be able to say so
... merchant may want to accept multiple dynamic data types,
with a hierarchy
tomasz: I confirm this is
reflected in SRC
... the DPA can specify preference for dynamic data type
IJ: Is there terminology we can reuse directly?
tomasz: There is dynamicDataType and also payloadTypeIndicator (what type of data should be included in payload - values indicate whether payment data or non-payment data)
IJ: Do we need payloadTypeIndicator?
<scribe> ACTION: Ian to add that question to the issues list (with current enum values from SRC version .9)
12 June