[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-05.doc) uploaded
My comments inline.... the rest of the subcommittee, please lend your opinions, please.
jdurand@us.fujitsu.com wrote:
TEB: I'm ok to narrow support to WSS 1.1 assuming (a) WSS11 has backward compatibility with WSS10 and (b) there is good toolkit support for WSS11.
Remaining discussion points for AS4 draft:
1. support for both WSS1.0 and WSS 1.1 (see "Interop Parameters" in 2.1.1
table). : should we narrow further to WSS1.1?
TEB: There seems to be some external interest in the AS4 Light Client, however I want to make sure everyone the ramifications of no X509 support means that eb:Receipts would be unsigned and whether or not that impacts the "legal" definition of business non-repudiation. There does seem to be some interest in deploying light clients at the "edge-of-the-internet" that do not have to maintain a PKI infrastructure with keystores, etc. and resources to process signed/encrypted messages. As I've stated before, a "light client" that supports X509 (and thus only really restricts and already short list of supported MEPs) is not much of a "light" client.
RE: I’m ok with narrowing support to WSS 1.1. I do not see a need to support both. Narrowing support will aide interop and interop testing.
2. The "Light Client" AS4 conf profile: final decision on this? What level
of security is it supposed to support? Right now, none except the
UsernameToken (user / password) profile in WSS, meaning no actual
implementation of WSS is needed, no X509 support.
I'm still really waiting to hear Dale and John, and even a guy like John Duker chime in on the field usability/viability of such a light client that's security model is restricted to username/password + HTTPS.
Section 3.11, right? Jacques, I'll work with you on the what needs to be added to these sections about compression and delivery awareness. Ric, I probably need to have a chat with you about compression....
3. Additional features (compression, delivery awareness) have been moved
out of the Conf Profile section (from "additional modules" , formerly 3.2 )
into the deployment section 3.10 "Additional Features"
4. Compression: need be more specific about it in 3.10.1
RE: Ok:)
As we talked last week, we are only talking about One-Way patterns with AS4. Sync responses refer to either (a) eb:Receipt or (b) an error message.
5. In 3.2.1: clarify if "sync responses" (business messages other than MDN)
are considered
RE: Synchronous Business Responses are not on the table for AS4. Only receipts and errors can be sent back synchronously.
I think this is best left for trading partner agreements, with the profile supporting errors being (a) not returned, (b) returned synchronously or asynchronously, and (c) if async, a possible alternative URL to return errors to
6. In 3.3.1: do we really want the default "Service" value to be one that
will never deliver the message? (default is for testing only)
RE: I would think that we would want the default service to be one for regular trading. Though I am open to discussion on this.
7. In 3.5.1 and 3.11.3: do we want to prescribe a particular error
reporting, or leave it to users to decide and agree on?
Yes.
8. In 3.6.2: replace eb:MessagingContainer with ...just eb:Messaging?
What about for the light client's synchronous document Push pattern? If they aren't able to sign, would they need to offer a username/password for authentication purposes?
9. Message authorization feature: only for PullRequest messages?
RE: I suppose either client authenticated SSL could be used. Or HTTP authentication. But... A light client probably does not want to maintain a SSL certificate. And HTTP Authentication is not very secure. Additionally a MSH might not have access to the authentication token (SSL Cert, HTTP username). User Token probably makes more sense.
--------------------------------------------------------------------- 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
-- Mr Jacques Durand
The document revision named AS4 Profile Development Draft
(AS4-Deployment-Profile-Draft-05.doc) has been submitted by Mr Jacques
Durand to the ebXML Messaging Services AS4 SC document repository. This
document is revision #2 of AS4 Profile Development Roadmap.doc.
Document Description:
V0.4:
- makes the semantics of Receipt more precise, in the COnf Profile
section.
- completes the definition of the AS4 Light Client CP.
- In "additional Features" section 3.11, add optional message
replay and dup detection.
V0.5:
- remove in Section 2 the "additional modules" (content moved to
section 3)
- various minor edits.
- more specific about message authorization (WSS usernameToken)
View Document Details:
http://www.oasis-open.org/committees/document.php?document_id=29576
Download Document:
http://www.oasis-open.org/committees/download.php/29576/AS4-Deployment-Profile-Draft-05.doc
Revision:
This document is revision #2 of AS4 Profile Development Roadmap.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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]