[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RLBob's votes on 6 thru 9
BALLOT ---------------------------------------------------------------------- All issue resolutions are mutually exclusive, so please choose one option for each issue. [UC-6-01:XMLProtocol] 1. Change requirement for binding to SOAP to binding to XML Protocol. 2. Leave current binding to SOAP. 3. Remove mention of binding to either of these protocols. My vote: 2 [UC-7-01:Enveloping] 1. Add proposed requirement [CR-7-01:Enveloping]. 2. Do not add this proposed requirement. My vote: 2 Comment on UC-7-01: There is a very slippery slope here, including recursive inclusion of SAML assertions, critical and non-critical included data, size expectations of SAML assertions, etc. Use of XML invites lack of clarity about functional layers; we should resist. We should standardize only the inclusion of elements that have clearly-defined semantics. [UC-7-02:Enveloped] 1. Add proposed requirement [CR-7-02:Enveloped]. 2. Do not add this proposed requirement. My vote: 1 Comment on UC-7-02: This is a mostly null requirement (what could we do to SAML assertions to make them un-fit?). A stronger statement of the same idea is that we should consider requirements of specific XML-based protocols/documents for included security assertions. This I believe we should not do at this time. [UC-8-01:Intermediaries] 1. Add proposed requirement [CR-8-01:Intermediaries]. 2. Do not add this requirement to the document. My vote: 2 Comment on UC-8-01: The idea is generally valid but this requirement states it incorrectly. Multi-hop forwarding of assertions is needed in *some* scenarios; but not all assertions need this property. So this is a bindings issue: "There shall be bindings such that assertions can be verified when passed thru intermediaries". [UC-8-02:IntermediaryAdd] 1. Add the given use-case scenario to the document. 2. Don't add this use-case scenario. My vote: 2 Comment on UC-8-02: This is no doubt important, but I believe the security relationships between the "B2B" players are not well-defined, and the theoretical semantics of assertions-modifying-assertions are tortuous. This is a good candidate for SAML version 2. [UC-8-03:IntermediaryDelete] 1. Add the given use-case scenario to the document. 2. Don't add this use-case scenario. My vote: 2 [UC-8-04:IntermediaryEdit] 1. Add this use-case scenario to the document. 2. Don't add this use-case scenario. My vote: 2 Comment on UC-8-03 and -04: Both of these violate what to me is a fundamental aspect of an assertion, that it is integrity-protected once issued. These requirements have to be met in some other way, by issuing new assertions. [UC-8-05:AtomicAssertion] 1. Add the non-goal [CR-8-05:AtomicAssertion] to the document, and change use case scenarios to specify that intermediaries must treat assertions as atomic. 2. Don't add this non-goal. My vote: 2 Comment on UC-8-05: Since this point seems to be contentious, it needs to be added as a positive statement: assertions are made by asserting parties, can be securely associated with asserters by receivers, can't be modified once issued, can't be passed along except if protected by signature, etc. These are just basic security principles. [UC-9-01:RuntimePrivacy] 1. Add the proposed non-goal [CR-9-01:RuntimePrivacy]. 2. Do not add this proposed non-goal. My vote: 2 [UC-9-02:PrivacyStatement] 1. Add [CR-9-02-3-DisclosureMorgan] as a requirement. 2. Add [CR-9-02-2-DisclosureBlakley] as a requirement. 3. Add [CR-9-02-4-DisclosureMishra] as a requirement. 4. Add none of these as requirements. My vote: 4 Comment on UC-09: I agree that this level of requirement is not consistent with the level of our other requirements. I hope we can agree that SAML will be used in environments where privacy protection is important; in that sense it is part of the "domain" in the same way that other aspects of our domain model are. Scalability and other "business requirements" as I have termed them are similar to this, and unfortunately we don't currently have a place to capture these. So, I'm content with this being referred to the security and privacy considerations group for further oversight.
Powered by eList eXpress LLC