Add credential dataset identifier by awoie · Pull Request #472 · openid/OpenID4VCI

awoie · 2025-03-25T10:06:08Z

Fixes #278

Defines term
Adds param to credential response and deferred credential response; param is required for issuers to return, and for wallets to not always expect to not break 1.0/1.1 implementations.

tplooker

Minor editorial review, generally very supportive of this proposal I think its a critical feature. Few other thoughts

We should consider making this feature required as leaving it optional will make communicating credential updates/refreshes difficult.
I believe the specification would benefit from a seperate additional endpoint that enables a wallet to ask if there are any updates for a specific credential. Otherwise without this a wallet is forced to ask for a new credential in order to determine whether anything has changed.

tplooker · 2025-04-27T02:50:07Z

Only other thing that came to mind on this topic that perhaps we need to discuss is how we support different datasets versus different versions of the same dataset as I suspect in the event an issuer is issuing two different datasets for the same credential (e.g two credentials about different people), to the same wallet this identifier would become ambiguous.

Sakurann · 2025-05-05T11:29:27Z

temporarily close to prevent confusion - will reopen once 1.0 goes out

Sakurann · 2026-01-20T19:51:57Z

reopening now that 1.0 has been published. Please push the changes to 1.1.md, and not 1.0.md

awoie · 2026-01-27T17:03:37Z

@Sakurann @jogu fixed the merge conflicts. Please review again @tplooker and others.

awoie · 2026-01-27T17:14:02Z

Only other thing that came to mind on this topic that perhaps we need to discuss is how we support different datasets versus different versions of the same dataset as I suspect in the event an issuer is issuing two different datasets for the same credential (e.g two credentials about different people), to the same wallet this identifier would become ambiguous.

@tplooker If the same credential configuration is used for two different initial data sets, then you would need some additional mechanism. Wouldn't this be rather two distinct credential configurations, e.g., child, parent configuration?

We could also introduce another layer between credential configuration and credential dataset identifier (version)?

Is there a third option and do you have a proposal, e.g., through some new endpoint?

Sakurann

I think it would be good to add a bit more description of the feature this parameter enables outside the definition of a term?

Co-authored-by: Kristina <52878547+Sakurann@users.noreply.github.com>

awoie · 2026-02-18T19:51:47Z

I think it would be good to add a bit more description of the feature this parameter enables outside the definition of a term?

Thanks for reviewing. Just added the use case and applied your suggestion. Please review again @Sakurann

…he wallet

Co-authored-by: Ralf Engbers <raleng@users.noreply.github.com>

applied christian's comments Co-authored-by: Christian Bormann <chris.bormann@gmx.de>

GarethCOliver · 2026-04-27T18:26:55Z

 * `transaction_id`: OPTIONAL. String identifying a Deferred Issuance transaction. This parameter is contained in the response if the Credential Issuer cannot immediately issue the Credential. The value is subsequently used to obtain the respective Credential with the Deferred Credential Endpoint (see (#deferred-credential-issuance)). It MUST not be used if the `credentials` parameter is present. It MUST be invalidated after the Credential for which it was meant has been obtained by the Wallet.
 * `interval`: REQUIRED if `transaction_id` is present. Contains a positive number that represents the minimum amount of time in seconds that the Wallet SHOULD wait after receiving the response before sending a new request to the Deferred Credential Endpoint. It MUST NOT be used if the `credentials` parameter is present.
 * `notification_id`: OPTIONAL. String identifying one or more Credentials issued in one Credential Response. It MUST be included in the Notification Request as defined in (#notification). It MUST not be used if the `credentials` parameter is not present.
+* `credential_dataset_id`: REQUIRED for the Issuer to return. An opaque string containing the Credential Dataset Identifier associated with the returned Credential(s). This allows Wallets to detect changes to the underlying Credential Dataset across different Credential Responses. This is useful in situations where claim values change over time, such as an updated address, correction of previously issued personal data, or a change in legal or entitlement status (e.g., reaching the age of majority), enabling the Wallet to distinguish between a cryptographic re-issuance of unchanged data and the issuance of a credential containing modified claim values. Note that this information is only valid for the scope of a concrete credential format - if a Credential is offered in different formats, they would have different values for  `credential_dataset_id`. The Wallet MUST NOT expect the `credential_dataset_id` to be always present in the Credential Response. 


credential_dataset_version rather than id?

fkj · 2026-04-27T18:26:21Z

 * `transaction_id`: OPTIONAL. String identifying a Deferred Issuance transaction. This parameter is contained in the response if the Credential Issuer cannot immediately issue the Credential. The value is subsequently used to obtain the respective Credential with the Deferred Credential Endpoint (see (#deferred-credential-issuance)). It MUST not be used if the `credentials` parameter is present. It MUST be invalidated after the Credential for which it was meant has been obtained by the Wallet.
 * `interval`: REQUIRED if `transaction_id` is present. Contains a positive number that represents the minimum amount of time in seconds that the Wallet SHOULD wait after receiving the response before sending a new request to the Deferred Credential Endpoint. It MUST NOT be used if the `credentials` parameter is present.
 * `notification_id`: OPTIONAL. String identifying one or more Credentials issued in one Credential Response. It MUST be included in the Notification Request as defined in (#notification). It MUST not be used if the `credentials` parameter is not present.
+* `credential_dataset_id`: REQUIRED for the Issuer to return. An opaque string containing the Credential Dataset Identifier associated with the returned Credential(s). This allows Wallets to detect changes to the underlying Credential Dataset across different Credential Responses. This is useful in situations where claim values change over time, such as an updated address, correction of previously issued personal data, or a change in legal or entitlement status (e.g., reaching the age of majority), enabling the Wallet to distinguish between a cryptographic re-issuance of unchanged data and the issuance of a credential containing modified claim values. Note that this information is only valid for the scope of a concrete credential format - if a Credential is offered in different formats, they would have different values for  `credential_dataset_id`. The Wallet MUST NOT expect the `credential_dataset_id` to be always present in the Credential Response. 


Not sure about the term "opaque" here. Not really used in the other parameters, and I don't think anyone would parse this anyway.

@fkj agreed. Does this read better?

Suggested change

* `credential_dataset_id`: REQUIRED for the Issuer to return. An opaque string containing the Credential Dataset Identifier associated with the returned Credential(s). This allows Wallets to detect changes to the underlying Credential Dataset across different Credential Responses. This is useful in situations where claim values change over time, such as an updated address, correction of previously issued personal data, or a change in legal or entitlement status (e.g., reaching the age of majority), enabling the Wallet to distinguish between a cryptographic re-issuance of unchanged data and the issuance of a credential containing modified claim values. Note that this information is only valid for the scope of a concrete credential format - if a Credential is offered in different formats, they would have different values for `credential_dataset_id`. The Wallet MUST NOT expect the `credential_dataset_id` to be always present in the Credential Response.

* `credential_dataset_id`: REQUIRED for the Issuer to return. Any string containing the Credential Dataset Identifier associated with the returned Credential(s). This allows Wallets to detect changes to the underlying Credential Dataset across different Credential Responses. This is useful in situations where claim values change over time, such as an updated address, correction of previously issued personal data, or a change in legal or entitlement status (e.g., reaching the age of majority), enabling the Wallet to distinguish between a cryptographic re-issuance of unchanged data and the issuance of a credential containing modified claim values. Note that this information is only valid for the scope of a concrete credential format - if a Credential is offered in different formats, they would have different values for `credential_dataset_id`. The Wallet MUST NOT expect the `credential_dataset_id` to be always present in the Credential Response.

I think you can even just say "A string". I don't think anyone would have any reason to try to parse this.

fkj · 2026-04-27T18:27:50Z

 * `transaction_id`: OPTIONAL. String identifying a Deferred Issuance transaction. This parameter is contained in the response if the Credential Issuer cannot immediately issue the Credential. The value is subsequently used to obtain the respective Credential with the Deferred Credential Endpoint (see (#deferred-credential-issuance)). It MUST not be used if the `credentials` parameter is present. It MUST be invalidated after the Credential for which it was meant has been obtained by the Wallet.
 * `interval`: REQUIRED if `transaction_id` is present. Contains a positive number that represents the minimum amount of time in seconds that the Wallet SHOULD wait after receiving the response before sending a new request to the Deferred Credential Endpoint. It MUST NOT be used if the `credentials` parameter is present.
 * `notification_id`: OPTIONAL. String identifying one or more Credentials issued in one Credential Response. It MUST be included in the Notification Request as defined in (#notification). It MUST not be used if the `credentials` parameter is not present.
+* `credential_dataset_id`: REQUIRED for the Issuer to return. An opaque string containing the Credential Dataset Identifier associated with the returned Credential(s). This allows Wallets to detect changes to the underlying Credential Dataset across different Credential Responses. This is useful in situations where claim values change over time, such as an updated address, correction of previously issued personal data, or a change in legal or entitlement status (e.g., reaching the age of majority), enabling the Wallet to distinguish between a cryptographic re-issuance of unchanged data and the issuance of a credential containing modified claim values. Note that this information is only valid for the scope of a concrete credential format - if a Credential is offered in different formats, they would have different values for  `credential_dataset_id`. The Wallet MUST NOT expect the `credential_dataset_id` to be always present in the Credential Response. 


Might make sense to say why the wallet MUST NOT expect this to be here. Presumably for backwards compatibility?

Exactly, and makes sense. We should add this.

GarethCOliver

Add either normative, or implementation considerations that if a credential data does not change then the version MUST remain the same.

This prevents thrashing on the wallet side, for wallets that are making use of the versioning to discard old data sets etc.

Co-authored-by: Frederik Krogsdal Jacobsen <fkj@users.noreply.github.com>

paulbastian

Please discuss:

is parameter mandatory/optional
is this a number or a string
add clarity how a wallet compares versions (likely simple string comparison)
I believe an implementation consideration would make sense, see Gareths comment and also this could shorten some of the texts in the normative part, that has become a little bloated

paulbastian · 2026-05-06T07:21:38Z

 Credential Dataset:
 :  A set of one or more claims about a subject, provided by a Credential Issuer.

+Credential Dataset Identifier


Suggested change

Credential Dataset Identifier

Credential Dataset Version

paulbastian · 2026-05-06T07:45:32Z

 :  A set of one or more claims about a subject, provided by a Credential Issuer.

+Credential Dataset Identifier
+:  A unique identifier that refers to a specific version of a Credential Dataset. This identifier remains stable across multiple instances of a Credential that share the same set of claim values, even if they differ in cryptographic proofs. When the claim values in the dataset change, a new Credential Dataset Identifier is assigned. This identifier enables Wallets to detect changes to the underlying data and to distinguish between Credentials issued with different versions of a Credential Dataset under the same Credential Configuration. Note that a Credential Dataset Identifier is bound to a specific Credential Format.


Suggested change

: A unique identifier that refers to a specific version of a Credential Dataset. This identifier remains stable across multiple instances of a Credential that share the same set of claim values, even if they differ in cryptographic proofs. When the claim values in the dataset change, a new Credential Dataset Identifier is assigned. This identifier enables Wallets to detect changes to the underlying data and to distinguish between Credentials issued with different versions of a Credential Dataset under the same Credential Configuration. Note that a Credential Dataset Identifier is bound to a specific Credential Format.

: A String that refers to a specific version of a Credential Dataset. This version is identical for multiple instances of a Credential that share the same Credential Dataset, even if they differ in cryptographic proofs. When any of the claim values in the Credential Dataset change, a new Credential Dataset Version is assigned. This version enables Wallets to detect changes to the underlying data and to distinguish between Credentials of the same Credential Configuration are issued with different Credential Datasets. Note that a Credential Dataset Version is bound to a specific Credential Format.

Is it okay to have the version as a number or rather a string?

paulbastian · 2026-05-06T07:53:21Z

 * `transaction_id`: OPTIONAL. String identifying a Deferred Issuance transaction. This parameter is contained in the response if the Credential Issuer cannot immediately issue the Credential. The value is subsequently used to obtain the respective Credential with the Deferred Credential Endpoint (see (#deferred-credential-issuance)). It MUST not be used if the `credentials` parameter is present. It MUST be invalidated after the Credential for which it was meant has been obtained by the Wallet.
 * `interval`: REQUIRED if `transaction_id` is present. Contains a positive number that represents the minimum amount of time in seconds that the Wallet SHOULD wait after receiving the response before sending a new request to the Deferred Credential Endpoint. It MUST NOT be used if the `credentials` parameter is present.
 * `notification_id`: OPTIONAL. String identifying one or more Credentials issued in one Credential Response. It MUST be included in the Notification Request as defined in (#notification). It MUST not be used if the `credentials` parameter is not present.
+* `credential_dataset_id`: REQUIRED for the Issuer to return. An opaque string containing the Credential Dataset Identifier associated with the returned Credential(s). This allows Wallets to detect changes to the underlying Credential Dataset across different Credential Responses. This is useful in situations where claim values change over time, such as an updated address, correction of previously issued personal data, or a change in legal or entitlement status (e.g., reaching the age of majority), enabling the Wallet to distinguish between a cryptographic re-issuance of unchanged data and the issuance of a credential containing modified claim values. Note that this information is only valid for the scope of a concrete credential format: if a Credential is offered in different formats, they would have different values for `credential_dataset_id`. The Wallet MUST NOT expect the `credential_dataset_id` to be always present in the Credential Response. 


Suggested change

* `credential_dataset_id`: REQUIRED for the Issuer to return. An opaque string containing the Credential Dataset Identifier associated with the returned Credential(s). This allows Wallets to detect changes to the underlying Credential Dataset across different Credential Responses. This is useful in situations where claim values change over time, such as an updated address, correction of previously issued personal data, or a change in legal or entitlement status (e.g., reaching the age of majority), enabling the Wallet to distinguish between a cryptographic re-issuance of unchanged data and the issuance of a credential containing modified claim values. Note that this information is only valid for the scope of a concrete credential format: if a Credential is offered in different formats, they would have different values for `credential_dataset_id`. The Wallet MUST NOT expect the `credential_dataset_id` to be always present in the Credential Response.

* `credential_dataset_ver`: REQUIRED for the Issuer to return. An opaque string containing the Credential Dataset Version associated with the returned Credential(s). This allows Wallets to detect changes to the underlying Credential Dataset across different Credential Responses. This is useful in situations where claim values change over time, such as an updated address, correction of previously issued personal data, or a change in legal or entitlement status (e.g., reaching the age of majority), enabling the Wallet to distinguish between a cryptographic re-issuance of unchanged data and the issuance of a credential containing modified claim values. Note that this information is only valid for the scope of a concrete credential format: if a Credential is offered in different formats, they would have different values for `credential_dataset_ver`. The Wallet MUST NOT expect the `credential_dataset_ver` to be always present in the Credential Response.

The last and first sentence are contradicting, feels like you didn't finish the first sentence and there is a condition missing. I would not make this feature mandatory.

paulbastian · 2026-05-06T07:55:23Z

 ```

-Below is a non-normative example of a Credential Response in an immediate issuance flow for multiple Credential instances in JWT VC format (JSON encoded) with an additional `notification_id` parameter:
+Below is a non-normative example of a Credential Response in an immediate issuance flow for multiple Credential instances in JWT VC format (JSON encoded) with additional `notification_id` and `credential_dataset_id` parameters:


Suggested change

Below is a non-normative example of a Credential Response in an immediate issuance flow for multiple Credential instances in JWT VC format (JSON encoded) with additional `notification_id` and `credential_dataset_id` parameters:

Below is a non-normative example of a Credential Response in an immediate issuance flow for multiple Credential instances in JWT VC format (JSON encoded) with additional `notification_id` and `credential_dataset_ver` parameters:

paulbastian · 2026-05-06T07:55:32Z

  ],
-  "notification_id": "3fwe98js"
+  "notification_id": "3fwe98js",
+  "credential_dataset_id": "Jk0eOt4CXQe1NXK"


Suggested change

"credential_dataset_id": "Jk0eOt4CXQe1NXK"

"credential_dataset_ver": "Jk0eOt4CXQe1NXK"

paulbastian · 2026-05-06T07:55:39Z

 * If the Credential Issuer still requires more time, the Deferred Credential Response MUST use the `interval` and `transaction_id` parameters as defined in (#credential-response) and it MUST respond with the HTTP status code 202 (see Section 15.3.3 of [@!RFC9110]). The value of `transaction_id` MUST be same as the value of `transaction_id` in the Deferred Credential Request.

-The Deferred Credential Response MAY use the `notification_id` parameter as defined in (#credential-response).
+The Deferred Credential Response MAY use the `notification_id` and the `credential_dataset_id` parameter as defined in (#credential-response).


Suggested change

The Deferred Credential Response MAY use the `notification_id` and the `credential_dataset_id` parameter as defined in (#credential-response).

The Deferred Credential Response MAY use the `notification_id` and the `credential_dataset_ver` parameter as defined in (#credential-response).

paulbastian · 2026-05-06T07:55:52Z

  ],
-  "notification_id": "3fwe98js"
+  "notification_id": "3fwe98js",
+  "credential_dataset_id": "Jk0eOt4CXQe1NXK"


Suggested change

"credential_dataset_id": "Jk0eOt4CXQe1NXK"

"credential_dataset_ver": "Jk0eOt4CXQe1NXK"

paulbastian · 2026-05-06T07:56:03Z

   * use derived origin for `expected_origins` in IAE flow
   * add require_interactive_authorization_request to AS metadata
   * add interactive_authorization_endpoint to AS metadata section
+   * add credential dataset identifier


Suggested change

* add credential dataset identifier

* add credential dataset version

awoie requested review from Sakurann, c2bo, danielfett, jogu, paulbastian, tlodderstedt and tplooker March 25, 2025 10:06

tplooker reviewed Apr 22, 2025

View reviewed changes

Comment thread openid-4-verifiable-credential-issuance-1_0.md Outdated

tplooker reviewed Apr 22, 2025

View reviewed changes

Comment thread openid-4-verifiable-credential-issuance-1_0.md Outdated

tplooker reviewed Apr 22, 2025

View reviewed changes

This was referenced Apr 27, 2025

clarify batch management in the Wallet when the new batch of the credentials was received #452

Closed

Add a mechanism for notifying the wallet about certain events #300

Open

Sakurann added this to the 1.1 milestone May 5, 2025

Sakurann closed this May 5, 2025

awoie mentioned this pull request May 7, 2025

Supporting Credential Versioning #278

Open

Sakurann reopened this Jan 20, 2026

fix: resolved merge conflicts

5846457

awoie force-pushed the awoie/add-credential-versioning branch from 1af74c9 to 5846457 Compare January 27, 2026 17:01

awoie added 2 commits January 27, 2026 18:02

fix: removed credential data set id from 1.0

1380487

fix: editorial

2c0bf28

awoie requested a review from tplooker January 27, 2026 17:03

Sakurann reviewed Feb 2, 2026

View reviewed changes