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: My Votes on 6, 7, 8, and 9


Thought I'd throw my votes out there.

---8<---

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

ESP: I believe David's right on this, SOAP is what's there.

[UC-7-01:Enveloping]

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

ESP: We need to explicitly require this kind of functionality,
especially for session management, single-signon, etc.

[UC-7-02:Enveloped]

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

ESP: This is crucial not only for B2B usage, but also for
making SAML useful for other XML standards.

[UC-8-01:Intermediaries]

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

ESP: It's too limiting not to allow some form of intermediary.

[UC-8-02:IntermediaryAdd]

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

ESP: This seems useful, especially in combination w/ UC-8-05.

[UC-8-03:IntermediaryDelete]

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

ESP: It's been discussed, it is a use case, we need to address it (but
within the scope of UC-8-05).

[UC-8-04:IntermediaryEdit]

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

ESP: Again, it's something that's going to happen, we need to address
it explicitly.

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

ESP: An important clarification for all the intermediary use case
scenarios that, if not stated, could greatly increase the work of the
TC.

[UC-9-01:RuntimePrivacy]

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

ESP: I believe that privacy and disclosure should be negotiated
between trust partners, and between user and service, out-of-band.
The overhead of making policy statements is too high.

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

ESP: I think if we have [CR-9-01] added, we can dismiss the issue of
privacy.

---8<---

~ESP



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


Powered by eList eXpress LLC