[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dss] public comment from ebXML
Hi all ! I can agree with the proposal completely to add the broad range of functionalities of ebXML to a DSS implementation ! Dtmo it wouldn't replace the existing profiles ( especially Async ), but enables a company to offer a DSS styled service over the internet, not just within the intranet. In addition to the signing and verification mentioned by Pim especially the timestamp would be a valueable service to offer. This is much more valuable when it's done by an independent third party. I once thought about starting an ebXML effort within the TC. But I was afraid to defer the 1.0 version. In the near future having 1.0 out / InterOp ready and getting some backing from the ebXML group it would be an interesting effort I would like to participate in. So future looks bright for DSS ! Greetings Andreas > 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 ___________________________________________________ Andreas Kühne phone: +49 177 293 24 97 mailto: kuehne@trustable.de Trustable Kirchröder Str. 70e 30625 Hannover Germany www.trustable.de Kostenlose Verifikation qualifizierter elektronischer Signaturen: www.sig-check.de
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]