RE: EARL security/privacy concerns

 

Hi Shadi,

> For option B, do you have specific properties (or classes) in 
> mind that need to have duplicates for encrypted variants (the 
> FOAF method)?

Right now I think that there are no specially sensitive information in the EARL core language, I'm not sure if we can consider pathnames (adoption currently under discussion) as "sensitive enough" to be encrypted.

However there is some information in the "HTTP Vocabulary in RDF" that is clearly sensitive. My first thoughts are for the "authorization" property which contains the userid and password, specially in "Basic Authentication" that relies just on a base64 encoded string.

I think that exactly the same applies to "proxy-authorization" and I'm not sure if there are other sensitive properties in the language.

Regards,
 CI.

> Carlos Iglesias wrote:
> > 
> > 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
> > 
> > 
> 
> -- 
> Shadi Abou-Zahra     Web Accessibility Specialist for Europe |
> Chair & Staff Contact for the Evaluation and Repair Tools WG |
> World Wide Web Consortium (W3C)           http://www.w3.org/ |
> Web Accessibility Initiative (WAI),   http://www.w3.org/WAI/ |
> WAI-TIES Project,                http://www.w3.org/WAI/TIES/ |
> Evaluation and Repair Tools WG,    http://www.w3.org/WAI/ER/ |
> 2004, Route des Lucioles - 06560,  Sophia-Antipolis - France |
> Voice: +33(0)4 92 38 50 64          Fax: +33(0)4 92 38 78 22 |
>

Received on Wednesday, 25 October 2006 16:46:52 UTC