[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Bundling in EDIFACT
A potential requirement of the bundling chapter not
yet mentioned in the draft, but of interest, is to be able to capture the capabilities of other messaging frameworks
without loss of functionality. One of these is
EDIFACT.
The eb3:Messaging and
eb3:UserMessage units look very
similar to EDIFACT interchanges and messages, respectively. When
sending a batch of messages an an
EDIFACT interchange, an
EDIFACT CONTRL message can accept or reject the entire interchange, or
indicate which parts in the
interchange are acknowledged and which are rejected (ISO
9734-4):
An action may be indicated for the complete
interchange, or it may be indicated for individual parts of it. Thus, some
messages, packages, or groups may be acknowledged and others may be rejected.
The CONTRL message shall indicate the action for all parts of the subject
interchange.
The counterpart of this would be an ebMS3 Messaging bundle
containing eb:SignalMessage/eb:Errors
for the rejected message units and eb:SignalMessage/eb:Receipts for the received message units. If we
could support the full functionality of this CONTRL
message, we could increase
the appeal
of ebMS3. I'm told that EDIFACT does not specify a delivery semantics in these
situations, but leaves this to trading partner agreements. If we too want to
leave the options open, we could define Pmodes to control this. Conformance
profiles could limit these to specific use
cases.
N.B. The checks performed by CONTRL are limited
to syntactic checks. In EDIFACT the APERAK message can be
generated by applications to confirm business application level validation, and
is more like an ebBP acceptance acknowledgement / acceptance exception.
Any message units passed on by an
ebMS MSH could similarly still
be accepted or relejected individually at the
business application level.
Pim
From: Pim van der Eijk [mailto:pvde@sonnenglanz.net] Sent: 18 September 2009 07:37 To: 'Moberg Dale'; ebxml-msg@lists.oasis-open.org Subject: RE: [ebxml-msg] Bundling expectations on error conditions The proposal states that security is applied based on the
settings of the primary unit. So if the configuration for that unit states
that SOAP headers including the eb3:Messaging header, the Body and all
attachments are to be signed (set via Pmode[1].Security.X509.Sign, if my understanding of
the purpose of that parameter is correct), then those elements
must be ds:referenced in the signature and the signature must be
valid. If the signature is not valid, then the entire message fails and no
parts must be delivered. If the hash for a particular MIME attachment with
cid:id@suffix is not correct, then it is not relevant which eb3:UserMessage
has a reference to that MIME part. No need to treat that case differently from
an incorrect hash for the eb3:Messaging header. I don't think we are in
disagreement here.
But if reliability and security pass, or are not present and
not specified to be present, then the message may still have other errors
(handled in the ebMS module, like the value of AgreementRef as an example) in
some units and not in others. In that case, the current draft says that
the correct units should still be delivered, just as if the units
were sent in separate messages, and that eb3:Errors are to be generated for
the incorrect parts.
From: Moberg Dale [mailto:dmoberg@axway.com] Sent: donderdag 17 september 2009 23:18 To: Pim van der Eijk; ebxml-msg@lists.oasis-open.org Subject: RE: [ebxml-msg] Bundling expectations on error conditions From: Pim van
der Eijk [mailto:pvde@sonnenglanz.net] The ebMS3 Core
specification states the order or processing (incoming, reverse for
outgoing): Transport, then WSS module, Reliability Binding, ebMS
packaging. Figure 7 of ebMS Core Spec. During the ebMS 3 public review
(two years ago) I asked about order of header processing and that figure was
what I was referred to. Nothing new. OK, forgot that we
stated that. An ebMS3 compliant
message may already contain multiple payloads. There was never any concern
about which payload caused the error. This extension is just an extension
to this concept, signing additional payloads using the security of the primary
message, as if the primary message had included those parts. IMHO any errors in
bundling do not need to satisy an additional detailed reporting requirements
that are not in the core spec. I don’t quite
understand that. The principle you referred to said that each message was
treated as if it were the only message. Now the principle is that there is a
root message and subordinate ones. The point is that with
the signature over all of them, we cannot tell which one is problematic.
Therefore, it would be a security violation to try to pass on any of them. So
they should all fail. Please consider this point Pim From:
New: This security header contains a single
ds:Signature element
containing multiple ds:Reference
elements for all payload parts, if payload signing is specified,
and any payload parts brought in via secondary message units will be treated in
the same way as parts that came with the primary message unit. Reliability processing
and regular WS-Security processing are the same for a
bundled message as for an message with just a single message unit. They
succeed or fail atomically. Only if both succeed do we get to the ebMS module
that knows about bundling. There we do have a question about what to do with
multiple ebMS errors (errors in the ebMS module), e.g. one message unit
references via AgreementRef an Agreement that has expired,
and the other units have no problems. The current
version of the spec is based on the following assumption
(3.5.1): Comment: we cannot
actually make any assumption about the order of header processing unless we want
to specify something. (SOAP generally does not say much about header process
ordering, but does I think allow header specifiers to say something.)
Another observation:
The change to signature over all parts means that we won’t necessarily be able
to say what part creates an error with signature. That is, the signature
verification process produces a single hash value (16, 32 or some longer
sequence of bytes), and this value is matched against what the signing party
computed. That does not show which part fails. Now you might sometimes be able
to guess, from a ds:Reference hash check mismatch, that the problem is with a
specific part. But all the ds:References might match, but the overall signature
check fail (because of some permutation of order of parts, for example).
Therefore, because of
the signature being over all parts, it seems false
that: For the Producer and Consumer
layers, the semantics of bundling is equivalent to sending and receiving a
sequence of distinct messages I will stop there and
wait for additional clarifications. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]