RE: [dss] [Fwd: Async comments by Tommy]

["Nick Pope" <pope@secstan.com>]

Andreas, Tommy and all DSS

Following on from the issue raised by Tommy some time ago suggesting adding
an optional response ID to the SignResponse and VerifyResponse in support of
asynchronous operation.

Is there any objection for inclusion of this change in the next draft of the
CD for confirmation at the next meeting?

Nick

> -----Original Message-----
> From: Tommy Lindberg [mailto:tommy.lindberg@gmail.com]
> Sent: 24 July 2005 17:18
> To: kuehne@klup.de
> Cc: dss@lists.oasis-open.org
> Subject: Re: [dss] [Fwd: Async comments by Tommy]
>
>
> Hi Andreas -
>
> Thanks for your reply.
>
> No I didnt mean to remove the RequestID in either request nor response
> - I simply meant adding a ResponseID to the response.
>
> (I am on hollidays; back next weekend.)
>
> Regards
> Tommy
>
> On 7/18/05, Andreas Kuehne <kuehne@klup.de> wrote:
> > Hi Tommy !
> > I wouldn't mind to widen the core functionality, but you are manadating
> > to
> narrow the functionality.
>
> > Sorry, I don't understand the second part.
>
>
> > I understand you want to leave out  the client-generated-request-id in
> > favour of server-generated-request-id. I see that the client-generated
> > approach introduces some problems but I wouldn't want to remove
> this from
> > the core. It's in there right from the start ...
> >
> > But I don't mind to add the server-generated id as an useful option.
> >
> > Greetings
> >
> > Andreas
> >
> >
> >
> > Regards,
> Tommy
>
> On 7/12/05, Andreas Kuehne <kuehne@klup.de> wrote:
>
> >
>
> ---------- Forwarded message ----------
> From: Andreas Kuehne
> > <akuehne@yahoo.com>
> To: Nick Pope <pope@secstan.com>, Tommy Lindberg
> > <tommy.lindberg@gmail.com>, kuehne@klup.de
> Date: Tue, 12 Jul 2005 05:39:15
> > -0700 (PDT)
> Subject: Async comments by Tommy
> Hi Tommy, hi Nick,
>
> currently I
> > am out of reach of my OASIS-licensed mail account. But I don't
> let more time
> > pass by
> ... I'll submit this to the list tonight.
>
>
>
> > 1)
> For service endpoints that support both the Sign and the
> > Verify
> protocol's there is no "general purpose" Response element
> available
> > that can be used as a response in situations where
> an unknown request id
> > received in a PendingRequest. I.e. an unknown
> request id corresponds to
> > neither a (previously received) Sign nor Verify
> request.
>
> I think DSS (and
> > its profiles) would benefit from a <Response> element that
> could be used in
> > situations like this. This could be implemented
> by refactoring the Core
> > schema through introduction of a common ancestor
> element to SignResponse and
> > VerifyResponse and pulling up common information
> items. This is identical to
> > XKMS from which this profile borrows.
>
> > Yes, you are right. It's a problem not limited to the Async profile. But
> > working on the Async I
> felt the need for a more abstract
> > 'request'/'response' objects. But after a short discussion (
> iirc with
> > Trevor and Ed ) we concluded to leave the core as it is for the sake of
> > clear
> structures.
>
> But indeed you brought up a good argument ! In case of a
> > poll request with an unknown id you may
> choose a response type unexpected by
> > the client.
>
> I would second an approach of moving up the common parts of the
> > different responses to a common
> base object. Let's discuss this on the list
> > !
>
>
> > 2)
> The Asynchronous Processing profile requires the service to index
> > responses
> *client* generates; the RequestID. I would be in favor of letting
> > the
> *service*
> generate the quantity that it, itself, subsequently uses for
> > lookups. This
> would ensure that the properties of this quantity suit the
> > service,
> e.g. constant length, uniqueness, adequate randomness, etc. It
> > would also alleviate the
> need for request-id collision detection and
> > reporting.
>
> This would also require a change in the core schema, allowing an
> > additional
> optional attribute in the {Sign, Verify}Response that would carry
> > a response
> id, the use of which the asynchronous profile would mandate.
> > Again, this
> is identical to XKMS.
>
> > Yes, I see the problem, too. But it's the same excuse : I
> wanted to use the
> > mechanism already
> defined in the core. I wouldn't mind to widen the core
> > functionality, but you are manadating to
> narrow the functionality. Let's
> > take this to the list, too.
>
> Greetings
>
> Andreas
>
>
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your
> TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
>