Add credential dataset identifier

[awoie]

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]

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]

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

[Sakurann]

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

[awoie]

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

[awoie]

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?

[awoie]

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

[GarethCOliver]

credential_dataset_version rather than id?

[fkj]

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

[awoie]

@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.

[fkj]

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

[fkj]

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

[awoie]

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.