RE: Zahid Ahmed's votes for Issue Groups 2, 3, 4, 10, and 12 attached

[Darren Platt <dplatt@securant.com>]

Corrections accepted.


> -----Original Message-----
> From: Ahmed, Zahid [mailto:zahid.ahmed@commerceone.com]
> Sent: Friday, April 06, 2001 7:57 PM
> To: 'Darren Platt'; 'UseCaseList'
> Subject: RE: Zahid Ahmed's votes for Issue Groups 2, 3, 4, 10, and 12
> attached
>
>
> 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
>