[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [provision] Community input on Future of Standards-BasedProvisioning and SPML
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 > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]