RE: [wss] Comments on Interop Scenario Descriptions - New Format

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

Responses in line.

> -----Original Message-----
> From: Irving Reid [mailto:Irving.Reid@baltimore.com]
> Sent: Monday, April 21, 2003 10:20 AM
> To: 'Hal Lockhart'; wss@lists.oasis-open.org
> Subject: [wss] Comments on Interop Scenario Descriptions - New Format
>
>
> > From: Hal Lockhart [mailto:hlockhar@bea.com]
> > Subject: [wss] Interop Scenario Descriptions - New Format
>
> Section 3.4.3.1, line 150: I don't think the receiver needs to explicitly
> check that the <wsse:Security> element has mustUnderstand="true"; the
> regular SOAP mustUnderstand handling would be appropriate. This
> also applies
> to the other scenarios.

Ok. Actually I was thinking that the core spec required the security element
to have mustUnderstand="true". The Interop scenario does but the core spec
does not, therefore I will strike this line from all three scenarios.

>
> Section 3.5.2, line 186, I think this may be too restrictive - some people
> may be working with SOAP infrastructures that always add some sort of
> header. Should we relax this to read:
>
> The response message must not contain a <wsse:Security> header. Any other
> header elements MUST NOT be labeled with a mustUnderstand="true"
> attribute.
>
> This also applies to the second scenario; the last half also
> applies to the
> third.

Agreed.

> Section 4.1.2, lines 220-225: for simplicity, should we use a
> single keypair
> so that people don't need to configure point-to-point relationships for
> every counterpart in the interop testing?

Nothing in 4.1.2 says whether everybody is using the same key pair or
everybody has their own. It just says the Responder must have access to the
private key. (I assume in practice we will use a single key pair and
everybody will know the private key.)

I don't see any reason to change the text.

> Section 5.1.1: Do we really want to sign the data with the public key, and
> verify it by the Responder having the private key? This scenario
> would make
> much more sense if the Requester has the private key and the Responder
> verifies using the corresponding public certificate. (section 5.4.2.4
> implies that this is what you really meant).

This certificate/key pair is used to encrypt the request and sign the
response. (Just like in scenario #2.) The other certificate/key pair
(carried in the BinarySecurityToken) is used to sign the request and encrypt
the response. The text in the document looks ok to me. Did I miss something?

Hal