Security/provenance issue with Extended Profile

[RubenVerborgh]

The spec draft currently states:

The combination of the main WebID Profile document, and all of the related profile documents is referred to as the Extended Profile.

Solid apps that interact anonymously with the WebID profile MUST also load and parse all of the related public RDF resources that are linked to from the main profile using any the following triples in the main profile document:

    $webid http://www.w3.org/2002/07/owl#sameAs ?public
    $webid http://www.w3.org/2000/01/rdf-schema#seeAlso ?public

Solid apps that interact as the user in question, logged in with their credentials, with their own WebID profile MUST also load and parse all of the related public resources above and also will normally load the user's preferences file.

This is problematic, because people often link to old WebIDs, which they might not control anymore. So mandating that these triples MUST be loaded is troublesome. Especially for seeAlso, to which no semantics are attached.

[csarven]

Any resource that a profile links to is subject being an issue for a consumer. Applications should take that as a given, and I think to some extent they do re AAA any way.

A safer perspective may be to let applications simply decide for themselves what they do with data they encounter.

Agreement can happen on one layer higher depending on use case and the data models or other protocols involved.

[JordanShurmer]

Since the users control their own links to other profiles I'm not sure this is really a big deal. The databrowser (or whatever experience users end up with to manage their profiles) must have a very easy/clear way to manage these links though, in case one of their other profiles does go down or is compromised somehow.

I suppose the fact that the spec says apps MUST access them is what makes this a bigger issue than any other link in the user's profile though.

[RubenVerborgh]

I suppose the fact that the spec says apps MUST access them is what makes this a bigger issue than any other link in the user's profile though.

Exactly, that is the big deal here. rdfs:seeAlso MUST NOT mean any kind of trust or endorsement. Also, owl:sameAs SHOULD NOT imply that all triples in the other documents are to be treated on an equal level.

Apart from that, the notion of "main" profile is flawed, but that's something else.

[bblfish]

What is needed is a general logic of how one merges linked data information. I have been working on this as part of my PhD on co-operating.systems (another angle on Solid) at the University of Southampton in Web Science, Cyber Security and Intelligent Agents groups. The second year report which details this was accepted just a few weeks ago. Perhaps there is a way to turn that into an Open Phd, so that what I am working on can be useful before I finish, as that risks being delayed because I am have used up all my own savings on this research (the UK did not pay my research because I did not live in the country for the required 3 preceeding years, and we got #Brexit too). I am not sure what the rules for sharing pre PhD documents are.

My first task was to find the logics that are relevant to this question. The remaining task to come was to build up a set of use cases and see how these could applied to linked data reasoning on the web.
For access control it is especially important for the reasoning to be clearly defined and to rest on clear logical/mathematical principles, since we want the client to be able to predict before submitting a credential if it will be accepted.

The logic to consider here is the work that started in 1991 by Abadi, Burrows et al [1], which turns out to be a modal logic. The tricky thing here is that some semantic web founders state that there is no modal logic in RDF. But there need not be, we can add it as an orthogonal dimension. According to Robert Brandom, in "Making it Explicit" [2] and later work, Brandom argues that modal logic is an explicitation of what is already present in first order logic. Another way to look at it is to see that the semweb is logic+document acts, where document acts are the equivalent of speech acts in everyday language as made famous by Austin and developed by Searle. Speech acts are formalised by Abadi in the "S says P" relation. 17 years later he shows that this is an Indexed Strong Monad [3] - indexed on the subject - which can then be placed in a lattice to allow trust reasoning.

More practically, Tim says ... is one monad Henry says ... is another, and these can be related or not depending on the lattice of trust between Tim and Henry. These Monads are the same as we have in functional programming, where we can have an operation pure that places an object in a monad eg List.pure(2) == List(2) and an operation of flattening that takes a doubled structure such as a list of lists and turns it into a list. So that if we have Tim says Tim says { <#i> foaf:name "Tim"} then we can flatten that to Tim says { <#i> foaf:name "Tim"}. On the other hand the monad does not allow us to flatten Tim says Pirat says { <#i> cert:key <key> } to Tim says { <#i> cert:key <key> } unless there is a relation of trust between Tim and Pirat.

That gives us some idea as to when we can clearly in access control situations flatten things. It should be quite easy for programmers more and more of which are now exposed to Functional Programming to understand. Developing this could allow us even to extend access control to incorporate descriptions of group using OWL, though that would need a lot more thinking through, and especially would require us to have what I think of as streaming OWL reasoners - ones that can give us partial results so we can draw our UI before we have the full information. (cwm does a bit of that, by counting iterations).

By the way this monadic/modal way of looking at the problem also allows us to reason withing the brackets (using RDF inferencing or OWL) since a monad is an applicative, ie a structure which comes with the following function
F(A->B)->F(A)->F(B)
which in logic via curry-howard tells us that we can reason within a context. (Here F could be the Tim says... context) Curry howard maps functions to logical if...then so if we know that within Tim's context we have an if clause we can conclude consequences withing his context. unit allows us to introduce logical rules into any context that allow us to reason in that context with them.

[1] "A calculus for access control in distributed systems."
Annual International Cryptology Conference. Springer, Berlin,
Heidelberg, 1991. (pdf)
(Note Mike Burrows was the author of the AltaVista search engine)
[2] Brandom, Robert.
Making it explicit: Reasoning, representing, and discursive commitment.
Harvard university press, 1998.
[3] Abadi, Martín.
"Access control in a core calculus of dependency." Electronic Notes in Theoretical Computer Science 172 (2007): 5-31. (pdf)