If we stipulate that, we're still left wondering what the utility is of a standard that creates affordances for the insecure defaults, as opposed to just designing it right from the beginning.

▲

jeswin 2 hours ago | parent | next [-]

> utility is of a standard that creates affordances for the insecure defaults

You could make the same argument about Cookies.

> as opposed to just designing it right from the beginning

And generally, it's quite difficult to design it right from the beginning because one would often start with the wrong assumptions. Most standards evolve, and it should be acceptable.

	▲	tptacek an hour ago \| parent [-]
		No, that doesn't square up. It's like arguing "you could say the same thing about TCP, because it allows you to build JWTs, which are a bad protocol".

▲

ForHackernews 4 hours ago | parent | prev [-]

Spec writers and library authors are human? Who knew

▲

tptacek 4 hours ago | parent [-]

I don't understand what this is meant to communicate. The standard is either good or it isn't. "Good effort" is not an engineering assessment.

▲

ForHackernews 4 hours ago | parent [-]

Your objection is that they should be "designing it right from the beginning" but that applies to all realms of endeavour. The reason they didn't is human frailty.

If everyone simply designed everything right from the beginning we would live in nirvana.

▲

andai 3 hours ago | parent | next [-]

I read an article about business which had this classification, "Would be weird if it worked", "Might work", and "Would be weird if it didn't work" and argued that you want to be in the last category.

In engineering we aspire to a slightly stronger standard: "I made it physically impossible to fuck this up."

▲

tptacek 4 hours ago | parent | prev [-]

You've completely missed my point. I don't even accept the premise of the JWT standard. But the eventual migration to safer default settings, in a format that continues to expend implementation effort to support settings nobody should use, is in fact a practical engineering problem with the standard.

▲

ForHackernews 4 hours ago | parent [-]

And they've published updates[0] and libraries have hardened their defaults and removed support for insecure values (e.g. alg='none'). I'm not sure what more you want?

I'd rather use a refined, battle-tested standard with lots of eyes on it than some new untested contender produced by a handful of upstarts ("look, we just designed it right from the beginning! This time it's perfect!") PASETO reeks of second-system syndrome.

[0] https://www.rfc-editor.org/info/rfc8725/

▲

tptacek 3 hours ago | parent [-]

I don't recommend PASETO either.

▲

doc_ick 2 hours ago | parent [-]

What do you recommend then? What technology has been designed, completed, then used for years without any updates or problems?

	▲	kasey_junk an hour ago \| parent \| next [-]
		Bearer tokens are a dead end? You have to validate them anyway so traditional auth is the fallback.
	▲	tptacek an hour ago \| parent \| prev [-]
		https://fly.io/blog/api-tokens-a-tedious-survey/ tl;dr: most of the time you should use opaque random strings.