---------- 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