Talk:Litmus:Web Services
should the attribute of the testresult be password or digital signature?
The password should be some hashed version of password if any. I would separate the platform information into a tag bay itself and added a signature at the end of test results.
<testresults> <sender username="foo@bar" /> <environment useragent="blah" platform="bar" opsys="sys" branch="branch" buildid="bid" /> <result testid="123" result="result"> <comment>Optional Comment Goes Here</comment> <!-- I don't understand the bits in process_test.cgi about bugs, so I've left that part out for the moment --> </result> <authentication signature="signed MAC of all tags above" /> </testresults>
Using tokens
I like your approach of hashing the whole message, but I don't think we need to use a separate token to do so. If it's not being sent over the wire, could we not simply use the password as the salt? Saves creating and maintaining another piece of sensitive user data.
--coop 19:30, 11 Nov 2005 (PST)
First what are we trying to achieve?
Is it integrity of the message during transport over the net?
Is it integrity of the message during storage?
Is it authentication of the message?
If it is transport over the net, can SSL/TLS be used?
Is this level of integrity required all the time or would it be okay for people/processes to submit test report without authentication and integrity check? (availability vs. integrity & authenticity tradeof)
--Ruza 20:45, 11 Nov 2005 (PST)
Our goal here is authentication. We want to make it as easy as possible for real testers to submit genuine results. We are throwing up the following barriers to entry:
- results must validate against DTD;
- submitter must be registered with Litmus, as verified by the authtoken required in each submitted result;
- a corresponding testcase for the test result must already exist in the database;
- all the result classification criteria (product, platform, etc.) must already exist in the database. We will publish a list of valid criteria, or have a simple tool to look it up;
- duplicate results are not accepted. Duplication will most likely be determined by a combination of username, testid, machinename, and timestamp.
--coop 07:50, 15 Nov 2005 (PST)