Votes for 2, 3, etc.

[Evan Prodromou <evan@outlook.net>]

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

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.

ESP: I think this is a reasonable use case scenario, it gives a good
illustration of a great application of SAML, and it especially calls
out the firewall/proxy issue.

ISSUE:[UC-2-03:ASP]
2. Do not add this use-case scenario.

ISSUE:[UC-2-05:EMarketplace]
   2. The above scenario should not be added to the 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]
   2. Do not add this scenario.

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

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
does not 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] 
2. Add non-goal [CR-10-07-2:NoExtensionNegotiation].

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

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

ESP: I have a lot of trepidation about this one, since I believe that
it's difficult to build in to SAML. But at the same time it's an
important principle, and I am having a hard time having us NOT apply
it. The requirement is general enough that it could be applied at the
protocol bindings level or as encryption of assertions or messages
without a change. Although I can see cases where in-the-clear SAML
data would be useful, in general I believe this is the right choice.

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.

ESP: We have to call it one way or the other. Unless we build our own,
apply a non-XML encryption mechanism, or wait for XML-Encryption --
none of which are very tasty.

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
***************

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] 
   2. Leave this requirement out of use case and requirements document.

ISSUE:[UC-13-04:OptionalSignatures] 
   2. Leave this requirement out of 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.