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: Irving's votes for 6, 7, 8, 9


All issue resolutions are mutually exclusive, so please choose one
option for each issue.


2. Leave current binding to SOAP.





IR: I feel that enveloping/enveloped formats will arise from particular
bindings and applications. We should let the requirement arise from a
specific use instead of arbitrarily asserting it. However, I don't feel
strongly enough about this to vote against.


   1. Add proposed requirement [CR-8-01:Intermediaries].

IR: This question really has two major parts: passing SAML through
intermediaries, and requiring that validity can be checked without
direct contact between AP and RP. The first is a clear yes, the
second I'm not so sure about.


   1. Add the given use-case scenario to the document.

IR: The use case could be greatly simplified. We don't need a full-blown
B2B design just to illustrate IntermediaryAdd.


   1. Add the given use-case scenario to the document.


   2. Don't add this use-case scenario.


   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.


   1. Add the proposed non-goal [CR-9-01:RuntimePrivacy].


   4. Add none of these as requirements.

IR: I would support adding [CR-9-02-4-DisclosureMishra] as a 'best practice'
but not as a requirement.

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

Powered by eList eXpress LLC