You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 11, 2024. It is now read-only.
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?
The text was updated successfully, but these errors were encountered:
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):
use the common_attributes variable but apply it only to the credential definitions that have the given attributes.
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
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.
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?
The text was updated successfully, but these errors were encountered: