Closed tfpauly closed 2 years ago
Here's a sketch describing the interaction between origin secrets and anon origin IDs. We could start with a simplified version of the protocol that has no origin secret rotation, which would not require anon origin ID to ensure stability. Then we can say that since these are rotated, causing client state to be reset, we need something to maintain the mapping across rotation windows, and that's the anon origin ID.
(rotate) (rotate)
Issuer: -----+-----|---------+-----|------
| policy window | ...
Client: |---------------|
(start) (end)
I think this is better explained in current versions
Reopening and taking this issue. I don't think we do the best job describing this right now, and that in part relates to #213. We could include a picture like the above in part towards addressing #213.
@chris-wood can we close this now? Or do we still want more pictures?
I'll address this as followup to #213.
The anon origin ID allows attesters to track the buckets as seen from the client. Without this, rotations on the issuer for the index generation would cause the counts to reset (in the middle of a window for some client). Having consistent counts relies on the client communicating information to the attester.