[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
Books on XSD just build on the online primer. http://www.w3.org/TR/xmlschema-0/ Arshad Noor wrote: > Oh, don't undersell your own capabilities, Tomas. I'm sure if there > was a question on ASN encoding of digital certificates, I would be > completely lost compared to yourself. :-) > > I will confess that I had to go to the XSD forums to get an answer > to a construct that I just couldn't understand either from the XSD > specification or a book I'd purchased and read at least 3 times; I > got the answer in 10 minutes. God, I love the open-source movement! > > Arshad > > Tomas Gustavsson wrote: >> >> 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]