Closed mark-moir closed 5 months ago
Some lint cleanup needed. Will the new tests run automatically for PRs?
Is it necessary to put in the NOTICE.md? This is a contribution to LF which means all licensing is considered APL-2
I reviewed that file with Hyperledger staff and it is fine/appropriate. It does not change the license. Lots of open source projects have such files.
I reviewed that file with Hyperledger staff and it is fine/appropriate. It does not change the license. Lots of open source projects have such files.
Thanks @swcurran, right. Apache 2 specifically mentions NOTICE
here. This was required for our approval to contribute.
Some lint cleanup needed.
I pushed some changes yesterday that I hope will satisfy both GitHub and you :smile:. It seems that it needs you to approve the workflow to check. Thanks.
This PR first adds some tests that exercise interactions between Selective Disclosure and Equality requirements. It also includes some testing machinery that may be of independent value. Some of the tests currently fail (in some cases relative to what we think the desired behaviour is). This PR then adds two small changes that make the tests pass.
Here is a summary of how the tests illustrate the issues and the outcome of the fix:
t03_reveal_ssn_a_eq_names_equal
requests equality of two equal attributes and disclosure of one attribute that is not subject to the equality constraint. Verification should succeed, but it currently fails withInvalidPresentationData
.t04_reveal_ssn_b_eq_ssns_equal
requests an attribute to be revealed which is also subject to an equality constraint. In our opinion, EITHER presentation creation should fail with an informative error message that this scenario is not allowed (it doesn't make sense to prove equality in zero knowledge if revealing the attribute anyway) OR creation and verification of the presentation should succeed, and the requested attribute should be revealed. The current behaviour is that creation and verification succeed, but no attributes are revealed. We prefer the first option, as expressed in the expectations fort05_reveal_ssn_a_eq_ssns_equal
andt06_reveal_ssn_b_eq_ssns_equal
, described next.t05_reveal_ssn_a_eq_ssns_equal
andt06_reveal_ssn_b_eq_ssns_equal
test variations on revealing an attribute that is subject to an equality constraint, expecting failure of presentation creation with an informative error message. They currently both fail, but in different ways:t05_reveal_ssn_a_eq_ssns_equal
fails withInvalidPresentationData
andt06_reveal_ssn_b_eq_ssns_equal
appears to succeed, but (as shown by testt04_reveal_ssn_b_eq_ssns_equal
, which has the same test setup but different expectations) does not reveal the requested attribute.Details of tests follow.
It's best to run the tests single-threaded for consistent readability of output:
Overview of tests
We create a simple schema with
name
andsocial security
claims (in addition to a revocation claim that is required, but not used or relevant to these tests). The tests exercise various combinations of equality and reveal requirements. Each test creates two credentials (using the same Issuer). The name of the first is alwaysAlice
, the name of the second is provided by each test to enable testing equal and non-equal examples.Test setup
Each test specifies:
Alice
)REV_NONE
requests no attributes to be revealed, andREV_SSN
) requests thesocial-security-number
attribute to be revealed)Expected outcome
Each test specifies one of
Error
specifying a pattern for expected failure. For example, an error matchesError::InvalidClaimData("XYZ")
if it is anError::InvalidClaimData
with a string containingXYZ
.Full test output before fixes
Full test output after fixes