I believe this is legacy and that the ISSUER_PROTOCOL.md is out of date. The redemption_time is no longer encoded in the redemption in PSTv1. The current struct, afaik, is:

struct {
   uint32 key_id;
   opaque nonce<nonce_size>;
   ECPoint W;
} Token;

struct {
   opaque token<1..2^16-1>; // Bytestring containing a serialized Token struct.
   opaque client_data<1..2^16-1>;
} RedeemRequest;

Client_data is un specified, but in chrome's implementation this is a CBOR encoded payload.

I've added a note that ISSUER_PROTOCOL is out of date, hopefully we'll get the spec changes merged in early next week (tracking as part of #230), but Colin's struct udnerstanding is the current one.

@dvorak42 is client_data somehow bound to the redemption token? If not, why is it not just sent in a separate header or something?

In the version we ended up on for PSTv1, we don't currently bind client_data to anything (and I believe is actually null in Chrome's implementation). We'll probably just chop it out for vStandard and make RedeemRequest be the token directly unless there's a push to bind redemption data into the redemption request.

Great -- thanks. If you chop it out, are you left with basic Privacy Pass?

Yeah, if we end up chopping it out I think we can align the redeemrequest to be the token shape from privacypass.

Even if you left it in, couldn't you achieve what you want via Privacy Pass with public metadata?

This would be a binding at redemption time, so we wouldn't be able to use public metadata then.

fwiw, the current client_data in PSTv1 in Chrome M114 is this:

{
  'redeeming-origin': 'https://private-state-token.colinbendell.dev',
  'redemption-timestamp': 1685027748
}

Presumably, the origin is intended to use this to prevent replay and forgeries.

fwiw, the current client_data in PSTv1 in Chrome M114 is this:

{
  'redeeming-origin': 'https://private-state-token.colinbendell.dev',
  'redemption-timestamp': 1685027748
}

Presumably, the origin is intended to use this to prevent replay and forgeries.

How can it be used to prevent replay and forgeries if origin (site sending the redemption request) does not have direct access to client_data?