RE: [wss] Interop Scenario Descriptions - New Format

["Hal Lockhart" <hlockhar@bea.com>]

Comments in line.

> -----Original Message-----
> From: Jerry Schwarz [mailto:jerry.schwarz@oracle.com]
> Sent: Tuesday, April 22, 2003 4:05 AM
> To: Hal Lockhart; wss@lists.oasis-open.org
> Subject: Re: [wss] Interop Scenario Descriptions - New Format
>
>
>
> At 11:51 AM 4/18/2003, Hal Lockhart wrote:
> >I have taken over editing the Interop Scenario descriptions and have
> >invented a new, more detailed format.
> >
> >There is a lot of new material here. Please review it carefully.
> I am sure I
> >must have made some mistakes.
> >
> >Hal
> >
>
> I have some questions and comments.
>
> A. The document doesn't say anything about transport. It's my
> understanding
> that we've agreed on HTTP, but it doesn't say anything about what fields
> might be present. In particular it doesn't say anything about the
> SOAPAction field. We would like it to be stated that this field should be
> empty (is one issue we would like to resolve.  Specifically we would like
> the SOAPAction header to be empty.

Actually lines 128, 235 and 398 say "This contract covers a request/response
MEP over the http binding." Since SOAPAction is optional in this binding, I
did not mention it.

I think we want the header not to be present, rather than empty. I will add
"The SOAPAction http header MUST NOT be present."


> B. There are several two places where something is said to be "an error"
> and there seems to be a requirement that the services detect these
> situations. Specifically invalid username/password combinations in
> secenario one and reuse of nonces in scenario 2. The requirement
> to detect
> nonce reuse seems a relatively significant one.  In any event who is
> responsible for creating clients that will test whether the
> services detect
> these errors.

The sense of the last meeting was that we are checking for interoperability,
not conformance. However, I suggest people design their client to accept a
typed in username and password. That way we can check for valid and invalid
values.


> C. You're using KeyIdentifier in Scenario #2 to identify the X509
> certificate. I can understand the motivation for this, but I don't think
> the X509 profile allows it.  I admit the X509 profile isn't completely
> clear about what is allowed, but the only mechanism it discusses
> is the use
> of a BinarySecurityToken and a direct reference.

If this is a problem, it has to be fixed in the X509 profile, not the
scenario contracts.


> D. Scenario 2 doesn't say what algorithms should be used for the
> encryption
> of the UserNameToken. The example uses tripledes and Scenario 3 does
> specify tripledes, so I suspect this is just an oversight.

Lines 260-261 say "The algorithm MUST be triple DES-CBC."

Hal
>
>