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


Hi Andreas,

thanks for your response. 

> thanks for pointing out the POAS spec. It's adressing the problem Oscar
> outlined in his presentation.

It's true that PAOS introduces some overhead due to 
1) the fact that one needs n+1 HTTP request/response pairs
     to transport n SOAP-request/response pairs from the server to the
client
2) some additional header information.

While 1) means that one needs two request/response pairs to send one
message,
the overhead induced by 2) seems to be negligible (with respect to the
verbosity of SOAP). 

> Nevertheless I'm a bit astound about the burden this spec puts on a client
> willing to use. The user agent has to state his support for POAS. Maybe
the
> agent hasn't got any idea about it, but some lines of javascript are
enough to
> do the job perfectly. So the binding cannot be used for formal reasons.

What do you mean with "formal reasons"? 

> Another point of critic is the impressive verboseness of the binding. Only
one
> request at a time, and this split into two full turn-arounds ? Doesn't
sound
> very performance-optimized, especially for mobile envorinments.

Yes, but the overhead in 1) is IMHO due to the nature of HTTP and hence the
situation will be the same for any XYZoverHTTP protocol. 

Alternatives based on WebSockets (http://dev.w3.org/html5/websockets/) for
example are
possible, but still in a fairly early stage.

In the end the PAOS-functionality may be realized in a small java applet or
MIDlet 
for example. Therefore this is not a real issue, if one decides to use XML
at all.
 
> In favour not to reinvent the wheel again dtmo there is no need to do on
the
> DSS side.I guess we don't need to enumrate all possible binding ...

For interoperability reasons, we certainly need to enumerate the bindings,
which
MAY, SHOULD or MUST be supported in a certain situation. Furthermore I would
strongly
recommend that the PAOS-binding should be among the set of bindings
mentioned
in a "DSS Client Profile", but we certainly can discuss this in the meeting
today.

BR,
   Detlef
> Greetings
> 
> Andreas
> 
> ----- original Nachricht --------
> 
> Betreff: AW: RE: [dss-x] Fwd: Presentation client and server signature
> Gesendet: Mo, 21. Feb 2011
> Von: Dr. Detlef HŘhnlein<detlef.huehnlein@ecsec.de>
> 
> > Hallo Pim, Andreas,
> >
> > if I correctly understood Oscar's proposal and your discussion around
> > the "inverted model", i.e. the HTTP-Client (e.g. a Java-applet) is
> > SOAP-Receiver and the HTTP-Server sends SOAP-requests, then this
> seems
> > to precisely what is specified in the PAOS-specification (PAOS =
> > reverse SOAP).
> >
> > This specification was developed within Liberty Alliance (see
> > http://projectliberty.org/liberty/content/download/1219/7957/file/libe
> > rty-pa
> >
> > os-v1.1.pdf and
> > http://projectliberty.org/liberty/content/download/909/6303/file/liber
> > ty-pao
> >
> > s-v2.0.pdf )
> > and today forms the basis of the PAOS-binding in SAML v2 (see ž 3.3 of
> > http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf
> > ), which is used in the " Enhanced Client and Proxy Profile" (see ž
> > 4.2 of
> > http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf
> > ) for example.
> >
> > The PAOS-binding is also used in the European Citizen Card
> > specification according to CEN TS 15480-3 and will be pushed towards
> > the ongoing revision of ISO/IEC 24727-3.
> >
> > The PAOS-binding is - just as a SOAP-binding - entirely independent of
> > the payload and the standards mentioned above only specify what is
> > necessary to realize the "inversion".  Hence the PAOS-binding should
> > be usable with any DSS-(X)-profile without any modification (even
> > including the asynchronous profile).
> >
> > If we search for a transport binding, which inverts the roles between
> > HTTP and e.g. SOAP then PAOS is exactly what we are looking for. But
> > we certainly can discuss this in the next meeting.
> >
> > BR,
> >  Detlef
> >
> >
> > > -----UrsprŘngliche Nachricht-----
> > > Von: Pim van der Eijk [mailto:pvde@sonnenglanz.net]
> > > Gesendet: Mittwoch, 16. Februar 2011 17:09
> > > An: kuehne@trustable.de; dss-x@lists.oasis-open.org
> > > Betreff: RE: RE: [dss-x] Fwd: Presentation client and server
> > > signature
> > >
> > >
> > > Andreas,
> > >
> > > 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.
> > > http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/part2/201004/
> > >
> > >
> > > 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.
> > >
> > > Pim
> > >
> > >
> > > -----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
> > > signature
> > >
> > > 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">
> > > 			<input
> > > message="impl:SignResponseList"/>
> > > 			<output
> > > message="impl:SignRequestList"/>
> > > 		</operation>
> > >
> > > 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 ...
> > >
> > > Greetings
> > >
> > > Andreas
> > >
> > > ----- original Nachricht --------
> > >
> > > Betreff: RE: [dss-x] Fwd: Presentation client and server signature
> > > 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:
> > > >
> > > http://docs.oasis-open.org/dss-x/profiles/ebxml/v1.0/oasis-d
> > > > 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
> > > "Two-Way/Pull-and-Push
> > > > MEP" in ebMS 3.0. The definition is in section 2.2.8 of:
> > > >
> > > http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/core/os/ebms_
> > > > 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
> > > 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 anyway.
> > > >
> > > > A light client conformance profile for ebMS 3.0 is defined
> > > in section
> > > > 3.2 of:
> > > >
> > > http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/profiles/2007
> > > > 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
> > > signature
> > > >
> > > > 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 ...
> > > >
> > > >
> > > > Greetings
> > > >
> > > > Andreas
> > > >
> > > >
> > > >
> > > >
> > > > ----- original Nachricht --------
> > > >
> > > > Betreff: [dss-x] Fwd: Presentation client and server
> > > signature
> > > > 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>,
> > > > <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
> > > la
> > > > 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
> > > annex,
> > > > 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
> > > 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:
> > > >
> > > https://www.oasis-open.org/apps/org/workgroup/portal/my_work
> > > > groups.php
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > > --- 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:
> > > https://www.oasis-
> > > open.org/apps/org/workgroup/portal/my_workgroups.php
> >
> >
> >
> 
> --- 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:
> https://www.oasis-
> open.org/apps/org/workgroup/portal/my_workgroups.php




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