I love how the OIDC standard is littered with “authentication identity token code id cookie identifier” and many subtle variations of homonyms in slightly different combinations and orders.
I’m sure someone thought it all made perfect sense.
Probably someone who never confuses “empathy” and “sympathy” while also carefully distinguishing between “should” and “ought”.
Usually vendors fight over terminology because they want to "own" a portion of mindspace. Ultimately authorization is a programming problem, and people have devised very complicated declarative solutions like Google Zanzibar to avoid biting the bullet.
> 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.
Even that is oversimplified. To launch nuclear-armed ICBMs, it takes to subjects to turn two keys separated by sufficient distance that no one person can turn both keys at the same time. In many cases, specially involving sysadmins, you want a quorum so a rogue sysadmin cannot lock others out or commit other destructive actions.
> 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: will I be allowed to do it or not? In the plain sense of the words, I can absolutely "utter the action", I have all of the "verbs" (upload) and "nouns" (the file, the destination path). Still, I should not be allowed to perform the action if I was only given read-only access here.
Now sure, you can say that "upload to dirA" is a different verb than "upload to dirB". But this is just confusing terminology, it doesn't enlighten anything.
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 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).
So the program only have access to those files you have it access to. It cannot even ask the question to open another file, because it only has opaque accessors to those files it has been given.
I have more experience with authorization than most engineers, even engineers who have some experience with authn/authz, and I have no idea what that "subject can utter the action" or "transfer of nouns and verbs to perform the utterances" could mean
> Capabilities achieve their objective of improving system security by being used in place of forgeable references. A forgeable reference (for example, a path name) identifies an object, but does not specify which access rights are appropriate for that object and the user program which holds that reference. Consequently, any attempt to access the referenced object must be validated by the operating system, based on the ambient authority of the requesting program, typically via the use of an access-control list (ACL).
> Instead, in a system with capabilities, the mere fact that a user program possesses that capability entitles it to use the referenced object in accordance with the rights that are specified by that capability. In theory, a system with capabilities removes the need for any access control list or similar mechanism by giving all entities all and only the capabilities they will actually need.
I've worked at places where it turned out different parts of the organization had a different idea of what a "user" of the core product was.
The team using Salesforce, the data warehouse team, the application development teams, all with different mental models of what "we added 5,000 users today" actually meant in concrete terms.
people still dont understand the difference. "you do iam but what about controllong access" comes in all the time.
words dont really matter all that much. people use them because it makes them sound like they know what it is, and if its important and complex, usually have no clue.
ive seen enough "abac" where the attribute is "your login name"
> ENTI- can you enter, ORI (or ORIZ) what can you do?
I don't mean to quarrel about it, but I understood Authentication to be closer to identification. To provide "adequate proof that you are actually who you claim to be".
Even the "can you enter" question falls under authorization; "does the user have appropriate permissions?" Entering is just one of perhaps many subsequent levels of permissions.
I think you've got the right idea, though in practice the initial "authentication" question (you are who you say you are) is very closely linked to the initial "authorization" evaluation (can you enter).... because in most systems the only "can you enter" authorization required for access is in fact that you are who you say you are.
But not all systems work this way. There are some systems where you can log in successfully, but then are immediately escorted out because the "can you enter" question has secondary considerations or is decided once identity has been established based on a larger criteria. Expired accounts in some systems work exactly like this.
What is missing is a graph of all the data and its relationships. Then its just a matter of grouping things together appropriately for humans to understand.
It's funny how a graph underlies absolutely everything but no one seems to use them.
I love how the OIDC standard is littered with “authentication identity token code id cookie identifier” and many subtle variations of homonyms in slightly different combinations and orders.
I’m sure someone thought it all made perfect sense.
Probably someone who never confuses “empathy” and “sympathy” while also carefully distinguishing between “should” and “ought”.
> Probably someone who never confuses “empathy” and “sympathy” while also carefully distinguishing between “should” and “ought”.
What do you mean by this?
I feel "ought" is stronger and is something that is expected of you, but English is not my native language.
"You should drink more water"
"You ought to help your sick mother"
12 replies →
Not sure what's giving you a pause there?
3 replies →
Are you fixing it at the IETF and RFC level, or is this just another way to say "BUY OUR SHIT AND IT TOTALLLY SOLVES EVERYTHING!!!!11"
Usually vendors fight over terminology because they want to "own" a portion of mindspace. Ultimately authorization is a programming problem, and people have devised very complicated declarative solutions like Google Zanzibar to avoid biting the bullet.
Unclosable cookie banner. Top notch website engineering.
Would you like cookies? (No) -> You can revoke consent at any time (Revoke) -> Would you like cookies?
I see no banner, but I use an ad blocker configured to reject and hide all such banners, like a sane person.
It’s about 20% of the vertical screen space on an iPhone, maddening.
> 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.
Even that is oversimplified. To launch nuclear-armed ICBMs, it takes to subjects to turn two keys separated by sufficient distance that no one person can turn both keys at the same time. In many cases, specially involving sysadmins, you want a quorum so a rogue sysadmin cannot lock others out or commit other destructive actions.
> 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: will I be allowed to do it or not? In the plain sense of the words, I can absolutely "utter the action", I have all of the "verbs" (upload) and "nouns" (the file, the destination path). Still, I should not be allowed to perform the action if I was only given read-only access here.
Now sure, you can say that "upload to dirA" is a different verb than "upload to dirB". But this is just confusing terminology, it doesn't enlighten anything.
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 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).
So the program only have access to those files you have it access to. It cannot even ask the question to open another file, because it only has opaque accessors to those files it has been given.
16 replies →
I have more experience with authorization than most engineers, even engineers who have some experience with authn/authz, and I have no idea what that "subject can utter the action" or "transfer of nouns and verbs to perform the utterances" could mean
They clearly mean capabilities.
https://en.wikipedia.org/wiki/Capability-based_security
> Capabilities achieve their objective of improving system security by being used in place of forgeable references. A forgeable reference (for example, a path name) identifies an object, but does not specify which access rights are appropriate for that object and the user program which holds that reference. Consequently, any attempt to access the referenced object must be validated by the operating system, based on the ambient authority of the requesting program, typically via the use of an access-control list (ACL).
> Instead, in a system with capabilities, the mere fact that a user program possesses that capability entitles it to use the referenced object in accordance with the rights that are specified by that capability. In theory, a system with capabilities removes the need for any access control list or similar mechanism by giving all entities all and only the capabilities they will actually need.
2 replies →
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”.
2 replies →
turns out naming is important
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!
I've seen a spreadsheet with NATO abbreviations and terms. It's tens of thousands of entries. And the best ones have tens of definitions.
Care to share some highlights?
1 reply →
I've worked at places where it turned out different parts of the organization had a different idea of what a "user" of the core product was.
The team using Salesforce, the data warehouse team, the application development teams, all with different mental models of what "we added 5,000 users today" actually meant in concrete terms.
1 reply →
And renaming things is hard, if not impossible
excellent article, very thorough and nuanced explanation.
Thanks!
https://xkcd.com/927
Nice work and all regardless
Quite literally the first thing that jumped to my mind when I read the title
Is the article inventing any new words?
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.
1 reply →
“It’s worth being honest about…” yeah, no.
[dead]
[dead]
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?
This has already been solved well-enough with AuthN and AuthZ as distinct names.
I have literally never seen anyone ever use those terms and also note they both truncate to Auth.
Never change programming/maths in holding onto terrible naming conventions and making really hard stuff even harder to understand (CQRS anyone?)
UK is rotating in its decaying royal grave
2 replies →
people still dont understand the difference. "you do iam but what about controllong access" comes in all the time.
words dont really matter all that much. people use them because it makes them sound like they know what it is, and if its important and complex, usually have no clue.
ive seen enough "abac" where the attribute is "your login name"
Sign in / Sign up is my go to pet peeve for this type of thing
ENTIC and ORIZ would make more orthographic sense...
or 4entic5 and 4oriz5, inverting the k8s, i18n pattern...
pronounced "forentics" and "forizes"...
somebody stop me!
> ENTI- can you enter, ORI (or ORIZ) what can you do?
I don't mean to quarrel about it, but I understood Authentication to be closer to identification. To provide "adequate proof that you are actually who you claim to be".
Even the "can you enter" question falls under authorization; "does the user have appropriate permissions?" Entering is just one of perhaps many subsequent levels of permissions.
I think you've got the right idea, though in practice the initial "authentication" question (you are who you say you are) is very closely linked to the initial "authorization" evaluation (can you enter).... because in most systems the only "can you enter" authorization required for access is in fact that you are who you say you are.
But not all systems work this way. There are some systems where you can log in successfully, but then are immediately escorted out because the "can you enter" question has secondary considerations or is decided once identity has been established based on a larger criteria. Expired accounts in some systems work exactly like this.
2 replies →
You're correct.
ident and perms
This. It's concise and I don't have to think about "which Auth" we're talking about.
magic, this is the ticket. Two totally different words.
What is missing is a graph of all the data and its relationships. Then its just a matter of grouping things together appropriately for humans to understand.
It's funny how a graph underlies absolutely everything but no one seems to use them.