My vote for issues 2,3,....

["Mishra, Prateek" <pmishra@netegrity.com>]

Attached text file holds my ballot!

- prateek
------
Attachments are virus free!

This message has been scanned for viruses at the originating end by
Nemx Anti-Virus for MS Exchange Server/IMC
	http://www.nemx.com/products/antivirus

  

****************
*  Group 2 
****************
Comment: i am proposing we keep 2-02, 2-03, 2-05 and 2-08 mostly in the
spirit of keeping some example service-to-service interactions within
the document.

ISSUE:[UC-2-01:AddPolicyAssertions] 
   2. Maintain the non-goal, leave out the requirement.



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



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]
   2. This use case scenario should not be added to the document.



ISSUE:[UC-2-07:MultipleEMarketplace]

   2. The above scenario should not be added to the document.


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


*******************
* Group 3 
*******************

There is no question that adding session semantics complicates
the design of SAML. At the same time, there is a lot of interest in 
supporting some form of inter-site session model. From an end-user
viewpoint, single-sign on does not provide quite enough functionality;
support for inter-operable single sessions is also needed.


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




ISSUE:[UC-3-05:SessionTermination]
   1. Add this requirement to SAML.




ISSUE:[UC-3-06:DestinationLogout]
   1. Add this scenario and requirement to SAML.




ISSUE:[UC-3-8:DestinationSessionTermination]
   1. Add this scenario and requirement to SAML.



ISSUE:[UC-3-9:Destination-Time-In]
1. Add this scenario and requirement to SAML.



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

ISSUE:[UC-4-01:SecurityService]

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

ISSUE:[UC-4-03:PrivateKeyHost]

2. A requirement for supporting "binding" between AuthN assertions and business payloads thru digital signature
be added 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] 
1. Add requirement [CR-10-02:ExtendAssertionData].



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



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]
2) Do not add [R-Confidentiality]


ISSUE: [UC-12-02:AssertionConfidentiality]

3) Add a non-goal:
SAML will not define a format for protecting confidentiality of individual
assertions; confidentiality protection will be left to the protocol
bindings.


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.




***************
*  Group 13
***************
My approach here is to go with the more specific requirements as it isnt
clear to me that the more "abstract" requirements can be "met" in any
verifiable way. 

ISSUE:[UC-13-01:Scalability] 

2. Do not add this requirement.


ISSUE:[UC-13-02:EfficientMessages]
   2. Leave this requirement out of use case and requirements document.


ISSUE:[UC-13-03:OptionalAuthentication] 
   1. Add this requirement to the use case and requirements document.



ISSUE:[UC-13-04:OptionalSignatures] 
   1. Add this requirement to the use case and requirements document.



ISSUE:[UC-13-05:SecurityPolicy] 
   2. Leave this requirement out of use case and requirements document.


ISSUE:[UC-13-06:ReferenceReqt] 
   1. Replace [R-Reference] with these requirements.