[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Zahid Ahmed's votes for Issue Groups 2, 3, 4, 10, and 12 atta ched
Darren and all, CORRECTION TO MY ATTATCHED BALLOTS FOR FOLLOWING TWO ISSUES (i.e., if Darren is allowing corrections): ISSUE:[UC-3-05:SessionTermination] 1. Add this requirement to SAML. ISSUE:[UC-3-06:DestinationLogout] 1. Add this scenario and requirement to SAML. NOTES: We do need some basic time-out descriptions in our SAML v1.0 specs althooug I'm concerned about the run-time and configuration complexities of 3-06. [However, if this is approved and widely uses, some of our own apps could exploit it.] thanks, Zahid >ISSUE:[UC-3-05:SessionTermination] > 2. Do not add this requirement and/or use cases. > >ISSUE:[UC-3-06:DestinationLogout] > 2. Do not add this scenario or requirement. -----Original Message----- From: Ahmed, Zahid Sent: Friday, April 06, 2001 3:11 PM To: Darren Platt; UseCaseList Subject: Zahid Ahmed's votes for Issue Groups 2, 3, 4, 10, and 12 attached **************** * 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. Note: This use case goals aee covered previous use cases already approved. 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 ******************* Note: Generally, I believe that session management would pose a difficult scenario to comply. However, I do see a need for application level session management. The concern I have is can we come out with a simple use case required in SAML 1.0 and deal with complex use cases in SAML v. 2.0. E.g., a simple logout could be useful in current timeframe. ISSUE:[UC-3-03:Logout] 1. Add this requirement to SAML. ISSUE:[UC-3-05:SessionTermination] 2. Do not add this requirement and/or use cases. 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. *************** * 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. ************** * 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. Zahid Ahmed Commerce One, Inc. Commerce Security Architect email: zahid.ahmed@commerceone.com v: (408)-517-3903 ------------------------------------------------------------------ To unsubscribe from this elist send a message with the single word "unsubscribe" in the body to: security-use-request@lists.oasis-open.org
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC