search

tfpauly / privacy-proxy

Specifications for Privacy Proxy Implementations
Other
29 stars 11 forks source link

Token issuance key management #150

Closed chris-wood closed 2 years ago

chris-wood commented 2 years ago

In the basic issuance protocol, there's no limit as to the number of tokens a client can get. This means that attesters play no role in the protocol beyond relaying requests and responses between client and issuer. If an origin wants a per-origin token, it includes an origin in its challenge, and any valid matching token will be bound to that origin. (Similarly for cross-origin tokens.) This means that issuers can maintain a single key for issuance across all basic issuance protocols.

The same goes for the rate-limited variants, too. The only thing that needs to change per-origin in the rate-limited case is the per-origin blinding key, since that's what influences the rate limit logic.

tfpauly commented 2 years ago

Yes, we should make sure this is very explicitly that a single key can be used.

It is possible to use multiple keys still, and it is still useful for the request to include the key ID to support different keys (due to rotation, or if there are per-origin or per-group-of-origins keys), but issuers don't need to have many keys.

chris-wood commented 2 years ago

It is possible to use multiple keys still, and it is still useful for the request to include the key ID to support different keys (due to rotation, or if there are per-origin or per-group-of-origins keys), but issuers don't need to have many keys.

Yep, but we need to discourage using many keys for a single context here as that can be used to track users. No more than 2 keys at any point time -- old and new -- is really all that's needed.

chris-wood commented 2 years ago

I think we can close this out now.