define where in mdocs to include transaction_data_hashes

[Sakurann]

blocked by #421

resolves #259

[Sakurann]

need to define proper data element identifier for KeyAuthorization? cc @martijnharing

[martijnharing]

When using the mdoc to sign data, there will often be security considerations is to whether the particular mdoc can / should / may sign a particular data element. Whether there are any limitations strongly dependent on the specific document type and use case. But typically the Issuer indicates with a particular namespace and data element identifier which exact things the mdoc can / should / may sign.
So from a security perspective we should define the namespace and data element dependent on the use case and not as a generic identifier.

[GarethCOliver]

as I understand it, transaction_data contains a 'type' parameter. If we want issuers to have more granular control over what type of transaction_data is allowed to be returned by the wallet we could define a set of DataElements:

namespace: net.openid.openid4vc.transactiondata
identifier: must be the type of the transaction_data

The wallet MUST return split the transaction_data_hashes so each is returned as part of the value array in a DataElement with a namespace net.openid.openid4vc.transactiondata and identifier of transaction_data.type. A wallet MUST return an error if a request contains transaction_data with a type that is not present in the KeyAuthorizations.

psuedocode example:
paymentsTransactionData = { type = "payments", ... }
fooTransactionData1 = { type = "foo" , ...}
fooTransactionData2 = { type = "foo", ... }

request {
...
transaction_data [ paymentsTransactionData, fooTransactionData1, fooTransactionData2 ]
..
}

then the response would have in DeviceSigned:

...
net.openid.openid4vc.transactiondata:
[
{ payments -> [ base64(hash(paymentsTransactionData))) }
{ foo -> [ base64(hash(fooTransactionData1)), base64(hash(fooTransactionData2)) ] }
]
}
..

additionally the KeyAuthorizations would either need to authorize the entire net.openid.openid4vc.transactiondata namespace, or the identifiers payments and foo within the net.openid.openid4vc.transactiondata namespace.

@martijnharing this would provide the granularity you are looking for?
@Sakurann does this roughly make sense?

[awoie]

If the type was included, it would mean the issuer controls what types of transactions the wallet can sign with the credential. Is this really an issuer decision?

[awoie]

Also, since the mdoc can use device signature or device mac, i would argue it should be mostly device signature since for transaction signing non-repudiation is probably a requirement, isn't it?

[sander]

If the type was included, it would mean the issuer controls what types of transactions the wallet can sign with the credential. Is this really an issuer decision?

@awoie in my opinion, yes. See also #259 (comment). Of course, an issuer may decide to include a device-signed attribute with arbitrary CBOR content, confirming “any” transaction. But I do not expect for example EUDIW PID issuers to do so.

[martijnharing]

The approach of @GarethCOliver on where to put the data mostly makes sense to me. I think we should define the openid namespace as an option that profiles can use, but not mandate it as the only option.

[andprian]

I believe the hash algorithm should also be protected by the signature of the mdoc. In the case of transaction data, signing implies commitment from the user on some data. Or the commitment is not complete if it is made on the data representation (hash) without committing to the algorithm as well.

[GarethCOliver]

I believe the hash algorithm should also be protected by the signature of the mdoc. In the case of transaction data, signing implies commitment from the user on some data. Or the commitment is not complete if it is made on the data representation (hash) without committing to the algorithm as well.

Yeah, you are right. Based on the outcome of #443 it should either be a single, additional data element, or in a wrapper cbor structure (if alg remains per-transaction-data).
{
hash = hash(...)
alg = ALG
}

[sander]

See also: #259 (comment)

[awoie]

Suggested change

	The `transaction_data_hashes` response parameter MUST be returned in DeviceSigned using the `transaction_data_hashes` DataElement defined below:
	The `transaction_data_hashes` response parameter MUST be returned in `DeviceSigned` using the `transaction_data_hashes` data element defined below:

[sander]

Note #421 contains an alternative proposal.