Revocation Notification - Identifier for the credential being revoked

[dbluhm]

During the ACA-PUG meeting today, we had a brief discussion about usage of the thread ID as the identifier for a credential used within the notification. To synthesize some of the discussion:

The thread ID is used as a consistent identifier for both the issuer and holder of a credential. The thread ID provides a simple, already present, credential system independent identifier. However, this requires both sides of the exchange to map from thread ID to credential system specific identifier for the credential. It also seems to break up the clean separation between business logic and the DIDComm messaging layer, requiring the business logic driver to be aware of message details in order to correlate the notification with a credential.

As an alternative, the idea of including credential identifiers as an attachment to the revocation notification was raised, allowing the definition of what attributes are expected for each credential system to be externalized from the revocation notification RFC.

Hoping to generate some discussion around this RFC and see if this leads us to a Revocation Notification v1.1 or v2.0.

cc @swcurran @TimoGlastra @darrellodonnell @ianco

[darrellodonnell]

Imagine you’re an Issuer who is using thread_id as a way to track a conversation. Your job is to manage credentials - not threads. You are not likely to consider thread_id for the long-term and likely already have a credential tracking identifier.

While the thread_id is currently in the spec, if we look at revocation we would likely add a new parameter (e.g. credential_id) and not use thread_id.

[swcurran]

I think that the mechanism to identify the credential will be unique per credential mechanism (e.g. AnonCreds, W3C credentials), and as such, the revocation notification should also be unique. As such, I suggest adding an attachment to this protocol, akin to the attachments we have for RFCs 453 Issue Credential and 454 Present Proof. We would include a registry of attachments, and define those along with the credential issuance attachments for the different credential types.

For AnonCreds, the data in the attachments is obvious -- the Rev Reg of the credential and the index for the credential in the Rev Reg. For W3C credentials it is less clear what to use -- some thought will be needed for that.

[darrellodonnell]

I think the broader community should be consulted. I imagine that anyone considering revocation must require a way to uniquely identify a credential.

[TelegramSam]

Isn't this muddied with the potential of multiple issuance within a single thread?

I'm nervous about tight coupling between two mostly unrelated pieces of the protocol.

[ianco]

+1 for @swcurran 's suggestion to add an attachment to the protocol. The method for identifying the credential will depend on the format of the issued credential. For Indy we can provide the rev reg id and index.

I agree the thread_id shouldn't be used, it is useful for the duration of the credential exchange and we shouldn't have to save it/rely on it later.

[darrellodonnell]

Isn't this muddied with the potential of multiple issuance within a single thread?

Yes.

[kdenhartog]

seems like the credential.id property would be a good way to identify the credential for W3C credential formats. For anoncreds style credentials, you could optionally use the signature as the identifier for the credential considering it's unique and already embedded in the credential.

[TelegramSam]

Discussed WG 20220119 (40min ish) Could specify the credential id, and a 'credential id method' string within the revocation notification protocol message. Each cred id method specifies how to use the cred id to look up the matching credential.