RE: [security-services] Ideas for issues list categories

["Jahan Moreh" <jmoreh@sigaba.com>]

Eve -
I definitely agree with your new categories. These are in harmony with our
current work.

Thanks,
Jahan

---------
Jahan Moreh
Chief Security Architect
310.286.3070


-----Original Message-----
From: Eve L. Maler [mailto:eve.maler@sun.com]
Sent: Wednesday, October 01, 2003 10:33 AM
To: 'security-services@lists.oasis-open.org'
Subject: [security-services] Ideas for issues list categories


In this week's telecon, I agreed to propose a fresh set of categories
for the issues list.  In V1.0 and V1.1, we used the following categories
for the issues list:

Use Case Issues
   Document Format & Strategy
   Single Sign-on Push and Pull Variations
   B2B Scenario Variations
   Sessions
   Security Services
   AuthN Protocols
   Protocol Bindings
   Enveloping vs. Enveloped
   Intermediaries
   Privacy
   Framework
   AuthZ Use Case
   Encryption
   Business Requirements
   Domain Model
Design Issues
   Naming Subjects
   Naming Objects
   Assertion Validity
   Assertion Style
   Reference Other Assertions
   Attributes
   Authentication Assertions
   Authorities and Domains
   Request Handling
   Assertion Binding
   Authorization Decision Assertions
   Attribute Assertions
   Dynamic Sessions
   General – Multiple Message Types
   Elements Expressing Time Instants
Miscellaneous Issues
   Terminology
   Administrative
   Conformance
   XMLDSIG
   Bindings

I suggest the following categories, which hew more closely to our
agreed-on V2.0 deliverables:

Technical Deliverables
   Technical Overview (OVER-nn)
   Assertions, Protocol, and Schemas (CORE-nn)
   Bindings and Profiles (BIND-nn)
   Metadata (META-nn)
   Other (TECH-nn)
Outreach Deliverables (OUT-nn)
Miscellaneous Issues (MISC-nn)

Since we're unlikely to be in doubt as to the document in which an issue
would be fixed, and relatively few issues will span documents, I think
this should work as a good approximation.  For issues that do span
documents, we can just detail the desired results in the issue text,
just as we always have.

As an example, we would have the following issues so far:

CORE-01: Remove AuthorityBinding element
CORE-02: Remove RespondWith element
CORE-03: Remove deprecated NameIdentifier URIs
CORE-04: Require URI references to be absolute
CORE-05: Null attribute values
BIND-01: Disallow Status as only child of SOAP Body
BIND-02: Remove deprecated artifact URI

I'm inclined not to go any deeper than this because I'm not sure that
the effort will result in corresponding gain in issue-disposition
efficiency or accuracy, but am willing to be convinced otherwise.  (I'm
not all that thrilled with my ad hoc experiment to put related work
items next to each other and give them "a" and "b" designations...)

What do y'all think?  If you agree with the top two(ish) levels I've
proposed but would prefer to see another level, can you recommend some
or do you think they should be created ad hoc?

	Eve
--
Eve Maler                                        +1 781 442 3190
Sun Microsystems                            cell +1 781 354 9441
Web Products, Technologies, and Standards    eve.maler @ sun.com


To unsubscribe from this mailing list (and be removed from the roster of the
OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/security-services/members/leave
_workgroup.php.