[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
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 > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]