[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-msg] Removing Security of Attachments from Core Spec
|
Attached, current consolidated list of
proposed updates on CD1 (e.g. Hamid's below is #19) Jacques From: Hamid Ben Malek I know this has been discussed previously, but I'd like to bring it
again on the table for discussion. I am suggesting deferring the security of
attachments to Part 2 of the ebMS-3 Specification. The main reason for this is
because the security of attachments is formally being part of WSS-1.1, whereas
the core part of ebMS-3 spec only supports WSS-1.0. I don't like the
pick-and-choose approach (we can't just pick one part of another version,
but not support the whole version, or have a position between two versions). I
understand the importance of security of the attachments for the business, but
we can assure the audience that it will be covered in Part 2, which by the way
can start before even finishing the core (we can start editing Part 2 in
parallel to the Core draft if nobody minds that). Hamid. |
Update on comments on CD1: (Jan 30) ----------------------------------------------------------------------- 1) In the whole document, replace every occurrence of eb:Message by eb:Messaging This aligns element with the name of the spec, allows for potential future bundling of messages, and containment of other messaging-related elements other than messages themselves. Tentative agreement; no objections at this time. Ian may follow up and raise issues after reviewing his notes. STATUS: agreed. ----------------------------------------------------------------------- 2) eb:ErrorList element: Already removed, except in Figure 8, which needs to be updated, as already noted. We now have eb:Error, which may be repeated if multiple errors need to be reported. If batching of errors is allowed, we can repeat eb:SignalMessage, each containing eb:Errors. STATUS: agreed. ----------------------------------------------------------------------- 3) Subsection 5.3 (Signal Packaging) should rather be a subsubsection of subsection 5.2 (Core Header Extension). After all, signal packaging is also about packaging in the header. Therefore, subsection 5.2 (Core Header Extension) should have only two subsubsections, namely eb:UserMessage Element and eb:SignalMessage Element. STATUS: Agreed. ----------------------------------------------------------------------- 4) Remove paragraph (lines 291-292): "Implementors are strongly advised to read and understand the Collaboration Protocol Profile." It is very clear in the specification that such binding is out of scope. In other terms, the specification explicitly allows many different representations of an ebXML agreement without being in favor for any of them (such as a CPA for example). See also Monica's comments. Note that a CPA binding could be in appendix of Part 2. STATUS: No consensus; decision deferred. Ian: We need a statement that understanding CPP/A is helpful in doing a proper implementation. ----------------------------------------------------------------------- 5) Subsubsection 5.1.3 (ebXML SOAP Envelope Extension ) should be moved to 5.1.4, and a new subsubsection 5.1.3 should be added having the title Example. STATUS: Agreed that a complete example be provided in its own section. Some disagreement as to placement of Example section. Some feel it should be first; others would like the normative specification text first with example following. ----------------------------------------------------------------------- 6) In examples, the element eb:Partref still contains the attributes: 5.a- eb:id : agreed to remove (replaced by XML Id) 5.b- eb:idref. Keep it as AnyURI type. Will use a cid scheme when referring to MIME parts, and an XML fragment ( #if-of-fragment) when referring to parts in the SOAP body. STATUS: agreed. ----------------------------------------------------------------------- 7) remove sections related to SOAP actors: In Part 1: - Remove sections 5.1.3.8 , 5.1.3.9, 5.1.3.10 about SOAP actors & mustUnderstand, as the related topologies that such actors support are relevant to Part 2. (see proposed changes for Section 3 below) In Part II: - introduce the additional topologies that are handled. - address the routing issue for MEPs in a more generic way, and add SOAP actors as needed. STATUS: To be discussed. ----------------------------------------------------------------------- 8) Remodeling of Section 3: 8.a- Remove 3.4 and in Section 1 Intro (1.2 "Scope") add: "Features defined in Part 1 only support the point-to-point MSH topology, where no MSH or SOAP intermediary is assumed. Part 2 takes into account topologies with intermediaries, hub or multi-hop, as well as topologies where the ultimate MSH acts as a SOAP intermediary." 8.b- move section 3.3 "Message Service Processing Model" at the end of Section 2 (Messaging Model), replace "Message Service " with "Messaging Service " or "MSH ". On line 674, the paragraph should describe not only the processing by the receiving role but also the processing by the sending role, because the picture above it is supposed to describe the structure of an MSH for both a sending and receiving role (accepted). 8.c- Replaces what is left of Section 3 (3.1 + 3.2) with proposal posted. 8.d- Section 3 should then be renamed "Processing Modes" STATUS: To be discussed. ----------------------------------------------------------------------- 9) @soapresp attribute: STATUS: Agreed to remove. (from 2.2.3.1 and 2.2.3.3) ------------------------------------------------------------------ 10) Security: - too many examples that may not add value, redundant with WSS examples? - Ric notes that the security examples are incorrect, where the references are supposed to be to the SOAP Body, but instead contain a cid:xxx. STATUS: to be discussed -------------------------------------------------------------------- 11) reliability of "Internal" Service/Action (such as msg:service/Ping): At the end of 8.2.2 (Reliability section) add: "Messages that have eb:CollaborationInfo/eb:Service set to “urn:oasis:names:tc:ebxml-msg:service” are not intended to be delivered (Deliver) to an MSH Consumer, although they may be submitted by an MSH Producer. They and are for internal MSH consumption. They may also be subject to reliability contracts. In this case, the delivery contract is fulfilled with a successful RM-delivery. In case of failure do deliver, and if this message was submitted by an MSH Producer (Submit) instead of the MSH itself, the Producer must be notified (Notify) of the failure, like for regular user messages." Also, in 8.1, L2811, replace "may be subject" with "is subject". STATUS: to be discussed ----------------------------- Error section: --------------------- 12) - Add 1 error EBMS:0010 "ProcessingModeMismatch", severity: failure, category: Processing "the ebMS header is not compatible with expected content for the associated P-Mode." - in Reliability errors, Add 1 error EBMS:0201 "DysfunctionalReliability" severity: failure, category: Processing "some reliability function as implemented by the Reliability module, is not operational, or the reliability state associated with this message sequence is not valid." - renumber the error code for "DeliveryFailure"as: EBMS:0202 (instad of 0010) - renumber the error code for "Failed Authentication" as: EBMS:0101 (instad of 0011) STATUS: to be discussed ------------------------------------------------------------------ 13) Section 2.2.2.1: reword: The response message, in case a two-way underlying protocol is used, may contain: (a) a SOAP envelope with a SOAP body that is always empty, in which case the One-way MEP is qualified as "composable". (b) a SOAP envelope with a SOAP body that is either empty or contains a SOAP Fault. In that case the MEP is qualified as "fault supporting" in addition to being composable. (c) never contains a SOAP envelope, in which case the SOAP One-way MEP is qualified as “strict”. STATUS: to be discussed ------------------------------------------------------------------ 14) Section 4.1: reword as: "...ways with another MSH, engaging in a client-server type of interaction with the remote MSH, without any need to open a port to incoming requests. This MEP also supports exchanges with a partner that is intermittently connected: instead of periodically polling for partner presence, a sending MSH will simply wait for the partner MSH to pull messages." Example: A mobile, occasionally connected device without static IP address and with limited storage capability can only initiate requests and receive messages as synchronous responses to these. The One-way Pull MEP allows this device to enable and control the flow of received messages, and to adjust it to its own resources. L742: "...without a need to transfer filter expressions. " --> "...without a need to transfer and process filter expressions. " STATUS: to be discussed -------------------- Operation COntext --> P-Mode ---------------- 15) Section 2.4.3: "...This is done by sharing the message pipes operation context (see OpCtx_MessagePipes in Section 3)." replace with: "...This is done by sharing the message pipes processing mode feature (see P-Mode.messagePipes in Section 3)." Section 5.2.9: "... AgreementRef is a string value that identifies the operation context that governs the exchange. The recipient of a message MUST be able to resolve the AgreementRef to this operation context, or to the related agreement between the Sending and Receiving parties." replace with: "... AgreementRef is a string value that identifies the agreement that governs the exchange. The P-Mode under which the MSH operates for this message MUST be aligned with this agreement." Section 7: "... Error generation and error reporting are treated here as orthogonal concepts. Some aspects of error handling - in particular, reporting - are best specified within the operation context for error handling (OpCtx-ErrorHandling) e.g. as resulting from an agreement." replace with: "... Error generation and error reporting are treated here as orthogonal concepts. While the generation of errors is a matter of conformance, the reporting of errors may be subject to an agreement. Consequently, the way errors are to be reported is specified in the P-Mode (P-Mode.errorHandling feature) that results from such an agreement." Section 7.5: "... Except for some cases defined in this specification, Error escalation policies are left to an agreement between users, represented in the operation context of an MSH ( OpCtx-ErrorHandling)." replace with: "... Except for some cases defined in this specification, Error escalation policies are left to an agreement between users, represented in the processing mode of an MSH ( P-Mode.errorHandling )." Section 7.7.1: EBMS:0003 : replace operationn context with "processing mode" Section 8.1 (end): "... Note that depending on the reliability operation context (OpCtx-Reliability), notification of delivery failure may be detected on either side." replace with: "... Note that depending on the reliability processing mode (P-Mode.reliability), awareness of delivery failure may occur on either side." STATUS: Editorial effect of replacing Section 3. Follows from agreement on (8) ------------------------- ---------------- 16) Rename Section 10 as "Reliability Protocol Bindings" (Because "Profile " is an overloaded term, with different meanings.) Replace: "It is not the intent of ebMS to open too many options, but the case of reliability is a particular one, as each one of the two OASIS reliability specifications has strong arguments in its favor." with: "Although either one of the above OASIS reliability specifications is sufficient, each one has strong arguments in favor of its use." - retitle 10.1: "WS-Reliability Binding" - insert also the new section content for 10.2 "WS-ReliableMessaging Binding" STATUS: to be discussed --------------------------------------------- 17) Insert COnformance Appendix, latest update. STATUS: 3rd iteration, to be finalized. --------------------------------------------- 18) Insert SOAP 1.2 binding Appendix. STATUS: 2nd iteration, to be finalized. --------------------------------------------- 19) Security Module (Section 6.3) Shouldn't we postpone the security of attachment to Part 2, where we can introduce the WSS 1.1 alternative that supports it (WSS-SWA), instead of tweaking WSS1.0? "[Hamid] I know this has been discussed previously, but I'd like to bring it again on the table for discussion. I am suggesting deferring the security of attachments to Part 2 of the ebMS-3 Specification. The main reason for this is because the security of attachments is formally being part of WSS-1.1, whereas the core part of ebMS-3 spec only supports WSS-1.0. I don’t like the pick-and-choose approach (we can’t just pick one part of another version, but not support the whole version, or have a position between two versions). I understand the importance of security of the attachments for the business, but we can assure the audience that it will be covered in Part 2, which by the way can start before even finishing the core (we can start editing Part 2 in parallel to the Core draft if nobody minds that). " STATUS: to be discussed --------------------------------------------- 20) Update the packaging figures Section 5 (fig 7 and 8) - eb:Message --> eb:Messaging - the comments behind the arrows need be more explanatory. - bold outline not justified - ping & pong signals need be discussed (advantage in reversing to Service/Action coding like in ebMS2, when combined with P-Modes) See posted proposal. STATUS: to be discussed
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]