Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Maybe it was foolish to ever make any allowance for this in the first place.

Since JWT is used as a wrapper around data, it is possible that your needs will vary based on deployment scenario. In some cases, that data may need to be encrypted, in other cases only signed.

In some cases I may not need integrity protection/repudiation and am already sending over a mutually authenticated/encrypted channel. The implementations may not want signing to be forced on them, impacting their compute/data budgets - but they still want to write their standards to depend on a single data format.

In general there should not be a whitelist, but a precisely known strategy going into evaluation. This is because: - unlike TLS, you likely have a relationship with the issuers - unlike browsers, the different components are being validated against the domain

For JWKS-based distribution, that usually means that a key identifier maps to a specific issuer and to a specific validation strategy. If you supported CA-based trust models, that specific validation strategy should come from the certificates.

You shouldn't look at the public key data and decide based on the algorithm inside the JWT how to interpret it.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: