RE: [provision] A Proposal for using DSML for Provisioning

[Tony Gullotta <TGullotta@access360.com>]

I like DSML, but I'm afraid that all by itself, there may be some small
points that won't fit in completely. For example, requesting a service
passing only the type of service you are subscribing for, then in the
result message sent back later, the PSP would provide the subscriber his
user id, password, etc. I'm not sure if DSML accounts for an interaction
like that. Do you think we can cover these fringe requirements with DSML
alone? Maybe DSML can be used more as a format for payload information
that we can wrap with a more provisioning flexible operational protocol?

Tony

-----Original Message-----
From: jbohren@opennetwork.com [mailto:jbohren@opennetwork.com]
Sent: Friday, July 26, 2002 10:37 AM
To: mpolan@ca.ibm.com
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
>
> |---------+---------------------------->
> |         |           jbohren@opennetwo|
> |         |           rk.com (Jeff     |
> |         |           Bohren)          |
> |         |                            |
> |         |           07/24/2002 02:31 |
> |         |           PM               |
> |         |                            |
> |---------+---------------------------->
>
>-----------------------------------------------------------------------
------------------------------------------------------------------------
---|
>   |
|
>   |       To:       Tony Gullotta <TGullotta@access360.com>
|
>   |       cc:       provision@lists.oasis-open.org
|
>   |       Subject:  Re: [provision] A Proposal for using DSML for
Provisioning
|
>   |
|
>   |
|
>
>-----------------------------------------------------------------------
------------------------------------------------------------------------
---|
>
> Tony,
>
> No, I would not say that is true in general, although it might be in
some
> cases. In use case 5 the RA is the requestor that is requesting a PSTD
on
> the behalf of a specific principle. The principle that is used for
> authenticating request at the protocol (i.e. SOAP) may or may not be
the
> principle of the RA. If it is not, then the authRequest tag must be
used to
> specificy that the principle upon which authroization decisions are to
be
> made is the principle of the RA. Obviously the principle that was used
for
> the protocol must have privalege to impersonate the RA.
>
> Jeff Bohren
>
> Tony Gullotta wrote:
>
> > So are you saying that the principal used for authentication of the
DSML
> > request would be used to identify the end-user being provisioned
when
> > communicating between the RA and PSP. In example 5 then,
provisioning
> > the email account jsmith@acme.com would be linked back to the
identity
> > cn=John Smith,o=acme.com for authorization of the provisioning
request.
> > Or to put it another way, the PSP would authorize that cn=John
> > Smith,o=acme.com could have the email account before provisioning
it.
> >
> > Tony
> >
> > -----Original Message-----
> > From: jbohren@opennetwork.com [mailto:jbohren@opennetwork.com]
> > Sent: Tuesday, July 23, 2002 9:44 AM
> > To: provision@lists.oasis-open.org
> > Subject: [provision] A Proposal for using DSML for Provisioning
> >
> > Since I keep bringing this up, it is only fair that I put forth some
> > concrete details. Attached is a rough draft I did this morning for a
> > proposal for using DSML for provisioning. Bear in mind that this is
a
> > very rough draft, but I think this gives us a good starting point
for a
> > discussion on the issue.
> >
> > --
> > Jeff Bohren
> > Product Architect
> > OpenNetwork Techologies
> > jbohren@opennetwork.com
> > (727) 561-9500x219
>
> --
> Jeff Bohren
> Product Architect
> OpenNetwork Techologies
> jbohren@opennetwork.com
> (727) 561-9500x219
>
> ----------------------------------------------------------------
> 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>

--
Jeff Bohren
Product Architect
OpenNetwork Techologies
jbohren@opennetwork.com
(727) 561-9500x219



----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>