Irving's votes for Issue Groups 2, 3, 4, 10, 12, and 13

[Irving Reid <Irving.Reid@baltimore.com>]

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.


Since use cases aren't normative, we can throw them all in for now
and decide later if some of them are too hard to support.


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

We really must support ebXML.

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

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

I'm not happy with the explicit "message format" in the requirement;
I think whether a message is needed or not is a protocol design decision.


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


As with the previous issue, I think that if we support sessions we must
support timeout, but we shouldn't specifically require a message format.



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.

I'd be happy if we come up with a design that supports this, but I
don't want to require it for SAML 1.0


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

ISSUE:[UC-4-01:SecurityService]
1. This issue is now obsolete and can be closed as several security services
(shared sessioning, PDP-->PEP relationship)


ISSUE:[UC-4-02:AttributeAuthority]
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 no need 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]
2. Do not add this requirement.

This is a design decision to implement the general extensibility
requirement.

ISSUE:[UC-10-03:ExtendMessageData]
2. Do not add this requirement.

Another design decision.

ISSUE:[UC-10-04:ExtendMessageTypes] 
1. Add requirement [CR-10-04:ExtendMessageTypes].


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


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]
1) Add the requirement:
[R-AssertionConfidentiality] SAML should define a format so that individual
SAML assertions may be encrypted, independent of 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
***************

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


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] 
   3. Remove mention of references entirely.

This decision belongs to the Bindings group.