search

solid / authorization-panel

Github repository for the Solid Authorization Panel
MIT License
19 stars 20 forks source link

efficiency requirements #162

Open bblfish opened 3 years ago

bblfish commented 3 years ago

On the Wedn 27 Teleconf I brought up the importance of us keeping track of efficiency in our protocols, that takes into account how HyperApps work. These are very different from normal apps tied to a single server, as they have to open connections by following links to other servers.

We need to have a requirement that allows us to keep in mind efficiency of authorization protocols, favoring more efficient ones. For that I suggest we develop a realistic use case (something @elf-pavlik had suggested doing at some point last year).

Here is a realistic scenario for a hyper AddressBook App which I implemented 6-7 years ago in React. Such an AddressBook used for the first time, should be able to be pointed to a WebID Profile, and from the information there start drawing an initial UI, while at the same time following all the links to the profiles, hosted on other Pods. Here is an image taken from a wiki page on banana-rdf that illustrates the layout of @timbl's profile and its links to other resources.

TimBLs foaf profile

We should count the number of links in his profile (and others) and the number of of connections required to get the content of his "foaf:knows" relations and potentially the number of connections from there on too. The first set of requests will lead to profiles or files linking to various groups. Each of these groups may or not be accessible to the client.

Let us say that TimBL has 150 foaf:knows linking to 100 Pods. Each of the resources on these Pods will return information letting the client know what credentials it can present to authenticate. With HTTP/2.0 the server could send the ACL description and related documents without needing to be asked for it if needed. In order to fill Tim's profile the client will want to download the picture, and a few other resources too, and the same for Tim's friends...

So we can imagine the client opening 1 connection to Tim's profile, then 100 connections in parallel to various servers and requesting 5 resources on each. (Of course future requests can then cache the data locally reducing the traffic). But this seems the right order of magnitude to consider.

csarven commented 3 years ago

Didn't want to duplicate content here about an existing public implementation (dokieli) where this is very much a concern, so linking: https://github.com/solid/authentication-panel/issues/123#issuecomment-768606815

elf-pavlik commented 3 years ago

I commented in https://github.com/solid/authentication-panel/issues/123 Let's close this one and keep conversation in one place.

bblfish commented 3 years ago

These are two different issues. One is about efficiency of authentication, and the other about efficiency of authorization. There are different types of things we need to keep into account in both. In this case here, we may want to add a use case to the UCR, and perhaps add a requirement for it.