OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-use message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Zahid Ahmed's votes for 6, 7, 8, and 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.

I vote for "2".

SOAP and BEEP need to be added to binding list; it seems
that neither one of them is present currently.


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

I vote for "1".

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 "1".
Rationale here is that security assertions will need to be
transported with business and application documents to
describe document originating parties identities and
authenticated assertions. However, the issue David Orachard
has raised w.r.t. enveloping vs enveloped requirements
is an important one that we can possibly resolve further 
during the B2B use case ballot. Additionally, the enveloped
issue is an important binding issue, e.g., SOAP, MIME,
and ebXML.

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


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

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

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

I vote for "1".


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

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

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





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC