I suppose we could remove the section
entirely but I thought we had a request to say something about filename
information… If so the two sentences I drafted previously sum up the
Profiling. (Stylistic adjustment is of course permitted to make the text fit
with the document style)
From: Timothy Bennett [mailto:timothy@drummondgroup.com]
Sent: Tuesday, February 03, 2009
9:01 AM
To: Durand, Jacques R.
Cc: Moberg
Dale; Emery Richard;
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
Based on our discussion
yesterday (and Ric's written comments), my impression was (2).
Dale? John? Ric?
Durand, Jacques R. wrote:
As the editor, I am not sure of what the final suggestion (or
consensus) is here:
Is it either:
(1) the "filename" property in
the message header is OK, yet optional. If it is there, then it must obey the
"profiling rule (a)" in table 4.1.9. What is NOT OK is the
"Alignment" requirement in 4.1.9. So we must remove it. Also, if
there is a need for transient security (TLS/SSL) then it should be just
in one place, say COntent-Disposition parameter.
Or:
(2) The profiling of filename is
alltogether unnecessary, so just remove the entire subsection 4.1.9.
Jacques
From: Moberg Dale [mailto:dmoberg@axway.com]
Sent: Monday, February 02, 2009
11:34 AM
To: timothy@drummondgroup.com; 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
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