W3C home > Mailing lists > Public > public-xg-webid@w3.org > February 2011

RE: WebID-ISSUE-9 (bblfish): Develop WebID Test Suite [WebID Spec]

From: peter williams <home_pw@msn.com>
Date: Sun, 20 Feb 2011 14:37:30 -0800
Message-ID: <SNT143-ds11C3276EE964DC7016795B92D90@phx.gbl>
To: "'Toby Inkster'" <tai@g5n.co.uk>
CC: "'WebID Incubator Group WG'" <public-xg-webid@w3.org>
I disagree. The use of .p12 files is very sensible, and avoids using keygen
tags (and similar HTMLisms that are not standardized and tend to need human
intervention, being all about forms and human-readable documents, terms and
conditions, copyrights etc).

As we see, .p12 files are easy to handle and fit the culture of unit
testing. One sets an input requirements

What might make sense is that a "support" website exists that provides the
.p12 files on demand, making the .p12 stream on the fly. Such a site merely
exports a credential from its implementation platform to the .p12 file, and
supplies it as a file stream resource. The site can mint keys/certs
periodically (using any local means it finds suitable) or on the fly: being
a simple openssl call. Henry already did 85% of the work by showing a pipe
of two openssl commands. Just augment these with the openssl CA command...

How hard would it be to change the test client so it obtains its .p12 file
dynamically from the web on a fixed URI, unpacking it with the likes of the
.p12 decoder in openssl to create the keying material ready to drive a unit
test run? If the http response indicates no change in file stream (given
etag in request), the nth test can reuse the previously unpacked .p12 file,
else force a new download to rebuild and rekey the test suite.



-----Original Message-----
From: public-xg-webid-request@w3.org [mailto:public-xg-webid-request@w3.org]
On Behalf Of Henry Story
Sent: Sunday, February 20, 2011 10:51 AM
To: Toby Inkster
Cc: WebID Incubator Group WG; sysbot+tracker@w3.org
Subject: Re: WebID-ISSUE-9 (bblfish): Develop WebID Test Suite [WebID Spec]

I just put together a "servlet" in Clerezza that accepts Toby's test suite
calls: ie it returns the WebID if it can find it or "-" if it cannot.

Then to get the rdf perl libs needed by your script  I compiled half of cpan
I think ;-) I tried it out. But your test certificates are out of date.

Running 

    openssl pkcs12 -clcerts -nokeys -in key/0002.p12  | openssl x509 -noout
-text

on the first two p12 files found here

   http://buzzword.org.uk/2008/foaf_ssl/tests/key/

Shows them to be valid sometime during  2009 and 2010. Well they have not
been updated recently. :-)

This is bound to be a problem when hard coding certificates like that. I
think to get these tests to work better one needs to create certificates and
WebIDs on the fly. Then one can also test the https server to see if it
correctly rejects invalid certificates. Also one can then create new WebIDs
much more easily, and so make it possible to test caching issues too.

So perhaps the RDF will be more useful in describing the results of the
tests, as your perl script does.  That does indeed make it easier to build
these test implementations, as one does not need to bother with the User
Interface aspect. Someone else can take the output of such a testing service
and make it look nice for their purposes. 

   What we could do perhaps is immediately put together an RDF list of tests
that we want to make. We just need to describe in english what they do
(though german might make it look more serious and thorough). Then we can
have different implementations of these test suites setup on different
servers which return results using that "ontology". It would make it
possible to compare the results of the tests from different servers, and so 

 -  distribute the testing load
 -  check how things are working from  different positions around the globe
 -  test the test suites among each other

I could write a test suite that goes into Clerezza, you could do elaborate
your perl script, and every perl instance or Clerezza instance could set up
a test service. The we are back in the git philosophy. 

   We could also develop a better ontology for the results to be returned by
a testing endpoint, instead of "-" and the webid, it could describe a number
of failures that occurred, or perhaps how it got the data (from cache? did
it fetch it?).  Then the tests could describe the type of failure expected.

  Not sure if this makes sense. Other ideas welcome. 


Henry
 


On 29 Jan 2011, at 23:16, Toby Inkster wrote:

> On Sat, 29 Jan 2011 10:10:28 +0000
> WebID Incubator Group Issue Tracker <sysbot+tracker@w3.org> wrote:
> 
>> There were some tests out there already. Something to place in the 
>> mercurial repository.
> 
> Beginnings of a test suite is here:
> 
> http://buzzword.org.uk/2008/foaf_ssl/tests/manifest.ttl
> 
> The idea is that a test harness (and there's an example test harness 
> provided at 
> http://buzzword.org.uk/2008/foaf_ssl/tests/test-harness.pl)
> would take the manifest as input and run each test against an endpoint 
> which is what's being tested. The endpoint is a WebID-secured script 
> which simply echoes out a text/plain document consisting of a single
> line: a dash if authentication is unsuccessful; the WebID URI 
> otherwise.
> 
> --
> Toby A Inkster
> <mailto:mail@tobyinkster.co.uk>
> <http://tobyinkster.co.uk>
> 
> 

Social Web Architect
http://bblfish.net/
Received on Monday, 21 February 2011 01:35:01 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:06:22 UTC