RE: [provision] PSTC: SPML Use Cases Draft v01 - For Working Gro upReview

[Tony Gullotta <TGullotta@access360.com>]

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