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

 


Help: OASIS Mailing Lists Help | MarkMail Help

election-services message

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


Subject: RE: Things to do - Requirement Document. Security.


Krishna,

I know that we are talking about general requirements for e-voting system,
but my comments were *only* about the security part of the requirements :)

> 
> |I believe that vote-casting environment should not be 
> included into the
> |security discussion. It has nothing to do with tokens/protocols.
> 
> 	Again, we need to touch upon the vote casting 
> environment in general terms
> in the requirements section. The more generic the better, but 
> still need to
> include any assumptions, requirements, ...
> 

Well, I don't see a point of "touching upon" something, in a formal document
produced by a standard body, which is not within a scope of the activity.
And I believe that a general voting procedure and the flow, and consequently
general vote casting environment, are outside of our concern.

I admit I may be wrong here and the group may consider the opposite. Then
the question really is how do we know where to stop in our "general view",
and who would be the intended audience for it. I don't think that those
running the election compain(s) would be interested in finding out what we
have to say about "their way of doing it" - our position would be a mere
reflection of existing practices, and I see no need in reiterating it.

I can think of an anternative :) - if anybody knows about a good document,
or a resource, which describes (in general terms!) a "common view" on
e-election process, with all participants, flows and interactions, then we
can simply reference that document. Or even take ownership of it, depending
of what it is.
I'm sure that there must be something like that, probably from the election
solution vendors who are on the list.

To me, that'd be probably a simpler and smarter way, instead of making it a
task for the TC to generate yet another document of the kind.

Best regards
Michael


-----------------------------------------------------------------------------------------------------------------
"How can I make sure the right people get access to the right resources 
and business applications, with a user base that's constantly growing and
changing?" 
The answer... 
Baltimore SelectAccess 
Next Generation Authorisation Management 
http://www.baltimore.com/selectaccess/index.html
-----------------------------------------------------------------------------------------------------------------
The information contained in this message is confidential and is intended 
for the addressee(s) only.  If you have received this message in error or 
there are any problems please notify the originator immediately.  The 
unauthorized use, disclosure, copying or alteration of this message is 
strictly forbidden. Baltimore Technologies plc will not be liable for direct, 
special, indirect or consequential damages arising from alteration of the 
contents of this message by a third party or as a result of any virus being 
passed on.

In addition, certain Marketing collateral may be added from time to time to 
promote Baltimore Technologies products, services, Global e-Security or 
appearance at trade shows and conferences.
 
This footnote confirms that this email message has been swept by 
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.


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


Powered by eList eXpress LLC