Good idea, but how is it supposed to be practical for non-technical users?
and if youre a technical user, how is it not redundant
Authorize, don't authenticate
41–49 of 49 posts
Re: Authorize, don't authenticate
#42This is essentially what Solid is about.
Re: Authorize, don't authenticate
#43I feel like this blends two discrete things 1. Can I have access to my data (the side effects of my interaction with an application) in a portable way? 2. Can I stop or prevent others (like the application author) from having access to my data? I wonder which -- if users had to choose -- they care more about? I think for most uses its #1 unless its very personal data, in which its #2. I love the idea as presented in…
(Author here) Hello there! I agree users may want one or both of these features in their interaction with an application, and that their preferences likely vary depending on the type of data we're considering. The way I'm reading what you're saying, there's some sort of tension or tradeoff between the two features that I don't fully understand. Can you help me understand it a bit better? Thank you!
Well for instance the approach that was demonstrated (as I understood it) seems to necessitate a lot of tradeoffs and maybe concessions in app design to meet the authorize criteria. Is it accurate to say that all data provided to the service is stored and operated on locally? I don't know how I would do something like a scheduled notification with that setup unless that too is locally executed (in which case it's all just an app?).
I was thinking more along the lines of how I want the ability to export my data into something machine readable, and then delete it from the server. This allows for most conveniences and flexibility on the authors part to be available, but still provides the user with control over the data.
I think I just wanted to communicate that on the spectrum between no ownership and what your approach proposes, I'm less of a maximalist.
Thank you for the piece and the reply.
Re: Authorize, don't authenticate
#44We are back to File->Open I guess. We could use native applications instead of web apps while we're at it. Sadly this approach does not work for a lot of (web) apps.
Author here! The solution I'm proposing does not assume the data is local to the user's machine. In the video attached to the blog post, a web application is authorized to access a database hosted by a different service/domain. While the blog post covers collaboration/social data as current limitations, I'm curious what other classes of web apps you think don't work with the proposed approach?
If the database is not local, and there’s no authentication, what stops someone else from accessing it inappropriately?
Re: Authorize, don't authenticate
#45Earlier quoted context omitted.
They didn’t call it a mnemonic. They are suggesting recalling a movie scene to remember AAA. And imo, it’s a great one that I’ll be reusing to help others remember! I have to remind folks of the difference frequently at work.
https://en.wiktionary.org/wiki/mnemonic Especially of a series of ideas, letters, words, etc.: intended to help in remembering. https://montypython.fandom.com/wiki/Bridge_of_Death
TIL!
So they have it covered then in their final sentence?
Re: Authorize, don't authenticate
#46(c.f. other comments about confusing misuse of security terminology) An easy way to remember the difference between the As in AAA: Who is your daddy, and what does he do? ^ authentication ^ authorisation And the all too often forgotten final A is accounting, for which you can imagine Arnold writing down the interaction in his police notepad. :-)
ah, the tragic truth of there being no daddy at all alive. alice bawled.
Re: Authorize, don't authenticate
#47(c.f. other comments about confusing misuse of security terminology) An easy way to remember the difference between the As in AAA: Who is your daddy, and what does he do? ^ authentication ^ authorisation And the all too often forgotten final A is accounting, for which you can imagine Arnold writing down the interaction in his police notepad. :-)
ah, the tragic truth of there being no daddy at all alive. alice bawled.
[dead]
Re: Authorize, don't authenticate
#48(c.f. other comments about confusing misuse of security terminology) An easy way to remember the difference between the As in AAA: Who is your daddy, and what does he do? ^ authentication ^ authorisation And the all too often forgotten final A is accounting, for which you can imagine Arnold writing down the interaction in his police notepad. :-)
Simplified: Who are you and what do you want?
authenticate: who are you?
authorize: what do you want?
account/audit: what did you do?
Re: Authorize, don't authenticate
#49(c.f. other comments about confusing misuse of security terminology) An easy way to remember the difference between the As in AAA: Who is your daddy, and what does he do? ^ authentication ^ authorisation And the all too often forgotten final A is accounting, for which you can imagine Arnold writing down the interaction in his police notepad. :-)
The English isn't that hard to remember though. Authentication == determine whether it is authentic (you are who you say you are). Authorization == are you authorized to do something (I know who you are but you are not authorized to do something). I hope the average reading level hasn't fallen to the point where that is confusing.