Signed transaction data object

[senexi]

Currently the transaction_data object is defined as a "base64url encoded JSON object". For some use-cases it might be useful to actually sign this data, so it can later be linked to its originator. So the idea would be to also allow an encoded JWT here.

[jogu]

Hi @senexi , can you confirm if you've signed an OpenID contribution agreement please, and if not sign one please? https://openid.net/intellectual-property/openid-foundation-contribution-agreements/

Thanks!

[c2bo]

Currently the transaction_data object is defined as a "base64url encoded JSON object". For some use-cases it might be useful to actually sign this data, so it can later be linked to its originator. So the idea would be to also allow an encoded JWT here.

Can you describe your requirement / use-case in a bit more detail? We already have the option to sign the Authorization Request containing the transaction_data (which will very likely be required in most use-cases that use transaction_data) - wouldn't that be enough or do you want a second signature by another party?

[senexi]

@jogu we are checking the paperwork today and sign it.

[senexi]

@c2bo we are currently working on using this feature for payments where the presentation of a credential is requested by a merchant but will be forwarded to an issuing bank for verification. If the transaction_data object would be signed, the issuing bank could verify who presented the data to the holder, given the presentation and the original (signed) transaction_data_object. The Authorization Request itself does not help in this case.

We will also publish a paper describing it in more details soon. Will link to it once it is published.

[senexi]

Hi @senexi , can you confirm if you've signed an OpenID contribution agreement please, and if not sign one please? https://openid.net/intellectual-property/openid-foundation-contribution-agreements/

Thanks!

@jogu I signed the agreement.

[jogu]

Thanks @senexi !

Can you expand on this bit please:

the issuing bank could verify who presented the data to the holder

A flow diagram might help as I'm not sure how the issuing bank and the merchant relate to the issuer/wallet/verifier roles in OID4VP.

[senexi]

Thanks @senexi !

Can you expand on this bit please:
A flow diagram might help as I'm not sure how the issuing bank and the merchant relate to the issuer/wallet/verifier roles in OID4VP.

Hi @jogu

Here it is explained in more detail.

However the important part might be this. An sd-jwt presentation (named P2Pay here) is forwarded from the verifier to the issuer of the credential. And the issuer could verify who the originator of the transaction_data object actually is, if it would be signed.

[tlodderstedt]

The current flow design is intended to be used by the ASPSP to authorize a transaction with its customer (through the wallet). That's why a payment credential (issued by the ASPSP) is used to do the authorization.

Your flow is the typical Open Banking Payment Initiation flow, where the TPP gets an access token to initiate a payment with the ASPSP. I don't understand what the value/purpose of the TPP to wallet interaction is in this case. Can you please explain?

Tp me it seems you want to utilize the credential presentation (with the transaction data) as kind of an access token towards the ASPSP.

[senexi]

In the standard OpenBanking SCA Flow the customer is initiating the payment through a different channel first. But the actual initiation of the payment (including SCA) could also be done using the wallet, by requesting an attestation that links to a payment account an a certain payment method of rail. This also provides the option for the TPP / merchant to request additional attestations like age verification or a loyalty card and thereby leverage the wallet ecosystem. In this case, the presentation would be forwarded to the issuer for verification (and payment execution). For that case, it would be useful if the ASPSP could not only verify that the presentation is linked to a certain payment request (transaction_data object), but also that this payment request is linked to the TPP.

[stefan-kauhaus]

Wouldn't the TPP be known to the ASPSP based on the interaction between them? Berlin Group etc. typically are not anonymous APIs; the TPP would have an API client id + secret / certificate of some sort in any case?

[senexi]

@stefan-kauhaus yes, looking at open banking, the TPP is identified by the according certificates. However we are not only looking at open banking. If we look at it from a more generic point of view, we are talking about forwarding the presentation - may be even relaying it through multiple parties. So it might not always be the case, that the party submitting the presentation to the issuing ASPSP is the one who created the authorization request for the wallet. In such a case, a signed transaction_data object would be a way to maintain this link.

[cyberphone]

It is a bit hard to understand what the TPP adds to the pudding in the depicted scenario. If there is a Merchant involved, it needs to be included in the sequence diagram as well.

In case a TPP forwards an authorization (like illustrated), I would assume that it would embed the received authorization data, in a specific TPP-signed TPP->ASPSP message.
EDIT: After reading step 8, it seems that this is what the current spec actually do. Isn't that sufficient?