RE: WebID Test Suite

The test suite should only touch those topics for which requirements are
stated in the spec. One has to be able to trace test case to stated
requirement.

One cannot start testing [here] whether authorization works in the abstract,
or cert lengths of 9 elements work, or missing extended key usage extensions
in the cert cause IE to struggle to interoperate. None of these topics are
spec'ed. We cannot test signout (as its out of scope). One cannot even test
really https session teardown (the SSL closure protocol, that I suppose maps
to signout)

Once the spec gets less logical and more into stating the details of making
80% of the web actually works well enough, then one can extend the tests to
profile common products, warts and all. 

----

Let's not forget, that the core webid use case was delivered as a research
output years ago. The world of self-signed client/server https certs is
already commodity (i.e. it's in Windows, even, and trivial to program). All
we have to do really is have the resource server consume a foaf card and do
a query, rather than consume a Directory object and execute an ldap query
over an IPsec tunnel. Ideally we'd standardize a service interface so we
could execute that data service remotely, but I don't seem able to convince
anyone of this.


-----Original Message-----
From: public-xg-webid-request@w3.org [mailto:public-xg-webid-request@w3.org]
On Behalf Of Henry Story
Sent: Wednesday, March 23, 2011 2:08 AM
To: bergi
Cc: public-xg-webid@w3.org
Subject: Re: WebID Test Suite

Hi Bergi,

great to see some progress being made on this issue.

A few questions:

 - what is the licence for the code? BSD/Apache or GNU would be great.

 - I am not quite sure what you are testing here. Well, it seems like you
are testing the validity of a particular webid certificate, to see if it
matches the foaf file. ie: if it would authenticate you. This would be
somewhat similar then to the foaf.me simple login page
   http://foaf.me/entry.php
  I suppose all implementations should have a component of this kind, to
help the developers of the component, administrators and users work out why
someone cannot log it. Is it their certificate that is wrong? Their foaf?
Which part of each? and so on.

   But if that is the case then the User Interface to your component could
be a lot simpler. You just need to set it up as a service, and people can go
to the certificate test page, and try to log in with their browser. You
could then have a page which goes into details in human readable form about
what failed or succeeded.

   Next one might wonder if having such a service return the same
information in machine readable format (RDF) would not also be useful... If
it is we could agree on an ontology. Any ideas here?


	Henry

On 22 Mar 2011, at 23:20, bergi wrote:

> Hi,
> 
> I have created a little WebID test suite. It's based on JUnit and 
> apache HttpClient. To test your own webid implementation you have to 
> create an endpoint which outputs all valid agents comma seperated. In 
> the default.properties file you have to change the endpoint to your 
> own url, the endpoint certificate to your own certificate in pem 
> format. The publish base url and path must point to a folder which is 
> accessable via your local file system and http. I'm using a local 
> apache with a hacked hosts file. Currently the following tests are
included:
> 	- Default (single entry in subjectAtlNames)
> 	- MissingRdf (404 http error)
> 	- MultipleIDs (two entries in subjectAltNames)
> 	- WrongModulus (wrong modulus in rdf)
> 	- WrongPublicExponent (wrong public exponent in rdf)
> 
> Issue:
> http://www.w3.org/2005/Incubator/webid/track/issues/9
> 
> Download:
> https://www.axolotlfarm.org/~bergi/projects/commons/test-webid-2011032
> 2.zip
> 
> Regards,
> the bergi
> 
> 

Social Web Architect
http://bblfish.net/

Received on Wednesday, 23 March 2011 15:50:33 UTC