OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

provision message

[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