Re: [ekmi] Request ID or entire request in sksml response

[Arshad Noor <arshad.noor@strongauth.com>]

See below for comments and some additional questions.
Thanks.

Anil Saldhana wrote:
> The example of an email usage was just an illustration of possibilities 
> of transport.  Inline answers:
> 
> Arshad Noor wrote:
>> Interesting requirement, Anil.  This leads to more questions:
>>
>> 1) Should SKSML then be sent using SOAP over SMTP, or using just
>>    S/MIME?
> Are we not relying on ws-security? That will provide the message level 
> security.

	Yes we are, but the moment you bring up SMTP you'll find a lot
	of people who are going to say why aren't we using S/MIME
	(something that has been around for over 15 years). Sending SOAP
	over SMTP certainly is technically feasible and provides the
	same level of security as SOAP over HTTP, so that isn't the
	issue.  Just trying to figure out what answer we as a TC have
	when someone poses this question to us.

>>
>> 2) How should the SKS server respond under the following conditions?
>>
>>    a) When the mail message is unsigned spam;
>>    b) When the mail message is signed spam;
>>    c) When the mail message is legitimate SKSML, but signed with
>>       an invalid certificate?
> What if it is a controlled environment?

	I should've clarified that by "spam", in this context, I meant
	any e-mail that did not contain a valid SKSML message.

>> 3) Are there other transports we should be considering besides HTTP
>>    and SMTP?
> Why tie the spec to any transport?

	Good point.  We're not doing that in the current DRAFT, so we
	should continue that practice.

> 
> I do not understand what difficulties arise in sending some id about the 
> request back in the response :).  I am just looking at usage in an 
> asynchronous manner such as Async WS.
> http://java.sun.com/blueprints/webservices/using/webservbp3.html

	No difficulty at all, Anil.  The SKMS architecture does have
	a request ID assigned to each request.  I just didn't think
	that a client might be interested in that information.

	Since the business use-case is to have the clients get keys
	asynchronously (essentially to not have the application sit
	there and wait for a key), here is another way of solving the
	problem (which is supported in StrongKey, but is not emphasized
	because it did not have any bearing on the standards effort):

	The KeyCachePolicy essentially tells clients how long they may
	cache keys, as well as how frequently to check with the SKS
	server for updates to policy.

	While one tends to think of the business application using the
	Symmetric Key Client Library (SKCL) to "manage" this cache,
	technically, there is nothing to prevent a little utility
	linked to the SKCL whose sole job is to manage the cache.  It
	can be configured to run periodically and update the cache
	with new/used keys as defined by the KCP.

	Since this "KCP-Utility" will run independently of the business
	application, in essence, even though the KCP-Utility makes
	synchronous SKSML calls, the business application gets the keys
	"asynchronously".  That is, when it needs a key, it calls the
	SKCL; the SKCL checks the cache, and lo & behold, there is a key
	always over there.

	The business application never has to wait synchronously for the
	SKS server to respond to a request, because the SKCL will always
	find it in the local cache.  The KCP-Utility can be configured
	to run as frequently as desired on the client, so that it is
	always making synchronous requests of the SKS server, but
	providing the keys to the business-application asynchronously.

	Does this design address the business problem you have?

	Another way of dealing with this business requirement is for
	the business application to call the SKCL and make the request.
	(It would have to be a different API method in the SKCL that
	would returns a flag indicating if a key is available locally
	in the cache for use).  The business-application then goes onto
	doing whatever it does while waiting for the key, but
	periodically, it calls the SKCL to see if the key is available.
	If it is, then the application makes the normal SKCL call which
	returns the key from the local cache.

	In both cases, this does not require modifying the current DRAFT
	of the SKSML and does not have to require supporting asynch
	communications for the protocol.

	I have nothing against asynchronous communications, Anil; I'm
	just trying to keep the protocol simple and finding other ways
	that can solve the problem.

	If you - and others - believe that it should be in the protocol,
	then adding the request ID to the response is easy enough.  But,
	we will then have to add a new message-type for polling the SKS
	server with an existing request ID.  Alternatively, we have to
	modify the SKCL to receive asynchronous responses from the SKS
	server (will businesses be open to that?  It will mean having
	to open up firewall ports on the client to allow SKS messages
	to reach the SKCL asynchronously).

Arshad

> 
>>
>>
>> Arshad
>>
>> Anil Saldhana wrote:
>>> Hi Arshad,
>>>  at least two use cases come into my mind.
>>>
>>> a) In enterprise software, typically transport is the variant.  So I 
>>> should be able to send sksml requests via smtp for example. :) With 
>>> JMS for example, I may
>>> get a response later and the only thing that I will have is either 
>>> the request id or the optional request element.
>>>
>>> b) With clients in low bandwidth and tough terrain, such as hand held 
>>> devices, you cannot always rely on synchronous communication.
>>>
>>> I would at least like to have the request id sent back from the 
>>> response. That should be sufficient for clients.
>>>
>>> Regards,
>>> Anil
>>>
>>> Arshad Noor wrote:
>>>> Hi Anil,
>>>>
>>>> Can you provide a business scenario where this is necessary and
>>>> where synchronous communication with the SKS server does not
>>>> address the problem.  Thanks.
>>>>
>>>> Arshad
>>>>
>>>> Anil Saldhana wrote:
>>>>> Hi all,
>>>>>  I would like to open the discussion to the use case of 
>>>>> asynchronous/batch requests for keys.  This will require that we 
>>>>> need to return a request id or the entire request (which can be an 
>>>>> optional element) in the response.
>>>>>
>>>>> Regards,
>>>>> Anil