OASIS TC Administrator’s Response to Appeal on 
Decision of OASIS Web Services Security TC
 
2 December 2005

1. INTRODUCTION

We received the following appeal under Section 4.2 of the OASIS TC Process on 3 November 2005:

The OASIS WSS TC was originally chartered [1] to do work on the contributed Web Services Security specification:

"The purpose of the Web Services Security TC (WSS) is to continue work on the Web Services security foundations as described in the WS-Security specification [1], which was written within the context of the Web Services Security Roadmap as published in April 2002 [2]." 

On Oct 4 the WSS TC voted [2 or 3] to do additional work on a proposal [4] from Verisign and RSA for a new "One Time Password" token profile.

We do not believe this new work is consistent with the TC's charter since there is NO mention of such work in the TC's charter's scope or deliverables.

Therefore we would like to appeal (under Section 4.2 of the OASIS Technical Committee Process [4]) the decision of the TC to add this new work to its work plan since it is not covered by the TC's charter.

Abbie Barbir, Nortel
Charlton Barreto, Adobe
Paul Cotton, Microsoft
Thomas DeMartini, ContentGuard
Vijay Gajjala, Microsoft
Martin Gudgin, Microsoft
Hal Lockhart, BEA Systems
Duane Nickull, Adobe
Denis Pilipchuk, BEA Systems
Corinna Witt, BEA Systems

[1] http://www.oasis-open.org/committees/wss/charter.php
[2] http://lists.oasis-open.org/archives/wss/200510/msg00012.html
[3] http://lists.oasis-open.org/archives/wss/200510/msg00033.html
[4] http://lists.oasis-open.org/archives/wss/200509/msg00118.html 
[4] http://www.oasis-open.org/committees/process.php#4.2 

OASIS rules require that within 30 days of receipt of the complaint, the TC Administrator shall respond to the appellants, with a copy to the TC, addressing each allegation of fact in the complaint to the extent of the TC Administrator's knowledge. 

That requirement anticipates the form of the appeal set by those rules:

The complaint shall state the nature of the objection(s), including any direct and material adverse effects upon the appellants; the section(s) of this TC Process or OASIS policies at issue; the actions or inactions at issue; and the specific remedial action(s) that would satisfy the appellants' concerns. Previous efforts to resolve the objection(s) and the outcome of each shall be noted.  

This document is the OASIS TC Administrator's response to the complaint.  Jamie Clark and Mary McRae currently serve in that role.  Patrick Gannon, OASIS CEO, also was consulted in the preparation of this response.   It has five parts:

1. This introductory  material 
2. A summary of the TC Administrator’s recommendations
3. Notes on the relevant rules & issues:  (a) rules about TC scope, (b) certain licensing and disclosure issues, and (c) rules about TC deliverables
4. Replies to each allegation in the complaint 
5. Recommendations and next steps 

2. SUMMARY:

The proposed work item, which was endorsed by a straw vote of the TC, does not exceed the stated scope of the TC;  and it is not prohibited by the fact that it is not explicitly named in the TC's charter.  However, the TC still will require a "Special Majority" vote in order to approve any such eventual work; and still may face closure under our rules when all of its stated deliverables are completed.   

3. RELEVANT RULES AND ISSUES

A. Rules regarding TC charters.   

Under OASIS rules, a Technical Committee's charter is extremely important: it serves externally as the metadata that informs users and prospects about a TC's field of operation, and internally as the scope boundaries outside it which it will not act.    

The rules do not explicitly state that TCs are prohibited from giving approval to a specification that exceeds the scope stated in its charter.  However, TC Administration believes that this necessarily must be implied from the rules, in order for them to work.  In other words, if a TC sought to approve a Committee Specification that clearly exceeded its stated scope in its charter, the TC Administrator should refuse to initiate the ballot.  We'll call that implied rule the "Approval Restriction Rule" when referring to it below.

The OASIS TC Process permits two kinds of changes to a charter:  a "Clarification" under section 2.11, which only may remove ambiguity, add consistent deliverables or narrow the TC's scope; and a "Rechartering" under section 2.12, which permits scope expansion, but requires re-soliciting all IPR contributions.  These two rules resulted from the Board's 2003 and 2005 changes to the TC Process and, taken together, indicate an intent to enforce tighter scope boundaries on TC activity than previously was used.  

B. Certain licensing and disclosure issues.  

In understanding charters, it's also important to note that a TC's scope, as stated in its charter, actively affect the licensing and disclosure obligations of TC members.   Under the 2005 OASIS IPR Policy, for example, members who actively participate in or contribute to a TC may be required to license certain rights in any claims they hold that are essential to the implementation of a specification approved by that TC.  A member's decision to join can be tantamount to an advance licensing commitment.  

Even members who participate in a TC under our legacy (2000) IPR Policy may incur obligations or expectations about their willingness to disclose and make available relevant owned technology.  Our members rely on TC scope, as a predictable boundary, in order to manage those obligations and expectations, and choose where to participate.  The implied "Approval Restriction Rule" helps enforce that boundary.

Our appeal rules ask the complaining party to specify "any direct and material adverse effects upon the appellants" in the complaint.  While this appeal did not explicitly provide that information, we deem that requirement satisfied.  A broad range of OASIS members and others rely heavily on the stated scope limits on our TCs, in many contexts, and often not in ways visible to OASIS.  So in our view it is self-evident that an official TC action taken outside the TC's scope clause is materially harmful.  

C. Rules regarding TC deliverables.  

Apart from scope, the TC Process rules also require that a TC maintain certain deliverables metadata in their charters:
    *    Deliverables and projected completion dates are to be listed in the charter (Sec. 2.2).
    *    Deliverables may be altered by charter clarification so long as within scope (Sec. 2.11).
    *    TC Administration must close a TC if it has completed the deliverables listed in its Charter and adds no new deliverables (Sec. 2.15).

Those rules give TCs an incentive to keep their deliverables plans up to date.  However, the TC Process rules do not appear to prohibit a TC from starting work on, or approving, a Committee Specification that is not explicitly named as a deliverable in its charter.  We could choose to infer a rule there, as with the implied "Approval Restriction Rule".  We decline to do so for three reasons.

i.  Under current OASIS rules, the proposers or members of a TC may, if they wish, enact explicit restrictions about the number or name of output specifications into a charter.  Some TC proposers have chosen to do so.  But here we have a more abstract issue: if no prohibition is stated, and some proposed work is in scope, but not named, should it be assumed to be permitted or prohibited?  This is an interpretative question.  OASIS is a standards organization, not a standards-preventing organization, so in our view the best result for the consortium in such cases is to err on the side of permitting output.  

ii.  TCs often re-factor their work while in progress.  A good example of this is the OASIS WSDM TC, where multiple competing contributions within a given scope were made, carefully compared, and then cooperatively re-factored into two planned final specifications, in a fairly long and careful negotiating phase.  The TC's scope was to create a functional "management" spec; but the TC's work led it to the conclusion that this one function was best fulfilled by two related, distinct specs.  Successful OASIS TC practice appears often to have involved some volatility of spec components and delivery dates.  Charter changes require a "Special Majority" vote under our rules, and thus can be blocked by 1/4 of a TC's voters.  The appeal essentially asks us to assume a rule that "everything that is not named is prohibited", in cases where no such rule is stated in the charter.  Doing so would increase that minority blocking power beyond the apparent intent of the rules.

iii.  The need of members for predictability, noted above with respect to scope, does not appear to exist with respect to deliverables lists.  When a TC describes its planned work in functional terms, by product-neutral feature or performance, it is providing information that allows outsiders to gauge for themselves whether the TC's scope is relevant to their own interests.   In contrast, the number or exact names of output specifications are not the kind of data that a prospective standards participant would reasonably need in order to make a patent licensing or clearance decision about joining.

4.  REPLIES TO EACH ALLEGATION IN THE COMPLAINT

Allegation
(1) "The purpose of the Web Services Security TC (WSS) is to continue work on the Web Services security foundations as described in the WS-Security specification [1], which was written within the context of the Web Services Security Roadmap as published in April 2002 [2]." 

The quote is correct.  What remains is to determine whether those words dictate a limit on scope.  Here we are reading the text of a public document (the charter), so in interpreting it we should focus on its plain meaning (as would any user would), and not look outside its explicit text for data about intent.   

Footnote [1] refers to a contribution made in 2002, identified by 3 URIs: http://www-106.ibm.com/developerworks/library/ws-secure/,   http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnglobspec/html/ws-security.asp , and .  

If the above sentence is intended as a scope limit, it is not a clear one, as the phrase "continue work on" does not seem either to clearly rule in or rule out work beyond the list of functions present at that time in the named contribution.   

In any case, the explicitly referenced work itself does not seem to delineate included or excluded token functions either.  Reviewing the latter copy, we noted that the 2002 contribution describes the specification as 

"designed to be extensible (e.g. support multiple security token formats).  For example, a client might provide proof of identity and proof that they have a particular business certification."  

The contributed specification goes on to name username, X.509 and Kerberos token methods as extensions.   The spec. does not seem to state or imply a restriction about which functions or extensions are planned or acceptable.

Footnote [2] refers to a document written by two companies in 2002, identified by 3 URIs:  http://www-106.ibm.com/developerworks/library/ws-secmap/, http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwssecur/html/securitywhitepaper.asp, and http://www.verisign.com/wss/architectureRoadmap.pdf.   We reviewed the latter copy, which describes itself as a "joint whitepaper".
 
Again, the reference to it in the charter ("... written within the context of ...") does not seem to be intended or readable as a scope limit.  Many  TC charters include informational pointers to precursor or related works.  As can be seen from other TC charters, TC proponents generally use clear prohibitive language when a restriction is intended.  Failing that, we are entitled to assume that the proposers did not agree on clear prohibitive language.  So the reference is merely informational. 

If the white paper were to be used as a source of limitations, it still does not seem either to clearly rule in or rule out specific tokens or extensions. The white paper refers to a number of precursor proprietary inputs, existing and proposed standards, and then-current names for future proposed standards.  But when discussing tokens and profiles, there is no suggestion of a finite or exclusive set.  It specifically references username, X.509 and Kerberos, as "some of the different kinds of security tokens", and also mentions as an instance "mobile device security tokens from SIM cards."  We see no implied boundary on other tokens.  

Allegation:
(2) "On Oct 4 the WSS TC voted [2 or 3] to do additional work on a proposal [4] from Verisign and RSA for a new "One Time Password" token profile."

The reference to a "proposal from Verisign and RSA" points to an archived e-mail message at , to the TC  from John Linn:

"RSA Security and VeriSign would like to propose a new work item for the WSS TC, defining a WSS profile for use of One-Time Password (OTP) authentication. ...  This profile would be functionally comparable to other profiles defined within the WSS TC, so we believe it is appropriate to standardize within the same forum.  We propose that this activity be undertaken as a general TC work item, comparable to other profiles addressed by the TC, rather than within a distinct subcommittee. It is not the proposers' intent that this work item be incorporated into WSS 1.1, or that it delay TC progress on that release. ..." 

The message, dated 27 Sept. 2005, references an anticipated input contribution from RSA Security.  There are various other messages on the list in which TC member discuss the possible project, before and after this message.  The appeal points to two copies of minutes of the 4 October 2005 TC meeting (a draft and a final version).  The minutes describe a discussion about whether a charter change was needed, or desirable, to reflect the possible new work on OTP, followed by a proposal from Hal Lockhart to vote to 

"see if TC by simple majority wants to do the work.  If yes, Paul can still call for formal charter clarification resulting in formal Oasis vote."  

This cannot have been an acceptance of the contribution, nor a charter change vote, so we conclude that it was a nonbinding straw poll.  No act seems to have been taken by the TC to approve any specific work.  

Allegation: 
(3) We do not believe this new work is consistent with the TC's charter since there is NO mention of such work in the TC's charter's scope or deliverables.

It is correct that the OTP profile is not mentioned in the scope.  However, it is not excluded by it either.  The charter says:

"The scope of the Web Services Security Technical Committee is the support of security mechanisms in the following areas:
  * * *
  * Attaching and/or referencing security tokens in headers of SOAP messages
  * * * "

For the reasons noted above in Section 3(A), the silence of the TC's charter about a prohibition or permission of additional profiles does not render another security token profile beyond the TC's scope.   This is particularly true because of this charter's emphasis on extensibility: it describes it own work plan as (among other things):

Produce as output a specification, in one or more documents, for Web Services Security. This specification will reflect refinements and changes made to the submitted version of WS-Security that are identified by the WSS TC members for additional functionality within the scope of the TC charter. 

(emphasis added).  

It also is correct that the OTP profile is not mentioned in the charter's list of deliverables, which reads:    

"The TC has the following initial set of deliverables.
  *  The "core"specification (final name TBD) 
  *  A SAML profile 
  *  An XrML profile 
  *  A Kerberos profile 
  *  An X.509 profile"

The word "initial" does not seem to imply exclusivity.  According to the TC's home page, the current v1.1 work of the TC includes the following specifications:

  *  SOAP Message Security 1.1 
  *  Kerberos token profile 1.1 
  *  Username token profile 1.1 
  *  X.509 token profile 1.1 
  *  SAML token profile 1.1 
  *  REL token profile 1.1 
  *  SwA profile 1.1 

Even if we view the REL profile as a successor to XrML, the TC appears to have completed 6 profiles without objection -- 4 of which were listed in the TC charter and two that were not -- without adding the other two (Username and SwA) into its charter "initial set" deliverables list.   

For the reasons noted above in Section 3(C), we do not believe that the absence of a specification from a charter's initial list of deliverables makes its adoption a violation of the charter, so long as (a) the charter does not explicitly prohibit additional deliverables and (b) the topic of the specific deliverable is within the TC's scope.  As noted in Section 3(C), we considered, but rejected, an alternative reading of the rules – that every deliverable explored by a TC must be added into the charter explicitly, or else is barred.  

Allegation:
(4) Therefore we would like to appeal (under Section 4.2 of the OASIS Technical Committee Process [4]) the decision of the TC to add this new work to its work plan since it is not covered by the TC's charter.

As we understand it, the "specific remedial action(s)" sought "that would satisfy the appellants' concerns" are a direction to the TC regarding whether the planned work is out of scope or otherwise prohibited by the charter.
 
Some steps in a TC's work require action by the TC, while others do not.  For example, contributions to a TC are unilateral acts by the contributor, and TCs do not vote to accept them.  On the other hand, a TC's creation of a subcommittee, or approval of a specification, are explicit acts requiring a vote.

While "straw polls" do not require a vote, still, they may result in member resources being directed into a specific project, and time consumed during TC meetings.  All TC members have an interest in clarity about the TC's scope boundaries.  Also, as noted in Section 3(B), all members of a TC face some potential obligations, expectations and liabilities as a result of their membership on the committee.   The straw vote causes a a reasonable expectation that the project may go forward.  That is sufficient in our view to permit an appeal to be made, in order to resolve the issue.  

5. RECOMMENDATIONS AND NEXT STEPS

Our rules require that, after we provide this response, we discuss with the appellants whether some mutually acceptable resolution can be reached.  (Another appeal round potentially exists after that.)  We will discuss these matters with them and explore some options.  We recommend that the TC forbear from any further work on the disputed project during the 15-day appeal period, so as to preserve those options.  

We have a majority of a committee who wishes to proceed with a project; a minority who opposes it as out of scope; and a need for interpretation due to a charter that (given the dispute) is not sufficiently explicit about permitting or prohibiting it.  We may suggest further discussions during the next two weeks.

The TC should bear in mind that any eventual work on the proposed project will still require spec approval, which still would at some future point require a Special Majority Vote; and that some members may feel a need to leave the committee, if the scope is defined as broader than they believed. 

Also, if the WSS TC reaches the end of its listed deliverables, and does not add new deliverables, it faces the possibility that it will be closed under the end-of-work-plan rule in Section 2.15 of the TC Process.  This also should be factored into any plans for resolution.  

END