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

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss-comment message

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


Subject: ebXML transport binding for DSS


 
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
 
 
 
 


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