W3C home > Mailing lists > Public > public-rdf-in-xhtml-tf@w3.org > February 2009

RDFa Security and Persistence (was: Re: RDFa Use Cases)

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Wed, 18 Feb 2009 21:43:06 -0500
Message-ID: <499CC73A.2030903@digitalbazaar.com>
To: Ian Hickson <ian@hixie.ch>
CC: RDFa mailing list <public-rdf-in-xhtml-tf@w3.org>
Ian Hickson wrote:
>>> My understanding was that people wanted RDF data to be persisted 
>>> across multiple sessions, which would lead to bad data "poisoning the 
>>> well" in a way that no other feature in Web browsers has yet had to 
>>> deal with.
>> Some people do, some don't. I think we should assume that the RDF triple 
>> store may be more akin to the browser cache (can be cleared on a whim) 
>> than to a traditional database (clearing the data is bad).
> If we allow any persistence without some solution to the trust/spam 
> problem, the store will quickly become useless (in the same way that the 
> various features to open a new window quickly became useless once sites 
> found ways to use them for doing popup ads).

I agree with you that we will need to find solutions to the trust/spam
problem, not only for RDFa, but for the general Web as well. There are
some ideas bouncing around, but we need to put them on the wiki. I have
started a page for this purpose:


The two examples that are up there have obvious flaws, but are meant to
be a starting point for the security/persistence conversation. Everyone
should feel free to rip those examples apart and improve upon them.

> This is one example of what I meant by having to evaluate each use case, 
> by the way. If we decide that "RDFa" means "a per-tab triple store with a 
> lifetime equal to the page and that is not affected by cross-origin 
> iframes", then that wouldn't address the "collect lots of data and then 
> query it" use case, despite still being "RDFa". 

I think it's going to be very difficult to find agreement on what RDFa
is and isn't at the application layer.

> It is IMHO important for 
> the RDFa community to agree on exactly which uses cases are the ones that 
> are intended to be addressed, so that we can make sure that what we come 
> up with actually does address exactly those cases. 

The list of use cases being non-exhaustive and constantly evolving, of

> Is there documentation 
> anywhere on what the existing RDFa specification is attempting to solve 
> along these lines?

The current version of RDFa is based on the scenarios defined in this


> e.g. what is the storage semantic for the current RDFa 
> specification? 

Right now, the how and when to do persistence and trust is left to the
language and application that utilizes RDFa.


> Does it have persistence? 

The current RDFa spec doesn't mention anything about a persistence layer:


> How does it deal with cross-origin data load?

The current RDFa spec does not address cross-origin data load:


> If we're just partitioning data stores on a per-origin basis, then there's 
> no need for signatures, even, we can just use the existing origin data. 
> The question is whether that is enough.

No, we would still want signatures even if we were partitioning data
stores. For example, if you wanted to verify a digital contract or
digital statement of work of any kind, per-origin verification isn't
good enough.

> (This still doesn't address the problem of sites like wikipedia or blogs 
> that accept input from multiple users, though.)

This is a stab at addressing that issue:


> There needs to be some mechanism for determining what's in the white 
> lists. 

Could you elaborate, please? Do you mean the format of the white lists?
Or the type of data the white lists store? Something else?

> (Black lists wouldn't work since an attacker could just come up 
> with an infinite number of alternative site names.)

Noted, correction has been made to (removed mention of blacklists):


> I don't really understand how the digital signature mechanism would work.

Does this help at all?


> In SSL, the user selects a single site, and the browser can verify that 
> that site is who the user thinks it is. 

In general, yes - but there are known attacks against this security
model (MITM, plug-in-based trusted certificate poisoning,
DNS/certificate hijacking), so it's not perfect.

> It doesn't prevent hostile sites 
> that the user intended to go to from interacting with the user. How would 
> digital signatures help here? Attackers can sign stuff just like anyone 
> else can, no?


-- manu

Manu Sporny
President/CEO - Digital Bazaar, Inc.
blog: Scaling Past 100,000 Concurrent Web Service Requests
Received on Thursday, 19 February 2009 02:43:43 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:30 UTC