[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: JeffH's votes RE: Ballot for Issue Groups 2, 3, 4, 10, 12,an d 13 attached
If I understand Jeff's votes on issue group 3 correctly, he is voting for a lesser strength of session management than stated. It seems he would vote for the 3-3,5,6,8,9 in the "should" or "may" sense rather than the "must" sense. So it seems that his votes on this issue are very clearly not against adding the reqs, but instead for loosening the requirements a little. I think this vote is very close so it's important to clearly characterize the differences. Cheers, Dave > -----Original Message----- > From: Jeff Hodges [mailto:jhodges@oblix.com] > Sent: Saturday, April 07, 2001 1:04 AM > To: oasis sstc use > Cc: Darren Platt > 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 > > ------------------------------------------------------------------ > 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