Hal's votes RE: Ballot for Issue Groups 2, 3, 4, 10, 12,and 13 a ttached

[Hal Lockhart <hal.lockhart@entegrity.com>]

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


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

I am voting for these reluctantly because I feel that this will add
complexity throughout  SAML. For example, in a session environment it will
NEVER be possible to use an assertion  without checking with the session
authority to see if the session has been killed. SAML will  have to provide
the means to determine if some online service must be consulted or if the
assertion can be used as is. I am concerned that the greater complexity will
delay both  agreement on SAML and deployment. I suggest we keep an open mind
on dropping this once we  see how complex the design is.


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]

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.

I don't think SAML should do this, but I think the final decision should be
a matter of  design not requirements.


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


***************
*  Group 13
***************

ISSUE:[UC-13-01:Scalability] 
1. Add requirement [CR-13-01-Scalability].


ISSUE:[UC-13-02:EfficientMessages]
   1. Add this requirement to the 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] 
   3. Remove mention of references entirely.

I favor the use of references (values with no inherent semantics) vs.
compressed, encrypted  assertions, but I think this is an engineering
decision, not a requirement.