Zahid Ahmed's votes for Issue Groups 2, 3, 4, 10, and 12 attached

["Ahmed, Zahid" <zahid.ahmed@commerceone.com>]

****************
*  Group 2 
****************

ISSUE:[UC-2-01:AddPolicyAssertions] 

   2. Maintain the non-goal, leave out the requirement.



ISSUE:[UC-2-02:OutsourcedManagement]
   2. Do not add this use-case scenario.
Note: This use case goals aee covered previous use cases already approved.


ISSUE:[UC-2-03:ASP]
1. Add this use-case scenario to the document.


ISSUE:[UC-2-05:EMarketplace]
   1. The above scenario should be added to the use cases document.


ISSUE:[UC-2-06:EMarketplaceDifferentProtocol]
   1. Add this scenario to the document.



ISSUE:[UC-2-07:MultipleEMarketplace]
   1. Add this scenario to the document.


ISSUE:[UC-2-08:ebXML]
   1. Add this use case scenario to the use case and requirements document.


*******************
* Group 3 
*******************
Note: Generally, I believe that session management would pose a difficult
scenario to comply. However, I do see a need for application level session
management. The concern I have is can we come out with a simple use case
required in SAML 1.0 and deal with complex use cases in SAML v. 2.0. E.g.,
a simple logout could be useful in current timeframe.

ISSUE:[UC-3-03:Logout]
     1. Add this requirement to SAML.

ISSUE:[UC-3-05:SessionTermination]
     2. Do not add this requirement and/or use cases.

ISSUE:[UC-3-06:DestinationLogout]
     2. Do not add this scenario or requirement.

ISSUE:[UC-3-8:DestinationSessionTermination]
      2. Do not add this scenario or requirement.

ISSUE:[UC-3-9:Destination-Time-In]
      2. Do not add this scenario or requirement to SAML.




***************
*  Group 4
***************

ISSUE:[UC-4-01:SecurityService]

1. This issue is now obsolete and can be closed as several securityservices
(shared  sessioning, PDP-->PEP relationship)
have been identified within S2ML.
 
ISSUE:[UC-4-02:AttributeAuthority]

2. This issue is adequately addressed by existing use cases and doesnot
require further  elaboration within SAML.


ISSUE:[UC-4-03:PrivateKeyHost]

3. This issue has been adequately addressed elsewhere; there is noneed for
any additions to  the use-case document.
 
 

ISSUE:[UC-4-04:SecurityDiscover]

  2.No, this extends the scope of [OSSML] too far. AuthZ in [OSSML]should be
concerned with  AuthZ attributes of a principal,
    not of resources.

 

**************
* Group 10
**************

ISSUE:[UC-10-01:Framework]

2. Leave the extensibility requirement.


ISSUE:[UC-10-02:ExtendAssertionData]
1. Add requirement [CR-10-02:ExtendAssertionData].


ISSUE:[UC-10-03:ExtendMessageData]
1. Add requirement [CR-10-03:ExtendMessageData].


ISSUE:[UC-10-04:ExtendMessageTypes] 
2. Do not add this requirement.


ISSUE:[UC-10-05:ExtendAssertionTypes] 
2. Do not add this requirement.


ISSUE:[UC-10-06:BackwardCompatibleExtensions] 
1. Add requirement [CR-10-06-BackwardCompatibleExtensions].


ISSUE:[UC-10-07:ExtensionNegotiation] 
3. Add neither the requirement nor the non-goal.


**************
*  Group 12
**************

ISSUE:[UC-12-01:Confidentiality]
1) Add [R-Confidentiality]


ISSUE: [UC-12-02:AssertionConfidentiality]

4) Do not add either requirement or the non-goal.


ISSUE: [UC-12-03:BindingConfidentiality]
1) [R-BindingConfidentiality] Bindings SHOULD (in the RFC sense) provide a
means to protect SAML data from observation by third parties. Each protocol
binding must include a description of how applications can make use of this
protection. Examples: S/MIME for MIME, HTTP/S for HTTP.


ISSUE:[UC-12-03:EncryptionMethod]

3) Add no requirement now, but include a note that this issue must be
revisited in a future version of the SAML spec after XML Encryption is
published.



Zahid Ahmed                     Commerce One, Inc.
Commerce Security Architect
email: zahid.ahmed@commerceone.com
v:   (408)-517-3903