[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [provision] Additional aggregation/composition use cases requ ired?
From some previous investigation on this aggregate service model, we discovered that if the front end PSP is simply signing people up for services provided by other PSP's, then the identity of the subscriber has to be carried through. The first PSP is simply a broker or a vender providing some value-add on top of the back end service. However, since the back-end services are most likely personalized in some way for the subscriber, knowing who the subscriber is can be very important to the back-end service provider. The billing can be simplified for the back-end service provider by having a front-end aggregator, but the identity of the subscriber is still important. Tony -----Original Message----- From: mpolan@ca.ibm.com [mailto:mpolan@ca.ibm.com] Sent: Monday, September 16, 2002 3:02 PM To: provision@lists.oasis-open.org Subject: RE: [provision] Additional aggregation/composition use cases requ ired? Good question, I was wondering the same thing. In the simple aggregation case I think the answer is probably yes. In the composition case, I think the answer is maybe, depending on the type of back end service. But in the retail/wholesale case I was thinking often no, that the PSP would be sharing a single resource among the RAs/Users, and that single resource would be in effect owned by the PSP. That is only the retailer would have an account (PSTD) on the wholesaler's system. Looking at what I've written, I didn't really distinguish between the RA and the users, and you're right, I should have. Mike Polan IBM Canada Ltd |---------+----------------------------> | | Tony Gullotta | | | <TGullotta@access| | | 360.com> | | | | | | 09/16/2002 05:49 | | | PM | | | | |---------+----------------------------> >----------------------------------------------------------------------- ------------------------------------------------------------------------ ---| | | | To: Mike Polan/Toronto/IBM@IBMCA, provision@lists.oasis-open.org | | cc: | | Subject: RE: [provision] Additional aggregation/composition use cases requ ired? | | | | | >----------------------------------------------------------------------- ------------------------------------------------------------------------ ---| Although the identity of the RA is not known by the backend PSPs, the identity of the individual subscribing for the service itself will be known, correct? Tony -----Original Message----- From: mpolan@ca.ibm.com [mailto:mpolan@ca.ibm.com] Sent: Monday, September 16, 2002 2:45 PM To: provision@lists.oasis-open.org Subject: RE: [provision] Additional aggregation/composition use cases required? Continuing this thread (after a long delay, I apologize). Recall this is the scenarios where a PSP uses other PSPs to provision a service. As I look at the existing use cases, I think we need to consider the extensions from the following perspectives: A PSP that is aggregating services by serving as a retail front to back end PSPs; the back end PSPs are unaware of the identity of the original RA and knows only the identity of the PSP. For each request, the PSP switches identities so that the back end PSP sees only the single PSU (which represents the front end PSP). A PSP that is aggregating services by serving as a simple broker to the back end PSPs; the back end PSPs are aware of the identity of the original RA. A PSP acting as a more sophisticated broker offering services composed of those provided by back end PSPs. Those back end services may or may not be referenced using the retail aggregation or the simple broker model. I think the way to approach this is to have new use cases which are similar to 9, 10, 11 and 12. These cases would be PSP-PSP rather than PSP-PST. In the retail front end case, the PSP would share accounts on the remote PSPs with multiple RAs. The easiest way to think of this might be a PST/RA-PSP connection, where the PST provides multiple PSTDs as per use case 9, mapping them to a single PSTD on the backend PSP by acting as an RA. The simple aggregation case is just that, with each PSP-PST call matched by a PST/RA-PSP call. The composition case requires the PSP to manage the aggregated services to appear as one. I picture a PSP-PST call where the PST acts as multiple RAs the back end PSPs, aggregating (composing) the back end PSTDs. Should the use cases reflect PSP-PSP operations, or perhaps it makes more sense to show them as PST/RA-PSP? Use cases 1-8 would be unchanged. Use case 13 would need extended to include the PSP-PSP case, or the PST/RA-PSP case if we went that route. Use cases 16 and 17 would not change, but would require the PSP to represent the PSP-PSP resources just like it must represent the PSP-PST resources. For the retail front and aggregation cases they will be a reflection of the back end PSP-PSTs. In the composition case, the PSP response would need to reflect the composed service. For use case 18, both the retail model and the composed models would manage the PSU/PSTD relationships on their own. Use case 18 might need to be extended for the aggregation model, the PSP would in theory need to query the PST/RA-PSP for the PSU/PSTD relationships (though likely they would be cached). Comments? Mike Polan IBM Canada Ltd |---------+----------------------------> | | Tony Gullotta | | | <TGullotta@access| | | 360.com> | | | | | | 08/07/2002 03:56 | | | PM | | | | |---------+----------------------------> >----------------------------------------------------------------------- ------------------------------------------------------------------------ ---| | | | To: Mike Polan/Toronto/IBM@IBMCA, provision@lists.oasis-open.org | | cc: | | 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> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl> ---------------------------------------------------------------- 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