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: DaveO votes on 6, 7,8,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.

[UC-7-01:Enveloping]

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

I would like a single place in the SAML message that allows for extension
via a schema ANY construct, nothing more complicated than that.

[UC-7-02:Enveloped]

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

After much thought, I think that it will probably be saml applications
talking to each other, then the b2b applications afterwards.  Enveloped
leaves out the processing model and makes for difficult conformance testing.

[UC-8-01:Intermediaries]

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

Clearly something needs to be done with intermediaries.  But I haven't seen
any responses to my questions on intermediaries, so I haven't heard
convincing use cases for add/delete/edit of assertions.  So I will vote for
intermediaries to keep in scope, as well as Adding as that seems a very
explicable thing for an intermediary to do, and against each of the
remaining particular instances.   Prateek's argument convinces me to vote
for add.

[UC-8-02:IntermediaryAdd]

*   1. Add the given use-case scenario to the document.
   2. Don't add this use-case scenario.

[UC-8-03:IntermediaryDelete]

   1. Add the given use-case scenario to the document.
*   2. Don't add this use-case scenario.

[UC-8-04:IntermediaryEdit]

   1. Add this use-case scenario to the document.
*   2. Don't add this use-case scenario.

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

[UC-9-01:RuntimePrivacy]

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

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







Dave Orchard
XML Architect
Jamcracker Inc.,    19000 Homestead Dr., Cupertino, CA 95014
p: 408.864.5118     m: 604.908.8425    f: 408.725.4310

www.jamcracker.com - Sounds like a job for Jamcracker.


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


Powered by eList eXpress LLC