OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [ebxml-msg] Removing Security of Attachments from Core Spec



Let me reword Hamid's concern as I understand it:


It is not about what security feature should or should not be in core.

It is that when reusing a standard-compliant implementation of WSS1.0 - say WSS4J 1.0 - it appears that the package, used as a plug-in component in an MSH, does not allow you to sign attachments as in WSS-SWA ( that is supported in WSS1.1.)

That's why the proposal of (1) either removing this from the "main conformance profile" or (2) using WSS1.1 instead of WSS1.0  in part 1.


I guess we need to hear from Ric and others about implementing this combination as is, and I would go with the consensus (in the same way I was reassured about SOAP 1.2 + SWA) . It seems to me though a b2b general conformance profile need be able to sign attachments - and that payload security alone may not be sufficient.


In all cases, I think we all agree that the main conf profile (whatever it is but mandatory to support for b2b users) should be based on Part 1 alone.





From: Dale Moberg [mailto:dmoberg@cyclonecommerce.com]
Sent: Wednesday, February 01, 2006 8:21 AM
To: Hamid Ben Malek; ebxml-msg@lists.oasis-open.org
Subject: RE: [ebxml-msg] Removing Security of Attachments from Core Spec


I am increasingly unclear about what importance attaches to being in part 1  ("the core") or part 2 (the periphery?) because of the increasing complexity introduced by conformance profiles.


Given my current understanding of how this is supposed to work, being in part 1 or part 2 is mainly a clerical matter, but with ramifications on what can be moved along for approval, and when it will be moved along.


What I am really  interested in for ebMS 3.0 is a mandatory to implement profile that includes


1. robust security features

2. reliability features

3. interoperable wire formats and transfer protocol(s).

4. convergence with WS-* functionality when that has become available since ebMS 2.0


[Point 4 is is mainly a matter of using the SOAP:body for business data for simple cases, making use of WSS for security, using one or more WS approaches to reliability.]



It now seems that such a profile will be spread over functionality described in part 1 and part 2. I don't think that ebMS 3.0 will have much b2b utility until the above mandatory to implement profile is agreed upon.


I would have preferred that the mandatory to implement profile for ebMS 3.0 be constructible from the first approved specification. This does not appear likely at present


I don't follow how the WSS versioning bears on putting something in part 2. If we do these in parallel, I am finding it less obvious why we have a part 1 and a part 2?


I hope to be on the call where you can elaborate a bit.




From: Hamid Ben Malek [mailto:HMalek@us.fujitsu.com]
Sent: Tuesday, January 31, 2006 5:20 PM
To: ebxml-msg@lists.oasis-open.org
Subject: RE: [ebxml-msg] Removing Security of Attachments from Core Spec


I know this has been discussed previously, but I'd like to bring it again on the table for discussion. I am suggesting deferring the security of attachments to Part 2 of the ebMS-3 Specification. The main reason for this is because the security of attachments is formally being part of WSS-1.1, whereas the core part of ebMS-3 spec only supports WSS-1.0. I don't like the pick-and-choose approach (we can't just pick one part of another version, but not support the whole version, or have a position between two versions). I understand the importance of security of the attachments for the business, but we can assure the audience that it will be covered in Part 2, which by the way can start before even finishing the core (we can start editing Part 2 in parallel to the Core draft if nobody minds that).



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]