[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dss-x] Groups - TestCases For Core v0.2 (DSS-X InteroperabilitySpecification Core OS Proposal-7June2010-v0.2.xls) uploaded
Hi Andreas, See below intermixed. Regards Juan Carlos. kuehne@trustable.de escribió: > Hi Juan-Carlos, > > sory for the late reply, but my daytime job is quite demanding right now. > > I'm still a bit unsure about the destincion between an interop and a conformance test scenario. What I see in the Excel sheet is a collection of some relevant validations. As far as I understand the tests in the Excel sheet can be performed on one single implementation. This is of course useful but I don't see the aspect of an interoperabilty here. For an InterOp I would expect to be at least two implementations to be involved. Do I miss this aspect somehow ? > To me an interop event is an event where different implementations perform a set of tests that somebody (us in this case) has designed and check if their applications understand eachother. If not, then there are discussions on whether one of the applications did something not aligned with the standard, whether the standard was ambiguously written, etc, and at the end some kind of conclusions are raised for each divergence if possible. The conclusions are reached through discussions and in our case, some kind of comments could be raised to the standardization committee. A conformance check requires to me, a precondition: a conformance check tool and somebody (entity, group of people) that claims that this tool is ***the*** tool, rightly developed, i.e., completely exhaustive, rigthly working, etc, etc, for doing conformance checks, i.e., a tool that ensures that whatever other application passes its tests, it follows the standard. My view of this is that this kind of tool is by far much more difficult to build: who would do that? under what entitlement? it requires exhaustive work for being sure that nothing is left of checking.... As for the excel, the way I see is that each test case instructs a participant in generating one specific request. This request would then be picked up by other participants and processed. At this point there would be an interoperability test: each participant would see how her tool reacts to the request generated by another tool. The different answers generated could even be checked by the one that generated the requests, completing the circle... > Another question on the Excel sheet : > There are some variations of input data defined. Do we just want to check the return status of the response ? No coarse check that the resulting signature is valid and of the intended type ? > If we put a PKI in place in the interop, the signatures generated could actually be verified...well, in fact, there are also verification protocols in our specs...so, to some extent some signatures verification should be performed, although this would not be the primary objective. > Greetings > > Andreas > ----- original Nachricht -------- > > Betreff: [dss-x] Groups - TestCases For Core v0.2 (DSS-X Interoperability Specification Core OS Proposal-7June2010-v0.2.xls) uploaded > Gesendet: Fr, 18. Jun 2010 > Von: cruellas@ac.upc.edu > >> Dear all, I have uploaded the excel sheet with details of test cases for >> core. Version 0.2. Added test cases for optional input <SignedReferences> >> (including a test case where both <SignaturePlacement> and >> <SignedReferences> optional inputs are present). >> >> This is for commenting and discussing at our next conference call. >> >> >> Regards >> >> Juan Carlos. >> >> -- Juan Cruellas >> >> The document named TestCases For Core v0.2 (DSS-X Interoperability >> Specification Core OS Proposal-7June2010-v0.2.xls) has been submitted by >> Juan Cruellas to the OASIS Digital Signature Services eXtended (DSS-X) TC >> document repository. >> >> Document Description: >> Excel sheet with details of test cases for core. Version 0.2. Added test >> cases for optional input <SignedReferences> (including a test case >> where both <SignaturePlacement> and <SignedReferences> >> optional inputs are present) >> >> View Document Details: >> http://www.oasis-open.org/committees/document.php?document_id=38345 >> >> Download Document: >> http://www.oasis-open.org/committees/download.php/38345/DSS-X%20Interoperabi >> lity%20Specification%20Core%20OS%20Proposal-7June2010-v0.2.xls >> >> >> PLEASE NOTE: If the above links do not work for you, your email application >> may be breaking the link into two pieces. You may be able to copy and paste >> the entire link address into the address field of your web browser. >> >> -OASIS Open Administration >> > > --- original Nachricht Ende ---- >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]