OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-use message

[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