Nice! I'd like to fix the prior abstract. Auth and auth upsets me greatly cos we have: Authentication & Authorization and we call both/either auth. Hence please help me make this a thing: AuthENTIcation & AuthORIzation : ENTI & ORI ENTI- can you enter, ORI (or ORIZ) what can you do?
ident and perms
Authorization terminology is a mess: Let's fix it
81–90 of 91 posts
Re: Authorization terminology is a mess: Let's fix it
#82Earlier quoted context omitted.
I chose those words here because they are not programming language specific. For the OOPers, I guess you can imagine I said “objects” and “methods”.
Not particularly an OOPer, but regardless tou're only making it less clear I'm afraid! "objects" and "methods" instead of what? I'll make an educated guess that you mean "objects and methods" instead of "subject and action" or "noun and verb" respectively. But it's really the "utter" and "transfer" terminology that I have no idea what it might mean
Re: Authorization terminology is a mess: Let's fix it
#83Earlier quoted context omitted.
> If the subject can utter the action, then it can perform it. This sounds like another layer of weird terminology that doesn't mean anything for someone who is not familiar with whatever capability system you're thinking of. Say I am a user who can see a particular directory on a shared setup. I try to upload a file in this directory, using the same method that worked on another directory. The question of AuthZ is:…
You seem to understand it just fine. Your accessor, dirB, should not contain the “upload files” verb, while your dirA accessor (noun) should. My favorite example is the home directory and the file picker. Why should a program have access to all your files by default then politely ask you which file it should read/write to? It would make more sense if the file picker was something the operating system ran when a progr…
> It would make more sense if the file picker was something the operating system ran when a program wants to edit a file, and what came back to the program after you selected was the accessor for that file (with read and/or write verbs).
You are describing the concept of XDG Desktop Portals [1] on Linux.Re: Authorization terminology is a mess: Let's fix it
#84Earlier quoted context omitted.
You seem to understand it just fine. Your accessor, dirB, should not contain the “upload files” verb, while your dirA accessor (noun) should. My favorite example is the home directory and the file picker. Why should a program have access to all your files by default then politely ask you which file it should read/write to? It would make more sense if the file picker was something the operating system ran when a progr…
> It would make more sense if the file picker was something the operating system ran when a program wants to edit a file, and what came back to the program after you selected was the accessor for that file (with read and/or write verbs). You are describing the concept of XDG Desktop Portals [1] on Linux. 1. https://wiki.archlinux.org/title/XDG_Desktop_Portal
Re: Authorization terminology is a mess: Let's fix it
#85Earlier quoted context omitted.
That's when you turn to the RFC2119 all-caps requirement levels!
> SHOULD — This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. You'll also need RFC 6919[1] for "OUGHT TO": > The phrase "OUGHT TO" conveys an optimistic assertion of an implementation behavior that is clearly morally right, and…
Hence OUGHT leads to SHOULD and the latter is meaningless without the former.
E.g.: You OUGHT to secure systems that handle sensitive customer data, so you SHOULD regularly patch your software.
Just telling someone they should do something without an initial moral motivation to do the “right thing” can fall on deaf ears.
I’ve seen an official patch management strategy in a government organisation that was simply: “Don’t”.
Their moral argument was that they OUGHT to save taxpayer money and so they SHOULD save time, money, and effort by not applying updates (which they felt weren’t necessary for security).
In other words: OUGHTs are like axioms that you can choose, and then the SHOULDs derive from them automatically.
Re: Authorization terminology is a mess: Let's fix it
#86Unclosable cookie banner. Top notch website engineering.
Re: Authorization terminology is a mess: Let's fix it
#87Earlier quoted context omitted.
Another take I like is "The good thing about standards is there are many to choose from!"
Just to clarify, it's not about a new standard, folks. It's about giving things names to avoid confusion and mixing up different things.
Re: Authorization terminology is a mess: Let's fix it
#88Earlier quoted context omitted.
I'm maintaining a document called Tricksy words with multiple meanings that cause endless confusion and strife Just in the past year I have wasted several months pulling my hair out due to incorrectly named projects. It really does turn out naming is important!
Care to share some highlights?
Function: a mapping from inputs to outputs, vs "a chink of code that runs and does arbitrary things with global state." Some languages resolve it by using the word procedure (and keyword proc).
(For an amusing read on this subject, see Chapter 5 of Let Over Lambda, which argues that Lisp is actually the least functional language!)
Deserve: can refer to unconditional rights, as well as conditional privileges. (e.g. "every child deserves a safe home", vs. "this person deserves to be punished.")
Positive/Negative have at least 3 separate meanings depending on context (good, present, self-amplifying). e.g. positive feedback can means the system is about to explode, positive symptom can mean "CIA replaced my Shasta again".
Normal can mean "happens all the time" or "is acceptable". Often those two are not in agreement. (People often fuse this one. If it's unusual then it must be bad! If it's common then it must be okay!)
Meaningful: something "means" something if it points beyond itself (as a symbol), or if it doesn't (direct experience).
Example: enjoying a sunset
The experience itself can be deeply satisfying. Or you can project ideas onto it like "I'm blessed", "I earned it", so the experience "points beyond" itself.
(Alan Watts has an excellent video on purpose and meaning, considering our approach to them a uniquely western neurosis.)
Serious: committed, vs overly heavy. People often confuse the two attitudes, which creates a lot of inner resistance. (And ironically produces childishness due to resistance to maturity.)
Selfish: prone to neglect others (bad), vs taking care of yourself (good and natural to every organism, yet often vilified in our culture). You can do both of course but they're kind of independent axes.
Several authors have written in defense of selfishness, but were so abrasive that they did the idea more harm than good!
Meditation can mean 10,000 different things, many of which are opposites (e.g. intentionally directing the attention, vs allowing it to wander freely). (Enlightenment is similarly open to interpretation, even within the same school of thought!)
Re: Authorization terminology is a mess: Let's fix it
#89> can this subject perform this action on this object? IMHO, the most elegant method to answer this question is capability based access control. If the subject can utter the action, then it can perform it. And then delegation is the transfer of nouns and verbs to perform the utterances.