W3C home > Mailing lists > Public > www-xkms@w3.org > October 2004

Re: Revised Test Cases

From: Tommy Lindberg <tommy.lindberg@gmail.com>
Date: Wed, 13 Oct 2004 18:17:00 +0100
Message-ID: <18ec59cc04101310177fade8ee@mail.gmail.com>
To: Yunhao Zhang <yzhang@sqldata.com>
Cc: www-xkms@w3.org

Hi Yunhao -

> I don't see how the tests could exclude implementors from inplementing only
> XKRSS. ...

My understanding from the additional tests was the new XKISS messages
would be used to verify that key bindings were affected in the desired
way after an XKRSS operation.  Whether they were individual XKISS
testcases or part of an XKRSS testcase, this approach creates a
dependency on XKISS.

So, it doesn't prevent the implemention of XKRSS - but it does seem to
get in the way of testing XKRSS as the implementor wouldn't have the
XKISS functionality required to execute the test.

I wagely recall someone indicating only implementing a subset of XKRSS
- I was only sensitive to this.  Personally, I couldn't give a toss :)

> The question is, do we allow people to test only registration without
> verifying state change?

Yes I think so. Register, like Reissue and Recover, returns some
artifact that can form the basis for determining whether the operation
succeeded or failed; provided of course that all service implementers
agreed upon returning that artifact.

Revoke may require a bit more; if we agreed, a service could produce a
CRL in the result on which the revoked key resided. This is X509'ish
but so are the current XKISS tests.

Regards
Tommy

On Wed, 13 Oct 2004 09:19:18 -0400, Yunhao Zhang <yzhang@sqldata.com> wrote:
> 
> Hi Tommy
> 
> > 1)
> > While I am personally OK with the approach, using XKISS messages to
> > verify that XKRSS operations have produced the expected results may
> > exclude implementors that only intend implementing XKRSS, or portions
> > thereof, from executing some tests.
> >
> 
> I don't see how the tests could exclude implementors from inplementing only
> XKRSS. We already have a long list of KRISS tests and it doesn't preclude
> people from implementing only part of XKISS or even part of a client to
> participate in the test. Remember that the test cases can be exercised
> individually, and untested cases can be marked as 4 in the report.
> 
> > 2)
> > Assuming that XKISS messages are used to verify expected results of XKRSS
> > requests, it may be more meaningful to incorporate the XKISS messages in
> the
> > actual XKRSS test case as opposed to having them separately, using T101 as
> > an example:
> >
> >   - verify that binding-to-be-registered does not exist (Validate/Locate)
> >   - attempt registration
> >   - verify that binding-to-be-registered does exist (Validate/Locate)
> >
> 
> Then the case can only be used by ones who implement both XKISS and XKRSS.
> The question is, do we allow people to test only registration without
> verifying state change?
> 
> > 4)
> > I am not in favor of using the same shared secret for everyone.  Not only
> is
> > it not realistic, but it also allows for accidental inteference
> > between individual
> > testers.
> >
> Using the same shared secret is to facilitate automated testing where all
> the test cases are conducted in sequential order. We can certainly make it a
> parameter so that it can be entered before testing.
> 
> As for more test cases, we can definitely add when needed.
> 
> Regards,
> 
> Yunhao
> 
>
Received on Wednesday, 13 October 2004 17:17:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 08:39:23 GMT