JeffH's votes for 6, 7, 8, 9

[Jeff Hodges <jhodges@oblix.com>]

> 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.

I abstain. 

Rationale: From draft-sstc-use-strawman-03.html...

  [R-Bindings] SAML should allow SAML messages to be transported by standard  
Internet protocols. SAML should define bindings of the message protocol to at  
least the following protocols: 
        standard commercial browsers 
        HTTP as a transport protocol 
        MIME as a packaging protocol 
        XML Protocol as a messaging protocol 
        ebXML as a messaging protocol 

SOAP isn't presently in the list, so the ballot choices don't seem to make
sense to me. I suggest we simply add SOAP (and BEEP) to the list (and keep
XMLP) when producing draft-sstc-use-strawman-04. [R-Bindings] says "should" so
I don't think we need to sweat this list a bunch right now -- we should list
more here for now than might be formally accomplished *by this present SSTC
incarnation* because (I claim) we should ultimately design SAML such that
others may come along later and define bindings to the protocols we didn't get
to or didn't even have on the list. 


> 
> [UC-7-01:Enveloping]
> 
>    1. Add proposed requirement [CR-7-01:Enveloping].
>    2. Do not add this proposed requirement.

I vote for "2".

Rationale: see "Rationale" for [UC-7-02:Enveloped].

> [UC-7-02:Enveloped]
> 
>    1. Add proposed requirement [CR-7-02:Enveloped].
>    2. Do not add this proposed requirement.

I vote for "2".

Rationale: I tend to agree with Eve that SAML constructs should be (or will
turn out to be) "standalone", but that said, I agree with Irving that it seems
we're getting the cart ahead of the horse here. 


> [UC-8-01:Intermediaries]
> 
>    1. Add proposed requirement [CR-8-01:Intermediaries].
>    2. Do not add this requirement to the document.

I vote for "1".

Rationale: I think we should put this in so we can continue to refine the
notions therein (there's a fair amount of work to do here as DaveO notes). I
tend to agree with Irving's thoughts on this item, as well as Prateek, DaveO,
and Marlena thoughts. 

> 
> [UC-8-02:IntermediaryAdd]
> 
>    1. Add the given use-case scenario to the document.
>    2. Don't add this use-case scenario.

I vote for "1".

Rationale: I agree with Prateek, DaveO, and Marlena on this one and the
following two items. 

> 
> [UC-8-03:IntermediaryDelete]
> 
>    1. Add the given use-case scenario to the document.
>    2. Don't add this use-case scenario.

I vote for "2".


> 
> [UC-8-04:IntermediaryEdit]
> 
>    1. Add this use-case scenario to the document.
>    2. Don't add this use-case scenario.

I vote for "2".


> 
> [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.

I vote for "1", sorta.

rationale: Nominally, I think we'll find that assertions will need to be
"atomic". But I don't think we should express this using a "non-goal". And I'm
concerned that we're straying far from "use cases & scenarios" and a ways into
protocol design. 


> 
> [UC-9-01:RuntimePrivacy]
> 
>    1. Add the proposed non-goal [CR-9-01:RuntimePrivacy].
>    2. Do not add this proposed non-goal.

I vote for "2".

rationale: see below.


> 
> [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.

I vote for "1".

Rationale: I think we should keep this notion in-scope at a requirements level
and the wording of "1" does it succinctly. Plus it is expressed as "should",
not a "must". 

(we need to discuss the meanings of those words in a requirements context. I
tend to think that having it as a "should" means that a design can still be
considered to "meet" a "should" requirement even if that notion isn't embodied
in the design IF there are well-reasoned and well-expressed justifications for
not meeting it.)