RE: [provision] Community input on Future of Standards-BasedProvisioning and SPML

[Hal Lockhart <hal.lockhart@oracle.com>]

My apologies to all. I misread the announcement and thought it was at 5:00 ET.

Do we have a new meeting time? Will someone publish minutes?

Hal

> -----Original Message-----
> From: John, Anil [mailto:Anil.John@jhuapl.edu]
> Sent: Monday, August 30, 2010 2:13 PM
> To: Hal Lockhart; Gary Cole
> Cc: provision@lists.oasis-open.org; Mark Diodati
> (Mark.Diodati@gartner.com)
> Subject: RE: [provision] Community input on Future of Standards-Based
> Provisioning and SPML
> 
> 
> Gary & Hal,
> 
> Re: "Connector problem"
> 
> This is meant to speak at the higher level that current 
> provisioning systems require custom connectors (that are 
> proprietary) to connect to existing systems and that SPML is 
> seen as the way to get away from that arena.
> 
> Re: "Optional, Standard Schema"
> 
> Think analog to inetOrgPerson (Payload) for provisioning use, 
> not about the XSDs defined by as part of the SPML protocol (Plumbing).
> 
> Regards,
> 
> - Anil
> 
> > -----Original Message-----
> > From: Hal Lockhart [mailto:hal.lockhart@oracle.com]
> > Sent: Monday, August 30, 2010 1:57 PM
> > To: Gary Cole
> > Cc: John, Anil; provision@lists.oasis-open.org; Mark Diodati
> > Subject: RE: [provision] Community input on Future of 
> Standards-Based
> > Provisioning and SPML
> >
> > Yes, I am sorry it has been a long time and I have forgotten the
> > terminology.
> >
> > Simplifying the provider is I believe what was intended. I am not
> > expressing my opinion, BTW, simply trying to interpret the 
> results from
> > the SIG. The first 4 of the 6 bullets seem to be aimed at 
> simplifying
> > implementations. The point about conformance may not be 
> something the
> > TC can do anything about. The one about a schema is confusing, I
> > thought SPML had a schema. Are they talking about schemas for the
> > actual provisioning data?
> >
> > Hal
> >
> >
> > > -----Original Message-----
> > > From: Gary Cole
> > > Sent: Monday, August 30, 2010 1:13 PM
> > > To: Hal Lockhart
> > > Cc: John, Anil; provision@lists.oasis-open.org; Mark Diodati
> > > Subject: Re: [provision] Community input on Future of 
> Standards-Based
> > > Provisioning and SPML
> > >
> > >
> > > I think the terminology or the diagram may be confusing.  A
> > > requestor
> > > (RA) requests operations of a provider (PSP).  The 
> provider manages
> > > identities (PSOs) on at least one target application 
> (PST).  The PST
> > > is the actual target application--e.g., an instance of 
> PeopleSoft or
> > > RACF or Active Directory--but is not at a part of the
> > > implementation,
> > > so we cannot simplify the PST.  We can simplify the requestor or
> > > provider--usually the provider.
> > >
> > > The simplest provider manages identities on a single 
> target.  A more
> > > complex provider may manage identities on several 
> targets, in which
> > > case the provider's listTargetsResponse should list the available
> > > targets and describe the schema for each target.
> > >
> > > If we interpret the diagram as if each of these entities were code
> > > that we write (as it sounds like you have), then the PST
> > > would be the
> > > component that is specific to each type of target
> > > application.  In the
> > > original terminology, that's still a provider (PSP), 
> perhaps front-
> > > ended by another PSP that is visible to remote requestors.
> > >
> > > Terminology aside, then, you think the connector problem is
> > > simplifying the development and testing (and perhaps
> > > certification) of
> > > a *provider* for each type of target application?
> > >
> > > Gary
> > >
> > > On Aug 30, 2010, at 11:56 AM, Hal Lockhart wrote:
> > >
> > > > Reading between the lines of Mark's blog, I think what is meant
> > > > about the connector problem is that since in a typical scenario,
> > > > there is one PSP provisioning multiple PSTs. Therefore 
> if the PSTs
> > > > can be made as simple as possible, with the PSP doing 
> most of the
> > > > work, the overall complexity of engineering a solution will be
> > > > minimized.
> > > >
> > > > Is that approximately correct, Anil?
> > > >
> > > > Hal
> > > >
> > > >> -----Original Message-----
> > > >> From: Gary Cole
> > > >> Sent: Monday, August 30, 2010 12:34 PM
> > > >> To: John, Anil
> > > >> Cc: provision@lists.oasis-open.org; Mark Diodati
> > > >> Subject: Re: [provision] Community input on Future of
> > > Standards-Based
> > > >> Provisioning and SPML
> > > >>
> > > >>
> > > >> Thank you for posting this, John. This statement by 
> the SPML SIG
> > > >> certainly helps to frame our discussion.  In order to 
> advance that
> > > >> discussion, it would be helpful to have a description of the
> > > >> "connector problem" and of the use-provisioning use-cases
> > > for cloud-
> > > >> based applications.  Would this SIG (or its members) be able to
> > > >> provide this kind of direction?
> > > >>
> > > >> I like the idea of a simple profile, and I look forward to the
> > > >> development of a consensus.  Perhaps the concrete use-cases for
> > > >> provisioning to cloud-based applications will help to 
> focus this
> > > >> profile and to limit some of the flexibility that
> > > >> participants in the
> > > >> specification of SPMLv2 and its DSML and XSD profiles required.
> > To
> > > >> that end, I offer a few comments and ask a few questions
> > > intended to
> > > >> clarify the "Back to Basics" description of the simple
> > > >> profile (inline
> > > >> below).
> > > >>
> > > >> On Aug 25, 2010, at 3:31 PM, John, Anil wrote:
> > > >>
> > > >>> All,
> > > >>>
> > > >>> I am sure that folks here have been tracking the
> > > >> conversation around
> > > >>> Standards based provisioning and SPML that was 
> initiated by Mark
> > > >>> Diodati of Gartner/Burton Group and since then has 
> continued both
> > > >>> online and at the SPML SIG that was held at the the
> > Gartner/Burton
> > > >>> Group Catalyst Conference last month.  Mark recently 
> posted the
> > > >>> notes of that meeting on his Gartner blog
> > > >> (http://blogs.gartner.com/mark-diodati/
> > > >>> ) and the consensus agreement of the participants in the SIG
> > (Full
> > > >>> Disclosure: I was a participant in the SIG)
> > > >>>
> > > >>> I wanted to make sure that it was provided to the SPML TC as
> > input
> > > >>> into the TC Charter discussions we will soon be 
> having (Full text
> > > >>> below as well as link to original entry)
> > > >>>
> > > >>> Regards,
> > > >>>
> > > >>> - Anil
> > > >>>
> > > >>> :-
> > > >>> :- Anil John
> > > >>> :- Johns Hopkins University - APL
> > > >>> :- http://www.jhuapl.edu
> > > >>> :- +1 240.228.0612
> > > >>> :-
> > > >>> :- E-Mail Response Time: 24 hrs
> > > >>>
> > > >>> ========================
> > > >>>
> > > >>> Consensus on the Future of Standards-Based 
> Provisioning and SPML
> > > >>>
> > > >> http://blogs.gartner.com/mark-diodati/2010/08/20/consensus-on-
> > > >> the-future-of-standards-based-provisioning-and-spml
> > > >>> by Mark Diodati  |  August 20, 2010
> > > >>>
> > > >>> I had the honor of facilitating the Standards-Based 
> Provisioning
> > > >>> Special Interest Group at this year's Catalyst conference. The
> > > >>> participants believe that standards-based provisioning is at a
> > > >>> crossroads and wish to publish the following statement. The
> > > >>> statement is based upon our conversation; all of the 
> participants
> > > >>> have reviewed it.  I hope that the perspectives of 
> these industry
> > > >>> luminaries push the industry (and the especially the
> > > >> newly-reformed
> > > >>> OASIS Provisioning Services Technical Committee) 
> towards a viable
> > > >>> provisioning standard.
> > > >>>
> > > >>> ---------------------------------------
> > > >>>
> > > >>> Moving Forward on Standards-Based Provisioning
> > > >>> On Tuesday, July 27 a group met at the annual Burton 
> Group North
> > > >>> America Conference in San Diego to discuss the future of
> > > >>> standardized provisioning and Service Provisioning Markup
> > Language
> > > >>> (SPML). The group readily achieved a consensus about two
> > > >> things: the
> > > >>> need for standards-based provisioning and the qualities
> > > >> required for
> > > >>> successful provisioning standard. The following people
> > > >> participated
> > > >>> in the special interest group (SIG):
> > > >>>
> > > >>> Abdullah Haydar (Open Dealer Exchange)
> > > >>> Andrew Ferguson (e2B2Bcom)
> > > >>> Anil John (Johns Hopkins)
> > > >>> Ash Motiwala (Identropy)
> > > >>> Chuck Mortimore (salesforce.com)
> > > >>> Jacob Farmer (Indiana University)
> > > >>> Jonathan Sander (Quest)
> > > >>> Mat Hamlin (SailPoint)
> > > >>> Nick Nikols (Novell)
> > > >>> Nishant Kaushik (Oracle)
> > > >>> Steven Legg (e2B2Bcom)
> > > >>> Tony Goulding (CA)
> > > >>>
> > > >>> The participants have firsthand experience with the
> > > >> difficulties of
> > > >>> proprietary provisioning from the perspective of both
> > > >> vendor and end-
> > > >>> user organizations. The SIG meeting was particularly
> > > >> timely, as the
> > > >>> Organization for the Advancement of Structured Information
> > > >> Standards
> > > >>> (OASIS) is evaluating the need for an SPML v3 standard.
> > > >>> Additionally, the SaaS market is at a critical juncture as
> > vendors
> > > >>> look for standards-based solutions to the 
> provisioning problem.
> > > >>>
> > > >>> SPML v2
> > > >>>
> > > >>> The second iteration of the SPML standard was approved in
> > > >> the spring
> > > >>> of 2006 and included additional capabilities and
> > > >> operational modes.
> > > >>> In trying to address every possible use case, interoperable
> > > >>> provisioning services leveraging the SPML v2 standard became
> > > >>> impractical. Since the approval, few (if any) conformant
> > > >>> implementations exist due to the complexity of the v2 
> standard.
> > > >>> Additionally, vendor participation in the OASIS Provisioning
> > > >>> Services Technical Committee (PSTC) has been nearly 
> non-existent
> > > >>> since v2 was approved.
> > > >>>
> > > >>> Organizations wishing to use SPML must write provisioning
> > services
> > > >>> specifically for each vendor's SPML implementation 
> (if the vendor
> > > >>> supports SPML at all). The difficulty in building a single,
> > > >>> interoperable provisioning service has made the adoption of
> > > >> SPML by
> > > >>> application developers a non-starter. Without adoption by
> > > >> enterprise
> > > >>> and cloud application developers, SPML will not be adopted. In
> > > >>> conclusion, the SPML v2 standard is broken.
> > > >>>
> > > >>> Back to Basics
> > > >>>
> > > >>> The next iteration of SPML should focus on solving 
> "the connector
> > > >>> problem" and provisioning use cases for cloud-based 
> applications.
> > > >>> That is, the next version of SPML should readily enable the
> > > >>> development of simple, standards-conformant 
> provisioning services
> > > >>> for both enterprise and cloud applications.
> > > >>>
> > > >>> The participants agree that a standards-based provisioning
> > > >> protocol
> > > >>> is needed, and all concluded (except Chuck Mortimore) 
> that it is
> > > >>> best to evolve the SPML standard rather than 
> introduce a new one
> > > >>> (salesforce.com has not yet arrived at this 
> conclusion). The next
> > > >>> iteration of SPML needs to become simpler. It must support
> > > >> a simple
> > > >>> use case for conformant, standards-based provisioning 
> services.
> > > >>> Additionally, the SPML standard is too imbalanced; it 
> places too
> > > >>> much burden on target applications. The participants assert
> > > >> that the
> > > >>> next version of SPML must possess a "simple" profile for to be
> > > >>> successful. The simple profile should include the following
> > > >> qualities:
> > > >>>
> > > >>> * Provide basic create, read, update and delete (CRUD)
> > operations.
> > > >>
> > > >> I assume this is a statement of required scope for the simple
> > > >> profile.  Aside from listTargets, these are the only
> > > operations that
> > > >> SPMLv2 requires.
> > > >>
> > > >>> * Focus on the default use case of a single 
> provisioning service
> > > >>> point (PSP) and provisioning service target (PST). This use
> > > >> case is
> > > >>> the default one for application developers and end-user
> > > >> organizations.
> > > >>
> > > >> SPMLv2 optimizes the use-case of a single target by 
> allowing the
> > > >> 'targetId' parameter to be omitted when a provider 
> exposes only a
> > > >> single target.  The listTargetsResponse for a minimal
> > > >> provider (or for
> > > >> a provider whose capabilities are well-known to the
> > > >> requestor) can be
> > > >> very terse.
> > > >>
> > > >> In what other ways should the simple profile focus on this
> > > >> default use-
> > > >> case?
> > > >>
> > > >>> * Eliminate transactional auditing requirements. In
> > > >> particular, the
> > > >>> Updates capability places an impractical data retention and
> > > >>> performance burden on the application.
> > > >>
> > > >> The Updates Capability is optional.  No provider is required to
> > > >> support this capability.
> > > >>
> > > >>> * Support a simple search mechanism. The current 
> search mechanism
> > > >>> can create nearly infinite search parameters across all known
> > user
> > > >>> attributes, which places an undue burden on the application.
> > > >>
> > > >> The design point for the DSML Profile was LDAP search. 
>  The design
> > > >> point for the XSD Profile was XPath search.  What would be
> > > >> the design
> > > >> point for search in the simple profile?
> > > >>
> > > >> Is the goal to improve the convenience of simple 
> searches for the
> > > >> requestor, or to simplify the search function that a 
> provider must
> > > >> support?  If the goal is to simplify the search function that a
> > > >> provider MUST support, would conformance with the simple
> > > >> profile also
> > > >> restrict the search function that a provider MAY support?
> > > >>
> > > >>> * Enforce conformance. Vendor's products must undergo 
> conformance
> > > >>> testing prove interoperability. Conformance likely requires a
> > > >>> reference implementation.
> > > >>
> > > >> This seems like an excellent suggestion.  If we can define (and
> > can
> > > >> agree to) a common set of behavior expectations, this
> > > should greatly
> > > >> simplify the process of developing and certifying a
> > > provider.  Would
> > > >> we want to do something similar for requesters?
> > > >>
> > > >>> * Provide an optional, standard schema. An optional
> > > >> standard schema
> > > >>> (like LDAP's inetorgperson) provides a potential schema for
> > > >>> immediate interoperability with other applications.
> > > >>
> > > >> This sounds highly desirable.  If participants can 
> define (and can
> > > >> agree to) a common set of attributes (and potentially
> > > common object-
> > > >> classes), this should greatly facilitate interoperability.
> > > >>
> > > >> The first questions that occur to me are: Would this
> > > standard schema
> > > >> need to be extensible?  Would all attributes be required?
> > > >> Would each
> > > >> predefined attributes imply a certain contract that the
> > conformance
> > > >> tests could exercise?
> > > >>
> > > >>>
> > > >>> The Path Ahead
> > > >>>
> > > >>> It is up to vendor and end-user organizations to move the SPML
> > > >>> standard forward so that the industry can begin to build
> > > >>> interoperable provisioning services. If you are interested in
> > > >>> influencing the direction of standards-based provisioning
> > > >> and SPML,
> > > >>> please consider participating in the OASIS PSTC.
> > > >>>
> > > >>>
> > > >>>
> > > >>
> > > 
> ---------------------------------------------------------------------
> > > >>> To unsubscribe from this mail list, you must leave the
> > > OASIS TC that
> > > >>> generates this mail.  Follow this link to all your TCs in
> > > OASIS at:
> > > >>>
> > > >> https://www.oasis-open.org/apps/org/workgroup/portal/
> > > >> my_workgroups.php
> > > >>>
> > > >>
> > > >>
> > > >>
> > > 
> ---------------------------------------------------------------------
> > > >> To unsubscribe from this mail list, you must leave the
> > > OASIS TC that
> > > >> generates this mail.  Follow this link to all your TCs in OASIS
> > at:
> > > >> https://www.oasis-open.org/apps/org/workgroup/portal/
> > > >> my_workgroups.php
> > > >>
> > > >>
> > >
> > >
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> 
>