[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [provision] Additional aggregation/composition use cases requ ired?
I definitely think these scenarios should be covered. In my opinion, its better to separate them into separate use cases so they can be given the proper focus so not to miss any subtle differences. Then, when implementing a protocol specification, look for the similarities and try to merge all the concepts into one consistent implementation. Tony -----Original Message----- From: mpolan@ca.ibm.com [mailto:mpolan@ca.ibm.com] Sent: Wednesday, August 07, 2002 12:49 PM To: provision@lists.oasis-open.org Subject: [provision] Additional aggregation/composition use cases required? 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 > ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC