Re: [provision] SPML Interop Storyboard.

[Gary P Cole <Gary.P.Cole@Sun.COM>]

Thanks, Jeff.  Please see inline.

Bohren, Jeffrey wrote:

>Some comments about Gary's and Kent's feedback on the interop:
>
>- The schema does not necessarily need to be returned by inclusion in
>the list targets response. The schema could be defined by reference and
>the referred to schema could be exchanged by the client and server
>out-of-band.
>  
>
For purposes of this interop, should we agree to recognize a particular 
namespace as referring to the DSML schema (and another namespace as 
referring to the XSD schema)?  Since the Interop scenario specifies a 
schema,  wouldn't  this simplify things?

>- For the DSML Profile the PSO object class is determined by setting the
>reserved attribute "objectclass". This is the same as now SPML 1.0
>worked.
>  
>
Thank you.  (I actually looked for an "objectclass" attribute in the 
XSDs but got nervous when I didn't find one.)

>- I would be careful about assuming that if a service supports both the
>DSML profile and the XSD Profile, the same ID in both profiles would
>mean the same underlying PSO. That is not a valid assumption.
>  
>
I absolutely agree.  First, the same ID should not normally occur on two 
targets.  Second, the same ID in two psoIDs with different targetIDs 
should not refer to the same underlying PSO. 
(I was working quickly, so the fact that both profiles show ID="27" is 
an oversight. 
I'll clean up my storyboard.)

>- In the user self-service use case, the assumption is made that the
>user is logging into an IdM system that will do password maintenance
>using SPML to other provisioned resources.
>  
>
Hmmm.  I was hoping to produce for the interop a test case (or a set of 
test cases) that could be automated.  That way, I could run (and re-run, 
if necessary) the same scenario against several different providers.  I 
would like to avoid manual steps (such as an interactive login) if possible.

Perhaps we could avoid an interactive login by exposing, in addition to 
the PSP, a resource such as an LDAP directory service as the implicit 
target of the PSP.  This would allow us to programmatically verify the 
existence or deletion of an account as well as its password.

Does this sound like a good idea?

>- For the "DA Grants Roles Use Case" it is not required that the client
>search for roles to grant. The roles that are granted and revoked for
>this use case can be negotiated out-of-band by the participants. This
>better reflects reality anyway.
>  
>
Again, I was hoping for a test case (or a set of test cases) that could 
be automated.  For that, I think we'd need one of the following:
- pre-arrangement (e.g., a role with a specific PSO-ID must already exist)
- the search capability (in order to list roles and select a role)
- each requestor should add (and subsequently delete) a role.

I suppose that if each provider also exposes an LDAP directory as the 
implicit target of provisioning, we could use LDAP to list roles or 
search for a role.  We could also verify the creation of a role if that 
is necessary.

>- No call to closeIterator is ever required unless the client does not
>wish to fetch all of the search results. When the last batch of data is
>returned, there will be an iterate response that returns only with
>search results and not an iterator. When that happens, the iterator
>should be closed automatically with no prompting from the client.
>  
>
Agreed.  However, this suggests a question.  Should closing an iterator 
that is already closed return an error?  Or should this be harmless?

>- we should assume that "deprovision" for the interop means a delete
>request not a suspend request.
>  
>
Thank you.  Delete is simplest.

>- the "Administrative Reconciliation Use Case" is intended for an client
>to discover accounts created out-of-band. Showing this would be done an
>ad-hoc basis. For instance if the SPML service provider front-ends an
>IdM system, then the provider can expose the web interface to create
>account out-of-band. 
>  
>
Again, I was hoping for a test case that can be automated.

Perhaps we could automate this if each provider exposes an LDAP 
directory as the implicit target of provisioning.  This would allow a 
requestor to create accounts out-of-band (i.e., without going through 
the PSP), and later to reconcile them, all programmatically.