use.id and Solid

Solid is a W3C draft specification that was invented by Tim Berners-Lee et al. in 2016. Since then, the specification has been incubated in a W3C Community Group and has been implemented by several companies like Janeiro Digital, Inrupt, Athumi and use.id.

However, during its incubation in the W3C Community Group, the requirements of the implementors were mostly neglected.

Yet, these requirements were actually very important for the implementor's customers (i.e. other companies) to actually adopt Solid. As a result, each implementor has developed their own dialect of Solid to meet the requirements of their customers.

Luckily, this sounds worse than it actually is. Indeed, after a thorough analysis, each company observed the exact same requirements, implemented the exact same concepts and is now intensively working together to align all solutions.

Sadly, the Solid implementation of each of the implementors bears significant differences with that of the pure specification that was incubated by the W3C Community Group.

Similarities between implementors and difference with pure Solid

Please find below a list of requirements and whether or not the Solid dialect can meet that requirement.

Requirement	Pure Solid	Janeiro Digital Dialect (aka Interop Spec)	Inrupt/Athumi Dialect	use.id Dialect
Discovery of data using subject/type	No, based on data location	Yes	Yes	Yes
Asking a user access to data	Not specified	Yes, based on type and subject	Yes, based on type and subject	Yes, based on type and subject
Access control rules applied to subject/type or individual resources	No	Yes	Yes	Yes
Apps can only access data you have granted access to	No. Apps use token impersonation. Any app can access any of your data.	Yes. Apps authenticate using redirect URI or client credentials.	Yes. Apps authenticate using redirect URI or client credentials.	Yes. Apps authenticate using redirect URI or client credentials.

Differences between implementors and our pledge for compatibility

There are indeed a few differences between the Solid dialects of the implementors. However, these differences are all in the form of syntactical discrepancies.

Yet, all implementors operate according the same paradigm and concepts and are currently working hard to resolve these syntactical differences.

use.id pledges to ensure compatibility with its current and future implementation if required.

Conclusion

Solid in its pure form is not able to fulfil the requirements specified above without workarounds or conventions. However, when adding workarounds or conventions, you will, in fact, create yet another new dialect. As such, it makes more sense to simply follow one of the implementors' dialects. Especially because most of the implementors ensure backwards compatibility.