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.
Updated 4 months ago