More flexibel Zero-Knowledge Attribute equality in Anoncreds

[mickrau]

Current Implementation

We were very curious when we noticed the support for general Zero-Knowledge Attribute equality in Anoncreds (1.0). Link
We have some use cases in mind that could really benefit from this feature.

But then we saw the implementations in indy-shared-rs and indy-sdk 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).

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 for AnonCred1 (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"). Same Discussion was initiated here for Anoncreds 2.0.

What do you think?

[mikelodder7]

No there isn't. We could expose it if we need to. I've also implemented a simpler version that can be used anywhere in https://github.com/mikelodder7/commit_twin

[mickrau]

ok great to hear. We would definitely support to make this useful feature accessible. Do you have a preference on how it should be integrated into the current CL code?

We see currently the following two options (as described before):

1. use the common_attributes variable but apply it only to the credential definitions that have the given attributes.
2. add a new variable that have a list of a list of credID and attribute that specifies exactly which attributes from which credentials have to be equal. Comparable to Proposal