Add credential dataset version

[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?

[GarethCOliver]

It's not just cryptographic data, also other security claims. e.g. exp, iat, cnf etc.

[awoie]

yep, i thought about this as well but we are using cryptographic data for these things. imo, we should have a term definition of cryptographic data, or credential metadata that includes these things. would it be ok to have a separate PR for this? we use the term cryptographic data in the batch issuance endpoint already. and there we define only three categories: format, dataset and cryptographic data which should be reworked a bit for clarity. i suggest to do that in the same PR.

[fkj]

I'm pretty sure I've seen some language similar to "security-related claims" in other specs, but I can't seem to find it right now. Would be nice to have a standard term.

[awoie]

Here it gets tricky, because for ISO mdocs this would essentially be all data contained in the MSO, right? We should think about the right term definitions and keep it very broad in this PR.

[awoie]

I updated this PR to mention timestamps but created this issue to discuss term definitions: #752

[paulbastian]

This text is missing the connection to credential_instance returned from Token Response.

[awoie]

You mean credential_identifier from the token response (aka credential instance). This makes sense.

[awoie]

I think "credential instance" may not be the best term, as multiple credential instances can correspond to the same credential identifier, credential configuration, and credential dataset, differing only in their cryptographic proof. Btw, we need a term definition for credential instance as well.

Suggested change

	* For a given Credential Dataset within the scope of a concrete Credential Format, if the Credential Dataset has not changed, the Credential Issuer MUST return the same Credential Dataset Version, even when issuing a new Credential instance with different cryptographic data, e.g., an Issuer signature.
	* For a given Credential Dataset as identified by the `credential_identifier`, if provided in the Token Response, within the scope of a concrete Credential Format, if the Credential Dataset has not changed, the Credential Issuer MUST return the same Credential Dataset Version, even when issuing a new Credential instance with different cryptographic data, e.g., an Issuer signature.

[paulbastian]

Suggested change

	* For a given Credential Dataset within the scope of a concrete Credential Format, if the Credential Dataset has not changed, the Credential Issuer MUST return the same Credential Dataset Version, even when issuing a new Credential instance with different cryptographic data, e.g., an Issuer signature.
	* If a Credential Dataset (identified by `credential_identifier` or `scope` for a particular Credential Configuration of a particular Credential Issuer) has not changed, the Credential Issuer MUST return the same Credential Dataset Version, even when issuing a new Credential instance with different cryptographic data, e.g., an Issuer signature.

[fkj]

WG discussion: maybe we need a new identifier for this that works even without credential_identifier (to support scope) and also to impose requirements without breaking changes.

[fkj]

This should really only be about non-cryptographic data, i.e. the actual data in the credential.

[fkj]

See #752.

[brentzundel]

Discussed in WG meeting. Oliver will take next steps with this PR, responding to latest feedback. Gareth will raise a new issue.

[jogu]

These 3 clauses make me feel that what we're returning isn't actually a version, and hence that credential_dataset_version is misnamed.

It's an opaque thing, and its only property is that if it changes the wallet must throw everything away. It could (kind of) just oscillate between 'a' and 'b' whenever anything changes. Not sure what the right word/phrase is - 'tag' maybe?

I think it would probably also be sensible to be clear about whether the field is intended to be displayed to the user or not. (I presume not.)

[jogu]

I think 'most recently received' is probably a clearer intent than 'latest received':

Suggested change

	* Wallets SHOULD maintain active Credentials only from the latest received version of a Credential Dataset. If the Wallet is unable to determine the latest received version, it is RECOMMENDED that it make a new Credential Request.
	* Wallets SHOULD maintain active Credentials only from the most recently received version of a Credential Dataset. If the Wallet is unable to determine the most recently received version, it is RECOMMENDED that it make a new Credential Request.

[jogu]

I'm pretty unclear about 'If the Wallet is unable to determine the latest received version, it is RECOMMENDED that it make a new Credential Request.' - when would this be the care?

[paulbastian]

MUST or SHOULD?

[brentzundel]

Discussed in DCP WG today.
Recommended path forward is this PR keeps SHOULD and gets merged, an issue is raised to track wallet capability negotiation as a general feature, then at such time that that feature gets added, likely these SHOULDs should become MUSTs.