let people login to zuzalu.city with either a new ticket or old ticket either today or tomorrow

[ichub]

No description provided.

[robknight]

So what Zupass did was this:

Users can provide a semaphore signature PCD, where the signed message is the user's UUID from the commitments table, which zuzalu.city uses to make API requests to Zupass to get the user's data. PCDPass does not support the exact same API - some fields were Zupass-specific. However, zuzalu.city doesn't seem to use much of the data it gets back, apart from email address.

This worked because the only way to become a user in Zupass was to have a Zuzalu ticket, so there was no need for the PCD to make any claims about being a ticket-holder - transmitting the UUID was enough, because having a UUID meant having a ticket.

PCDPass does support the Zuzalu fetchParticipant/fetchUser API, and with some tweaks can be made to work in the same way that the Zupass one did. Since this API will only work for Zuzalu ticket-holders, everything is fine.

However, none of this works for Zuconnect tickets, for the reason that the PCDPass server doesn't know anything about Zuconnect tickets.

I think the title of this ticket is a bit ambiguous: I originally interpreted "new ticket" to mean a Zuconnect ticket, and "old ticket" to mean a Zuzalu 1.0 ticket ported to PCDPass (as per #618). But now I wonder if "new tickets" are just the old tickets ported to PCDPass, and Zuconnect tickets are another issue altogether.

[ichub]

I think both Zuconnect and Zuzalu tickets should be issued as new eddsa-ticket-pcds. Logging into Zuzalu.city should work in the case that you have one of the tickets, but not the other. Having both tickets should not cause problems.

This may require you to augment the get-without-proving request type, so that it can ask for multiple PCDs.

[robknight]

I don't think it needs to ask for multiple, it just needs one.

If we imagine someone who has a Zuzalu1 ticket, a Zuconnect ticket, and one or more Devconnect tickets, then when they're prompted to select the PCD they will have to choose which one to provide. If they choose a non-Zuzalu/Zuconnect ticket then it shouldn't work (zuzalu.city should reject it).

[robknight]

zuzaluorg/zuzalu#5

The hard part here was figuring out what data zuzalu.city really uses, and whether it's therefore safe to ignore some of the data that is currently being provided by the Zuzalu API (e.g. the resident/visitor/organizer role - although zuzalu.city stores this, it doesn't actually use it for anything, so it's OK that the PCD doesn't include it).

[robknight]

Remaining to do is:

• Check the ticket category field or event ID field once confirmed
• Verify the public key (not sure whether to put this in an environment variable or to fetch it at runtime from the passport server)

[ichub]

@robknight could you send me the PR in which you implemented this on the zuzalu.city repository please

[robknight]

zuzaluorg/zuzalu#5

[ichub]

this already works