| I don't have a problem removing "XML-based" and saying just "standard framework". That language was copied from the current SSTC Charter.
Gary
ps. Just to follow your thought, a RESTful approach would be *very* different from what we have today. SPML defines the *verbs* (i.e., operations) and leaves open the nouns (i.e. payload). Rather than require a standard schema that would apply across profiles, SPML2 abstracts common attributes as sets of operations. For example, rather than recognize a special "password" attribute (which would be difficult to do in an XSD Profile, where each provider decides what XML schema to expose), SPML specifies a Password capability that contains password-related operations such as changePassword() or resetPassword(). Rather than specify a "disabled" attribute, SPML2 specifies suspend() and resume() and active() operations.
As you know, RESTful design is noun-based: Resource-Oriented Architecture. As much as possible, URLs represent resources, such as an identity or an attribute within an identity, and a RESTful client uses the standard HTTP verbs to manipulate those resources. This approach is an inverse, if you will, of SOA or SPML. Only in really odd cases does an operation end up as a resource in a RESTful representation. (FWIW, I led the development of a provisioning system that supports multiple, equivalent interfaces: RESTful and WSDL and SPML and Java. We funneled all of these interfaces into a single underlying substrate, but the external interfaces looked very, very different. Even in the RESTful approach, the payload was somewhat abstracted. Because we followed the DSML profile of SPML, we could return the payload easily enough in XML or in JSON.)
I guess what I'm saying is that the payload already can be something other than XML, since SPML2 allows each profile (and to some extent, allows each provider) to specify the format of its content.
For that matter, one could implement a protocol that is equivalent to SPML2 without representing the request-response pairs as XML objects. (In fact, I daresay most implementations of an SPML2 Provider already parse the XML request objects into a language-specific representation and then call language-specific functions or methods that return language-specific representations of the response objects, which the provider then converts to an XML representation.) Specifying these request-response pairs as XML objects was the easiest way to remain agnostic with respect to network-transport and with respect to implementation-language. On Oct 22, 2010, at 11:04 AM, Richard Sand wrote: Hi all, Just a reminder, this is the latest draft for the updated PSTC charter that Gary sent out. On our next meeting we’ll discuss it in preparation for an oasis vote. One comment I have to it is regarding “standard, XML-based framework” I’m wondering if we can just say “standard framework” so that we can incorporate other web service mechanisms (e.g. RESTful, maybe non XML payloads like JSON) in possible future work. Not saying we will necessarily do this, but that the charter should be general enough to allow for it. Thoughts? Best regards, Richard Sand | CEO
239 Kings Highway East | Haddonfield | New Jersey 08033 | USA
Mobile: +1 267 984 3651| Office: +1 856 795 1722| Fax: +1 856 795 1733
<image001.jpg> From: Gary Cole [mailto:gary.cole@oracle.com]
Sent: Monday, September 27, 2010 4:04 PM
To: OASIS PSTC
Cc: Daniel A. Perry
Subject: Re: [provision] PSTC Charter The draft charter incorporating Dan Perry's comments is as follows below, after my signature. (My previous post on this subject, sent on September 13, includes for reference the current PSTC charter and the current charter of the SSTC. This draft charter is based on that of the SSTC, but has been adapted for the PSTC. Any error is mine.) Please review the proposed charter and offer any comment or suggestion that you may have. OASIS Provisioning Services TC The original Call For Participation for this TC may be found at <link>. The charter was revised at the a meeting of the TC on <date> as minuted at <link>. The charter for this TC is as follows. Name The official name is the Provisioning Services Technical Committee (PSTC). The PSTC is sometimes unofficially called the "SPML TC" or the "PSTC/SPML committee". Statement of Purpose Inter- and intra-enterprise application architectures require interoperable provisioning services that transcend the boundaries of single security domains. The interoperable exchange of identity information between domains, including the ability to manage identities across such domains, is crucial to developing solutions for provisioning across arbitrary systems and topologies. The purpose of the TC is to define, enhance, and maintain a standard, XML-based framework for creating and managing information that represents user identities and related entities. Scope of Work The TC is engaged in evolving the suite of SPML specifications and in applying those specifications to use-cases that are of interest to its members. The Statement of Purpose above will guide the scope of this effort, which continues after the release of SPML 2.0. This effort will deliver on the following goals: • Address issues and enhancement requests that have arisen from experience with real-world implementations of SPML and from experience with other enterprise architectures that use SPML. • Add support for features that were deferred from previous versions of SPML. • Develop an approach for unifying various identity-provisioning models found in real-world implementations of SPML and in SPML-based provisioning services. List of Deliverables The TC released the V2.0 specifications on <date>. Work products may include updates to the following specifications published by the TC for V2.0: The Committee may also produce additional documents, such as specifications of new SPML profiles. Audience The primary audience for the final output of this TC are the architects and implementers of provisioning services. Language of the TC All business of the TC will be conducted in English.
|