I could ready #1 immediately and thought "hey, I can actually read faux-cyrillic a lot better that I thought" and then I realized that you used a semi-proper transliteration.
I doubt that it is like an object store. I think that it is built around the notion of multidimensional array (matrix) by focusing on data science tools. Yet, they use the term "table" which is somewhat confusing because there are significant differences between tables and arrays. Maybe they use (sparse) arrays at physical level and then support other data models at the level of operations. For me it is not clear.
Probably this introduction is good for some purposes but for me it is too informal and too far from (my) reality. I would say it is 90% identical to many other introductions to OAuth.
I have been trying to comprehend and formulate the main idea behind the usage of this technology, for example, as follows:
OAuth allows us to use surrogates (like JWT) instead of the original credentials (like name and password) with the main benefits that once it is available, the original credentials are not needed anymore: neither by the client nor by the server
Why it is the central idea? Because we do not consider where and how the tokens are obtained: you can get it by USB stick or maybe forge somehow artificially. It is important only that access to resources requires a special piece of data rather than (traditional) credentials. The main question for the client is whether the server will accept this token or not. For the server, the main question is whether it can trust this client and its tokens.We aslo abstract from what is inside this token and how the server decides what to do - these are considered details.
Hello, author here. First off, thank you for taking the time to read this.
The original draft started out much more technical than this version, but it was simplified to read less like a whitepaper. In the original draft, I discussed the Authorization Code Grant with the PKCE extension, which is for public clients (clients that cannot be trusted):
"The barebones authorization code grant is used for server-side applications, where confidential clients are trusted with a secret. By using the PKCE (Proof Key for Code Exchange) extension, this same flow can be used with public clients like browsers or mobile applications. The only modification to this flow is cryptography.
1. Client generates a random string of length 43-128 characters and turns it into a URL-safe 256 hash. Other hashing methods can be used
2. Client directs the resource owner to sign into the authorization server. The hashed string is included as a parameter in the query
3. Resource owner signs in and approves client, then redirects back
4. Client makes an HTTPS POST request for a token. Included is the unhashed randomly generated string
5. Authorization server hashes this string with the same hashing method (SHA256) and compares its calculated hash to the hash received in step 2. If the hashes match, and access token is issued
The trick here is knowing that the odds of two hashes with different inputs being the same are infinitesimally small and can be ignored. If even one character is different in the input, the outputted hash will be entirely different. By sending the hash in step 2 and then the original input string in step 4, the authorization server can verify it is still communicating with the authorized client by comparing what it received to what it produced. Any fraudulent client would have no way of knowing what the input string is."
Applications must not be given passwords. Consider that there are hundreds of applications/api/reports in a company, managed by hundreds of developers in different departments.
Passwords would be leaked all over the place (verbose logging, debugging to investigate issues, etc...). That's totally compromising employees/users, as passwords are rarely changed and reused for personal accounts.
The mechanism of refresh token is also important.
You can have a token with a short lifetime, so if someone stole this token, he won't have an infinite access to your data.
Of course, this would also be possible with credentials, but you would have to store them (risky) or ask them to the user every 20 minutes (annoying).
Something I’ve never really got about refresh tokens is how they improve that situation - I have difficulty seeing a situation where the access token can be compromised but the refresh token can’t, and with a refresh token you’re free to request new access tokens indefinitely.
I think it's more like when you use the refresh token, there's a surface area of attack - lets say it's a login server. If the login server is the only one to ever get refresh tokens, then that's the only surface area where refresh tokens can be breached, audited, etc.
Every other API gets a short lived access token. While that also needs to be secure, the vulnerabilities of that become different. Eg if your logs printed your access tokens, and after 30 days you moved them to S3, no one could read the S3 logs and log into your service. Probably a terribly insecure example but i think it illustrates the different vectors to be concerned about. Refresh tokens vs Access tokens just have different surface areas to be concerned about.
Thanks, that makes a lot of sense - I was thinking in terms of the ultimate client application being compromised, which isn't helped by refresh tokens, but hadn't considered that services along the way don't ever see those tokens.
In a complex application I'd rather send a very short lived and tightly scoped token to a service written by another team or another company that I know less about.
If the service handling your access token has some security issues (old version of x y z, etc) there is limited damage if nefarious actors acquire that token. They could not keep your session alive, spread horizontally, etc. Also, you can make access tokens very short lived to minimize the window of opportunity, should someone acquire one.
Then I can concentrate on my "session service" (the thing issuing tokens) to be very secure, and tune the characteristics of either token as needed.
It was a separate data processing engine within Excel developed by another team (SQL server) for the purposes of self service BI (Power Pivot/Query). Most probably, this engine is not used for normal (traditional) calculations.
You mean if you create the pivot table from data in a sheet? It's not needed for that because you'll run out of memory trying to fit any more than about a couple million rows in a sheet first. Meanwhile you can easily load 10s and possibly 100s of millions of rows into Power Query.
> A time-varying relation is just what it says: a relation that changes over time ... Critically, the full suite of existing SQL operators remain valid on time-varying relations
Any relation by definition is supposed to change in time. So why do we need to introduce a special kind of relations? The authors essentially confirm that there is no difference between classical relations and "time-varying" relations.
Also, it is not clear how does it relate to EPL (in CEP) which is also based on SQL.
According to relational theory, relations are immutable sets of tuples. The way you “change” a relation is by assigning a new relation to the name, e.g.:
R1 <- R1 union R2
Is the relational algebra way of “inserting” R2 into R1. Of course, most RDBMS’s (and the SQL family of languages) are only reasonably faithful implementations of relational theory under some practical constraints.
But those differences re important, and I think the authors are proposing a new relational model (though I don’t think this is a totally new idea; I’m not a database researcher). One that incorporates time and history of a relation as first-class citizens of the theory, that allows sql to operate natively on both traditional relational-theoretic relations and streams of data. Pretty cool! Can anyone who knows more than me comment on how this relates to Kafka tables, which seems to me a similar concept?
Relations in most systems don’t implicitly store the time a change occurred or the past versions of a row, nor do they have a model for building a “now table” from an “event table”. When people talk about time-varying tables or temporal tables, they are describing event sourcing in a SQL context.
> The heavier the ball, the quicker it falls. But if it’s too heavy, it can get stuck or overshoot the target.
This explanation of momentum is somewhere between misleading and wrong. Momentum is about inertia and acceleration, i.e., the ability to quickly change speed.
A misleading experiment: the heavier the feather the quicker it falls is obviously true; steel feathers are useless. The same is true for balls (except for the exceptional situation of a perfect vacuum), it's just that drag and air currents don't influence balls all that much at low speeds.
2) αcτµαlly pδrταblε εxεcµταblε
What is easier to comprehend?