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

["Philpott, Robert" <rphilpott@rsasecurity.com>]

I'm happy with the proposed categorization.  If it needs refinement as we
move forward, there's nothing to stop us (other than time) from refactoring
a bit.

Rob Philpott 
RSA Security Inc. 
The Most Trusted Name in e-Security 
Tel: 781-515-7115 
Mobile: 617-510-0893 
Fax: 781-515-7020 
mailto:rphilpott@rsasecurity.com 


> -----Original Message-----
> From: Jahan Moreh [mailto:jmoreh@sigaba.com]
> Sent: Wednesday, October 01, 2003 1:43 PM
> To: Eve L. Maler; security-services@lists.oasis-open.org
> Subject: RE: [security-services] Ideas for issues list categories
> 
> 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.
> 
> 
> 
> 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.