should token issuers use a /.well-known/token-issuer-directory to mirror Privacy Pass?

[colinbendell]

PrivacyPass Protocol specifies a well-known location for the issuer keys. Should PST use the same or similar .well-known location?

Secondarily, should the issuer protocol key commitments be reconciled with privacy pass' schema?

[dvorak42]

From the OT, we found that issuers preferred the flexibility to store their keys at general URLs rather than having to place them in a well-known directory. The .well-known requirement works better for use cases where individual clients need to determine the keys based on the issuer identity, while with the current version of PST that information is provided by the key commitment bundles from the UA.

The key commitment format in privacypass isn't particularly suited for a version where the keysets are intended to allow for an implicit "public metadata" value. If a variant of privacypass ends up getting standardized with public metadata (either as a POPRF, partial RSA blinding, or keysets) we might move a future version of PST to support that.

[colinbendell]

which public metadata are you referring to?

[dead-claudia]

Thought OpenID Connect's mixed approach is also worth calling out here. To name a couple key bits:

• Authorization and token refresh use dymamic endpoints that are just (in most cases) idiomatically named authorize and token
• Discovery uses .well-known both directly for configuration and indirectly via WebFinger for provider identification.