# More flexibel Zero-Knowledge Attribute equality in Anoncreds

## Current Implementation

We were very curious when we noticed the support for general Zero-Knowledge Attribute equality in Anoncreds. [Link](https://github.com/hyperledger/ursa-docs/blob/main/docs/features/attribute_equality_anoncreds.md)
We have some use cases in mind that could really benefit from this feature.

But then we saw the implementations in [indy-shared-rs](https://github.com/hyperledger/indy-shared-rs/blob/9aa8f605fb3cedb7d8abae072493fcc0cb57fd3b/indy-credx/src/services/prover.rs#L155) and [indy-sdk](https://github.com/hyperledger/indy-sdk/blob/9fbbb7939440b67e92f2698e868f14c2432cce72/libindy/src/services/anoncreds/prover.rs#L118) and recognized that this feature is "only" used for the *link secret* (*master-secret*) and the APIs don't allow to set more common attributes. This is probably because the current implementation in ursa is not very flexibel due to the fact that a common attribute MUST be present in every credential/sub proof that is involved in the proof ([src](https://github.com/hyperledger/ursa/blob/92d752100e6c8afde48e3406eaa585e1cb02b954/libursa/src/cl/verifier.rs#L290)).

## What we want to achieve

In our use cases we think about domain-specific link data that perhaps is generated by the issuer (in contrast to the link secret).
For example the user wants to make a proof with three credentials. All share the same link secret and two of them share a domain-specific link data.

| Cred1 | Cred2 | Cred3 |
| -------- | -------- | -------- |
| link secret | link secret | link secret |
| link data | link data | |
| c1_a1 | c2_a1 | c3_a1 |
| c1_a2 | c2_a2 | c3_a2 |
| ... | ... | |

We would like to make a ZK proof that link data of cred1 equals the link data of cred2. The user should still be able to add another credential cred3 without the domain-specific link data (but with the same link secret).

## Questions

Is there any crypthographic reason to NOT ALLOW attribute equality that involve only a subset of all sub proofs by just compare the m_hat of these subproofs (see example)?

If no, would it be ok to change the semantics of common_attributes that is only enforced for credentials that have the given attributes it its schema?

Or should there be a more flexible but also more complex construct, where the equality attributes can be described for specific credential definitions and attribute name? (i.e "cred1:name" should be equal to "cred2:lastname")

What do you think?