Re: Proposed additional interop test cases

Hi Tommy,

Thanks for this message. See my inline comments.

-jose

On Tue, Nov 23, 2004 at 08:53:24AM +0000, Tommy Lindberg wrote:
> 
> 1) SOAP binding related tests.
> 
> Test that SOAP envelopes of wrong versions are rejected with appropriate
> fault indications as per [1] section 3.4 and subsesctions.  This can
> be achieved by
> sending a SOAP 1.1 envelope to a SOAP 1.2 endpoint and by sending SOAP
> 1.2 envelope to
> a SOAP 1.1 endpoint.

Ok.

> Test that unsupported Header's marked with MusterUnderstand = 1/true
> are rejected with
> appropriate fault indications as per [1] section 3.4 and subsesctions.

I guess that this means we have to encapsulate a message that is not
XKMS and send it to a SOAP server?

I'm confused in that I don't know if an XKMS server should return in
this case an error return code, and whether it should be
Sender.Failure or Sender.Refused.

> 2) Additional (general) tests that can be applied to all XKMS request types:
> 
> Test that
>  - OpaqueClientData.OpaqueData is correctly returned; use OpaqueData
> multiplicity > 1

Do you mean having a compound request with different OpaqueClientData
associated to each message? Or having OpaqueClientData that is
represented as an XML tree?

I am wondering what happens when we associate a <CompoundRequest> element
with <OpaqueData> and some of the results are returned asynchronously.
I suppose this means that each time there is a result available, there
will be a <CompoundResult> element and it will include the same
<OpaqueData>.

>  - RequestSignatureValue is correctly returned for signed request

Ok.

>  - RequestSignatureValue is not returned when request signature does
> not validate

Does this mean having a custom client to send invalid requests?

>  - ResultMajor=NoAuthentication is received for requests for which
> signature validation fails

I guess we could do this if we have an expired certificate, e.g.

>  - ResultMajor=TooManyResponses is received for requests indicating a
> ResponseLimit less than the available number of key bindings, and that
> the indicated number key bindings are returned in the result

The above is true if the request include a ResponseLimit attribute. We
can also have a TooManyResponse result selected on the initative of the
server and that returns one or more results.

It may require two test scenarios (with and without ResponseLimit).

> 3) XKISS tests
 
> Locate/Validate with QueryKeyBinding with RetrievalMethod for rawX509Certificate

Good :)

> 4) XKRSS tests
> 
> Two phase RegisterRequest
> Two phase ReissueRequest
> Two phase RecoverRequest
> Two phase RevokeRequest
> 
> Asynchronous RegisterRequest 
> Asynchronous ReissueRequest
> Asynchronous RecoverRequest
> Asynchronous RevokeRequest
> 
> RevokeRequest authenticated by HMAC signature
> Revoke authenticated by private key signature
> 
> RegisterRequest with DSA key
> ReissueRequest with DSA key
> RevokeRequest with DSA key

Ok with all of these.

> 
> 5) Compound tests
> 
> Compound request with XKRSS synchronous inner requests
> Compound request with XKRSS asynchronous inner requests
> Compound request with both XKISS and XKRSS inner requests
> Twophase CompoundRequest
> Asynhronous CompoundRequest

We could have futher combinations:

Compound request with Combined XKISS and XKRSS , asycnhronous inner
requests
Compound request with Combined XKISS and XKRSS , sycnhronous inner
requests

Twophase CompoundRequest for all of the above
Asynchronous compound request for all of the above.

-jose

Received on Tuesday, 23 November 2004 15:59:14 UTC