votes on 2,3,4,10,12,13

["Orchard, David" <dorchard@jamcracker.com>]

Note, I found issue group 10 to be almost completely design oriented, and
not use case/requirements oriented.  I would actually have prefered a vote
on whether this should even be addressed in the use case/reqs.  I realize
that this comment would have been more effective on wednesday.  Like Evan
and the rest, my life has been hectic.

As a leading player in the ASP space, please note my vote on 2-03. 

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

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]
   1. This issue is now obsolete and can be closed as several
security services
      (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
does not
      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 SAML too far. SAML should not
specify AuthZ
      policies.


**************
* 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-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] 
   1. Add requirement [CR-10-07-1:ExtensionNegotiation].


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

ISSUE:[UC-12-01:Confidentiality]
   1. 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
***************

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] 
   1. Replace [R-Reference] with these requirements.

Dave Orchard
XML Architect
Jamcracker Inc.,    19000 Homestead Dr., Cupertino, CA 95014
p: 408.864.5118     m: 604.908.8425    f: 408.725.4310

www.jamcracker.com - Sounds like a job for Jamcracker.