[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [provision] Discussion and analysis of SPML 2.0 submission from IBM
-----Original Message-----
From: Darran Rolls [mailto:Darran.Rolls@waveset.com]
Sent: Thursday, December 04, 2003 9:31 AM
To: provision@lists.oasis-open.org
Subject: RE: [provision] Discussion and analysis of SPML 2.0 submission from IBMJeff/GerryIt sounds like we have a good waypoint here. If we can converge our efforts around a set of changes that retain the current SPML request/response model, but extends current verbs to support the WS-Provisioning data model, would you both agree that we have something that warrants close inspection?Jeff, if you are taking the lead on such a proposal, I'd like to propose we set an agenda item this Monday to discuss with Gerry and the rest of the team what this might look like?-darran
From: Jeff Bohren [mailto:jbohren@opennetwork.com]
Sent: Wed 12/3/2003 9:35 AM
To: provision@lists.oasis-open.org
Subject: RE: [provision] Discussion and analysis of SPML 2.0 submission from IBMGerry,
I am sorry that you feel that SPML 1.0 spec was railroaded through. The
SPML 1.0 effort took almost 2 years to reach an approved specification.
The effort include individuals from previous standardization efforts,
XRPM, ADPr, and ITML. The direction for the current spec was developed
with the participation and approval of IBM (although via a different
individual representative). When IBM changed direction and decided that
the effort needed to start over, the effort was delayed by several
months while the issue was discussed. IBM was given ample time to
present it's case. A committee vote was ultimately taken and the IBM
proposal to start over was rejected. The spec then went through the
proper OASIS review cycles and was approved first by the TC and then by
the required 15% of OASIS member organizations. To say that this was
"railroaded" is an unfair characterization.
You keep making the straw man argument that we "decided against a web
services approach". You apparently make this case based on the fact that
the provisioning meta-data is represented in a form other than XSD. Are
you claiming that any protocol that does not XSD to represent meta-data
is not taking a "web services approach"? If you want to argue that the
current approach is not appropriate for the provisioning domain, that is
legitimate debate. To argue that it is not "web service based" is not.
The current SPML data model seems to be the biggest point of contention.
It seems that the other issues are more tractable. If could put together
a compromise proposal where the current SPML spec was expanded to
support both the current data model and a data model similar to what is
proposed in WS-Provisioning, would that be acceptable? This would still
use the current SPML request/response model, but each of the verbs (add,
mod, del, get schema) would be expanded to support both the current
model and the model proposed in WS-Provisioning. This would support the
open ended data model that you want as well as the backwards
compatibility that I want. Would IBM be willing, in theory at least, to
support that as a compromise solution?
Jeff Bohren
Product Architect
OpenNetwork Technologies, Inc
Try the industry's only 100% .NET-enabled identity management software.
Download your free copy of Universal IdP Standard Edition today. Go to
www.opennetwork.com/eval.
-----Original Message-----
From: Gearard Woods [mailto:gewoods@us.ibm.com]
Sent: Wednesday, December 03, 2003 2:18 AM
To: Jeff Bohren
Cc: provision@lists.oasis-open.org
Subject: RE: [provision] Discussion and analysis of SPML 2.0 submission
from IBM
Jeff,
We've had all these arguments before and we could go back and forth for
days on this. The bottom line is that I feel the SPML 1.0 was
railroaded through for marketing purposes to make Catalyst. The
official argument at the time against a Web Services approach was that
the committee would lose both credibility and an investment in work
already done. You argued vigorously, almost violently, against what we
were trying to propose because, you said, directories are proven and our
approach wasn't. Now here we are again, there is too much investment in
the current path and directories are proven.
I'll re-iterate my previous high-level arguments for the record:
- The SPML should interoperate seamlessly with Web Services
- The SPML should itself take advantage of, and be implemented using,
accepted Web Services standards
- The SPML should offer a Provisioniong model, not a directory model.
This point is very relevant at this juncture because had the SPML 1.0
offered a provisioning foundation we would now be discussing what a
richer provisioning model would look like rather than how we might cram
XML Schema and XML data into a directory protocol.
These things seem self-evident, just as the creation and refinement of
another directory protocol seems redundant. Your roundup of
attribute/value protocols and products makes it clear that there are
plenty already but fails to mention that SPML is, in fact, crippled as
compared to the directory protocol is is based on, DSMLv2. Your recent
e-mail on the search limitations indicate that you fully understand
this. The roundup also fails to acknowledge that directory vendors are
putting a lot of thought into how to get around the very problems we are
discussing, initiatives such as XED illustrate this. But here is a
protocol hot off the press that has all of the traditional directory
limitations and more built right in from the start. You'll forgive me
if I don't consider the SPML1.0 to be an appropriate foundation for the
future of provisioning interfaces. It's a good reflection of the past
though, I'll give you that. Gerry
|---------+---------------------------->
| | "Jeff Bohren" |
| | <jbohren@opennetw|
| | ork.com> |
| | |
| | 12/02/2003 05:53 |
| | PM |
|---------+---------------------------->
>-----------------------------------------------------------------------
-------------------------------------------------------|
|
|
| To: Gearard Woods/Irvine/IBM@IBMUS
|
| cc: <provision@lists.oasis-open.org>
|
| Subject: RE: [provision] Discussion and analysis of SPML 2.0
submission from IBM |
>-----------------------------------------------------------------------
-------------------------------------------------------|
Gerry,
I agree that we should be willing to consider all options for SPML 2.0.
I would be willing to consider just about anything including a total
rewrite if that is what is required to meet the requirements for 2.0.
But I am not going to support a total rewrite if the requirements can be
met with an approach that is backwards comatible with the current spec.
Of course we have not finalized the requirements so that decision can
not be made yet.
At highest level the SPML 1.0 spec is based around the concept that the
provisioning data is represented as a collection of attribute/values
rather than arbitrary XML. This is the approach taken by SAML as well as
SPML. It is also the approach taken by many of the currently
provisioning products in the market place. Many workflow, EAI, and BPA
products use this approach as well. And of course it is also how all
directory, meta-directory, and virtual-directory products work. Given
that, I don't think it is reasonable to characterize that approach as
"crippled" or "worthless".
My suggested compromise for SPML 2.0 is that the provisioning data be
represented as a collection of attribute/values plus arbitrary XML where
appropriate. Under this approach provisioning target developers are free
to use as much as needed from either model. People who already have
provisioning targets (as we do) don't have to be impacted. This approach
is not perfect, as compromises seldom are.
I have a hard time believing that not being able to represent provision
schema solely through XSD means that the spec has to be rewritten. It
seems that there should be a compromise somewhere in between. If not the
one I am suggesting, then perhaps another one.
Jeff Bohren
OpenNetwork Technologies
-----Original Message-----
From: Gearard Woods [mailto:gewoods@us.ibm.com]
Sent: Tue 12/2/2003 6:21 PM
To: Jeff Bohren
Cc: provision@lists.oasis-open.org
Subject: RE: [provision] Discussion and analysis of SPML
2.0 submission from IBM
Jeff,
You know the history of this debate as well as I do,
including the rush to
demo at Catalyst in the face of the strenuous objections of
both ourselves
and Microsoft. Now you are using exactly the same
arguments as you used
then. We have committed to try to work with the committee
as part of the
SPML 2.0 effort but if we are not to debate the merits of
different
approaches now then there is no debate. I'd like to point
out too that a
radical departure from an earlier approach is not
unprecedented - an
example close to your heart would be the fact that DSMLv2
is obviously a
far cry from DSMLv1.
I'm not saying that WS-Provisioning does not require that a
client retrieve
the schema. What I'm saying is that it doesn't get in the
way by imposing
a proprietary schema language. If you are using XML Schema
then you get
XML Schema, not XML Schema shoehorned into another schema
language.
In terms of the respect that SPML 1.0 deserves, in my book
that's something
that results from being tested and implemented and found to
be thorough,
robust and appropriate. As you know we will not be
implementing it. In
terms of the utility that it represents, in any large scale
application,
which the interop demo was not, the limitations of the spec
are crippling.
It's encouraging to see that you recognize that there is
merely "some"
level of interoparability because to claim interoperability
for a demo in a
highly controlled environment with 10 simple attributes
would be
overstating the case.
If the committee is to try to build a provisioning standard
rather than
another directory protocol, then it should not be built on
the SPML 1.0
schema language, simple as that. If you are prepared to
commit
wholeheartedly to the use of XML Schema then let's dispense
with the SPML
schema language altogether. Sure, make it backward
compatible but with
SPML 2.0 as a superset, not as a dependant specification.
Gerry
|---------+---------------------------->
| | "Jeff Bohren" |
| | <jbohren@opennetw|
| | ork.com> |
| | |
| | 12/02/2003 12:30 |
| | PM |
|---------+---------------------------->
>-----------------------------------------------------------------------
-------------------------------------------------------|
|
|
| To: <provision@lists.oasis-open.org>
|
| cc:
|
| Subject: RE: [provision] Discussion and analysis
of
SPML 2.0 submission from IBM |
>-----------------------------------------------------------------------
-------------------------------------------------------|
Gerry,
I will try to flesh out the examples more in the next
iteration of the
OpenNetwork proposal. I should hopefully have that done
soon.
I agree with you about the SPML Identifier. In retrospect a
pure urn
based approach would have served better. I would like to
make that
change in SPML 2.0 so as to allow for either the current
identifier
approach or a URN approach.
You seem to be implying that in WS-Provisioning an XSD
based tool could
somehow use the provisioning target schema definition to do
something
useful. The WS-Provisioning approach requires that the
client queries
the service to get the provisioning schema, and parses the
result. For
instance if you wanted to automatically generate client
code then you
would have to create a WS-Provisioning specific tool to do
it. This is
true with both proposals.
Now whether SPML 1.0 had compelling features that make it
worth being
backwards compatible with is certainly a matter of opinion.
From our
standpoint it is compelling for many reasons, not the least
of which is
the fact that it is part of our currently shipping product.
I suspect
that is the case with some other TC members. From a OASIS
TC standpoint
it is compelling in that there is a published spec, and we
should
respect it as much as possible. Additionally the spec has
been
demonstrated to have some level of interoperability.
This should not be a debate about which approach is
superior. I would
have had no problem with using any number of different
approaches, had
they been put forth earlier in the process. The question
should be what
is going to move the industry forward to adopting a
provisioning
standard. I can't see how issuing a completely different
spec is going
to accomplish that. If the SPML 2.0 spec is a complete
rewrite of the
1.0 spec, why would anyone adopt it? What confidence would
they have
that SPML 3.0 would not come out and be totally different
from 2.0?
Jeff Bohren
Product Architect
OpenNetwork Technologies, Inc
Try the industry's only 100% .NET-enabled identity
management software.
Download your free copy of Universal IdP Standard Edition
today. Go to
www.opennetwork.com/eval.
-----Original Message-----
From: Gearard Woods [mailto:gewoods@us.ibm.com]
Sent: Tuesday, December 02, 2003 2:16 PM
To: Jeff Bohren
Cc: provision@lists.oasis-open.org
Subject: RE: [provision] Discussion and analysis of SPML
2.0 submission
from IBM
Jeff,
I have to admit that I only glanced at your submission,
assuming it was
the same approach you had propsed on the list some time
ago. Looking at
it now, it does indeed offer a lot of benefits over SPML
1.0. It
appears to be incomplete though and I'd like to see a more
thorough
example if you have one. For example, I'd like to see how
something
like the Liberty profile schema is imported, more
information on the
"name" attribute in your search request would be useful
("CommonName\cn"
looks strange to me). I'm also not sure that I understand
the object
reference example. It would be useful to see the modified
SPML core
schema for this so that I can understand exactly how it
would work.
Of course, I still have an issue with the SPML-specific
schema language.
You know my complaints:
- The language is incompatible with Web Services tools, or
XML tools for
that matter - XML Spy won't generate a sample SPML document
for you as
an example, off-the-shelf schema compilers such as Castor
won't
recognize it.
- The approach flies in the face of accepted Web Services
practices and
the use of SPML schema essentially gets in the way of the
XML Schema.
If a user is to describe their data in XML Schema, what's
the point of
SPML schema?
- The identifier mechanisms are clumsy and is much better
handled using
standard XML namespaces and URIs.
- The schema language is still directory-oriented and is
not an XML
schema language. This is true also of DSMLv1 of course but
it
introduces difficulties when dealing with XML. For
example, in your
object reference example (and as I said I may not
understand this
properly), you define:
...
<attributeDefinition name="role"
type="urn:oasis:names:tc:SPML:1:1#Identifier"/>
...
<objectClassDefinition name = "role">
<memberAttributes>
<attributeDefinitionReference name = "cn" required =
"true" />
<attributeDefinitionReference name = "description" />
<attributeDefinitionReference name = "password" />
</memberAttributes>
</objectClassDefinition>
...
The problem here of course is that the "type" of the role
attribute is
not a role but an "identifier". This is handled much
better in XML
schema languages that have strong typing and relate closely
to their
resultant XML representation.
If backward compatibility is an issue, and I'm not sure how
much of a
problem it could be at this point, then consider that the
WS-Provisioning proposal can easily transport SPML 1.0
schema and data.
To me, this approach offers a number of benefits including
the tool
compatibility and Web Services emphasis that SPML lacks.
As an example
of how an SPML1.0 schema might be expressed in
WS-Provisioning:
<wsp:ProvisioningTarget
xmlns:wsp="urn:ibm:names:ws:provisioning:0.1:core">
<wsp:identifier name="xyz123"/>
<wsp:schema>
<spml:schema
xmlns:spml="urn:oasis:names:tc:SPML:1:0"
xmlns:dsml="urn:oasis:names:tc:DSML:2:0:core">
<spml:providerIdentifier providerIDType =
"urn:oasis:names:tc:SPML:1:0#URN">
<spml:providerID>urn:oasis:names:tc:SPML</spml:providerID>
</spml:providerIdentifier>
<spml:schemaIdentifier schemaIDType =
"urn:oasis:names:tc:SPML:1:0#GenericString">
<spml:schemaID>standard</spml:schemaID>
</spml:schemaIdentifier>
<spml:attributeDefinition
name="objectclass"/>
<spml:attributeDefinition name="cn"/>
<spml:attributeDefinition name="uid"/>
...
<spml:objectClassDefinition name="person">
<spml:memberAttributes>
<spml:attributeDefinitionReference
name="objectclass" required="true"/>
<spml:attributeDefinitionReference
name="cn"
required="true"/>
<spml:attributeDefinitionReference
name="uid"/>
...
</spml:memberAttributes>
</spml:objectClassDefinition>
</spml:schema>
</wsp:schema>
</wsp:ProvisioningTarget>
If the SPML 1.0 had many compelling features that we could
not afford to
lose then tacking on support for XML Schema and XML data
would be a
worthwhile exercise. However, this is not really the case
and the
retrofitting is going to result in a cumbersome
specification that will
be difficult to understand and implement. Gerry
|---------+---------------------------->
| | "Jeff Bohren" |
| | <jbohren@opennetw|
| | ork.com> |
| | |
| | 12/02/2003 07:27 |
| | AM |
|---------+---------------------------->
>-----------------------------------------------------------------------
-------------------------------------------------------|
|
|
| To: <provision@lists.oasis-open.org>
|
| cc:
|
| Subject: RE: [provision] Discussion and analysis
of
SPML 2.0
submission from IBM |
>-----------------------------------------------------------------------
-------------------------------------------------------|
Gerry,
I have already proposed an enhancment to SPML to allow for
arbitrary XML
to be used as provisioning data (see the OpenNetwork
proposal for more
details). This requires no encodings or transformations and
allows XSD
to be used to define the structure of the XML data. This
also has the
advantage of being fully backwards compatible with SPML
1.0.
Why does this not meet your requirements for the transport
of XML data?
Jeff Bohren
Product Architect
OpenNetwork Technologies, Inc
Try the industry's only 100% .NET-enabled identity
management software.
Download your free copy of Universal IdP Standard Edition
today. Go to
www.opennetwork.com/eval.
-----Original Message-----
From: Gearard Woods [mailto:gewoods@us.ibm.com]
Sent: Tuesday, December 02, 2003 1:35 AM
To: Jeff Bohren
Cc: provision@lists.oasis-open.org
Subject: RE: [provision] Discussion and analysis of SPML
2.0 submission
from IBM
Jeff,
I think you might not be remembering our original proposal
correctly. We
have always advocated the use of a target object to hold
schema. I
plucked the following segment from an e-mail in the list
archives dated
February 28th of this year:
...
<complexType name="ProvisioningTargetSchema">
<sequence>
<any namespace="##other" minOccurs="0"
maxOccurs="unbounded"/>
</sequence>
</complexType>
<element name="ProvisioningTarget">
<complexType name="ProvisioningTargetType">
<sequence>
<element name="identifier"
type="tns:ProvisioningIdentifier" minOccurs="1"
maxOccurs="1"/>
<element name="schema"
type="tns:ProvisioningTargetSchema" minOccurs="0"
maxOccurs="1"/>
</sequence>
</complexType>
</element>
...
You'll find this almost verbatim in our submission. It was
never a
suggested that the target schema had to be embedded in
WSDL.
As far as the portions of the SPML that should be kept, as
I said
earlier, and as you well know, our problems go to the heart
of the spec.
The SPML-specific schema language is unsatisfactory for a
number of
reasons that we've discussed at length already. The schema
then
dictates the data model - that XML-unfriendly
attribute-value data model
that we have also discussed at length already. The schema
and data
model then impact the operational interface.
I don't want to suggest that we at an impasse but I do
think that any
proposals based on the SPML schema language will not come
close to
satisfying our requirements. The SPML must allow the use
of XML Schema
as the target schema language, at a minimum. Not as a
tacked on
band-aid but as a first-class schema language. It must
also provide for
the transport of XML data as XML data - no wierd
transformations or
encodings. The reasons for these requirements are obvious
and
particularly imperative in a Web Services context. Fixing
these demands
a major overhaul of SPML 1.0. Gerry
|---------+---------------------------->
| | "Jeff Bohren" |
| | <jbohren@opennetw|
| | ork.com> |
| | |
| | 12/01/2003 05:47 |
| | PM |
|---------+---------------------------->
>-----------------------------------------------------------------------
-------------------------------------------------------|
|
|
| To: Gearard Woods/Irvine/IBM@IBMUS
|
| cc: <provision@lists.oasis-open.org>
|
| Subject: RE: [provision] Discussion and analysis
of
SPML 2.0
submission from IBM |
>-----------------------------------------------------------------------
-------------------------------------------------------|
Gerry,
It would be helpful to make a proposal of what parts of the
current SPML
1.0 specification should be kept as is and what should be
replaced or
modified. That way we can have a useful discussion on the
mail list
leading up to the next face to face.
For instance you originally insisted that the only
acceptable way to
represent the meta-data of the provisioning target (i.e.
the
provisioning
schema) was to represent it in XML Schema in WSDL so that
client could
be auto-generated. Now in your WS-Provisioning submission
that approach
is not taken. Instead the client gets the schema using a
"FetchTargetRequest", and processes the
"FetchTargetResponse" in order
to read the schema. Since you have already abandoned a pure
WSDL
approach for representing schema, why could that not be
merged into the
current SPML schema mechanism?
Jeff Bohren
OpenNetwork Technologies
-----Original Message-----
From: Gearard Woods
[mailto:gewoods@us.ibm.com]
Sent: Mon 12/1/2003 4:42 PM
To: Jeff Bohren
Cc: provision@lists.oasis-open.org
Subject: RE: [provision] Discussion and
analysis of SPML
2.0 submission from IBM
I think it's fair to say that the submission
is intended to
act as a
statement of direction, indicating the form
that we would
like to see the
SPML take. We've been quite clear about the
fundamental
problems that we
have with the current approach and on many
occasions have
pointed out that
these issues need to be addressed at the
foundations of the
SPML.
Reconciling the SPML1.0's schema and data
models with the
direction
detailed in our submission is not trivial. It
is certainly
not a
cut-and-paste exercise. The question to me is
what
portions of the SPML
can be retained to meet our needs. At present
those are
few.
|---------+---------------------------->
| | "Jeff Bohren" |
| | <jbohren@opennetw|
| | ork.com> |
| | |
| | 11/25/2003 06:56 |
| | AM |
|---------+---------------------------->
>-----------------------------------------------------------------------
-------------------------------------------------------|
|
|
| To:
<provision@lists.oasis-open.org>
|
| cc:
|
| Subject: RE: [provision] Discussion
and analysis
of
SPML 2.0 submission from IBM
|
>-----------------------------------------------------------------------
-------------------------------------------------------|
The IBM Proposal looks to be a very good
specification on
it's own merits,
but has no compatiblity with the current SPML
1.0
specification. What
exactly is IBM proposing? Is IBM proposing the
the current
SPML
specification be wholesale replaced with the
IBM proposed
specification? Or
is IBM proposing this as input into the SPML
2.0
specification?
If IBM is proposing this as input rather than
a wholesale
replacement, what
parts does IBM feel are appropriate to
incorporate into the
SPML 2.0?
Jeff Bohren
Product Architect
OpenNetwork Technologies, Inc
Try the industry's only 100% .NET-enabled
identity
management software.
Download your free copy of Universal IdP
Standard Edition
today. Go to
www.opennetwork.com/eval.
-----Original Message-----
From: Darran Rolls
[mailto:Darran.Rolls@waveset.com]
Sent: Tuesday, November 25, 2003 9:46 AM
To: provision@lists.oasis-open.org
Subject: [provision] Discussion and
analysis of SPML
2.0 submission
from IBM
As you are no doubt aware, IBM has
submitted a
specification document
to the PSTC for consideration as content
and
requirements for SPML
Version 2.0. This submission can be
found at [1]. Do
you have
questions regarding the intent, status
or content of
this submission?
[1]
http://www.oasis-open.org/archives/provision/200310/msg00001.html
To unsubscribe from this mailing list (and be removed from
the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/provision/members/leave_wor
kgroup.php
.
To unsubscribe from this mailing list (and be removed from
the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/provision/members/leave_wor
kgroup.php
.
To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/provision/members/leave_workgroup.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]