tfpauly / privacy-proxy

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

Rename "issuer-key" #131

Closed chris-wood closed 2 years ago

chris-wood commented 2 years ago

The issuer's config value "issuer-key" is the base64-url encoded public key used for fetching tokens, but the name is a bit misleading. Maybe we can rename this to "token-issuance-key" or similar?

tfpauly commented 2 years ago

What about the name is misleading? It's the key the issuer has to issue keys, which is the primary function of the issuer.

chris-wood commented 2 years ago

As in the PR, there are multiple keys the issuer holds. It's not clear what key this refers to.

tfpauly commented 2 years ago

The reason I used the name "issuer-key" within the auth scheme (and for the basic issuance flow) is that it is the only issuer key that's ever seen by the clients and origins in the normal flow. The challenge includes the issuer key that needs to cover the tokens, and that's the one the client uses.

When looking at this from a "base" spec for privacy pass tokens, "issuer key" is IMO the simplest option. The fact that rate-limited tokens also have an "origin name key" is an extra thing, and it's not necessary to know about that to understand the base spec.

chris-wood commented 2 years ago

When looking at this from a "base" spec for privacy pass tokens, "issuer key" is IMO the simplest option. The fact that rate-limited tokens also have an "origin name key" is an extra thing, and it's not necessary to know about that to understand the base spec.

I dunno. I find it quite confusing. I get that "issuer-key" is arguably simpler, but it doesn't capture what the key actually does. It's a key for verifying tokens, regardless of issuance protocol. Confusion is compounded when referenced in the context of the rate-limited protocol, which has a pile of keys hanging around.

I think we want the vocabulary here to be clear and descriptive. If we have to explain the name, then the name can surely be improved. "issuer-validation-key" (or "token-validation-key") is specific and works equally well for all protocols. I don't think we're helping much by choosing overly simplified names.

tfpauly commented 2 years ago

Okay, "token-validation-key" sounds good there.

Are you OK with keeping the "origin-name-key" for the key used to encrypt origin names?

chris-wood commented 2 years ago

Are you OK with keeping the "origin-name-key" for the key used to encrypt origin names?

What about something like "issuer-encapsulation-key", as in, the key used to encapsulate things to the issuer? I'm thinking the name should probably reflect that capability.

tfpauly commented 2 years ago

I guess it's a call between what it does at a very technical level, and how it's used. We use this key to encrypt origin names to the issuer, and it's not clear what other things we'd encapsulate similarly at the moment using this particular protocol—if we had other things, it could be a different key, etc.

chris-wood commented 2 years ago

Fixed in #138.