0D4373E9E1236F42AB63FD6B5B306AA3B7B776@SV-EXCHANGE.fjcs.net"
type="cite">
Pim: <JD>
Hello Jacques and others,
#1 and #10:
I'm not sure if the point I wanted to make
is clear. In addition to assuring the confidentialy of the SOAP message
(and protecting usernames/password tokens in the "ebms" WSS header),
SSL/TLS can provide certificate-based client authentication. With the
identity of the Pulling client established, if this identity can be
passed to the Pull request authentication service, there may be no need
for any WS-Security headers in the Pull request at all. (The client
would still need to be able to process any WSS headers in the pulled
SOAP messages). In this case it would not be orthogonal to the other
two options, but a third option.
<JD>
The key part of your solution is in: "if this
identity can be passed to the Pull request authentication service,..."
(which I think is more an authorization service here). Indeed the
authorization of the PullRequest goes beyond authentication of the
client: some clients will be authorized to pull on some MPCs, and
others to pull on other MPCs. It is more like an Access Control issue.
It
is unclear how the ebMS processing module in the MSH would get
knowledge of these user credentials: they would not show at all in the
message header. ebMS Core V3 did not describe this option. Of course we
could say it is implementation-dependent.
Going
back to AS4: the conformance profile in 2.1.1 does not preclude the
*usage* you describe: it only requires support for the two
authorization techniques described (authorization options (1) and (2)).
If we wanted to allow this 3rd option, I believe we only need to:
(a)
make it clear in 2.1.1 that other authorization techniques could be
supported in addition to 1 and 2. But if we were to describe this one
you mention, it would have to be described in the "additional features"
(Section 3), because Section 2 can only deal with what Core V3 has
specified. I guess it also would be an optional feature to support (not
mandatory to implement in order to comply with AS4)
(b)
in the usage profile 4.2.3, describe this 3rd solution as an option
that users may want to agree to use instead of (1) and (2)
Is
that what you are looking for?
#5:
Another reason to include the
filename in the ebMS SOAP header is to allow it to be encrypted (in
case the name is potentially meaningful).
<JD> So I think what we
suggested would allow for this - yet not make this filename in
<partInfo> mandatory. Would be PMode-controlled, in the same way
as the PMode should more generally specify what properties are expected
to be found in addition to the basic ones.
#8:
An idea would be to add P-mode parameters
equivalent to the CPA elements TransportServerSecurity and
TransportClientSecurity and subelements
TransportSecurityProtocol, ClientCertificateRef, ServerCertificateRef,
ServerSecurityDetails, ClientSecurityDetail and the EncrytionAlgorithm
element with its attributes @minimumStrength, @oid, @w3c,
@enumerationType.
<JD> So we already have
the PMode[1].Security.X509 parameters family (see 2.1.3). We could extend it as
needed above, with specific support for SSL / TLS. I guess what may be
needed is PMode indicating what use will be made of these certificates:
either for transport security, or for persistent security (WSS)... we
could have two sets used simultaneously I guess.
Pim
Pim:
In the AS4 call today, here is our take on your comments:
Jacques
-----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 [mailto:jdurand@us.fujitsu.com]
Sent: 09 January 2009 00:50
To: ebxml-msg-as4@lists.oasis-open.org
Subject: [ebxml-msg-as4] Groups - AS4 Profile Development Draft
(AS4-Deployment-Profile-Draft-95.doc) uploaded
V0.95:
- Fixed all comments summarized in email 12/30 ("comments on 0.9")
- Cleaned-up the bundling option for Receipts both on the conf profile
side and the usage profile side.
- Added the duplicate detection feature as required (see section 3),
and added PMode config parameter for it in the Usage profile section.
- Added requirement for "MissingReceipt" new error code.
- Added a small section that summarizes the semantics of Receipts in
AS4.
-- Mr Jacques Durand
The document revision named AS4 Profile Development Draft
(AS4-Deployment-Profile-Draft-95.doc) has been submitted by Mr Jacques
Durand to the ebXML Messaging Services AS4 SC document repository.
This document is revision #3 of AS4-Deployment-Profile-Draft-07b.doc.
Document Description:
v0.7b:
- Added some details to the Section 3.1 about the Compression feature.
V0.8
- Added compression profiling (section 3.1)
- updated authorization for light client (table 2.2.1, Security)
V0.9:
- added the proposed update for Compression indicator (additional
eb:Property, in addition to the gzip content type)
- reorganized completely Section 4 (Deployment Profile now renamed Usage
Profile) with two major subsections: (4.1 AS4 Usage Rules, 4.2 AS4
Usage Agreements).
- enhanced the description of major agreement options (in new 4.2), and
referenced appropriate PMode parameters.
- also added additional PMode parameters needed to control Delivery
Awareness (Section 3).
V0.95:
- Fixed all comments summarized in email 12/30 ("comments on
0.9")
- Cleaned-up the bundling option for Receipts both on the conf profile
side and the usage profile side.
- Added the duplicate detection feature as required (see section 3),
and added PMode config parameter for it in the Usage profile section.
- Added requirement for "MissingReceipt" new error
code.
- Added a small section that summarizes the semantics of Receipts in
AS4.
View Document Details:
http://www.oasis-open.org/committees/document.php?document_id=30589
Download Document:
http://www.oasis-open.org/committees/download.php/30589/AS4-Deployment-Profi
le-Draft-95.doc
Revision:
This document is revision #3 of AS4-Deployment-Profile-Draft-07b.doc.
The document details page referenced above will show the complete
revision history.
PLEASE NOTE: If the above links do not work for you, your email
application may be breaking the link into two pieces. You may be able
to copy and paste the entire link address into the address field of
your web browser.
-OASIS Open Administration