[Design] Prove link between Uniqueness Proof and Session Proof

[paolodamico]

Motivation

One interesting approach in general of World ID is to prove to an RP you only have one account with them. This can be accomplished by the RP setting an epoch and requesting a Uniqueness Proof per epoch (e.g. a calendar year). Without epochs, then a user would never be able to "rotate" their "verification" in an RP account (because the user cannot prove the previously verified RP account and hence the RP cannot "unverify" the old account, if the RP doesn't unverify then it leads to double claims.

Now, assuming an RP has this epoch scheme, the RP may want to ensure continuity of the same World ID from one epoch to another. For example, let's say I first verify my RP-Account belongs to a human (through the PoH credential) at epoch $t$. At epoch $t+1$, I generate a new Uniqueness Proof which is completely unlikable to the verification on epoch $t$. This particular RP needs to ensure that at epoch $t+1$ I haven't sold/transferred/traded my account with someone else, so wants to ensure that when I verify my account at epoch $t+1$, I prove I am still the same World ID holder.

Design Space

One approach to solve this is that at epoch $t+1$ I provide a Session Proof (with action = epoch $t$) such that the RP establishes continuity, and I provide a Uniqueness Proof for epoch $t+1$ to maintain my verification active. The proofs however would need to have some mechanism to privately prove they're coming from the same World ID.

This is not the only approach to solve this. Open design space.

[paolodamico]

From discussion today. Likely the most straightforward approach to solve this would be: allowing RPs to optionally provide an action for Session Proofs. If not provided, Session Proofs continue to generate a random action as it is today. If provided, then the nullifier is directly exposed to the RP (instead of opaque in the sessionNullifier). What this accomplishes is that if the RP has the epoch mechanism described above, the following cases are possible at epoch $t_n$:

1. The user is returning from epoch $t_{n-1}$. In this case the user presents a Session Proof with the existing sessionId (which the RP provides), and the action corresponding to epoch $t_n$. The RP gets assurance of continuity from the previous period while obtaining the user's nullifier for epoch $t_n$ which would prevent double claim.
2. The user has previously registered in epoch $t_{n-1}$ but wants to rotate their verification to a new RP account. In this case the user starts a fresh session, which includes a Uniqueness Proof for action = $t_n$. With this, the user is unable to extend the verification of their previous account, and the new account is verified without links to the previous account.
3. The user is completely new. This case would look the same to (2) to the RP, a new user starting a fresh session.

The RP can then set their own business rules on whether they allow an existing user (on scenario (1)) to extend their verification in the new $t_{n}$ epoch or only allow this with the same World ID.