Conversation
awoie
requested review from
Sakurann,
c2bo,
danielfett,
jogu,
paulbastian,
tlodderstedt and
tplooker
| * `credential`: REQUIRED. Contains one issued Credential. It MAY be a string or an object, depending on the Credential Format. See Appendix A for the Credential Format-specific encoding requirements. | ||
| * `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. | ||
| * `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`: OPTIONAL. 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. |
There was a problem hiding this comment.
Personally I think this feature is important enough that this identifier should be mandatory to return otherwise it makes it very difficult for credential update/refresh to be supported. If its left optional we need to discuss how it gets signalled whether this feature is supported and what a wallet is suppose to assume when it comes to updating/refreshing credentials.
There was a problem hiding this comment.
@tplooker I cannot be mandatory, otherwise this would be a breaking change, right?
tplooker
left a comment
tplooker
left a comment
There was a problem hiding this comment.
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.
|
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. |
|
temporarily close to prevent confusion - will reopen once 1.0 goes out |
|
reopening now that 1.0 has been published. Please push the changes to 1.1.md, and not 1.0.md |
awoie
force-pushed
the
awoie/add-credential-versioning
branch
from
1af74c9 to
5846457
Compare
@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? |
| ], | ||
| "notification_id": "3fwe98js" | ||
| "notification_id": "3fwe98js", | ||
| "credential_data_set_id": "Jk0eOt4CXQe1NXK" |
There was a problem hiding this comment.
| "credential_data_set_id": "Jk0eOt4CXQe1NXK" | |
| "credential_dataset_id": "Jk0eOt4CXQe1NXK" |
Sakurann
left a comment
Sakurann
left a comment
There was a problem hiding this comment.
I think it would be good to add a bit more description of the feature this parameter enables outside the definition of a term?
3 participants
Fixes #278