Support for mixed proof with revocable/non-revocable credentials

[ianco]

This is an issue with existing anoncreds implementations (indy-sdk and credx) and is illustrated in an aca-py integration test:

https://github.com/hyperledger/aries-cloudagent-python/blob/main/demo/features/0454-present-proof.feature#L120

When a proof includes both revocable and non-revocable credentials, and the request includes the revocation timestamp at the REQUEST level, then the proof will fail (even though it should pass).

Note that when the revocation interval is requested at the ATTRIBUTE level, the proof will pass (see integration test https://github.com/hyperledger/aries-cloudagent-python/blob/main/demo/features/0454-present-proof.feature#L100)

[whalelephant]

Hi @ianco,

AFAIK (quite new to this!), the reason why this is failing is because when there is a Request level revocation interval, anoncreds expects that all attributes / predicates will come with a timestamp of which the revocation state in the proof is updated to (should be in the interval). This will, as you have mentioned, fail if the credential does not support revocation.

Does this mean that Request level revocation requirement is not requiring all attributes have to have this non-revoke proof, but only those that are revocable?

[TimoGlastra]

Does this mean that Request level revocation requirement is not requiring all attributes have to have this non-revoke proof, but only those that are revocable?

@whalelephant Yes I think that is correct. The proof request indicates that the credential should not be revoked. If the credential isn't revokable it means it can never fail as it can't be revoked (at least that's my understanding).

@ianco I would be curious to know in that case how you would request that a credential is revokable (i.e. I want to only verify revocable credentials)? Or is that something you would check after you've received the credential and can't indicate in the proof request?

[swcurran]

Regards the use case, does this help? Suppose you are asking for a credential type (e.g., by schemaId or schemaName) from any issuer, and some issuers provide revocable and others non-revocable credentials. You will accept any credential, but if they are revocable, you want the NRP to be included. From AnonCreds, you want the cryptographic verification to be complete, and then (presumably) there would be other logic (outside of AnonCreds) to determine if the source credentials are acceptable (e.g., do you trust the issuer).

Equally interesting is the same case and the verifier does NOT specify a revocation interval. If a holder has a revocable credential that it uses in the presentation, should it include an NRP? I assume the answer is no, but am not sure what the AnonCreds holder software does.

[ianco]

and the verifier does NOT specify a revocation interval. If a holder has a revocable credential that it uses in the presentation, should it include an NRP?

In this case No the holder shouldn't include an NRP, and I don't believe it does. A revoked credential will verify, so there is no need to provide a "non-revocation proof".

[ianco]

and some issuers provide revocable and others non-revocable credentials. You will accept any credential, but if they are revocable, you want the NRP to be included.

Currently, if you specify the revocation interval at the ATTRIBUTE level, the proof will be accepted regardless of whether the credential is revocable or not. If you specify the revocation interval at the REQUEST level, then the presentation will fail. So it's possible to support this use case, however the verifier needs to know how to ask for the proof.

[whalelephant]

Currently, if you specify the revocation interval at the ATTRIBUTE level, the proof will be accepted regardless of whether the credential is revocable or not.

This is not the case for this current repo, if a revocation interval is specified, it should require rev_reg_id and therefore NRP.

Does this satisfy both types of non-revoke requests as feature to implement and test?
If an interval is defined in either request or attribute level, we should be verifying NRP iff the credential supports revocation.

[ianco]

The verifier doesn't necessarily know whether the holder will present a revocable credential or not. Or, as @swcurran describes, different issuers may issue based on the same schema, but some may issue revocable credentials and some not, in which case if the verifier specifies the restriction using the schema id, the presentation could include a revocable or non-revocable credential.

From a business perspective, the verifier is just asking for a non-revoked credential, in which case a non-revocable credential should be acceptable.

[whalelephant]

Yep, to clarify:

Current - we take the request interval as the indicator for requiring to check revocation or not.
To be - we should also check if the Cred Def defines support for revocation or not, and IFF both Interval && Revocable, do we check the NRP.