https://xkcd.com/927 Nice work and all regardless
Another take I like is "The good thing about standards is there are many to choose from!"
Authorization terminology is a mess: Let's fix it
21–30 of 91 posts
Re: Authorization terminology is a mess: Let's fix it
#22I 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"
Re: Authorization terminology is a mess: Let's fix it
#23What 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.
Re: Authorization terminology is a mess: Let's fix it
#24> 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.
> 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 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.
Re: Authorization terminology is a mess: Let's fix it
#25> 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.
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
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”.
Re: Authorization terminology is a mess: Let's fix it
#26Earlier 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…
I used to use the example of Dropbox’s chooser API to illustrate this: https://www.dropbox.com/developers/chooser
If you use this API (via a simple widget library) then the user simply picks a file in their dropbox and the app gets access to that one file. Vs OAuth where you grant the app broad access to the whole dropbox (or maybe some sub-folder).
Re: Authorization terminology is a mess: Let's fix it
#27I 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?
Not sure what's giving you a pause there?
Re: Authorization terminology is a mess: Let's fix it
#28> 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.
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.
Re: Authorization terminology is a mess: Let's fix it
#29Unclosable cookie banner. Top notch website engineering.
Would you like cookies? (No) -> You can revoke consent at any time (Revoke) -> Would you like cookies?
Re: Authorization terminology is a mess: Let's fix it
#30Earlier quoted context omitted.
> 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"
I'm a native speaker and I agree. "Ought" can connote an obligation or responsibility of some sort. "Should" is used more often when the outcome is out of any control. It might only be the speaker's belief.
But there is significant overlap.