add transaction_data

[Sakurann]

resolves #174
resolves #173
resolves #172

• need to clarify how the hashing function is communicated
• add changelog
• clarify that transaction data type might require a credential specifically issued for that purpose
• opened define where in mdoc presentation to include transaction data #259 on mdocs
• might add examples

[paulbastian]

I still believe that putting transaction data into a
a) a dedicated response_type and/or
b) using a dedicated Credential format would be a better separation.

vp_token and existing Credential Formats assume a three party model, while transaction authorization is a 2 party model, it seems this may create problems in the future that we can't foresee, I would appreciate a better logical separation.

I don't have explicit counter-proposals, just a bad feeling. If there is no support for this direction, you may override my disapproval.

[Sakurann]

• ToDo: need to clarify which credential is allowed to be used for transaction authorization and for what kind of transaction can be authorized (might not make sense for all types). Issuer would express it in a credential and that should be standardized as part of a credential format definition and not part of OpenID4VP - part of implementation consideration?

[paulbastian]

In LSP POTENTIAL there are two designs for QES with Transaction data:

• the Wallet-centric model
• the QTSP-centric model

Are these flows applicable for both?

[alenhorvat]

Hi,
questions:

a) Is transaction data different from a consent?
b) Transaction data needs to be displayed to the end user, except if it's a M2M exchange. Keeping it generic, can lead to implementation issues. Should at least "display" or similar parameter be defined?
c) Should the RAR or PE (presentation definition?) syntax be reused? (https://datatracker.ietf.org/doc/html/rfc9396#name-authorization-request)
d) Explicit yes/no: default mode is that the user must authorise all actions, or the transaction fails?
e) If user declines 1 action, should it be recorded?
f) Is there a need for more elaborate transactions, such as conditional statements (e.g., you must answer all, you must answer to some of the questions), supporting multiple options (e.g., do you want to tip 5, 10 or 20%)? Or for QES: select a signature profile (e.g., advanced, qualified).

We introduced something similar about 2 years ago for our B2B/M2M VP exchange (https://hub.ebsi.eu/conformance/learn/verifiable-presentation-exchange#service-to-service-token-flow). We defined a simple key:value approach where, where key is a scope, and value is a VP definition. I believe this matches your definition of transaction_data. In our model, for a given action all conditions must be fulfilled, no conditional statements, no multiple options (like tipping).

Thank you!

[Sakurann]

Hi Alen,
a) transaction data is about authorization. the end user agrees to authorize a certain transaction (payments, QES, etc.)
b), c), f) specific details of transaction data are left to the experts of each use-case. so they will not be defined in openid4vp
d) yes, there is not partial succcess. we agreed to make that clearer. I just have not reflected in the PR text yet..
e) recorded where? in the wallet? according to eidas regulation, i think so?

I will look at the pointer! thank you!

[alenhorvat]

Hi. Thank you for the answers.
e) recorded by the "verifier"

[Sakurann]

In LSP POTENTIAL there are two designs for QES with Transaction data:

the Wallet-centric model
the QTSP-centric model

Are these flows applicable for both?

@paulbastian I would say so, because in both flows, presenting a credential from the wallet is used as a way to authenticate the user, right? do you have a hypothesis why this would not work for the wallet-centric model?

[paulbastian]

In LSP POTENTIAL there are two designs for QES with Transaction data:

the Wallet-centric model
the QTSP-centric model

Are these flows applicable for both?

@paulbastian I would say so, because in both flows, presenting a credential from the wallet is used as a way to authenticate the user, right? do you have a hypothesis why this would not work for the wallet-centric model?

I would say the workings of the QTSP centric model does not align with the general model of OpenID4VP and what most readers here would assume. For example, it wouldn't allow the real relying party to request a credential and QES in the same request, as the actual request is from QTSP embedded into relying party website.

[jogu]

I have a feeling there's an unintended consequence here between this PR (if merged after 1.0) and the extensibility PR.

I think this language says "a wallet MUST fail a request that includes a transaction_data if it doesn't support transaction data". But the other PR says "wallets supporting 1.0 of this spec must accept requests that contain unknown elements, including transaction_data.

I think we need the first behaviour - i.e. particularly when using the browser api, a wallet that doesn't support transaction_data must never say it can satisfy a request that contains transaction_data.

If we agree on that, then I can see two solutions:

1. We add transaction_data to 1.0 with language like "wallets MUST reject claims that contain this element".
2. We add something like 'crit', but for the body, define that in 1.0, and when 1.1 comes along with transaction_data support then verifiers that want to use it are required to include "crit": [ "transaction_data" ] in the request payload.

[bc-pi]

adding one little generalization to the generalization you did (thanks for that generalization btw)

Suggested change

	* `credential_ids`: REQUIRED. Array of strings each pointing to an identifier that identifies a set of information describing a Credential that the Verifier is requesting transaction data in a particular object to be bound to (Input Descriptor in Presentation Exchange).
	* `credential_ids`: REQUIRED. Array of strings each pointing to an identifier that identifies a set of information describing a Credential that the Verifier is requesting transaction data in a particular object to be bound to (e.g., Input Descriptor in Presentation Exchange).

[paulbastian]

@Sakurann I would like to better understand the QTSP centric model for QES.
I imagine a scenario where I am on a website (OpenID4VP Relying Party) and it wants me to sign a contract.
How does an Authorization Request look like in this case, especially what is the client_id and request_uri?

[paulbastian]

This PR adds a significant feature that should be described in a use case appendix, similar to what OpenID4VCI does in my opinion.

[paulbastian]

I am looking at this from the perspective using this within eIDAS QES use case. Illustrating with this picture, there are two possible flows:

• QTSP centric flow
• Wallet centric flow
  

The QTSP centric flow and how transaction data is used is very clear to me.

The Wallet centric flow is less clear to me. As I imagine this, the communication between Wallet and QTSP look quite similar with the Wallet having a fixed relation with a particular QTSP. The question arises how a Verifier would send a request for a QES (either including the hash or the document itself) to the Wallet, marked with "?" in the diagrams. Questions:

• Should we use OpenID4VP for this? (I think yes)
• Should this be done be using a new Credential Format? Should this use transcaction_data or credential-specific parameter to communicate the hash/document? (I am not sure and would like to clarify if transaction_data applies here or not)