Skip to content

Latest commit

 

History

History
78 lines (49 loc) · 9.35 KB

M5.md

File metadata and controls

78 lines (49 loc) · 9.35 KB
Raw

Milestone 5

summary of activity from 21/09/2021 to 29/10/2021 and activities from the beginning of the project relating to M5

Index

ACP reasoning

  1. Summary of Activities
  2. ACP
    1. Work with authorization group
    2. Develop Theory
    3. find tools and try implementation

1. Summary of 21/09/2021 to 29/10/2021

This month has been taken up mostly in adapting Tim Berners Lee's rdflib.js to banana-rdf in continuation of Milestone 6: banana-rdf and in order to get to Milestone 7 to write the Client Auth library. See the commits for scala-3 branch of banana-rdf.

The initial attempt to build a simple scala-js facade did not work because JS does not have a standard equals function that Scala inherits from Java. So that would not have allowed one to use the rdflib code with Scala collection libraries for example.

Instead I had to re-implement the RDF/JS Data Model Specification in Scala as rdf.scala.js and rewrite some functions used by the Indexed Store Module and inject those changes into rdflib.js. This makes it possible now to use a lot of the knowledge accumulated in rdflib over the past 15 years, and improve pieces as needed.

Having a Store I needed to add that functionality for Jena and Sesame too (in M6 I had ported the Graph to Scala3). Finding the right abstraction for higher level concepts such as stores is quite tricky.

Also: on request I made a release of banana-rdf 0.8.6.

2. ACP

1. Work with Authorization Group

The work on improving Web Access Control to a more attribute based access control has been going on all year. But it turns out that the work I was doing for my PhD was quite a lot more ambitious than what the community is able to integrate at the moment.

There is clearly a desire by some in the community to move further along from what the established Web Access Control spec (now published as Technical Report) allows, as the newly published ACP draft spec published by the Inrupt team at the end of October shows. Note that even though that spec has been published, it has not been the product of a discussion process in the group.

We have over the past 4 months started a process of comparing WAC and ACP by looking at the Use Cases published at the beginning of the year. We have an evaluation directory with 2 well developed cases, which has been very helpful in allowing detailed protocol level comparisons to start taking place. But as the results of such comparison don't always give the results desired, enthusiasm for comparison has cooled off and instead of continuing with the project, we have found the meetings getting interrupted with completely different projects ideas.

My aim has been to argue to evolve WAC by adding new features one at a time, rather than the full blown rewrite that the Inrupt group wants to do. This is in line with other Web standards such as HTTP or HTML that both evolved over the years by adding new headers or html tags. Furthermore I believe that the reasons given initially for the ACP team wanting to rewrite WAC from scratch have more to do with misunderstandings of what WAC can do when enhanced a bit with OWL reasoning than with any real limitations of the ontology. I think the meeting on 28-04-2021 helped show very clearly how each of the features deemed to be only possible with ACP could also be done by extending WAC. Another example is the UC-3 inheritance use case.

Having two access control systems for Solid is of course silly. But there does not seem to be wilingness to find a compromise solution between both groups at present. Indeed recently I found the simplest possible proposal that would allow both to fix an important efficiency problem and start a process of coming together, but so far even that is proving difficult.

Both suffer from some basic HTTP level efficiency problems to do with default rules. Having default rules cover whole HTTP subtrees has the advantage that very large number of resources could have one same resource specify the access rules, allowing documents to be cached and so requiring minimal HTTP requests for multiple resources. But

  • ACP decided it must copy default rules to a specific ACR for every resource, duplicating rules everywhere, and forcing requests. This reveals a misunderstanding of HTTP caching architecture, and can come from overexposure to OO programming.
  • WAC uses defaults, but for some reason has (recently?) chosen a completely broken discovery mechanims which requires 2n+1 requests to discover the active resource.

I proposed this month a very simple solution which would be to just specify one link to the active rule set in specification issue 324 and specification issue 325. This would immediately fix WAC's problem. And it could allow ACP to realise that requiring an Access Control resource for every resource is unecessary and counterproductive. The pushback is really quite surprising and may explain why there are two groups that don't communicate.

I brought this up at last week's W3C Technical Plenary Solid meeting.

This work does show I believe that WAC extended with OWL can cover most use cases. Perhaps not all though. It looks like giving rights to the creator of a resource requires dependent types or rules. It is not clear to me yet that the proposed ACP answer is not just wishful thinking.

2. Develop Theory

The problems of HTTP efficiency show that having a theory that could cover the web server piece would be already very helpful. It could also help resolve problems such as which modes are required as per issue 253 authz panel. I have been looking at modeling a web server with the FP concept of Lenses and written it up in web-cats issue 28. I think that needs to be extended to take into account that web servers act as providing codata (see Agda lecture by Connor McBride) not data . I have been discussing this on the Category Theory Zulip Chat Security channel archives here.

The other part of the theory that needs developing is how to integrate OWL with reasoning on the web to gain the full generality of access control. As Tim Berners-Lee pointed out at the end ofTPAC Solid meeting it would help to have a way of sending proofs to the server.

3. Find tools and try implementation

I tested the Lenses idea with some simple Scala code (as per web-cats issue 28), but to be able to understand the implications of codata I would need to use something like Agda.

For the moment anything involving reasoning is not something that can be brought up easily in the Authorization Group for lack of expertise there (e.g it soon requires simple OWL concepts to be explained here.) So this really needs to be done by the PhD level which will be able to build on the basic server being developed in this project. My aim will be to cover WAC well. For client side reasoning it would also need integration of reasoning into the JS side of banana-rdf.

Meetings

  • 2021-09-22 Discussion of Access Modes
  • 2021-09-29 Tim Berners Lee came to WAC Panel and a group presented Open Digital Rights Language (ODRL)
  • 2021-10-06 discussion on Auxiliary resources
  • 2021-10-13 discussion
    • problems with meeting processes being changed without group approval, leading to misunderstandings of what was happening
    • Inefficiency problems of WAC and ACP discussed at length above
  • 2021-10-27 TPAC meeting of Solid community with Tim Berners-Lee