Token and token reference use cases

[ianbjacobs]

In the tokenization spec [1] we distinguished the use case where the payee receives a "full" payload from the use case where the payee receives only a token reference id (and uses that reference on the back end to fetch the full data).

I assume we still wish to represent both use cases. How does this impact our response data model?

[1] https://w3c.github.io/webpayments-methods-tokenization/

[ianbjacobs]

Per discussion on 29 May [1] I have added "tokenReferenceOnly" as an input preference parameter and "tokenReference" in the response data.

[1] https://www.w3.org/2019/05/29-wpwg-minutes.html#item04

[tblachowicz]

In EMVCo SRC API specification [1] there is a notion of payload type indicator that is an optional parameter that can be provided by the client into Checkout API. There are four values for the PayloadTypeIndicator enumerated type:

• SUMMARY - indicates that Checkout API call should not return any encrypted Payload object. Instead, the client can use Payload API to retrieve the Payload object presenting srcCorrelationId as a reference.
• PAYMENT - indicates that encrypted Payload object should contain only payment credentials, but no other data such as Consumer details nor address.
• NON_PAYMENT - indicates that encrypted Payload should contain only non-payment personal data such as Consumer details and shipping address when requested by the Merchant/DPA
• FULL - indicates that encrypted Payload should contain both payment credentials and personal data.

It seems a good idea to follow the concept of payload type indicator in the definition of SRC payment method to be able to cover all the use cases as supported by SRC in the latest specification.

Please note, the specification also allows the use of payload type indicator to request a certain type of Payload object in Payload API, but I have not included details above to maintain clarity of my comment.

[1] https://www.emvco.com/terms-of-use/?u=/wp-content/uploads/documents/EMVCo-Secure-Remote-Commerce-Specifications-API-1.0.pdf