[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [security-services] Proposed charter and standing rules
Folks-- Attached are a revised charter and a corresponding set of standing rules. I believe I made all the requested edits to the charter, and I have started to use the new proposed OASIS filenaming rules for that file. I hope we can discuss these in the next meeting. Regarding the proposed standing rule(s) on IPR requirements, here is what I learned in talking to the LegalXML folks and an attorney in my company: - LegalXML has a specific reason for using the "in no event" (MUST) language regarding producing RF specs. Since their outputs are used by the public sector, particularly courts, the technologies using their specs have to be as open as possible. - They see no reason for a provision not to accept non-RF contributions, since the OASIS copyright provisions allow for the reuse of contributed material, and since TC spec outputs are judged wrt patents regardless of whether the patented material was included with foreknowledge or not. - To quote John Greacen, the LegalXML person who kindly responded to my queries: "One other solution to the IPR issue has been suggested by one of our TC members -- that we may choose in the future to leave some areas of specifications open with a note that there are several effective proprietary solutions available in this area and users of the standard should investigate them and choose one. We could even list the vendors in the specification. I think that approach would be consistent with our charter provision." Such a solution would apply to us as well, in any case where we choose an RF path. - My company attorney weighed in on the value of softening the wording from "In no event..." (MUST) to something like "It is the intention..." (SHOULD). He pointed out that a SHOULD version it has no legal teeth, but it serves as business purpose in indicating (obviously) our intent and direction. So he felt it's a reasonable thing to do, if that's what we want. Given the above, in the attached standing rules document I have proposed the following singular IPR standing rule: "It is the intention of the TC not to approve any technical specification if it believes that the use, distribution, or implementation of such specification would necessarily require the unauthorized infringement of any third party rights known to the TC, and such third party has not openly specified and agreed to provide necessary license rights on perpetual, royalty-free, non-discriminatory terms." On re-reading this, I wonder if this isn't too MUST-like... But hopefully sending it out will give people a chance to seek input from their own corporate attorneys etc. Eve -- Eve Maler +1 781 442 3190 Sun Microsystems cell +1 781 354 9441 Web Technologies and Standards eve.maler @ sun.comTitle: [Draft] SSTC Charter
|
Table of Contents The official name is the Security Services Technical Committee (SSTC). It is sometimes unofficially called the "SAML TC". The purpose of the TC is to define, enhance, and maintain a standard XML-based framework for creating and exchanging authentication and authorization information. The TC held its first meeting by telephone on 9 January 2001. On 31 May 2002 it delivered a suite of SAML V1.0 Committee Specifications to the OASIS membership for review. On 5 November 2002 the SAML V1.0 specifications were declared to be approved as an OASIS Standard. The TC plans to complete the following tasks:
Auxiliary documents (such as SAML profile specifications) and additional versions may also be produced at the Committee's discretion. The TC's intent is to pursue OASIS Standard status for all SAML Committee Specifications. Teleconferences are held every other Tuesday from noon to 2pm Eastern Time. Exceptions to this schedule are posted on the TC home page. Agendas and contact information for the teleconferences are provided on the security-services mailing list (archive) in advance of the meeting. As required, the TC will follow the operating rules of OASIS. In addition, the TC has adopted a set of additional standing rules. |
|
The Security Services Technical Committee (SSTC) has approved the following standing rules:
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC