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: RE: [dss-x] Fwd: Presentation client and server signature


What I was saying is that ebMS 3.0 in Pull mode offers
exactly this "inverted" model.  The DSS server would pull
messages as an HTTP client (initiator+receiver) from a DSS
client that is the HTTP server (sender+responder). The
requests are pulled using a standardized pre-defined pull
signal message.

In the ebMS 3.0 Part 1 Core that the DSS ebXML profile
references, a pull request pulls a single "UserMessage", and
multiple such user messages are polled by repeated polling.
If there is nothing to pull, there is a standardized
response indicating this. Section 5.2.4 of the Core also
describes a way of combining a UserMessage push and Pull
request, which you want here.  The only limit is that the
Part 1 Core bundling is limited to a single user message per
bundle. The ebMS 3.0 Part 2 defines a "bundling" feature to
pull or push a set of user messages. That makes it
equivalent to what you describe, and that is what I wanted
to point out.

If your WSDL operation definition is about responses that
are responses to requests made in a previous invocation of
the operation, and about requests that are new requests, the
responses to which will sent in a later invocation, then you
are stretching the semantics of "operation".  But as long as
everybody understands what you're doing, why not.  It's
possible to define custom polling, bundling, asynchronous
processing protocols for DSS as for any other application.


-----Original Message-----
From: kuehne@trustable.de [mailto:kuehne@trustable.de] 
Sent: 16 February 2011 16:07
To: pvde@sonnenglanz.net; dss-x@lists.oasis-open.org
Subject: Re: RE: [dss-x] Fwd: Presentation client and server

Hi Pim, 

I'm afraid I don't get your hint regarding the ebXML profile
aligned with Oscar's problem ;-)

I'm thinking of adding a new operation to the wsdl,
something like this 

		<operation name="pollingForSignRequests">

These are more or less the same structures as we know them
from core, just wrapped into a 0..n List. But in contrast to
the usual 'client calls, server responds' scenario, here the
'server' (the process holding the private key) calls the
client (the process requesting the signature). With this
call zero or more SignResponses of previous requests are
send to the client and in return zero or more fresh
SignRequests travel to the server.

This matches Oscars scenario where the browser serves as the
'server' as it has access to the private key. The browser
periodically performs calls to the an instance where a
specialized DSS process does all the pre- and postprocessing
of the signature. But to a certain degree it plays the role
of a client as it isn't able to encrypt a hash value.

This approach looks a bit wierd, especially as it intermixes
the wellknown roles of server and client. But it's just a
inversion of control to circumvent the inability of the web
browser to be an endpoint of a call. It  serves as an
originator of the polling calls.

I cannot an advantage of using ebXML as dtmu it just
transports the payload for a given operation ...



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

Betreff: RE: [dss-x] Fwd: Presentation client and server
Gesendet: Mi, 16. Feb 2011
Von: Pim van der Eijk<pvde@sonnenglanz.net>

> Hello Andreas,
> Just a comment that a "polling" use case could be provided
by using 
> the ebMS 3.0 transport binding for DSS:
> ss-1.0-profiles-ebxml.pdf
> 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
> MEP" in ebMS 3.0. The definition is in section 2.2.8 of:
> core-3.0-spec-os.pdf
> A main benefit of this is that no changes are needed to
the DSS 
> messages, the polling functionality is provided by the
> protocol binding, not by a DSS profile.  A regular DSS
> 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 anyway.
> A light client conformance profile for ebMS 3.0 is defined
in section 
> 3.2 of:
> 07/ebms3-confprofiles-cs-01.html
> 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.
> Pim
> -----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,
> processed call. And the server response transports new
> 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
> 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 ...
> Greetings
> Andreas
> ----- 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
> <stefan@drees.name>
> > 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
> Concepciˇ
> > 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
> contÚ
> > 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
> >
> >
> --- 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
> groups.php

--- original Nachricht Ende ----

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