RE: [wss] Updated Interop Scenarios

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

Thank you very much for these comments they are all correct and changes have
beem made in draft-05.

> Here are my comments on interop draft-04.
>
> - Lnes 320, 509 and 653: Each <xenc:EncryptedKey> element has
>   "http://www.w3.org/2001/04/xmlenc#EncryptedKey" Type attribute.
>   This value is the identifier for the <xenc:EncryptedKey> element
>   itself and I think we don't need (should not?) specify it as a Type
>   of a <xenc:EncryptedKey> element.
>
>   From the "XML Encryption Syntax and Processing":
> | 3.5.1 The EncryptedKey Element
> | Identifer
> |   Type="http://www.w3.org/2001/04/xmlenc#EncryptedKey"
> | (This can be used within a ds:RetrievalMethod element to identify the
> | referent's type.)
> | <snip>
> | The Type attribute inheritted from EncryptedType can be used to
> | further specify the type of the encrypted key if the EncryptionMethod
> | Algorithm does not define a unambiguous encoding/representation.
>

Correct
>
> - Line 314: <xenc:EncryptionMethod> doesn't have the beggining "<".
>
Got me.
>
> - Lines 617-619:
> | This section describes the processing performed by the Responder. If
> | an error is detected, the Responder MUST cease processing the message
> | and issue a Fault with a value of FailedAuthentication.
>
>   Second message is received and processed by Requester. If an error
>   is detected, what shoud Requester do? I guess just to show error
>   message to the operator or write to a log file.
>
I was told the the phrase "generate a fault" was a standard form of SOAP
weasel wording that was ambigious as to how the fault was actually reported.
Looking back I see actually wrote: "issue a Fault." Since the purpose of
this spec is to eliminate ambiguity, I will change the text to say "report
the fault locally".
>
> - Lines 532 and 671: The value of the Algorithm attribute of the
>   <CanonicalizationMethod> element is not quoted (from draft-04).
>
Got me.
>
> - Lnes 381-382: The plus/minus signs must be synchronized with
>   lines 298-299.
>
Fixed.
>
> - Lines 465, 607 and etc.: Though "The Body MUST be first signed and
>   then encrypted", <Ping> or <PingResponse> element is encrypted in
>   the examples in sections 5.4.4 and 5.5.4.
>   What do we want to do?
>   - Encrypt the <soap:Body> element (as the sentenses).
>   - Encrypt the <Ping> element or <PingResponse> element in the
>     <soap:Body> element (as the examples).
>   - Encrypt the contents of the <soap:Body> element.
>     In this case, the Type attribute of the <EncrypteData> element
>     would be "#Content".
>
I choose the last alternative, with suitable changes to text and examples.

This leads me to observe that I don't see any straightforward way of
specifying a signature over the contents of an element. (Analogous to
#Content for encryption.)

Hal
>
> ---
> Toshi
>
> ---
> NISHIMURA Toshihiro (FAMILY Given)
> nishimura.toshi@jp.fujitsu.com
> XML Application Technology Dept., PROJECT-A XML, FUJITSU LIMITED