Integrate revocation notification with issue credential v2

[TimoGlastra]

with ICv2 supporting different credential formats and potentially mulitple issuances of the indy credential we should take another look at the indy metadata we store in the credential record.

So what I'd like to propose is the following:

1. Do not store the revocation registry id and credential revocation id in the CredentialExchange record anymore, instead when we receive a revocation notification we will query the actual indy record (see here for default tags that are added: https://hyperledger-indy.readthedocs.io/projects/sdk/en/latest/docs/design/002-anoncreds/README.html). Then we will afterwards look for a credential exchange record that has the credentialId of the indy credential. This means we don't have to store this in the cred ex record and it will be easier to support multi issuance in the future.

2. Remove the revocation notification part from the top level of the credential exchange record and add it to the CredentialRecordBinding interface. This way each credential issued in a credential exchange can be revoked separetely.

In the future we could also take the following steps, but that will require some more thought

• remove the attributes from the record, if you want the attributes you should fetch them from the indy / w3c credential record
• remove the schema id / credential definition id from the record, it's convenient but won't work well with multiple credential types.

Checklist:

• add prover search credentials to the @types/indy-sdk
• 🚧 add prover search credentials to the indy-sdk-react-native wrapper (feat: add prover search credentials hyperledger-archives/indy-sdk-react-native#45)
• add findCredentialsByQuery method to IndyHolderService
• update revocation notification handler to query credentials using findCredentialsByQuery on revocationRegistryId. Then on the returned results filter for credentials based on the credentialRevocationId
• Find the CredentialExchangeRecord based on the credentialId value
• remove revocation registry id and credential revocation id from the metadata
• Next: do we also remove the schemaId and credentialDefinitionId from the exchange record?

[TimoGlastra]

@JamesKEbert @TheThreek any thoughts on this approach?

[swcurran]

I've been meaning to mention this for a bit, and this seems like a good place. Could we start to migrate to use the term "AnonCreds" rather than Indy when talking about verifiable credentials? We have been for some time scoping "Indy" to just the ledger, and moving towards using AnonCreds independent of a ledger. As such, it makes sense to use AnonCreds instead of Indy in discussions like this, and the code that results.

This does mean updates to the V2 RFCs, initially just as clarifications. In V3 we should move away from the term Indy for the AnonCreds attachments.

FYI: @TelegramSam