[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