RLBob's votes on 6 thru 9

[RL 'Bob' Morgan <rlmorgan@washington.edu>]

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.