Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

define where in mdocs to include transaction_data_hashes #330

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

define where in mdocs to include transaction_data_hashes #330

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 8 additions & 0 deletions openid-4-verifiable-presentations-1_0.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2234,6 +2234,14 @@ See ISO/IEC TS 18013-7 Annex B [@ISO.18013-7] and ISO/IEC 23220-4 Annex C [@ISO.

The VP Token contains the base64url-encoded `DeviceResponse` CBOR structure as defined in ISO/IEC 18013-5 [@ISO.18013-5] or ISO/IEC 23220-4 [@ISO.23220-4]. Essentially, the `DeviceResponse` CBOR structure contains a signature or MAC over the `SessionTranscript` CBOR structure including the OpenID4VP-specific `Handover` CBOR structure.

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

| Namespace | Identifier | Description | Encoding format |
| --------- | ---------- | ----------- | --------------- |
| `net.openid.openid4vc` | `transaction_data_hashes` | as defined in Section 7.4 of this specification | [ tstr* ] |

If KeyAuthorization for the requested transaction authorization is not present, the Wallet MUST return an error.
Copy link
Collaborator Author

@Sakurann Sakurann Nov 19, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?


See ISO/IEC TS 18013-7 Annex B [@ISO.18013-7] and ISO/IEC 23220-4 Annex C [@ISO.23220-4] for the latest examples on how to use the `presentation_submission` parameter and how to generate the Authorizaton Response for presenting Credentials in the mdoc format.

## IETF SD-JWT VC
Expand Down