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:
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
|