[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [provision] PSTC: SPML Use Cases Draft v01 - For Working Gro upReview
Thanks to all who have made the effort to write these down. Sorry I've only reviewed the first six so far, but here are some comments to start discussions. 1. I thought we all agreed to have authentication be out-of-band to this protocol. If so, all statements referencing "PST Connection Information" should be removed. 2. I don't think the identity information is needed when communicating to PST's. Its definitely needed when communicating to PSP's, but not PST's. The "account" information is the identity information as far as a PST is concerned. 3. I don't believe the last acknowledgement as in step 7 of user case 1 is really needed. What if its not received? Are we going to do anything anyway? Besides, if the client of the PST doesn't receive the acknowledgement in an appropriate time interval, it can always query for status. 4. The use cases to the PST's so far are all asynchronous. I think we need a synchronous flow as well. Many operations, such as simple change passwords, should be practically immediate and not require the overhead of asyncrhonous messaging. It also eliminates the need for acknowledgements. 5. At the face-to-face we discussed PST's possibly generating information and support for returning that generated information to the PST's client (i.e., unix id's). I didn't see that in user case 1. Should we add it? 6. We also discussed partial completions. Since these requests could be implemented through several API calls, some of the optional parameters of an "account" may not be successfully implemented but we may want to reflect a partial completion to the client. We discussed providing a list of attributes that did not get implemented back to the client. We may need to add this to both #1 and #4. 7. In use case #2, I think we need to provide some sort of certificate of authenticity with the identity information. Something like the way SAML does it. 8. I don't think we need to spell out use case #3. It should be out-of-band at this point. 9. In use case #6, the unique identifier for the "account" should be all that is required to send to the PST to identify the "account" to delete. Tony -----Original Message----- From: Gavenraj Sodhi [mailto:Gavenraj.Sodhi@businesslayers.com] Sent: Friday, March 15, 2002 9:14 PM To: 'provision@lists.oasis-open.org' Subject: [provision] PSTC: SPML Use Cases Draft v01 - For Working Group Review Importance: High All, As stated earlier, draft v01 of the SPML Use Cases Draft will be made available by this evening, 3/15. Well, here it is. I have not got to the UML and the business framework doc is still in the works, but the document covers the use cases discussed at the F2F and more and I have updated the glossary which is also covered. Please review and comment and let me know any mistakes I missed as this is the initial draft. The more commenting the better for the PSTC as this is the step forward for the working group. If I did not cover an item which you feel needs to be addressed, please post this to the group or email me directly. Enjoy!! We need to get all comments, suggestions, etc.... by the end of March. ***If you plan to make changes, additions, etc., please use "Track Changes" in MS Word.*** <<SPML Use Cases Draft v01.doc>> -Gavenraj gavenraj.sodhi@businesslayers.com M: 201-757-4090
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC