Solid: Go with the flow
I’ve written a few blogs about Solid already (read here how to set up a pod or how linked data works). However, I haven’t touched down on a really important part, namely user experience and flows.
Because after all, you can have the best technology available, but if nobody wants to use it because it’s too difficult, well… That’s a recipe for disaster.
Current situation
So, how do flows work today? Let’s take, for example, a webshop. Usually, there are two options when it comes to actually buying your stuff online. You can choose to create an account and move forward, or you don’t create one and continue as a guest.
One-off
Without an account, you scroll through the website while adding products to your basket. Eventually, when you feel like you’re satisfied with your soon-to-be-purchases, you check your shopping basket and confirm. As a last step, you have to provide shipping and payment data, so you can actually enjoy your purchases. You can automate the last step by using a browser or password manager, but you still need to do this every time.
Let us make it easier for you!
With an account, this process is simplified. This way, you only have to provide your data one time per website. If you want to change anything over time, these websites usually have in-built data managers where you can change your preferences. For this website. Only for this particular website…
If you happen to forget to change the prime delivery address on a website you used to frequent a lot, after you move, you totally don’t have to convince the new inhabitants to hand over the package you’ve been waiting more than 2 months for… (not talking from personal experience here — cough, cough).
Let this other company make it easier for you!
These days you can even use the login of a third party to grant access to a lot of websites. Talk about simplifying everything! You don’t need to remember all these passwords when you can just use your Facebook, Google, …. account to log in. Often, you can do this with just one click. The only downside to this, is that the third party now knows about everything you do on that website. But hey, it’s Google or Facebook and they already know everything… Right?
Divide and conquer?
In my opinion, this current situation has a few drawbacks.
First of all, your data is all over the internet. This can be regarded as a good thing though. For instance, I don’t think a clothing shop must know your online streaming history… But if you don’t register, you have to enter all your things again and again.
But what if you log in with a third-party account? Then they have all the data in one place? That’s surely true, but the data is owned by the third party and who knows what they’re doing with it. As you know, one of the biggest lies of modern times: I have read and agree to these terms and conditions…
Secondly, if you want to alter your home address, for instance, you have to change this for every single site that needs this information.
Let’s take back your data, with Solid!
If you’ve read my previous blogs, you know that the whole idea about Solid is that you take back control of your own data.
WebId, revisited
So, your WebId, “the only login you will ever need”, is actually the link to your profile page. Everything on there is public information. However, the resources linked to your profile do not have to be public.
At the moment, Solid uses Access Control Lists (or Access Control Protocol on the enterprise server). This is a separate file holding triple statements, as usual in Solid, but these pertain to who has which mode of access.
By default, you have to grant one or more of the access-modes (read, write, append or control), otherwise the access is denied. You can grant access to agents (other webIDs), groups of agents, applications (based on the HTTP origin header), authenticated agents (users who have logged in), or make it public.
The current flow
Say, I want to use an application that needs my home address. Usually, you state this on your profile page which is publicly accessible. But what if you don’t want this to be public and you’ve put a link to a resource file holding your address?
Itsa me, the WebID!
The first option the developer of the app can opt for is that the user has to log in. After all, one of the tenets of Solid is that an application is but a view of the data. There’s a big but though. By logging in, you grant this app access to everything you have access to. To me, this raises some concerns.
I like where you come from!
Of course, when you log in on a web-application for the first time, you get a pop-up asking if you want to give access to this app and which access-mode you want to grant.
So in theory, you could indicate you trust the website without setting an access-mode, and then give the app the correct modes per resource.
However, you have to log-in and change it manually on your pod. This is not very user-friendly since you actually have to drag the URL from another browser window to the wanted mode.
But only if you send your origin!
The biggest drawback of the current implementation is that the identification for a trusted application is based on the HTTP location header. This is a forbidden header, which means you cannot adapt it. This is why they chose this header, but when you try to create a mobile app, it causes trouble.
You see, you can’t predict the port/domain combination your app uses, which makes this feature unusable on mobile. You could whitelist an API service, but then everyone using that service would have access the same access. What’s more, to do so, you have to figure out where to configure it. And since the current pod interface is not very intuitive…
Improving Solid
So, from a mobile perspective, you either give full access by login or they can only access the publicly available data. In a world where most people access the internet via apps on their mobile devices, this simply won’t do.
Client identifiers
The developers of Solid have also noticed this issue and are working on a new specification. The idea is that the application is identified with a WebId instead of by a http header. When you grant the application control (or another access-mode) a token is created with a combination of the applications WebId and the access-mode. This would mean that the user would only have to grant access one time to specific parts of their data.
Do I trust you?
Then the only problem that remains is how can you be sure the WebId utilized by this application is the correct one. This could theoretically be solved by an independent third party that holds a registry of application WebIds and their uses.
So how should it flow
When you use an application for the first time, it should ask for authorization to use your pod. Ideally, it should also ask which parts of the data it can use.
Here, the issue is how to group/find the relevant data. You could say, I group my mobility data on a mobility page or my financial data on a financial page. But will everyone use the same scheme?
Your application can enforce a certain way of working, but then the possibility of redundant data resurfaces… If you grant access to all your data.
But say, there’s a way to standardize or otherwise find your data. Then the user gives access to that part of the pod that holds the relevant data. If that part of the data does not exist, the app asks the user. Ideally, a token would then be exchanged based on the app fingerprint and the accesses granted. On a second connection, when this is checked with the server entries, the identity of the app could be ensured and the relevant data is made available.
Things are moving!
As to be expected with new technology, there are still some kinks to be worked out, but that’s also the case with existing tech. The Solid developers are highly motivated to get Solid working and are very open to suggestions! Although they are not quite there yet, I can see Web 3.0 replacing the current state of affairs with improved user-friendliness every step of the way.
