[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: votes on 2,3,4,10,12,13
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC