[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Marlena's votes on 6-9
UC-6-01:XMLProtocol] Abstain. [UC-7-01:Enveloping] 1. Add proposed requirement [CR-7-01:Enveloping]. [UC-7-02:Enveloped] 1. Add proposed requirement [CR-7-02:Enveloped]. Comment: Initially, I thought both enveloped/enveloping to be "no-brainers", but then the dialog on the topic sowed doubt within me. I still have doubt but also I still think these both should be put in. I expect that if they are kept in, we will have more debate on them. [UC-8-01:Intermediaries] 1. Add proposed requirement [CR-8-01:Intermediaries]. [UC-8-02:IntermediaryAdd] 1. Add the given use-case scenario to the document. Comment: I think "add" is fine in the sense of "adding on" but not in the sense of "adding in". [UC-8-03:IntermediaryDelete] 2. Don't add this use-case scenario. [UC-8-04:IntermediaryEdit] 2. Don't add this use-case scenario. Comment: "Deleting" and "editing" have the feel of "tampering" to me. If the intermediary is truly a trusted entity then it can rewrite the assertions and be believed. And rewriting is what it should do. [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. Comment: I don't understand those folks who voted for "Atomic Assertions" but who also voted to include delete/edit by intermediaries as a use-case. (I look forward to clarification.) [UC-9-01:RuntimePrivacy] 1. Add the proposed non-goal [CR-9-01:RuntimePrivacy]. [UC-9-02:PrivacyStatement] 4. Add none of these as requirements.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC