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:]
Sent: Wednesday, October 01, 2003 10:33 AM
To: ''
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.
