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: Ballot for Issue Groups 2, 3, 4, 10, 12, and 13 attached


My votes attached.

> -----Original Message-----
> From: Darren Platt [mailto:dplatt@securant.com]
> Sent: Wednesday, April 04, 2001 6:02 PM
> To: UseCaseList
> Subject: Ballot for Issue Groups 2, 3, 4, 10, 12, and 13 attached
>
>
> Please send your completed ballots to my email address
> (dplatt@securant.com)
> directly as well as to the whole list.  Deadline for voting is end of day
> Friday.
>
> I am asking that you send them to me directly because, due to a
> configuration problem with an email server (either Securant's or Oasis's -
> it's not clear which), there is often a delay of a day and sometimes more
> before I receive email that was sent to the lists (security-use,
> security-services, ...).
>
> Regards,
>
> Darren Platt
> Principal Technical Evangelist
> Securant Technologies
> 345 California St., 23rd Floor
> San Francisco, CA 94104
> tel - (415) 263-4976
> fax - (415) 764-4949
> http://www.securant.com/
> -----------------------------
>
>
****************
*  Group 2 
****************

ISSUE:[UC-2-01:AddPolicyAssertions] 
   2. Maintain the non-goal, leave out the requirement.

ISSUE:[UC-2-02:OutsourcedManagement]
1. Add this use-case scenario to the document.

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 securityservices (shared sessioning, PDP-->PEP relationship)
have been identified within S2ML.

ISSUE:[UC-4-02:AttributeAuthority] 
1. A use-case or use-case scenario similar to that described above should be added to 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] 
2. Add non-goal [CR-10-07-2:NoExtensionNegotiation].


**************
*  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] 
2. Do not add this requirement.

ISSUE:[UC-13-02:EfficientMessages]
   2. Leave this requirement out of use case and requirements document.

ISSUE:[UC-13-03:OptionalAuthentication] 
   2. Leave this requirement out of use case and requirements document.

ISSUE:[UC-13-04:OptionalSignatures] 
   2. Leave this requirement out of 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.














[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC