Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Authorization terminology is a mess: Let's fix it

idpro.org

Post reply on HN
Print view View original

41–50 of 91 posts

Re: Authorization terminology is a mess: Let's fix it

#41

Post by uncommoncense »

black_knight wrote: post #24
simiones wrote: post #12

Earlier 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…

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.

Re: Authorization terminology is a mess: Let's fix it

#44

Post by uncommoncense »

nmadden wrote: post #26
black_knight wrote: post #24

Earlier 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…

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).

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).

Re: Authorization terminology is a mess: Let's fix it

#45

Post by simiones »

black_knight wrote: post #24
simiones wrote: post #12

Earlier 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…

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.

Re: Authorization terminology is a mess: Let's fix it

#46

Post by rzzzt »

throwaway1058 wrote: post #22
theasisa wrote: post #18

Earlier 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"

That's when you turn to the RFC2119 all-caps requirement levels!

Re: Authorization terminology is a mess: Let's fix it

#47

Post by ptman »

andai wrote: post #10
tuberreact wrote: post #2

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.

Re: Authorization terminology is a mess: Let's fix it

#48

Post by hilariously »

happytoexplain wrote: post #33
perching_aix wrote: post #27

Earlier quoted context omitted.

Not sure what's giving you a pause there?

It's going over my head, too. I don't understand what the implication of the sentence is in context.

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.)

Re: Authorization terminology is a mess: Let's fix it

#49

Post by ButlerianJihad »

hilariously wrote: post #48
happytoexplain wrote: post #33

Earlier quoted context omitted.

It's going over my head, too. I don't understand what the implication of the sentence is in context.

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.)

> Someone who is incredibly pedantic

> 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.

Re: Authorization terminology is a mess: Let's fix it

#50

Post by black_knight »

uncommoncense wrote: post #41
black_knight wrote: post #24

Earlier 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…

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.

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.

Post reply on HN