[security-jc] Specification Errata Process Issue

[Hal Lockhart <hal.lockhart@entegrity.com>]

Title: Specification Errata Process Issue

The understanding of the SSTC (and others) is that the specification voted for by the membership must be EXACTLY the same document presented at the begining of the review cycle. The problem is that we have found errata and expect there will be more. These do not differ from the intent of the specification, but they are important for implementers to be aware of. As we understand it, the only way to get these in the spec is an additional 4-5 month review + approval cycle.

The kind of process we would recommend (this is my summary of the consensus at the last concall) is as follows:

1. publish spec with a statement that errata can be found at such and such location and will be incorporated into the document at the end of the review cycle.

2. Post an errata document with two sections: identified errors and approved changes to the spec

3. At the end of the review period, close all errors by either approved changes or deferral. Apply all changes to document.

4. Membership votes on updated document which becomes normative spec.

Obviously variants of this are possible.

Other TCs, e.g. XACML believe this may be an issue for them as well.

IMO people have rightly been impressed with the speed with which SAML was developed. It is certainly a good idea to allow plenty of time (3 mo review + 1 month voting) to approve a major specification. However, there ought to be a more streamlined way to correct minor errors and ommisions without going through the entire cycle.

Hal