FW: Favor ...

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

Forwarding on behalf on Tommy Lindberg

-----Original Message-----
From: Tommy Lindberg [mailto:tommy.lindberg@gmail.com]
Sent: 09 July 2005 00:12
To: Nick Pope; Juan Carlos Cruellas
Subject: Favor ...


Hi Chairs -

I all of a sudden have problems mailing to the DSS list. I have
signaled this to the admins.  In the meantime could you please forward
this for me.

Thanks
Tommy

snip

I am implementing the Asynchronous Processing profile
and I ran into some issues that I figured I'd comment on.

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.

2)
The Asynchronous Processing profile requires the service to index responses
(data that relates to or will be part of responses) by a quantity that the
*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.

Regards
Tommy