Rendered at 23:26:15 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
jiggawatts 14 hours ago [-]
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”.
theasisa 14 hours ago [-]
> Probably someone who never confuses “empathy” and “sympathy” while also carefully distinguishing between “should” and “ought”.
What do you mean by this?
throwaway1058 13 hours ago [-]
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"
da_chicken 12 hours ago [-]
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.
zobzu 9 hours ago [-]
im not a native speaker and these always made perfect sense to me :(
rzzzt 11 hours ago [-]
That's when you turn to the RFC2119 all-caps requirement levels!
deathanatos 9 hours ago [-]
> 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 thus does not require substantiation.
And the up-threads gut feel that "ought to" is slightly stronger comes across there, I think: ought to conveys that moral stance, where as "should" is more "there's a decision here, possibly".
[1]: https://www.rfc-editor.org/rfc/rfc6919.html; n.b., this is an April 1st RFC. I like it, though, and it isn't uncommon to see a stray "ought to" lacking a citation in a non-April-1st RFC.
jiggawatts 22 minutes ago [-]
My understanding is that they’re generally treated as homonyms in most cases but some philosophers like to use OUGHT in a moral sense and SHOULD as practical advice to achieve an OUGHT.
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.
wky 8 hours ago [-]
What I find strange about RFC2119 is technically RFC8174 amends it, yet the amended text never seems to be used.
dragonwriter 8 hours ago [-]
The amendment add verbiage which is irrelevant when the purpose for which it is being referenced is almost any purpose other than interpreting an RFC in which one or more of the specified words appear in lowercase in a place relevant to the interpretation.
actionfromafar 10 hours ago [-]
You really OUGHT to.
intrasight 10 hours ago [-]
SHALL vs SHOULD
rzzzt 7 hours ago [-]
shan't vs. oughtn't! Both are equally horrendous.
drfloyd51 6 hours ago [-]
Shan’t is a lot of fun. It feels like such a misuse of contractions. But it works. And it’s fun to say.
It's going over my head, too. I don't understand what the implication of the sentence is in context.
hilariously 11 hours ago [-]
Someone who is incredibly pedantic and also specific about their word use, who doesn't have a problem with four different descriptions because they all elide to the same thing. ie someone who should have more sympathy AND empathy even if they can disambiguate the terms (for their audience.)
Current article title: Authorization terminology is a mess: Let's fix it
That being said, GP mentions OIDC Connect, which is indeed a standard using jargon, just like the IETF uses jargon, and when a standard uses or invents jargon, it makes an effort to define that terminology, and also delineate when it's being used.
If someone believes that standards and specifications are written by pedantic people who are precious about the definitions of words, they may also be likely to fire their attorney during a court case, because that attorney just refuses to use plain English in the courtroom.
nekusar 11 hours ago [-]
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"
andrewshadura 14 hours ago [-]
Unclosable cookie banner. Top notch website engineering.
aleqs 22 minutes ago [-]
I see no banner, but I use an ad blocker configured to reject and hide all such banners, like a sane person.
zero_shift 12 hours ago [-]
Would you like cookies? (No) -> You can revoke consent at any time (Revoke) -> Would you like cookies?
010101010101 11 hours ago [-]
It’s about 20% of the vertical screen space on an iPhone, maddening.
black_knight 15 hours ago [-]
> 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.
simiones 14 hours ago [-]
> 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.
black_knight 13 hours ago [-]
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.
exceptione 2 hours ago [-]
> 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.
Indeed, that strikes me as a fine example of capability inspired design. The mechanism used is passing file descriptors, and for some reason file descriptors is the most "capability based" part of the Linux kernel.
uncommoncense 11 hours ago [-]
What you're describing is essentially what the authorization system would need to do in order to answer the question "can this subject perform this action on this object?". If you're suggesting that the program should receive a list a priori, then there are potential scale issues since that list would need to be exhaustive of both nouns and verbs, which can be a large set.
black_knight 10 hours ago [-]
The point is to flip the burden of proof.
Instead of an authorisation system trying to find a reason to give you permission, you have to carry the proof in the form of a “verb”. Which you use when you perform the action.
uncommoncense 10 hours ago [-]
Right, but where do you get the proof to begin with? Using your OS example, it seems like the OS would need to precompute all of the possible accesses for the file picker? In this case, the OS is an authorization system.
Do you mean that the directory should not be responsible for making this decision and there should be a central authorization authority?
black_knight 10 hours ago [-]
There a sort of “might makes right” principle here. If you can do it, you can mint a capability for it, which means you will perform the action when someone with that capability requests it.
A central authority is not a requirement. What is required is some way making sure capabilities are unforgeable.
This can be a central authority, which then has a completely mechanical task of registering capabilities and their ownership. But it can also be ensured “cryptographically” with a key.
The OS already has a capability system called “file descriptors”. Which works quite well, within its limited scope. This could be expanded out to more areas.
simiones 10 hours ago [-]
The question is - how do you get the ability to write to pathA and to pathB but not to pathC, while another user gets the ability to write to pathA and pathC but not to pathB?
Do you get a huge list of capability keys when you log into the system, one for each path? Do you ask a service for a capability when you want to perform the action?
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).
uncommoncense 11 hours ago [-]
What you're describing is the difference between Fine Grained Authorization (FGA) and traditional Role-based Access Control (RBAC). This article covers the difference: https://www.osohq.com/learn/what-is-fine-grained-authorizati... (disclaimer: I used to work there but continue to be a fan of their documentation).
simiones 11 hours ago [-]
First of all, this necessitates a certain data model, where instead of a "UploadFile(file, destPath)" operation, I have to have a "destPath.UploadFile(file)" operation. This would be ok for this case, but not all operations can be expressed in this simple parent -> child relationship.
Furthermore, even here, this doesn't cover another case: what if I am allowed to add files to destPath, but I'm not allowed to modify a specific file? This API still has to fail if `destPath/file.Name` already exists and I'm not allowed to modify it (or it at least has to do something different than when `destPath/file.Name` doesn't already exist).
And even if we accept that we can only ever write things in this way, this still leaves the problem of terminology intact. Depending on the technology, it's simply not true that I can't "utter this phrase" if I don't have the capability. For example, if this is an HTTP API, then I can always do a `POST /dest-path/upload-file` with the file I want, regardless of whether I have the authorization to access that or not. Sure, if it's a HATEOAS-style API, the `GET /dest-path` might not return a link to `./upload-file` at all, but that doesn't mean that I can't utter that sentence - i.e. issue that HTTP request.
black_knight 10 hours ago [-]
I have designed capability based HTTP APIs before, it took some work but the end result was ergonomic. Of course over the web the capabilities must be secured in some way. I opted for keys to prove that you can perform a given action.
So, “utter” there means make a valid request with a key. On both the client side and the server side the keys and validations were invisible to the business logic, they just carried objects as usual.
You created capabilities by registering a handler for the operation, and got back a token object you could hand out and even send over the api to those who were meant to use them. And the clients got these objects which they could just manipulate and keep around for making API requests.
The cool part was that you could never forget to do an authorisation check. The keys were automatically checked when the request came in. An API request handler would have no privilege itself, it would only call the key-validated handlers created when the capability was minted.
simiones 10 hours ago [-]
Oh, I'm sure it can be done, and what you're describing sounds quite nice.
All I take issue with is the claim that this is a way to make the unauthorized actions "impossible to utter". The reality is that, at least at some level, you always have to evaluate a request and, based on some cryptography related to user identity, decide if you'll honor it or refuse it. That may be checking a cookie to look up the user and then checking a separate place to see if the user is authorized to perform the action (perhaps with an extra step of finding a role, etc), or it can be checking a "pre-approval" signature obtained at some earlier point as you're describing here, but it's ultimately the same concept, and isn't "implicitly handled" in one case anymore than the other.
black_knight 10 hours ago [-]
I would hate to argue over semantics. But in addition to the keys being checked automatically at run time, the type system ensured that, unless the capability had been revoked, illegal requests would not type-check at compile time. Which I think is pretty close to unutterable.
The keys were there to stop an attacker, the type-checker helps the good guys stay in line.
simiones 9 hours ago [-]
> the type system ensured that, unless the capability had been revoked, illegal requests would not type-check at compile time
I don't think I can imagine what you mean here. How would my compilation success depend on whether an Admin has given me the right to read or write to a certain path?
black_knight 9 hours ago [-]
First, I am talking about the capability based HTTP APIs I have worked on here. Not some imagined operating system. I can see if I get around to your question in the other sub thread.
But the point is, you would not grant access to a “path” or some such. You gain access to a collection of actions, described by types. It can be simple “get/set property” or more complicated actions, maybe involving capabilities to several things at once.
To mint such an access token the “admin” will have say how the actions are performed, and then pass the token to you. The client code then will have a typed set of actions it can perform using the token.
This does not mean that we compile in the specific rights of each user or anything, it only means that we must ensure a valid flow of rights in order for the whole program to compile. You can get a capability in two ways: you mint a capability for something you already can do (you are the admin and own the data base, say), or you receive it (via an API call, say).
There is definitely a knack to design the system with this kind of flow. But once in place it feels very natural, you get the right to do something just in time for your need to do it. Very much principle of least privilege taken to an extreme.
williamdclt 14 hours ago [-]
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
black_knight 13 hours ago [-]
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”.
williamdclt 10 hours ago [-]
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
black_knight 2 hours ago [-]
"utter" meaning writing in the code, and "transfer" as in pass between functions/objects/processes/machines.
> 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.
rapnie 11 hours ago [-]
Some nice Object Capability technologies not mentioned in the Wikipedia article:
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!
ptman 11 hours ago [-]
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.
rrr_oh_man 14 hours ago [-]
Care to share some highlights?
simonw 11 hours ago [-]
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.
jcdreads 10 hours ago [-]
Oh man. This gets really exciting when in addition the Finance team has to tell the SEC how many active users there are, but they're using different definitions every quarter because they get their numbers in some non-reproducible way from whichever of those other teams has time to help them this month.
Source: my own years on data warehouse and application development teams.
ithkuil 14 hours ago [-]
And renaming things is hard, if not impossible
bijowo1676 15 hours ago [-]
excellent article, very thorough and nuanced explanation.
Quite literally the first thing that jumped to my mind when I read the title
whazor 11 hours ago [-]
Is the article inventing any new words?
bayindirh 14 hours ago [-]
Another take I like is "The good thing about standards is there are many to choose from!"
andychiare 7 hours ago [-]
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.
zbentley 12 hours ago [-]
“It’s worth being honest about…” yeah, no.
kalayciburak 11 hours ago [-]
[dead]
rimworld 11 hours ago [-]
[dead]
Quarrelsome 14 hours ago [-]
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?
hobofan 14 hours ago [-]
This has already been solved well-enough with AuthN and AuthZ as distinct names.
Quarrelsome 4 hours ago [-]
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?)
rrr_oh_man 14 hours ago [-]
UK is rotating in its decaying royal grave
hobofan 12 hours ago [-]
I'm not opposed to AuthS either! :)
antonvs 10 hours ago [-]
Terrible idea. Looks like a plural of auth.
zobzu 9 hours ago [-]
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"
nicwolff 8 hours ago [-]
ENTIC and ORIZ would make more orthographic sense...
or 4entic5 and 4oriz5, inverting the k8s, i18n pattern...
pronounced "forentics" and "forizes"...
somebody stop me!
rrr_oh_man 14 hours ago [-]
Sign in / Sign up is my go to pet peeve for this type of thing
lozf 12 hours ago [-]
> 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.
sbuttgereit 12 hours ago [-]
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.
antonvs 10 hours ago [-]
One problem is that treating authentication as a "can you enter" authorization is predicated on the idea of a session-based system with two states, logged in or logged out. But there are many scenarios where e.g. taking some particular action requires authn and authz, regardless of login status. A simple example is performing some destructive action.
The distinction between authentication and authorization allows modeling of many different kind of systems, including the degenerate case where identification is treated as a proxy for authorization.
Btw, the kind of thinking behind that degenerate case is what leads to IDOR security bugs - "this person is logged in, so they can access whatever the URL says... even if it's another customer's data!" It turns out that thinking clearly about security helps be more secure, and unfortunately, vice versa.
sbuttgereit 7 hours ago [-]
Right. The de facto/apparent case that many users encounter shouldn't be considered the correct mental model or implementation pattern... it just explains why some people see it that way.
Not long ago I designed an authentication system which had to be disconnected from authorization pretty fully. The authentication was global in a multi-tenanted system, but access to any tenant was authorized at the tenant level (as well as all other authorization concerns). To be fair, there was some global authorization concerns, but the vast majority of authorizing actions, including tenant access was governed at the tenant level after authentication.
antonvs 10 hours ago [-]
You're correct.
andai 14 hours ago [-]
ident and perms
icedchai 10 hours ago [-]
This. It's concise and I don't have to think about "which Auth" we're talking about.
Quarrelsome 4 hours ago [-]
magic, this is the ticket. Two totally different words.
erlich 13 hours ago [-]
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’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”.
What do you mean by this?
"You should drink more water"
"You ought to help your sick mother"
But there is significant overlap.
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 thus does not require substantiation.
And the up-threads gut feel that "ought to" is slightly stronger comes across there, I think: ought to conveys that moral stance, where as "should" is more "there's a decision here, possibly".
[1]: https://www.rfc-editor.org/rfc/rfc6919.html; n.b., this is an April 1st RFC. I like it, though, and it isn't uncommon to see a stray "ought to" lacking a citation in a non-April-1st RFC.
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.
Also fun: yesn’t. Yes, but really no.
> they all elide to the same thing
I see what you did there: https://en.wiktionary.org/wiki/elide#Usage_notes
Current article title: Authorization terminology is a mess: Let's fix it
That being said, GP mentions OIDC Connect, which is indeed a standard using jargon, just like the IETF uses jargon, and when a standard uses or invents jargon, it makes an effort to define that terminology, and also delineate when it's being used.
https://openid.net/specs/openid-connect-core-1_0.html#Termin...
If someone believes that standards and specifications are written by pedantic people who are precious about the definitions of words, they may also be likely to fire their attorney during a court case, because that attorney just refuses to use plain English in the courtroom.
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.
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.
1. https://wiki.archlinux.org/title/XDG_Desktop_Portal
Instead of an authorisation system trying to find a reason to give you permission, you have to carry the proof in the form of a “verb”. Which you use when you perform the action.
Do you mean that the directory should not be responsible for making this decision and there should be a central authorization authority?
A central authority is not a requirement. What is required is some way making sure capabilities are unforgeable.
This can be a central authority, which then has a completely mechanical task of registering capabilities and their ownership. But it can also be ensured “cryptographically” with a key.
The OS already has a capability system called “file descriptors”. Which works quite well, within its limited scope. This could be expanded out to more areas.
Do you get a huge list of capability keys when you log into the system, one for each path? Do you ask a service for a capability when you want to perform the action?
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).
Furthermore, even here, this doesn't cover another case: what if I am allowed to add files to destPath, but I'm not allowed to modify a specific file? This API still has to fail if `destPath/file.Name` already exists and I'm not allowed to modify it (or it at least has to do something different than when `destPath/file.Name` doesn't already exist).
And even if we accept that we can only ever write things in this way, this still leaves the problem of terminology intact. Depending on the technology, it's simply not true that I can't "utter this phrase" if I don't have the capability. For example, if this is an HTTP API, then I can always do a `POST /dest-path/upload-file` with the file I want, regardless of whether I have the authorization to access that or not. Sure, if it's a HATEOAS-style API, the `GET /dest-path` might not return a link to `./upload-file` at all, but that doesn't mean that I can't utter that sentence - i.e. issue that HTTP request.
So, “utter” there means make a valid request with a key. On both the client side and the server side the keys and validations were invisible to the business logic, they just carried objects as usual.
You created capabilities by registering a handler for the operation, and got back a token object you could hand out and even send over the api to those who were meant to use them. And the clients got these objects which they could just manipulate and keep around for making API requests.
The cool part was that you could never forget to do an authorisation check. The keys were automatically checked when the request came in. An API request handler would have no privilege itself, it would only call the key-validated handlers created when the capability was minted.
All I take issue with is the claim that this is a way to make the unauthorized actions "impossible to utter". The reality is that, at least at some level, you always have to evaluate a request and, based on some cryptography related to user identity, decide if you'll honor it or refuse it. That may be checking a cookie to look up the user and then checking a separate place to see if the user is authorized to perform the action (perhaps with an extra step of finding a role, etc), or it can be checking a "pre-approval" signature obtained at some earlier point as you're describing here, but it's ultimately the same concept, and isn't "implicitly handled" in one case anymore than the other.
The keys were there to stop an attacker, the type-checker helps the good guys stay in line.
I don't think I can imagine what you mean here. How would my compilation success depend on whether an Admin has given me the right to read or write to a certain path?
But the point is, you would not grant access to a “path” or some such. You gain access to a collection of actions, described by types. It can be simple “get/set property” or more complicated actions, maybe involving capabilities to several things at once.
To mint such an access token the “admin” will have say how the actions are performed, and then pass the token to you. The client code then will have a typed set of actions it can perform using the token.
This does not mean that we compile in the specific rights of each user or anything, it only means that we must ensure a valid flow of rights in order for the whole program to compile. You can get a capability in two ways: you mint a capability for something you already can do (you are the admin and own the data base, say), or you receive it (via an API call, say).
There is definitely a knack to design the system with this kind of flow. But once in place it feels very natural, you get the right to do something just in time for your need to do it. Very much principle of least privilege taken to an extreme.
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
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.
https://capnproto.org (used by Cloudflare)
https://spritely.institute/goblins (with wasm support via Hoot)
https://ocapn.org (where things come together in a future open standard)
(shameless plug)
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!
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.
Source: my own years on data warehouse and application development teams.
Nice work and all regardless
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?
Never change programming/maths in holding onto terrible naming conventions and making really hard stuff even harder to understand (CQRS anyone?)
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"
or 4entic5 and 4oriz5, inverting the k8s, i18n pattern...
pronounced "forentics" and "forizes"...
somebody stop me!
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.
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.
The distinction between authentication and authorization allows modeling of many different kind of systems, including the degenerate case where identification is treated as a proxy for authorization.
Btw, the kind of thinking behind that degenerate case is what leads to IDOR security bugs - "this person is logged in, so they can access whatever the URL says... even if it's another customer's data!" It turns out that thinking clearly about security helps be more secure, and unfortunately, vice versa.
Not long ago I designed an authentication system which had to be disconnected from authorization pretty fully. The authentication was global in a multi-tenanted system, but access to any tenant was authorized at the tenant level (as well as all other authorization concerns). To be fair, there was some global authorization concerns, but the vast majority of authorizing actions, including tenant access was governed at the tenant level after authentication.
It's funny how a graph underlies absolutely everything but no one seems to use them.