search

proofcarryingdata / zupass

Zuzalu Passport
259 stars 64 forks source link

Throw exceptions when event ID doesn't match configuration #1802

Closed robknight closed 3 days ago

robknight commented 1 month ago

Closes https://linear.app/0xparc-pcd/issue/0XP-974/zuauth-doesnt-check-event-id-when-revealed

Fixes authenticate so that, if the event ID is revealed and event IDs are configured as filters, the revealed event ID must match one of the filtered values.

Also updates the tests to be more careful in identifying the kind of exception thrown.

robknight commented 2 weeks ago

I've made several changes here. The server-side code now takes a full set of arguments, identical to those provided to the client (and so including fieldsToReveal). It will check that all of the fields configured to be revealed are in fact defined.

In addition, if event or product IDs are provided to authenticate against, then the relevant fields must be revealed. I have removed the use of the validEventIds feature in preference for a simpler and easier-to-understand comparison of the revealed value against the configured values.

The tests have been updated to check specific error messages, and to test the cases where there is a mismatch in the revealed fields used when making the proof and those provided to the authenticate function.

robknight commented 1 week ago

I've made further modifications:

From a ZuAuth perspective, it doesn't make sense to include validEventIds, because in cases where the event ID is hidden it is not possible to be certain that the (hidden) matching event ID really did belong to a ticket with the expected signing key for that event ID (there could be a duplicate event ID from another signer whose tickets are also in the set of valid tickets, but not for the event ID used).

I've tightened up all of the checks that ensure that the claim matches the configuration. This is important because we want to ensure that the same configuration is used to derive the prove screen URL on the client side, and for authentication on the server-side. Any mismatch may suggest a configuration error, or use of a credential prepared with a different configuration (though the watermark should be sufficient to prevent credential replay attacks). Therefore we now check:

I have also added some tests, and cleaned up the implementation of existing tests. This includes checking the precise exceptions thrown for each failure case.