These comments from Sun Microsystems on the WSFED TC proposal
(http://lists.oasis-open.org/archives/oasis-charter-discuss/200703/msg00002.html)
are provided in four parts:
- Related work
- Specification dependencies
- Audience targeting
- Specification development and scheduling
Related work:
The non-normative Similar Work subsection says: "The proposers of
this TC recognize there are other possible approaches to federation
and believe that the defined Scope of Work of this TC addresses many
functional use cases of these parallel efforts. The proposers of
this TC seek involvement from authors of other such activities and
the contribution of their expertise and experience, and intend to
work in harmony with them in the creation of the product of this
technical committee."
The only provision in the normative charter language for how this
harmony is to be achieved is the statement in the Scope of Work
introduction that "OASIS members with extensive experience and
knowledge in these areas are particularly invited to participate."
It is left unsaid what would motivate those experts to come to this
table (for example, greater interop between the technologies, a plan
for convergence, or a demonstration of business use cases that the
parallel efforts do not address).
The field of cross-domain federated identity has been active for six
years or more, with SAML, the predominant standardized application
protocol, now widely deployed. SAML is a product of the OASIS
Security Services TC, which is curiously not mentioned in the
Applicable Work subsection. This is despite the fact that SAML
often appears in reference architectures in both the public and
private sectors, has been extensively profiled for interoperability,
is the subject of an interop certification program at the Liberty
Alliance, and has a vibrant specification and development community
of many years' standing. The ID-WSF standard produced by Liberty
shares many of the same strengths. They define a variety of
solutions for both active (Web services-based) and passive (plain
browser-based) interactions for single sign-on and other federated
identity tasks.
Therefore, the TC proposers must add normative charter provisions to
coordinate with existing solutions that address the same or similar
use cases, to enable better interoperability and harmonization in
the spirit of the OASIS mission (http://www.oasis-open.org/who/). A
Joint Committee or formal liaisons would be appropriate, in which a
number of profiling deliverables could be proposed for addressing
functionality or interoperability deltas.
Specification dependencies:
The WS-Federation V1.1 specification makes reference to a number of
documents (and the charter makes reference to additional ones) that
are not standardized; some are privately published and not on any
standards track at the moment, and some appear never to be intended
for contribution to a standards venue (such as charter references
[21], "Secure, Reliable, Transacted Web Services", and [22],
"Security in a Web Services World", mentioned in "The TC may also
take into consideration the following specifications/works listed in
the References section, numbers 19-22, 24-27.").
The charter's General Notes on Scope say "If any of the above
specifications is outside of a standardization process at the time
this TC moves to ratify its deliverables, or is not far enough along
in the standardization process, any normative references to it in
the TC output will be expressed in an abstract manner, and the
incarnation will be left at that time as an exercise in
interoperability."
As has already been pointed out by others, this statement is
problematic because a subjective judgment must be made about the
meaning of "far enough along". It is also problematic because it is
unclear exactly how any "exercise in interoperability" is served by
the under-specification of standards or the dependency of standards
on unstable non-standards. If the foundation of referenced
specifications on which WS-Federation needs to rest is this shaky,
the risk of delay while this foundation reaches stability should be
accounted for in the schedule (on which see more below).
Audience targeting:
Section e, Anticipated Audience, focuses solely on vendors and users
of "Web services", which seems to mean SOAP-based services
exclusively given the context of the charter as a whole. But the
greatest portion of the extensive Scope of Work description is spent
on passive requestors, which are defined in WS-Federation V1.1 as
web browsers that are "not able to construct a SOAP message".
Indeed, this is current the most common case in federated identity
deployments.
Thus, the audience description needs revision. In so doing,
however, note that it would overlap in large part with the audience
for SAML, which again suggests that coordination, interoperability,
and harmonization activities with the SSTC are required.
Specification development and scheduling:
The charter appears designed to ensure that the TC's output remains
identical to the named input specification. See, for example, these
statements:
- Section b: Statement of Purpose: "This work will be carried out
through continued refinement of the Web Services Federation Language
Version 1.1 specification [1] submitted to the TC as referenced in
this charter"
- Section c: Scope of Work: This section contains more than a dozen
pages' worth of paraphrasing of the input specification, paying
particular attention to "web (passive) requestors". The statements
under the "This work will focus on:" headings frequently provide
detailed instructions for using certain underlying technologies,
rather than true use cases or problem statements.
- Out of Scope subsection in Section c: The "non-exhaustive" items
that are out of scope include "Mechanisms and protocols for
establishing federations beyond those described in the input
document" (#2).
Thus, the note in the introduction to the Scope of Work section that
says "Other contributions and changes to the input documents will be
accepted for consideration without any prejudice or restrictions and
evaluated based on technical merit..." is belied by the rest of the
sentence, "...in so far as they conform to this charter."
Given the design constraints placed on the TC as the charter is
written today, the plan to complete a Committee Specification within
18 months seems incredibly generous. (However, also see our
comments on schedule risk because of dependencies, above.) If
appearances are deceiving and it is not the intent to duplicate the
input specification in the TC's output deliverable, 18 months seems
highly optimistic, and this risk should be accounted for in the
charter. The purpose and scope statements noted above should also be
corrected in this case.
Eve
--
Eve Maler +1 425 947 4522
Technology Director eve.maler @ sun.com
CTO Business Alliances group Sun Microsystems, Inc.