[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-msg-as4] Groups - AS4 Profile Development Draft (AS4-Deployment-Profile-Draft-95.doc) uploaded
Pim:
In the AS4 call today, here is our
take on your comments:
-----Original Message-----
From: Pim van der Eijk [mailto:pvde@sonnenglanz.net]
Sent:
Monday, January 12, 2009 1:39 AM
To: Durand, Jacques R.;
ebxml-msg-as4@lists.oasis-open.org
Subject: RE: [ebxml-msg-as4] Groups - AS4
Profile Development Draft (AS4-Deployment-Profile-Draft-95.doc)
uploaded
Hello,
Here are some written review
comments:
#1
Section 2.1.1 Pull authorisation, Security section. This
mentions two options to secure the Pull signal. In a single-hop context, a
third option could be to use SSL/TLS client authentication and authorize based
on the established client identity.
<JD>
Usage Profiling (b) in table of 4.2.3 mentions this
option. To be sure, 2.1.1 only talk of what a product MUST support, without
making any rule on the use of these features (4.1 is making such rules, and 4.2
is letting users decide of their own usage rules that are still required for
itneroperability).
So we decided we could improve on the wording in (b) of
table 4.2.3, saying that SSL / TLS are an option that could be used
independently from the two major options defined
above.
#2
Section 2.1.1 Authorization option 1 is based on a
separate WSS header targeted at an actor with value "ebms". This is from the
core so it probably shouldn't change, but in SOAP 1.2 similar values are
expressed as qualified URIs with values like "http://www.w3.org/2003/05/soap-envelope/role/next" or "http://www.w3.org/2003/05/soap-envelope/role/ultimateReceiver", so would something like "http://docs.oasis-open.org/ebxml-msg/ebms/3.0/ns/..." be more appropriate?
<JD> because of compatibiity with Core V3, decided to not change this - not even allowing the alternative you mention: Sure it is more appropriate, but we can't undo what the Core V3 spec said...
#3
Section 2.1.1 "if the SSL protocol
is used" --> "if transport level security is used"
The core spec
references TLS 1.0 (which supersedes SSL) and IPsec.
(Also in
other parts of the spec)
<JD> OK.
#4
Section 3.1. Why the limitation to
GZIP? Most toolkits will support multiple compression mechanisms, and they
have different pros/cons that a community could profile further.
<JD> GZIP was the mandatory compression in AS2, and that worked well. For the sake of interop, we decided to restrict to GZIP only, in terms of what a conforming product must support (you can have products that support alternatives in addition).
#5
Related comment on Payload
PartProperties:
Would it be useful to have a convention to include the
original filename too?
<eb:Property name="FileName">order123.xml</eb:Property>
This
information may also be in the MIME Content-Disposition, but some products don't
provide access to MIME part information at the SOAP/ebMS layer and it may be
more convenient to include it in the SOAP/ebMS header.
<JD> We discussed that one quite a bit. Indeed it is helpful to indicate this info in ebMS header, in addition to having it in some MIME Content parameter (so this is an intended redundancy here).
But that should remain an option, and there is no specific processing requirement associated with this anyway, productwise. Also, this information
So what we suggest, is to add in the Usage rules something like:
" In case users decide to report the file name associated with a MIME part in the ebMS header, it must follow the rules:
(a) must be done as a <property> element in <partinfo>, with the @name = "FileName",
(b) the value of this property must be same as the file name value in the corresponding COntent parameter XYZ."
It becomes then a user decision whether or not to use this property (agreements section under 4.2.8 )
#6
Section
4.1.2
"When sending a Receipt for this MEP, a Sending MSH conforming to this
profile SHOULD NOT bundled the Receipt with any other ebMS message header or
body."
Should this be (assuming "Sender", "Receiver" at ebMS level where the
receiver is the one that pulls):
"When sending a Receipt for this MEP, a
Receiving MSH conforming to this profile SHOULD NOT bundle the Receipt with any
other ebMS message header or body."
But, is this restriction on bundling
consistent with 2.1.1 "ebMS MEP", which does seem to allow for this level of
bundling?
<JD> Not discussed yet. My $0.02:
>Should this be (assuming
"Sender", "Receiver" at ebMS level where the receiver is the one that
pulls):
Right, sending of a Receipt is not in the role of the Sending
MSH .
>But, is this restriction on
bundling consistent with 2.1.1 "ebMS MEP", which does seem to allow for this
level of bundling?
No. 2.1.1 requires for the ability to "process"
received bundled Receipts, for max interoperability. In theory that should not
be necessary.
#7
Section 4.1.8
"reciept" -->
"receipt"
<JD> Sure
#8
Section 4.2.3
Refers to SSL authentication,
but does not provide P-mode parameters for specific certificates that are
used/trusted.
Section 4.2.6 allows the community to specify trusted CAs, but
some applications may want to control the specific certificates or use
self-signed certificates. So a fine-grained control as is done at WSS
configuration would make sense.
<JD> Not discussed yet. My $0.02: Yes we need more PMode parameters. Can you suggest whats needed to address your concern?
#9
Section 4.2.4
"contains a composite
string"
It would be cleaner to have separate P-mode parameters for
these properties.
<JD> Not discussed yet. My $0.02: Problem is, at this level of granularity there might be many options that are different from one implementation to the other, and they are not really critical for AS4 interoperability. For example, an implementation will detect dups over a time window back from present time, another one will guarantee dup check for the last 1M messages, no matter how far in the past. Same for Replay parameters: could be controlled by timeout, by time interval * max retries, etc. Thtas why WS-RX decided to not standardize such paraemters.
#10
Section 4.2.6 (b)
Why are TLS encryption algorithms a "usage
agreement" rather than part of the profile?
It seems important for technical
interoperability of products.
<JD> Not discussed yet. My $0.02: You mean why aren't they part of the Conformance Profile section? The Conformance Profile dictates what a product MUST support (or in some cases, just a SHOULD). So far, SSL or TLS appears as out of scope of(orthogonal to) the AS4 profile: no product requirement on using these. They still appear in the "Usage agreement" part as a major agreement item for users to decide, and one that is advised to be used when using Pull Authorization option #1 without other security headers.
Pim
-----Original
Message-----
From: jdurand@us.fujitsu.com [
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]