[provision] Additional aggregation/composition use cases required?

[mpolan@ca.ibm.com]

Sorry for my delay in continuing this thread.  Darran and I have been
discussing whether or not additional use cases are needed, and we wanted to
get the opinion of the rest of the group.

The use cases that I am proposing involve the thought that services being
provisioned may be either aggregated or composed by a PSP.  By aggregation,
I mean that a PSP may be a single access point offering services fulfilled
by other PSPs.  By composition, I mean a service offered by a PSP is
composed of services offered by other PSPs.

The high level flow would be:  RA to PSP [to one or more PSPs] to their
respective PSTs.  One or more would distinguish between aggregation and
composition (if we should find a distinction to be necessary), and the
square brackets indicate that those PSPs might in turn use composition or
aggregation to provide those services.

I think the issues to be resolved center around how and to where identities
flow, ie: which systems know about jdoe and jsmith (from the discussion
below).  One model is that a PSP becomes an RA to the next PSP.  As an RA,
which identities does the PSP pass through to the PSP on the next level?
Does the PSP/RA use an internal identity itself?  Similarly, we'd need to
figure out how/when PSU-IDs and PSTD-IDs would be created and flow.

Should the model be that the PSP to PST flow is the same as the RA to PSP
flow, so that aggregation/composition are simply the existing flows?  That
is, should it matter to the PSP or the RA that the PST is provided by a
separate PSP?  I would expect that security, billing and SLA considerations
will come into play here.

Depending on what we decide with the above, most of the use cases would be
affected.  In particular, we would need to look at a UC #9 & 10, perhaps by
adding a PSP-PSP version for add PSTD.  Does is make sense to add new UC's,
or should we generalize the existing ones?  I think this question pivots
around whether the back end PSPs are aware of the original RAs or not.

Mike Polan
IBM Canada Ltd






|---------+---------------------------->
|         |           jbohren@opennetwo|
|         |           rk.com (Jeff     |
|         |           Bohren)          |
|         |                            |
|         |           07/26/2002 01:37 |
|         |           PM               |
|         |                            |
|---------+---------------------------->
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                                                  |
  |       To:       Mike Polan/Toronto/IBM@IBMCA                                                                                                     |
  |       cc:       provision@lists.oasis-open.org                                                                                                   |
  |       Subject:  Re: [provision] A Proposal for using DSML for Provisioning                                                                       |
  |                                                                                                                                                  |
  |                                                                                                                                                  |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|




That is pretty much the gist of it, as I see it. There is an implied third
party, which is the party (most likely a system) that makes the request at
the
protocol layer. Suppose that the RA is a provisioning system (system A) in
one domain and the PSP is a provisioning system (system B) in another.
There is
a supervisor user named jdoe that has rights to request a PSTD for jsmith.
Now the trust relationships would be:

Systems A and B have a trust relationship.
System A has the rights to impersonate user jdoe.
jdoe has the rights to request a PSTD for user jsmith

So then the flow might be:

1) jdoe requests a PSTD for jsmith in System A.
2) System A sends a DSML addRequest to System B, using the authRequest tag
to refer to jdoe.
3) System B processes the request and sends a response to System A.
4) System A sends a response to jdoe.

In this case System B has knowledge of all three parties involved in the
request.

Although these are interesting questions, does anyone have any comments
about the overall notion of using DSML for provisioning? Is this something
that
makes sense?

Jeff B.

mpolan@ca.ibm.com wrote:

> Can I play this back to make sure I understand?
>
> The RA requests a PSTD for the principle specified in the request data.
So
> there will be authorization of
> 1) The RA as entitled to request PSTDs
> 2) the RA as entitled to act for the principle in requesting this PSTD in
> particular
> 3) The principle of being entitled to have the new account allocated
>
> Is that right?
>
> I've been wondering if a 3rd party should be added as a parameter to this
> and related requests.  The use cases support the delegation of request -
> that is a PSP or PST becoming an RA in order to complete a provisioning
> request, right?  If a request has been delegated, might it be necessary
to
> also know the original RA?
>
> Mike Polan
> IBM Canada Ltd
>