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


I agree with Darren's comments.  I would like to standardize the message
formats, not standardize the behaviour on the destination end.  This is very
akin to what XML has done.  For example, XML defines many things as "errors"
that must be "reported" to an application.  But there is little mention made
of how the reporting is to be done, how the application could/should deal
with the error, and when processing can/can't continue.  

So I think we are in agreement that we want to standardize the
messages/protocols/assertions/bindings, but not require end-point behaviour.

Dave 

> -----Original Message-----
> From: Darren Platt [mailto:dplatt@securant.com]
> Sent: Sunday, April 08, 2001 3:54 PM
> To: Hal Lockhart; UseCaseList
> Subject: RE: Hal's votes RE: Ballot for Issue Groups 2, 3, 4, 10, 12,
> and 13 attached
> 
> 
> Hal,
> 
> <Extracted from ballot comments>
> > I am voting for these reluctantly because I feel that this will add
> > complexity throughout  SAML. For example, in a session 
> environment it will
> > NEVER be possible to use an assertion  without checking 
> with the session
> > authority to see if the session has been killed.
> </Extraction>
> 
> I agree we don't want that, and I don't think that is the 
> goal of these
> requirements.  Instead, the goal is to say that the 
> individual 'destination'
> security domains can use this information any way they want.  
> The domains
> may choose to check with the 'source' security domain each 
> time a local
> session is used, at intervals, or not at all.  They may 
> choose to ignore
> explicit logouts sent to them by the source security domain.  The
> requirement should be to define a way within SAML that this 
> info could be
> communicated between security domains.  What the domains do 
> with it is up to
> them.  I also don't think that we are specifying that we link all SAML
> assertions to active sessions either - I'm not sure if that 
> was implied by
> your comment.
> 
> Regards,
> 
> Darren
> 
> 
> > -----Original Message-----
> > From: Hal Lockhart [mailto:hal.lockhart@entegrity.com]
> > Sent: Friday, April 06, 2001 11:42 AM
> > To: 'Darren Platt'; UseCaseList
> > Subject: Hal's votes RE: Ballot for Issue Groups 2, 3, 4, 
> 10, 12, and 13
> > attached
> >
> >
> > ****************
> > *  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]
> > 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
> > *******************
> >
> > I am voting for these reluctantly because I feel that this will add
> > complexity throughout  SAML. For example, in a session 
> environment it will
> > NEVER be possible to use an assertion  without checking 
> with the session
> > authority to see if the session has been killed. SAML will  have
> > to provide
> > the means to determine if some online service must be 
> consulted or if the
> > assertion can be used as is. I am concerned that the greater
> > complexity will
> > delay both  agreement on SAML and deployment. I suggest we keep
> > an open mind
> > on dropping this once we  see how complex the design is.
> >
> >
> > 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]
> >
> > 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.
> >
> > I don't think SAML should do this, but I think the final decision
> > should be
> > a matter of  design not requirements.
> >
> >
> > **************
> > *  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.
> >
> >
> > ***************
> > *  Group 13
> > ***************
> >
> > ISSUE:[UC-13-01:Scalability]
> > 1. Add requirement [CR-13-01-Scalability].
> >
> >
> > ISSUE:[UC-13-02:EfficientMessages]
> >    1. Add this requirement to the 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]
> >    3. Remove mention of references entirely.
> >
> > I favor the use of references (values with no inherent 
> semantics) vs.
> > compressed, encrypted  assertions, but I think this is an 
> engineering
> > decision, not a requirement.
> >
> 
> 
> ------------------------------------------------------------------
> 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