[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ekmi] Request ID or entire request in sksml response
Hi Arshad, asynchronous/deferred processing probably is 10-20% of usage. So is it worth adding explicit elements into the schema? :) My proposal of status and status code should take care of it. If the status is pending, then the relationship between the client and the server is outside the scope of the spec, as to how the end response is delivered to the client. It can be callbacks, polling etc (which is implementation detail). Once the response is ready and delivered to the client, the status can be success. The requestID that is part of the response will tell the client that this is the result of a deferred processing. Asynchronous/deferred processing will involve smarter clients. So we can assume that the client has more processing capabilities in comparison to regular clients. Regards, Anil Arshad Noor wrote: > I am working on modifying the XSD to include a <SymkeyWorkInProgress> > element as a third response-type. When I get back from my presentation > at ISSE/SECURE 2008, I'll send out an update on this. In the meantime, > if there are other suggestions, they are welcome. > > Arshad > > Tomas Gustavsson wrote: >> >> I'll second that. >> >> /Tomas >> >> Anil Saldhana wrote: >>> In my opinion, the 1.0 spec should provide 3 items - status , status >>> code (optional) and status message (optional). The status can be >>> success, error or pending. When the status is error, the code and >>> message are relevant. Apart from the status of pending (or any >>> suitable word), the spec needs to do little for deferred processing. >>> >>> Arshad Noor wrote: >>>> I concur. Any other opinions? >>>> >>>> Arshad >>>> >>>> Tomas Gustavsson wrote: >>>>> >>>>> I vote for 1) or 3). Either one would work. Version 1.0 is not >>>>> likely to be very widely deployed, especially if the roadmap to >>>>> 1.1/2.0 is not too long. On the other hand if these are the only >>>>> important changes in the roadmap we might just take that time and >>>>> hope that 1.0 will be long lived. >>>>> >>>>> I'm leaning toward 3) right now. >>>>> >>>>> Cheers, >>>>> Tomas >>>>> >>>>> >>>>> Arshad Noor wrote: >>>>>> Tomas, >>>>>> >>>>>> Including a Request ID in a current SKSML response that includes a >>>>>> key is easy. It just means adding an extra element to the response. >>>>>> >>>>>> However, returning an SKSML response that only includes a Request ID >>>>>> and a PENDING status element does require defining a new Response >>>>>> type. >>>>>> >>>>>> So, the choices we have are: >>>>>> >>>>>> 1) Do nothing for 1.0 and add all this in the next version of the >>>>>> protocol; >>>>>> >>>>>> 2) Add the RequestID element to a full SKSML response (with the key) >>>>>> and add the new Polling Request and the Pending Response messages >>>>>> in 2.0; >>>>>> >>>>>> 3) Add the new messages in 1.0, but delay the 1.0 >>>>>> standard. Right, now, if we assume we want to add the >>>>>> Error/Message Codes and Standard Messages to the >>>>>> specification, that is going to take at least a month, and >>>>>> then we have to go through a TC vote (I think) >>>>>> and a 15-day Public Review period. We would then be right >>>>>> where we >>>>>> are now in terms of the process. >>>>>> >>>>>> Since I have heard positive responses to the need for adding >>>>>> standard >>>>>> codes/messages, it looks like we're going to have to go >>>>>> through this >>>>>> 45-50 day delay anyway, so we could use the opportunity to >>>>>> include >>>>>> the Polling Request/Pending Response message to the protocol. >>>>>> >>>>>> What do you all think? >>>>>> >>>>>> Arshad >>>>>> >>>>>> ----- Original Message ----- >>>>>> From: "Tomas Gustavsson" <tomas@primekey.se> >>>>>> To: "Arshad Noor" <arshad.noor@strongauth.com> >>>>>> Cc: "Anil Saldhana" <Anil.Saldhana@redhat.com>, >>>>>> ekmi@lists.oasis-open.org >>>>>> Sent: Thursday, October 2, 2008 9:42:22 AM (GMT-0800) >>>>>> America/Los_Angeles >>>>>> Subject: Re: [ekmi] Request ID or entire request in sksml response >>>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> It's a common approach in other protocols to allow both methods, >>>>>> either synchronous or asynchronous. When using the asynchronous >>>>>> mode the server just returns the requestId in the reply with a >>>>>> "pending" status, and optionally some time interval when the >>>>>> client should check back. >>>>>> The polling type message from the client is definitely the way to >>>>>> go I think. >>>>>> >>>>>> This is how both SCEP and CMP (I think) work, and it's common in >>>>>> PKI since some people keep insisting on using off-line CAs and >>>>>> such unnecessary things. Or they keep very strict network >>>>>> separation with an RA/proxy in between so polling is needed. >>>>>> >>>>>> I'm not suggesting that we implement this polling in the first >>>>>> version of the protocol, but It might be a good idea to keep it >>>>>> in the roadmap for future revisions. After all, we don't know if >>>>>> if there is really need for it, and I'm against bloating the >>>>>> protocol if we don't have to. >>>>>> >>>>>> But... >>>>>> If we return the requestId in the response now, a future revision >>>>>> might only have to define the polling message? Since there is >>>>>> already a status in the response that could be used to send >>>>>> PENDING back to the client right? >>>>>> >>>>>> Regards, >>>>>> Tomas >>>>>> >>>>>> Arshad Noor wrote: >>>>>>> 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]