Summary of activity from 22/02/2021 to 1/04/2021
- Basic LDP implementation (and review of Solid-Spec)
- Simple Auth using IETF Signing HTTP Messages (and link to implementation work and issues)
- Review and contribute to Attribute Based Access Control
- Other
The Reactive-Solid Server now has a basic LDP implementation with the ability to
- GET resources and containers
- Create content (with POST) and containers, avoiding name clashes for new resources
- DELETE content
as shown by the simple test suite. Content can be created and served for around 180 mime types plus the following RDF Media Types.
The server is built on a fully asynchronous architecture (as described in previous report), with minimal memory requirements: e.g. containers don't need a listing of the filesystem before serving a resource, but can find it by fetching metdata for the requested reoource directly from the file system. Taking this serious led to the StackOverflow Question: How to get Streams of File Attributes from the FileSystem?.
Todo (but see issue database for full list):
- Content Negotiation on resources - needed for images and serving RDF
- DELETE on container
- More work on LDP protocol details such as setting the correct headers to inform of available methods to use, ...
- Content negotiation of RDF using banana-rdf
- At some point "garbage collection" of unused actors would help reduce the memory footprint
The above has lead a couple of feedbacks to the solid specifications
But mostly this is still LDP based.
The proposal for using Signing HTTP Messages for authentication was accepted as a proposal by the authentication panel: HttpSig Authentication for SoLiD.
A first version was implemented in Reactive-SoLiD in HttpSig.scala, using an older version of the Signing HTTP Messages spec, as it was easier to start with existing Java libraries implementing those.
This led to the question on what ontology should be used by the KeyID document, and after research we found that the w3id.org security vocabulary by the Credentials Community Group was a good choice. (Though the right choice of JSON-LD 1.1 Java parser is important.) Example test code is available in JWKExtractorFn.
These findings will make their way into the next release of the spec.
One important aspect of the Authorization framework is that it should allow a client to view the Access Control Rules associated with a resource.
- Solid by default only makes resource visible to the resource controller. This led to PR 250: reading of ACL resource should be reduced to requiring client to have Read rights. Another more drastic PR was accepted with the effect of removing that restriction.
- This would make it possible to have ACLs on ACLs for WAC, allowing clients to determine what credentials to present
- I proposed a simple extension of WAC to Allow policies to be reused, going in the direction of ACP.
- we have now a document to compare various proposals against the use cases
- Full list of software dependencies can be found in Dependencies.scala
- We had a couple of video conferences with the Credentials Community Group to present our work.
- CCG presented their Work
- Solid Community presentation with opening by Tim Berners-Lee
- Reopened WebID spec work on W3C Github
- A did:solid spec proposal has been opened to which I sent a first comment
- Weekly Meeting notes:
- Authentication panel for CG meeting, 2021-02-22, 2021-03-01, 2021-03-15, 2021-03-22
- Authorization panel 2021-02-17, 2021-02-24, 2021-03-03, 2021-03-17, 2021-03-24
To quickly get a good understanding of the Work by the Credentials group I suggest theSelf-Sovereign Identity book published by Manning.