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


Help: OASIS Mailing Lists Help | MarkMail Help

dss-x message

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

Subject: RE: [dss-x] Fwd: Presentation client and server signature

Hello Andreas,

Just a comment that a "polling" use case could be provided
by using the ebMS 3.0 transport binding for DSS:

In ebMS 3.0, it is possible to have a service provider that
is HTTP "client only":  it pulls requests, and pushes the
responses back. This message exchange pattern is referred to
as the "Two-Way/Pull-and-Push MEP" in ebMS 3.0. The
definition is in section 2.2.8 of:

A main benefit of this is that no changes are needed to the
DSS messages, the polling functionality is provided by the
transport protocol binding, not by a DSS profile.  A regular
DSS sign/verify request can be polled, and a regular DSS
response returned. I'm not sure that is appropriate for the
use cases you're describing, but it may be of interest

A light client conformance profile for ebMS 3.0 is defined
in section 3.2 of:

This ebMS 3.0 conformance profile does not require any of
the "heavy" Web Services modules (security or reliable
messaging) and no HTTP server capabilities.  It can be built
using just HTTP client, TLS, SOAP/MIME and XML libraries, so
it is not hard to implement.


-----Original Message-----
From: kuehne@trustable.de [mailto:kuehne@trustable.de]
Sent: 14 February 2011 19:31
To: dss-x@lists.oasis-open.org
Subject: Re: [dss-x] Fwd: Presentation client and server

Hi all,

I would like to make on Oscars use case :

In this scenario the client itself requests a signature ad
is holding the required private key, too. In this case
outlined request / response pair is a perfect fit.

In my use case the requirements a bit broader :
The client can request a document to be signed but
additionally there may be more requests ready to be signed
originated earlier / by other sources. So I would like to
propose a more general approach that solves both
requirements :

1. A signing request as we already know it. Usually
asynchrounous, as it may take an unpredictable amount of
time to be processed. It cannot be guessed in advance when
the user / the supervisor / the notary logs in again to sign
pending documents.

2. A polling-styled request to get new signing requests for
the local private key and to return encrypted hashes. This
new method can be consructed by the elements we already got
in the schema, just a bit twisted :

The client request holds a signing response to an earlier,
already processed call. And the server response transports
new signing requests stripped down to the plain bytes that
should be encrypted by the clients private key.

As this is a polling mechanism, responses and / or requests
may be empty.

3. The server returns the signature as the response to the
initial call from 1. .

This solution could cover both requirements without to much
extra burden on Oscar client-initiated signing. Just a
little bit of inversion-of-control ...



----- original Nachricht --------

Betreff: [dss-x] Fwd: Presentation client and server
Gesendet: Mo, 14. Feb 2011
Von: Juan Carlos Cruellas<cruellas@ac.upc.edu>

> -------- Mensaje original --------
> Asunto:       Presentation client and server signature
> Fecha:        Mon, 14 Feb 2011 16:23:26 +0100
> De:   Ďscar Burgos <oburgos@catcert.net>
> Para:         Juan Carlos Cruellas <cruellas@ac.upc.edu>,
> CC:   Ďscar Burgos <oburgos@catcert.net>
> Sorry for the delay.
> If we have time (Iĺll be a bit late) we can discuss on
this mixed
> scenario and how can we approach it (whether it is
possible using a
> profile or adding new elements to the core)
> See you later.
> Oscar.
> _
> *Oscar Burgos Palomar*
> └rea d'assessorament
> AgŔncia Catalana de Certificaciˇ - CATCert Passatge de la
> 11, 08008 Barcelona
> tel: 93 272 25 88 - fax: 93 272 25 39
> www.catcert.cat <http://www.catcert.cat/>
> _
> _
> Aquest correu electr˛nic, aixÝ com qualsevol fitxer annex,
> informaciˇ classificada. Queda prohibida la seva
divulgaciˇ, c˛pia o
> distribuciˇ a persones diferents del seu destinatari
exclusiu sense
> autoritzaciˇ prŔvia per escrit de l'AgŔncia Catalana de
Certificaciˇ -
> CATCert. Si vostŔ ha rebut aquest correu electr˛nic per
error, si us
> plau notifiqui-ho immediatament al remitent reenviant-lo.

--- original Nachricht Ende ----

To unsubscribe from this mail list, you must leave the OASIS
TC that generates this mail.  Follow this link to all your
TCs in OASIS at:

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