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


a process comment: we need to define what "end of the day" actually means. It
means to me at this point to call up Darren and ask him when he ~really~ needs
it to be in. Using UTC time might indeed help. 


> ****************
> *  Group 2 
> ****************
> 
> ISSUE:[UC-2-01:AddPolicyAssertions] 
>    1. Remove the non-goal, add this requirement, and refer to data in
>       this format as "policy documents."
>    2. Maintain the non-goal, leave out the requirement.

vote: 2.



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

vote: 2.


> ISSUE:[UC-2-03:ASP]
> 1. Add this use-case scenario to the document.
> 2. Do not add this use-case scenario.


vote: 2. 


> ISSUE:[UC-2-05:EMarketplace]
>    1. The above scenario should be added to the use cases document.
>    2. The above scenario should not be added to the document.

Vote: 1.

rationale: it's describing things at a fairly high level of abstraction and
isn't already covered in the present doc (draft-sstc-use-strawman-03.html).
However, I (also) feel that addressing this sort of scenario is a lower
priority than the "web-browser sign-on scenario(s)".


> ISSUE:[UC-2-06:EMarketplaceDifferentProtocol]
>    1. Add this scenario to the document.
>    2. This use case scenario should not be added to the document.

vote: 2.


> ISSUE:[UC-2-07:MultipleEMarketplace]
>    1. Add this scenario to the document.
> 
>    2. The above scenario should not be added to the document.

Vote: 2.


> ISSUE:[UC-2-08:ebXML]
>    1. Add this use case scenario to the use case and requirements document.
>    2. Do not add this scenario.

vote: 2. 

rationale: needs work. specific mention of "DN" way too deep a level for this
doc (draft-sstc-use-strawman-0x).


> *******************
> * Group 3 
> *******************

overall rationale: for the level of abstraction appropriate in
draft-sstc-use-strawman-0x, I think we need to only expand the existing
requirement..

  [R-UserSession] SAML shall support web user sessions.

..as-needed. Also, many of the below detailed features ought to be expressed as
"SHOULD" or "MAY" clauses in the so-edited [R-UserSession], not as "MUST"s. 



> ISSUE:[UC-3-03:Logout]
>    1. Add this requirement to SAML.
>    2. Do not add this requirement to SAML.

Vote: 2.

> ISSUE:[UC-3-05:SessionTermination]
>    1. Add this requirement to SAML.
>    2. Do not add this requirement and/or use cases.

Vote: 2.

> ISSUE:[UC-3-06:DestinationLogout]
>    1. Add this scenario and requirement to SAML.
>    2. Do not add this scenario or requirement.

Vote: 2.

> ISSUE:[UC-3-8:DestinationSessionTermination]
>    1. Add this scenario and requirement to SAML.
>    2. Do not add this scenario or requirement.

Vote: 2.


> ISSUE:[UC-3-9:Destination-Time-In]
> 1. Add this scenario and requirement to SAML.
> 2. Do not add this scenario or requirement to SAML.

Vote: 2.


> ***************
> *  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.
> 2. This issue should be kept open.

Vote: 2.

rationale: the term "security service" is used throughout
draft-sstc-use-strawman-03 without being clearly defined. We should do so. 



> ISSUE:[UC-4-02:AttributeAuthority]
> 1. A use-case or use-case scenario similar to that described above should be
> added to SAML.
> 2. This issue is adequately addressed by existing use cases and doesnot
> require further elaboration within SAML.


Vote: 2.

rationale: this issue is a result of terminological muddiness in
draft-sstc-use-strawman-03 et al. draft-sstc-use-strawman-03 needs to be
normalized with draft-sstc-use-domain-03. [the latter perhaps should be
incorporated into the next rev of the former]




> ISSUE:[UC-4-03:PrivateKeyHost]
> 1. A use-case or use-case scenario comprising steps (a) and (b) aboveshould be
> added to the use-case document.
> 2. A requirement for supporting "binding" between AuthN assertionsand business
> payloads thru digital signature
> be added to the use-case document.
> 3. This issue has been adequately addressed elsewhere; there is noneed for any
> additions to the use-case document.


Vote 3. 

rationale: this is outta scope and is already being addressed elsewhere (tho
some SSTC folk are involved) see..

http://www.ietf.org/html.charters/sacred-charter.html

http://www.ietf.org/internet-drafts/draft-ietf-sacred-reqs-02.txt
http://www.ietf.org/internet-drafts/draft-ietf-sacred-framework-01.txt
http://www.ietf.org/internet-drafts/draft-ietf-sacred-scenarios-00.txt

Securley Available Credentials; Speaker - Magnus Nystrom
http://www.appcluster05.com/images/123/stamon11.pdf




> ISSUE:[UC-4-04:SecurityDiscover]
>   1.Yes, a service could be provided to send authorization dataabout a service
> between security zones. This would require some
>     sort of policy assertions (UC-2-01:AddPolicyAssertions). 
>   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.


Vote: 2.


> **************
> * Group 10
> **************
> 
> ISSUE:[UC-10-01:Framework]
> 1. Remove the extensibility requirement.
> 2. Leave the extensibility requirement.


Vote 2.

rationale: but we need to extensively re-work it. 


> ISSUE:[UC-10-02:ExtendAssertionData]
> 1. Add requirement [CR-10-02:ExtendAssertionData].
> 2. Do not add this requirement.

Vote 2.



> ISSUE:[UC-10-03:ExtendMessageData]
> 1. Add requirement [CR-10-03:ExtendMessageData].
> 2. Do not add this requirement.


Vote 2.



> ISSUE:[UC-10-04:ExtendMessageTypes] 
> 1. Add requirement [CR-10-04:ExtendMessageTypes].
> 2. Do not add this requirement.


Vote 2.



> ISSUE:[UC-10-05:ExtendAssertionTypes] 
> 1. Add requirement [CR-10-05:ExtendAssertionTypes].
> 2. Do not add this requirement.

Vote 2.




> ISSUE:[UC-10-06:BackwardCompatibleExtensions] 
> 1. Add requirement [CR-10-06-BackwardCompatibleExtensions].
> 2. Do not add this requirement. 

Vote 1, sorta.

rationale: this actually needs to be mixed-into the [R-Extensible] requirement
statement. 



> ISSUE:[UC-10-07:ExtensionNegotiation] 
> 1. Add requirement [CR-10-07-1:ExtensionNegotiation].
> 2. Add non-goal [CR-10-07-2:NoExtensionNegotiation].
> 3. Add neither the requirement nor the non-goal.

Vote 1, sorta.

rationale: this actually needs to be mixed-into the [R-Extensible] requirement
statement. I feel that extension negotiation is a "MUST" if one's protocol
supports the notion of extensions. 





> **************
> *  Group 12
> **************
> 
> ISSUE:[UC-12-01:Confidentiality]
> 1) Add [R-Confidentiality]
> 2) Do not add [R-Confidentiality]

Vote 1.

comment: but the term "SAML data" is vague and undefined. 


> ISSUE: [UC-12-02:AssertionConfidentiality]
> 1) Add the requirement:
> [R-AssertionConfidentiality] SAML should define a format so that individual
> SAML assertions may be encrypted, independent of protocol bindings.
> 
> 2) Add the requirement:
> [R-AssertionConfidentiality] SAML assertions must be encrypted, independent
> of protocol bindings.
> 
> 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.
> 
> 4) Do not add either requirement or the non-goal.

Vote 4. 

rationale: redundant. 




> 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.
> 
> 2) [R-BindingConfidentiality] Each protocol binding must always protect SAML
> data from observation by third parties.
> 
> 3) Do not add either requirement.


Vote: 1. 



> ISSUE:[UC-12-03:EncryptionMethod]
> 1) Add the requirement:
> [R-EncryptionMethod] SAML should use XML Encryption.
>
> 2) Add the requirement:
> [R-EncryptionMethod] Because there is no currently published standard for
> encrypting XML, SAML should define its own encryption format.
> Edit the existing non-goal of not creating new cryptographic techniques to
> allow this.
>
> 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.
> 
> 4) Do not add any of these requirements or notes.


Vote: 4.



> ***************
> *  Group 13
> ***************
> 
> ISSUE:[UC-13-01:Scalability] 
> 1. Add requirement [CR-13-01-Scalability].
> 2. Do not add this requirement.

Vote: 2. 


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

Vote: 1.

rationale: I suppose it's worth stating explicitly. 


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

Vote: 2.


> ISSUE:[UC-13-04:OptionalSignatures] 
>    1. Add this requirement to the use case and requirements document.
>    2. Leave this requirement out of use case and requirements document.

Vote: 2.


> ISSUE:[UC-13-05:SecurityPolicy] 
>    1. Add this requirement to the use case and requirements document.
>    2. Leave this requirement out of use case and requirements document.


Vote: 1.



> ISSUE:[UC-13-06:ReferenceReqt] 
>    1. Replace [R-Reference] with these requirements.
>    2. Leave [R-Reference] as it is.
>    3. Remove mention of references entirely.

Vote: 3.

rationale: "reference" is undefined and vague and way too deep into design-time
detail. 


---
end


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


Powered by eList eXpress LLC