RE: [provision] SPML 2.0 Use Case doc, first draft...

[Gearard Woods <gewoods@us.ibm.com>]

Jeff,
Maybe I could just outline what I'm suggesting by throwing out a few examples without any detail:

1. Provision a resource
1a. Schedule the provisioning of a resource at some time in the future
2. Deprovision a resource
2a. Schedule the deprovisioning of a resource at some time in the future
3. Modify provisioned data associated with a provisioned resource
4. Query available targets
5. Query target schema
6. Query provisioned resources
7. Modify the state of a provisioned resource
7a. Suspend
7b. Restore
8 Query the state of a provisioned resource
9. Create and query relationships between provisioned data instances or targets
9a. Create/query hierarchical organizations
9b. Create/query dependancy graphs
9c. Create/query groups
10. Federate heterogeneous (multi vendor) or homogenous (single vendor) provisioning systems
10a. Vendor A PSP provision to Vendor B PSP

Apologies for avoiding the PSTC acronyms for the most part but I find that they can be kind of confusing at times. The original use cases can still be effectively captured in 1-6 but I would like to get away from the complexity of who creates what ID where. I'm not sure those separate use cases were very helpful in describing the problem domain in any case. 1a and 2a have been suggested by Gary's model where times for activation and de-activation have been in the schema. There has been a lot of discussion regarding state so #7 and #8 might speak to that and could encompass your D1-D2. #9 is essentially your C1-C3 but I would prefer to model relationships in general since I think they have great value in this domain. The federation use cases reflect your B1-B2 but our scenarios do not have a strict sequence of messages visible through the external interface so I think this should be a little more general. Perhaps these might form the basis of an interoperability discussion? I'm sure other people have better interoperability use cases.

These are not intended to negate your document but just to offer a slightly different view. In my opinion, at the level of a use case things should be fairly general and easy to understand. I found the proliferation of use cases based on the generation of PSO-IDs very distracting in the original document and did not lead to an understanding of the real problems that the SPML was trying to solve.
Gerry

"Jeff Bohren" <jbohren@opennetwork.com>

"Jeff Bohren" <jbohren@opennetwork.com> 04/06/2004 10:51 AM

To: <provision@lists.oasis-open.org> cc: Subject: RE: [provision] SPML 2.0 Use Case doc, first draft...

I don't mind revisiting the "Basic Use Cases" (SPML 1.0 Use Cases). I think that Gerry has a good point about the level of detail.

But one important point to remember is that the Use Cases are not requirements. The point of the Use Cases is to capture the problem space that we are trying to solve. In that context organizational hierarchy is an important use case that should be captured. Whether or not that is ever explicitly reflected in SPML 2.0 is another issue entirely.

If anyone would like to suggest better use cases for the "Basic Use Cases" post your suggestions (or send them to me directly) and I will try to incorporate them into the Use Cases document. The we can go through the document and scrub out the ones that seem to be duplicate or unnecessary.

Jeff Bohren
Product Architect
OpenNetwork Technologies, Inc

Try the industry's only 100% .NET-enabled identity management software. Download your free copy of Universal IdP Standard Edition today. Go to www.opennetwork.com/eval.

-----Original Message-----
From: Gearard Woods [mailto:gewoods@us.ibm.com]
Sent: Tuesday, April 06, 2004 1:33 PM
To: Jeff Bohren
Cc: Gary Cole; provision@lists.oasis-open.org
Subject: RE: [provision] SPML 2.0 Use Case doc, first draft...


If I could just add a comment. I think if use cases are to be useful as a tool in the 2.0 effort, we should revisit the "Basic Use Cases" and re-orient their perspective. I have two interrelated reasons for saying this:
1. The original use cases are too low level in my opinion and unnecessarily reflect a number of preconceptions regarding implementation.
2. The use cases do not identify the goals of the SPML or the business use cases that offer benefit to all of the committee members.

The first point is reflected in the questions raised by Gary about the creator of IDs etc. These are, to me, low-level concerns that probably do not belong in the use cases to begin with. More important is the description of specific elements in the request such as a client-generated request ID. Whatever about the question of who takes responsibility for creation of PSO-IDs, it is really not necessary to dictate that the client generate a request ID for every request. It might be argued that the inclusion of a request ID speaks to the ability to batch requests. If that is so, I would argue that there should be a "Batch Request" use case.

In terms of identifying the high-level goals of the SPML, the original use cases fail because they do not speak to the real scenarios where the SPML offers benefit. In fact, those of us who were at the last face-to-face will recall that there is still confusion about some of the fundamental questions surrounding a primary goal: Interoperability. I submit that the use cases should identify interoperability scenarios to put pay to these questions once and for all. A set of use cases at this level would serve to focus the efforts of the PSTC and would also be a valuable tool to describe the potential benefits of the SPML.

Jeff's Federation use case is a start on the road to higher level scenarios but I do feel that it falls into the same trap of approaching the problem from too low a level. From our point of view, federation is not exposed through the public interface and so does not have a convenient sequence of messages that turn it on or off. This does not in the least mean that a use case is not valuable, it just means that, in my opinion, the use case should refrain from attempting to define a set of sepecific messages that effect federation.

I would be a little hesitant to endorse the Organization use cases for the same reasons. Our product relies heavily on the notion of organizational structure, and perhaps the concept is universal enough that it should be included in some form, but a use case less tied to a specific set of operations might be more useful.
Gerry

"Jeff Bohren" <jbohren@opennetwork.com>



"Jeff Bohren" <jbohren@opennetwork.com> 04/05/2004 08:10 PM

To: "Gary Cole" <gary.cole@waveset.com> cc: <provision@lists.oasis-open.org> Subject: RE: [provision] SPML 2.0 Use Case doc, first draft...




All of the "Basic Use Cases" (the A-* ones) are simply the SPML 1.0 Use Cases, so I really can't take the credit (or blame depending on how you look at it) for those.

Some participants in the SPML 1.0 effort felt strongly that the PSP should be responsible for assigning unique identifiers for new PSOs and some felt that the RA should be responsible, hence those use cases.


Jeff Bohren
OpenNetwork Technologies



-----Original Message-----
From: Gary Cole [mailto:gary.cole@waveset.com]
Sent: Mon 4/5/2004 2:40 PM
To: Jeff Bohren
Cc: provision@lists.oasis-open.org
Subject: Re: [provision] SPML 2.0 Use Case doc, first draft...


Hot dog!  You *have* been busy.  I think these use cases are a great basis for discussion.  Just so you're not surprised, here's what I intend to ask:

A-1:  Why let the RA specify PSO-ID?  What if the specified value is invalid or non-unique?  The PSO-ID identifies the PSO to the PSP, so it must be valid and unique within the (ID namespace managed by the) PSP.

Even if you let the RA *suggest* a PSO-ID, we should specify that the PSP returns PSO-ID.

A-3:  When you say "attributes", do you mean specifically attributes or do you mean (more generically) "content"?  

I'm guessing the latter, since we discussed using XPATH expressions to specify replacement of content in complex XML objects.

A-5:  Why let the RA generate PSTD-ID?  Username for an Account is fine; but I don't think that username should be the PSTD-ID (e.g., because the account could be natively renamed).  The PSTD-ID should be opaque, unique, and meaningful only to the PSP.  The PSP should therefore generate it.

Even if you let an RA *suggest* PSTD-ID, we should specify that the PSP returns the PSTD-ID.

A-6: More of A-5.  PST may generate native identifier(s), but PSP should define PSTD-ID.

A-7: Suggest using the word "Implicit" rather than "Pass-through".

Gary

----- Original Message -----
From: Jeff Bohren <mailto:jbohren@opennetwork.com>  
To: provision@lists.oasis-open.org
Sent: Monday, April 05, 2004 9:00 AM
Subject: [provision] SPML 2.0 Use Case doc, first draft...

Attached is the first draft of the SPML 2.0 Use Case document. Please review this document for discussion on the next conference call.

Darran, could you add an agenda item for the next conference call to review this?