EARL security/privacy concerns

Hi group,

In response to the action item recorded at [1], the following is an attempt to summarize the privacy/security concerns in EARL and the two different positions that were raised during the last teleconference.

As an introduction we can say the key question is that there could be certain information in EARL reports which will contain some "sensitive" information (e.g. usernames/passwords). There are two different approaches regarding this issue:

A- We can see the security/privacy problems as an additional external layer without any relation with EARL (e.g. further encryption of the EARL reports later in the workflow when necessary and/or desirable).

This approach doesn't have any impact on EARL and requires no modification of the language, but it also requires that those who need some privacy/security should develop and manage their own privacy/security systems from the scratch.

B- On the other hand we can provide new EARL attributes to easily allow some built-in privacy/security levels (a solution similar to that which the FOAF language followed with the "mbox" and "mbox_sha1sum" properties [2])

This solution needs some changes in the language but provides more power to final users that could be able to provide some privacy/security level without many efforts.


Additionally, a third route that came up was the possibility of splitting the model into a confidential part and a non confidential part to clearly stage what could be the "sensitive" parts of the language.

These are the proposals on the table so far.

[1] - [http://www.w3.org/2006/10/18-er-minutes.html#action01]
[2] - [http://xmlns.com/foaf/0.1/#term_mbox_sha1sum]


Regards,
 CI.

 
--------------------------------------

Carlos Iglesias

CTIC Foundation
Science and Technology Park of Gijón
33203 - Gijón, Asturias, Spain 

phone: +34 984291212
fax: +34 984390612
email: carlos.iglesias@fundacionctic.org
URL: http://www.fundacionctic.org

Received on Monday, 23 October 2006 16:32:27 UTC