I agree with Ric that
it will be simpler to put the information in just one “place”
If there is a need to
protect the information during transfer, use TLS/SSL.
While it does not
follow a WS-splat standardization, it does follow an IETF
one.
So it remains a good
“applicability statement” by reusing existing standards for functionality where
possible.
Dale
Moberg
From: Timothy Bennett
[mailto:timothy@drummondgroup.com]
Sent: Monday, February 02,
2009 12:22 PM
To:
Emery Richard
Cc: Durand, Jacques R.; Pim van der Eijk;
ebxml-msg-as4@lists.oasis-open.org
Subject: Re: [ebxml-msg-as4] Groups - AS4
Profile Development Draft (AS4-Deployment-Profile-Draft-95.doc)
uploaded
OK... I withdraw my proposal to
add the filename to the <PartInfo/> element as an optional attribute in
order to finalize the AS4 draft
Ric Emery wrote:
I am in favor
of sticking with the Content-Disposition Header and utilizing transport layer
encryption if necessary.
-Ric
On 2/2/09 10:39 AM, "Timothy
Bennett" <timothy@drummondgroup.com>
wrote:
Ric,
I believe the AS4
profile is written such that allows for the Filename to be preserved in either
the Content-Disposition header or as an optiona attribute of the
<PartInfo/> element. Are you saying you are in favor of just
sticking with the traditional Content-Disposition header, and if so, is Pim
correct in saying that for ebMS message the Content-Disposition header might not
be part of the encrypted message? If so, are you suggesting we just leave
encryption of the filename to the transport layer?
I do agree that we
shouldn't reference the internet draft of the filename preservation spec, since
it mostly just points to RFC2183. I think we could just get away with
referencing that RFC.
Timothy
Ric Emery wrote:
Re: [ebxml-msg-as4] Groups - AS4
Profile Development Draft (AS4-Deployment-Profile-Draft-95.doc)
uploaded What does it mean to align to the filename preservation profile?
“The filename SHOULD align with the
filename preservation profile (http://www.ietf.org/internet-drafts/draft-harding-ediint-filename-preservation-01.txt
<http://www.ietf.org/internet-drafts/draft-harding-ediint-filename-preservation-01.txt>
)”
This is confusing as the filename
preservation profile talks about placing the filename in the
Content-Disposition. Also is it bad to reference an Informational internet draft
document that is going to expire on May 19,
2009?
-Ric
On 1/26/09 9:54 AM, "Timothy Bennett"
<timothy@drummondgroup.com>
wrote:
Ric,
Does the latest
version of the AS4 Profile (v0.97) uploaded on Thursday, Jan 22 satisfy your
concerns? If not, what changes to the profile do you suggest to abate your
concerns?
Timothy
Ric Emery wrote:
Re: [ebxml-msg-as4] Groups - AS4
Profile Development Draft (AS4-Deployment-Profile-Draft-95.doc)
uploaded For AS1/AS2/AS3 – filename preservation is described in - http://tools.ietf.org/html/draft-harding-ediint-filename-preservation-01
.
Basically the specification calls for the filename to be included in the
filename param of the Content-Disposition mime header (of each payload body
part) .
Pim pointed out below that including the filename in the
ebMS Header would allow the filename to be encrypted. This is true. But, the
encryption would only be useful if the filename was not also included in the
Content-Disposition. Some products may choose to fill out the
Content-Disposition. If the goal of putting the filename in the ebms header is
to encrypt the filename, then there needs to be an additional requirement that
the filename should not be included in the Content-Disposition. In EDIINT the
Content-Disposition gets encrypted along with the payload – so the filename is
encrypted along with the payload itself.
As an implementer I am not
jazzed about having to deal with the case of AS4 having the filename up in the
ebMS header. And, general ebMS 3 where the Content-Disposition is the logical
place (at least to me) to put the filename (based on rfc2183 - http://tools.ietf.org/html/rfc2183#section-2).
-Ric
On 1/19/09 2:51 PM, "Timothy Bennett"
<timothy@drummondgroup.com>
wrote:
Re: #5...
AS2 already
has a Filename profile that was sponsor by the the banking community, so there
is legitimate known needs from at least one possible end-user community for this
type of information to be included in the message. I think an optional
parameter in <partInfo> would be appropriate, but there is some
specifications around filename in the AS2 profile that we probably need to look
at and include.
Durand, Jacques R. wrote:
Pim:
<JD>
From: Pim van
der Eijk [mailto:pvde@sonnenglanz.net]
Sent: Wednesday, January 14, 2009 12:53
AM
To: Durand, Jacques
R.
Cc: 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 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
From: Durand,
Jacques R. [mailto:JDurand@us.fujitsu.com]
Sent: 13 January 2009
01:26
To: Pim van der
Eijk
Cc: ebxml-msg-as4@lists.oasis-open.org
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:
Jacques
-----Original
Message-----
From: Pim van der Eijk [mailto:pvde@sonnenglanz.net <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 <http://www.w3.org/2003/05/soap-envelope/role/next>
" or "http://www.w3.org/2003/05/soap-envelope/role/ultimateReceiver <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/ <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 <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 <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 <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
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that generates
this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that generates
this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that generates
this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that generates
this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php