FW: [dss] public comment from ebXML

Pim,

Further the comment that you submitted to the DSS TC during the public review, we in the DSS would very much welcome the opportunity to work with you and others in bringing together the capabilities of ebXML and DSS.

At the moment we are concentrating on the release of the existing specifications using the DSS protocols as they exist. However, once this has been completed we would like to look again at the ebXML capabilities and consider how DSS can be best integrated with ebXML including asynchronous support. This might be done, for example, by the definition of a DSS profile specifically directed at support for ebXML.

When we are ready to plan the next set of activities of the DSS TC we will be in touch to see how we might further progress these ideas.

Kind regards

Nick Pope, Juan Carlos Cruellas

Co-chairs OASIS DSS TC

-----Original Message-----
From: Pope, Nick [mailto:Nick.Pope@thales-esecurity.com]
Sent: 13 November 2006 17:39
To: dss@lists.oasis-open.org
Subject: [dss] public comment from ebXML

Subject: ebXML transport binding for DSS

From: "Pim van der Eijk" <lists@sonnenglanz.net>
To: <dss-comment@lists.oasis-open.org>
Date: Tue, 7 Nov 2006 17:29:15 +0100

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

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. You must not disclose, copy or rely on any part of this correspondence if you are not the intended recipient.

If you have received this email in error, please delete it from your system and notify the System Administrator at Thales e-Security +44 (0)1844 201800 or mail postmaster@thales-esecurity.com

ebxml-jc message