Delete or replace credential

[ianco]

Add functionality to the credential registry to delete or replace a credential

Will require a new/updated message protocol in Aries agent

[swcurran]

I think the solution for this is might be to add an optional decorator to the credential or credential-offer message (0.1 and 1.0) that the issuer can use to notify the holder about what to do with the previously issued credential. Something like:

   "~prev_cred" : "delete"

In theory, the same decorator could be used to notify the recipient that the credential/offer is being made because there is a replacement available for the revoked credential (e.g. "revoked" as the value). A mechanism for telling the holder about a revocation is needed regardless, and will be proposed for the 1.1 Issue-Credential protocol. This seems like a good way to do it.

The "delete" indicator feels like it is IndyCatalyst specific, so may not make it as part of the 1.1 Issue-Credential, but it could as it indicates a different semantics - "I issued this credential incorrectly and you should delete it".

The decorator might also be in the form:

   "~prev-cred" : {
            "action" : "delete"
            "reason" : "reason for action"
   }

For ACA-Py, the admin interface would have to be modified to enable the controller to set the value(s) of the decorator. As well, for the receiver agent, the decorator would have to be passed through to the message handler, to the controller via a webhook and understood in the --auto-store logic within ACA-Py. Presumably that is all pretty straight forward.

@andrewwhitehead - what do you think?

[swcurran]

Ping @andrewwhitehead for feedback. I'd like to propose this as the initial 1.1 version that evolves the 0036 RFC.

[andrewwhitehead]

@swcurran I'm not sure how the previous credential would be identified by the holder in the general case. For Catalyst we define the cardinality attributes per credential type so we can derive credential sets. As far as I can tell the default behaviour (delete) is also known by Catalyst and doesn't need to be specified by the issuer. In 1.0 the propose-credential message has a comment field which would seem to represent the reason field here.

[swcurran]

That's not right. The default behavior in indycat is revoke, not delete. This functionality is to do exactly that - to let the issuer tell the holder why a new credential is being offered or issued. In the IndyCat case, this gives us a way for the issuer to tell IndyCat - hey, delete the previous version of this versus the default behavior.

Hmm...that only works for the active credential, not if we want to use this for deleting/replacing an historic one. Have to think about that.

The revocation is just a notification needed to let the holder know.