[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Commenets on WSFED TC charter proposal
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]