Support for DPC "instrument" in Payment Request

[jcayzac]

I thought @ianbjacobs's suggestion during our TPAC meeting to allow passing a generic dpc instrument made sense, and would allow for decoupling concerns nicely, so I would like to hear opinions about that.

[tblachowicz]

There are a few points to consider:

In the design of credentials for payments, aka DPC, we assumed that each type of payment instrument would have it's own definitions of a credential. For example, payment card credential, account-to-account credential and so on. Therefore I would rather think about supporting verifiable credentials for payments (DPCs) individually by type. For example type of the credential could be listed as Payment Method Identifier and therefore recognized as supported payment method.

Current design of DPC assumes use of Digital Credentials API to request the presentation of the credential where payment data such as amount, currency, payee details are provided in a way specific for presentation protocol. For example in OpenID4VP they'd most likely go into transaction_data element and in ISO 18013-7 Annex C it'd be requestInfo element. Specification of Payment Request API already defines comprehensive structures allowing requestor providing such data.

Digital Credentials API allows combining claims from multiple credentials within a single presentation. There is a use case for that in payments where merchant wants to confirm age of the consumer at the checkout. I'm not too sure if that could be easily achieved in Payment Request API.

[ianbjacobs]

I think this issue belongs in the payment request repo not the spc repo.