RLS means your database understands what a user is allowed to see and not allowed to see. It is usually much simpler to express authz in a SQL constraint than it is in code. It's also harder to forget, so you don't get an authz failure in like, one endpoint.
There are numerous practical issues with Macaroons: the caveat format is not standardized (both binary and allowed claim types), that matters a lot when using third party caveats. There are some de facto formats but they are full of issues (e.g. date format not exactly ISO).
Validation of a set of Macaroons requires walking a graph, that needs cycle detection, implementations that I've checked do not allow nested third party caveats, that invalidates one reason to use them.
Attenuation is nice but it doesn't play nice with third party caveats (hash is used as a key for decryption, appending to a third party caveat changes hash).
Then there are implementation errors such as: https://github.com/nitram509/macaroons.js/blob/master/lib/Cr...
Some of these issues could be removed by slightly changing implementations but the de facto implementation basically froze it. (then there is a fact that the de facto impl already changed some aspects from the paper, e.g. calculation of hash for appended third party caveat).
Wow what a treasure trove of goodness. Thank you!
I wrote PASETO, with a lot of feedback from cryptographers and security engineers, to avoid a lot of the design flaws of JWT.
Learn more about it here: https://paragonie.com/blog/2018/03/paseto-platform-agnostic-...
You can find a lot of implementations available: https://paseto.io
(Also: You almost certainly want to use v2)
Joking on the last two sentences, but that's how you sound when you accuse me of wanting free work. Thanks for the links.
Oh, that's easy to explain. You said:
> This is a real production issue for me, so could you please elaborate on why you think one of these (whichever you prefer) is better or link me to a source?
Specifically:
> This is a real production issue for me,
If you want a cryptographer (i.e. lvh) to solve a real production issue for you, that would in most cases be a business transaction.
If we're being uncharitable, yes.
But the parent didn't ask the other to sit down and write code, or consult, or design a system for them. In the course of an already existing discussion on the merits (and the faults) of various session auth schemes, the parent asked the other person to elaborate on why he said something.
Which people do all the time without getting paid, and the grandparent was already doing (offering his opinion) anyway.
So that it's a "real production issue" for them is irrelevant. I participate in conversations all the time concerning something that is a real business issue for me or the others, and nobody feels like we should be getting paid because we have a talk. In fact half of the discussions on HN concern frameworks, tools, deployment schemes, etc, we use in production, and we have "real production issues" with and are interested in getting other's opinions in the discussion.
I think one can easily see how this is different from a proper consulting gig.
>"If you want a cryptographer (i.e. lvh) to solve a real production issue for you, that would in most cases be a business transaction."
That sounds like what some kind of caricature of a high street lawyer who charges from the first minute, even people they casually talk with. As if answering a comment on HN would equal to doing a consulting gig.
It's doubly uncharitable since the parent asked nicely and also added "or link me to a source". Should he be charged for a link too?
I respectfully disagree.
If it was truly irrelevant, it didn't need to be brought up in the first place.
But it was, and it's what made me believe that the other person was trying to solicit for a security expert to solve a production problem for them without an invoice being involved. It was relevant to my interpretation.
They insist they didn't mean it that way, and I believe them, but it was still relevant.
Whether or not it was relevant in the comment I replied to, it became relevant once it was entered into the discussion.
You can call that "uncharitable" if you want. I don't really have a horse in that race.
It's not like people must have some hidden agenda, or that they necessarily consciously "bring things up" with some ulterior motive.
The parent just shared some context, that he has an issue related to the discussion. If anything, if they really had some hidden motive, like getting market-worthy consulting as part of a HN comment reply (!), they'd have, well, hidden the fact that they have this problem at work.
It's totally common to casually mention that "you know, this issue we're discussing on this thread I also have a work, and why do you say this approach sucks and which do you then suggest".
In fact it happens all the time on HN, between regular developers, the occasional star scientist or programmer (from Alan Kay to Ryan Dahl and Dan Brown), and even far more important and busy pros than some security expert, and I've never heard anybody counting their lost pennies from what they'd have gained if they charged for talking to them...
It's also not like the person the question was addressed to can't handle the matter themselves, and e.g. not answer if they fill they need to be paid for their musings...
The structure of the comment in question is also relevant:
"This is a real production issue for me, so could you [...]"
This reads like a demand if you parse it in spoken English.
If it helps, imagine working in retail and hearing a disgruntled customer ask you to hurry up and give them priority service. Their request might be structured like, "I need to pick my kids up from school at 3, so could you hurry it up?"
Your word choice is far less demanding than theirs. If they wrote their comment the way you just wrote yours, it wouldn't have struck me that way.
The entire reason I brought it up was because I was unsure of the intent. They clarified their intent. I believed them. Life moved on. You're still trying to litigate this.
But none of this matters. What matters is, they didn't intend it that way, and JWT sucks.
> In fact it happens all the time on HN, between regular developers, the occasional star scientist or programmer (from Alan Kay to Ryan Dahl and Dan Brown), and even far more important and busy pros than some security expert, and I've never heard anybody counting their lost pennies from what they'd have gained if they charged for talking to them...
To be fair: me neither. But knowing how humanity is, I wouldn't totally discount that it does happen somewhere on the Internet (maybe even HN).