[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
Crystal clear. It really shows is that I'm not an expert in webservices. Regards, Tomas Arshad Noor wrote: > That is true, Tomas; however, the occurrence is within a <choice> > element, which implies that you can place only a <GlobalKeyID> or > a <SymkeyRequestID> in the <SymkeyRequest> and whichever one you > choose, there must be at least one occurrence of the sub-element. > > Does that claify it? I will make it clear in the specification > and update the notes inside the XSD to indicate this. > > Arshad > > Tomas Gustavsson wrote: >> >> Hi Arshad, >> >> Just to make the (false) impression that I read and fully analyzed >> everything carefully :-) >> >> >>> SymkeyRequest.xsd >>> ----------------- >>> >>> 01) Added the choice of sending either a GlobalKeyID or a >>> SymkeyRequestID in the SymkeyRequest to accommodate >>> asynchronous request/responses to/from SKS servers. >> >> It says "either or" above. In the symkeyRequest.xsd it says >> minOccurs="1" on both the GlobalKeyID and the SymkeyRequestID. >> >> Cheers, >> Tomas >> >> >>> >>> SymkeyResponse.xsd >>> ------------------ >>> >>> 01) Added the SymkeyWorkInProgressType as an additional choice to >>> the SymkeyResponse element, to accommodate asynchronous >>> request/responses to/from SKS servers. >>> >>> The zip file is available at: >>> >>> http://www.oasis-open.org/apps/org/workgroup/ekmi/download.php/29681/SKSML-DRAFT7.zip >>> >>> >>> I don't want to modify the Specification Document until I have >>> some consensus on the XSD itself. Once we're agreed on the >>> changes in the XSD, then I'll modify the Spec document to >>> reflect the changes. >>> >>> Can we use Tuesday October 21st (the day of our TC meeting) >>> as a deadline for reviewing the changes (they're not very big >>> changes). We can then discuss them on the monthly call and >>> decide our course of action. >>> >>> Thanks. >>> >>> Arshad Noor >>> StrongAuth, Inc. >>> >>> Arshad Noor wrote: >>>> Sorry for the delayed response; just got back last night from >>>> Madrid where I presented SKSML at the ISSE 2008 conference. >>>> As always, the work this TC is doing generates great interest. >>>> Given that entire countries already have PKIs established in >>>> the EU, EKMI is starting to generate much interest over there. >>>> >>>> WRT to the elements, Anil, I feel if we are going to support >>>> asynch message/responses, then we should do it right, right >>>> from the beginning. The elements I'm thinking of are fairly >>>> simple and will not add too much to the protocol. But, the >>>> advantage is that it allows the SKCL to take on more and the >>>> client application has to do less. I will have the XSD done >>>> in a few days and send it to the TC for review. >>>> >>>> Arshad >>>> >>>> Anil Saldhana wrote: >>>>> 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 >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> 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]