[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wss] Interop Scenario Descriptions - New Format
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 > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]