[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [provision] Additional aggregation/composition use cases required?
Mike, On additional use cases, I agree with your assessment. Implicit in this is a statement that needs to be clearly called out. When a PSP aggregates services from a downstream PSP, the protocol represents no material knowledge of that relationship. Example: - PSP-1 aggregates service-A from PSP-2 and advertises it as service-B - PSP-2 implements service-A by creating an account on PST-1 - RA-1 has an established provisioning relationship with PSP-1 Statements: - RA requests service-B from PSP-1 - RA does not see PSP-2's service-A - When RA requests service-B, PSP-1 manages the request flow with PSP-2 - PSP-1 adopts the role of RA in it's request flow with PSP-2 - PSP-1 has no direct control or request flow to PST-1 On a PSP communicating with a PST in another "domain", I'd say that when ever a PSP is communicating with a PST, the PST is considered "in-domain". If we assume an established trust relationship between the PSP and the PST we are assuming it within the provisioning domain. -------------------------------------------------------- Darran Rolls http://www.waveset.com Waveset Technologies Inc drolls@waveset.com (512) 657 8360 -------------------------------------------------------- > -----Original Message----- > From: mpolan@ca.ibm.com [mailto:mpolan@ca.ibm.com] > Sent: Tuesday, October 08, 2002 1:55 PM > To: provision@lists.oasis-open.org > Subject: RE: [provision] Additional aggregation/composition use cases requ > ired? > > > I spent some time working on this idea and adding in Tony's points, and > came up with a short write up that I've pasted below. Net of it is that > the PSP to PSP aggregation scenarios don't appear to require extensions to > the use cases, as the information exchanges and the data content looks to > be no different from the base use cases. I could only come up with one > wrench to throw into the discussion. I've been thinking about the case > where the front end PSP or the PST act as RAs to the back end PSPs. > Should > we consider use cases where PSPs would talk to PSTs that reside in a > different domain (that is, normally controlled by a different PSP)? Does > that even make sense? > > PSP to PSP Interactions > > There are use cases that involve a "wholesale" model where the actual > service is provided by a PSP other than the one that an RA contacts > directly. Two variations are of interest: > > a. A PSP that is aggregating services by serving as a retail front end > to back end PSP(s). > b. A PSP that offers services composed from those provided by back end > PSPs. > > In both cases, the back end PSPs may not be aware of the PSU of the > requestor of the service. The back end PSPs would represent the user of > the service via a PSU containing details only of the front end PSP. The > actual service users would be anonymous. The front end PSP in these cases > would manage the identity swapping needed for this scenario > programmatically. This could be implemented by providing PSTs that would > represent and act as RAs to remote PSPs. The use cases as defined already > cover these scenarios. > > A more interesting variation of these use cases is presented when the back > end PSPs do need to be aware of the identity of the consumer of the > service. This would be necessary for example to allow personalization of > the provisioned services. In this case the front end PSP would need to > cause the creation of user and service accounts (PSUs and PSTDs) on the > remote PSPs. > > In the anonymous case, the front end PSP creates a single PSU on the back > end PSPs the first time the service is requested by any RA. In the > non-anonymous case, the PSPs would likely defer creation of PSUs on the > back end PSPs until the first time a given user required the service. > When > a request to provision a service offered by the front end PSP arrived, > that > PSP would need to determine which back end PSPs would be targets and act > as > an RA. Again, these exchanges would operate by using the existing use > cases. No additional use cases or extensions are necessary. > > > Mike Polan > IBM Canada Ltd > > > > > |---------+----------------------------> > | | Tony Gullotta | > | | <TGullotta@access| > | | 360.com> | > | | | > | | 09/16/2002 06:11 | > | | PM | > | | | > |---------+----------------------------> > >----------------------------------------------------------------------- > ------------------------------------------------------------------------ -- > -| > | > | > | To: Mike Polan/Toronto/IBM@IBMCA, provision@lists.oasis- > open.org > | > | cc: > | > | 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> > > > > > > ---------------------------------------------------------------- > 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