DSS - ebXML transport binding

[Stefan Drees <stefan@drees.name>]

Dear public,

the following comment from the discussions of the TC shall be hereby 
made available to the public during puplic comment period.

Following the initial Comment by Pim van der Eijk the following 
subsequent Comments and Discussion by Nick Pope and Andreas Kühne:
"""
Nick,
 >>  How would you suggest we answer the specific point made about adding
 >>  ebXML capabilities to the Core.
 >>
 >>  I thought initially that maybe a ebXML specific profile would be
 >>  more appropriate.
 >>  Alternatively, is adding ebXML transport to the Core
 >>  something
 >>  that can be done with minimal disruption to the Core?  Is it
 >>  for something the next round?
For several reasons I would prefer to go for a separate ebXML profile :

- 1.0 is out for public review, it's too late to add significant
functionality

- Once there is a reference to ebXML is in the core, people may shy away
from the whole spec : 'much too heavy-weighted !' Iirc we saw concern
regarding SOAP, and ebXML is quite a different class.

- If there is a ebXML profile ready next year, hopefully along with some
other profiles, we keep some attention on our effort.

- InterOp for ebXML is quite some effort. Especially starting with ebXML
from scratch is a significant task. Can't see that we can handle this
'til end of the year ( or any other acceptable InterOp deadline )

Other opinions welcome !

[[Nick Pope agreed]]
"""

Initial Comment by Pim van der Eijk noted here for ease of reference:
"""
On behalf of an end-user community that is looking to implement DSS in 
an ebXML infrastructure, I would like to submit the following comment 
public comment to the DSS TC.

The ability of the ebXML Messaging as a transport protocol to use 
standard facilities for asynchronous messaging, routing based on 
PartyId, and reliable messaging, and the bilateral service configuration 
capabilities of ebXML Collaboration Protocols and Agreements are a main 
benefit compared to Asynchronous Processing Abstract Profile for the 
OASIS Digital Signature Services (which uses a protocol similar to XKMS).

Core features of an ebMS binding, for consideration:

-  Fixed value for the ebXML "eb:Service" header element:
    "urn:oasis:names:tc:dss:1.0:ebxml-msg"

-  Fixed values for the ebXML "eb:Action" header element, one of:
    "SignRequest"
    "SignResponse"
    "VerifyRequest"
    "VerifyResponse"

Payload/header/message correlation:

An ebXML message with a value "eb:Action" set to "SignResponse"
(respectively, "VerifyResponse") sent from MSH A to MSH B should contain 
an "eb:RefToMessageId" header element. The value of this element must 
match the value of the eb:MessageId header element in an earlier ebXML 
message sent from MSH B to MSH A with a value "eb:Action" set to 
"SignRequest" (respectively, "VerifyRequest"). The "eb:Service" would be
"urn:oasis:names:tc:dss:1.0:ebxml-msg".

If the DSS XML document included in that earlier request message 
contains a DSS "RequestId", the response message should include a DSS 
"RequestId" with the same value.

Request and response messages have the same values for eb:ConversationId 
and eb:CPAId/eb:AgreementRef.

The SSL/TLS transport level security settings for the ebXML message 
exchange would adhere to the DSS transport security settings.

The above is only a binding and would work with DSS XML request and 
response documents as used in the HTTP and SOAP 1.2 bindings.  To take 
advantage of the ebXML message structure, it might make sense to allow 
the dss:Document to reference documents stored in subsequent MIME 
attachments in the SOAP-with-attachments message structure (via a 
reference attribute using an RFC 2392 "cid" URI).

When using a registry to store partner profiles or agreement templates 
(or negotiation description documents), the fixed values of the 
eb:Service and eb:Action would allow partners to find a suitable digital 
signature service provider in a particular community using the query 
functionality of the registry.

This profile works equally with ebXML Messaging version 2 (ISO 15000) 
and the upcoming version 3 ebXML specification.

Would the TC consider adding an ebXML Messaging transport profile along
these lines to section 6 of the DSS 1.0 core specification?

Pim van der Eijk
"""




Regards,
Stefan Drees, Editor DSS Core Draft.

OASIS::TC_DSS.ActionRef("06-10-30-04")
OASIS::TC_DSS.ActionRef("06-10-30-05")