feat: repo structure and hitherto docs#1
Conversation
wojciechkrzos
force-pushed
the
feat/initial-commit
branch
from
36b63c3 to
51da75f
Compare
|
quick initial comment: if you're linking to directories from the root readme, you might as well put a readme file in each of the directories being linked to |
| auth = softwareSystem "3rd Party Auth" { | ||
| tags "External System" | ||
| } |
There was a problem hiding this comment.
imo we shouldn't be immediately saying that all auth is going to be 3rd party - i'd use the term Authentication Module(s) when referring to the way auth can be done in voting sessions
some auth modules will be communicating with 3rd party services, but some may rely on the voting session organizers manually verifying the voter's identity, or others may be just a simple email verification code check
There was a problem hiding this comment.
In the C1 view, we set our system in an ecosystem of users and external systems.
When we develop the diagram further, I can imagine there will be an authentication container handling user authentication that also communicates with those external auth services.
I can see how the inclusion of only the C1 view may be misleading this way.
| | ID | Name | Description | | ||
| | --- | --- | --- | | ||
| | FR-101 | Casting Votes | The system allows eligible voters to cast a single vote per question in an active voting session. A voter cannot vote more than once on the same question. | | ||
| | FR-102 | Adding Questions During Voting | The system allows admins to add new questions to an active voting session. Added questions apply only to voters who have not yet cast their vote. Users who have already voted are not required to vote again. | |
There was a problem hiding this comment.
describing "adding new questions" like this will cause problems, mainly because you're creating a possibility for some voters to be accidentally excluded from voting on new questions.
my original idea of the ability to add questions relies on the entire voting session being synchronous (i.e. everyone's voting on the same question, one by one, and we're waiting for everyone to vote before moving onto the next question)
this idea likely will not be applicable to asynchronous voting sessions, should we decide to implement those
anyway, in a synchronous voting session, for the voter there's no distinction between a "new question" and a "prepared question" - all they should see is the next question becoming available to vote on when the time comes.
for the voting session organizer, this functionality should boil down to being able to edit the question templates that they have prepared in the preparation stage, or even creating new ones and inserting them into their queue, before putting that question up to the vote.
(the question queue should be a function visible exclusively to the organizer, and it should only be a suggestion - it shouldn't block the organizer from starting questions out of order)
oh and editing a live question obviously should not be permitted
| | --- | --- | --- | | ||
| | FR-101 | Casting Votes | The system allows eligible voters to cast a single vote per question in an active voting session. A voter cannot vote more than once on the same question. | | ||
| | FR-102 | Adding Questions During Voting | The system allows admins to add new questions to an active voting session. Added questions apply only to voters who have not yet cast their vote. Users who have already voted are not required to vote again. | | ||
| | FR-103 | Vote Anonymity | The system does not associate cast votes with individual voter identities. Admins can only view aggregated results. | |
There was a problem hiding this comment.
...unless the vote was explicitly designated as public/non-confidential
for some question types (mainly the "presence/quorum check") the non-confidential voting mode would likely be preferred
|
|
||
| | ID | Name | Description | | ||
| | --- | --- | --- | | ||
| | FR-201 | Session Configuration | The system allows admins to create, edit, and delete voting sessions, including setting their start and end time and assigning questions. | |
There was a problem hiding this comment.
scheduling session start/end times should be exclusive to asynchronous sessions - it doesn't make sense for synchronous sessions
|
|
||
| Client->>Client: Generate token m | ||
| Client->>Client: Generate blinding factor r | ||
| Client->>Client: Blind token using m, r and signer public key |
There was a problem hiding this comment.
is the public key actually used in the blinding process?
There was a problem hiding this comment.
tl;dr yes
Yes, public key is used during blinding process on the client side. We're rising r-factor to power of e-value from RSA key, and server during signing utilizes private key and rises everything to the d-value from it's private key. From the RSA keys property - e*d = 1, which leaves to client clear r-factor, and can be removed by client itself.
Whole explanation can be found on our Google Drive folder.
| Signer->>Auth: Check voter eligibility | ||
| Auth-->>Signer: Voter eligible and not used yet | ||
|
|
||
| Signer->>Signer: Sign blinded token with private key | ||
| Signer->>Auth: Mark authorization as used |
There was a problem hiding this comment.
race condition possibility: checking whether the voter was already issued a token and storing the fact that they have already voted should be one, atomic operation
otherwise it would be possible to get two votes if you send the two requests fast enough
There was a problem hiding this comment.
During signing process, we can associate blinded token with user that is requesting his token that is being signed (because it's blinded).
Before signing, server can check in database, whether this user already requested voting token or not. If not, it should refuse this operation.
This forces us to warn user, that getting a new voting "card" (for us: generating a new voting token) is one time operation, and can't be repeated on other device.
| Client->>Client: Unblind signed token using r | ||
| Client->>Client: Obtain signed anonymous voting token | ||
|
|
||
| Voter->>Client: Select vote | ||
| Client->>Client: Encrypt vote with election public key |
There was a problem hiding this comment.
not an expert in blind signatures, but i feel like something's wrong here.
from my understanding, i believe that the whole reason why we're blinding something, is that we want the authentication/verifier server to sign our vote without knowing what was our vote
as i understand, the "blinded token" being signed is simply the blinded vote (or maybe a hash of the vote payload, either way it's supposed to validate the vote)
then, unblinding the token produces a signed vote, without anything stating that we were the ones who cast that vote
therefore i think that stating that the token is obtained before actually casting the vote is inaccurate
There was a problem hiding this comment.
Only thing that is being blinded, is voting token, not whole vote.
This allows us to obtain a token, which server consider as valid, but doesn't know which user requested it.
Voting payload (user answers if I understand correctly) should be additionally encrypted, to make sure they are secure during sending.
Server gets voting payload (that it can easily decrypt) with voting token that is unblinded, but signed. Server validate its sign and saves vote.
Because the only thing that server saw before, is blinded version of token, it's impossible to associate it with user that requested this sign.
|
@mini-bomba it should be ok rn |
|
🔥 |
| | ------ | ------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ||
| | FR-101 | Casting Votes | The system allows eligible voters to cast a single vote per question in an active voting session. A voter cannot vote more than once on the same question. | | ||
| | FR-102 | Managing Question Queue | In synchronous voting sessions, the system allows admins to manage a private suggested queue of question templates before each question is opened for voting. Admins can edit prepared question templates, create new templates, insert them into the queue, and start questions out of order. A live question cannot be edited. | | ||
| | FR-103 | Vote Confidentiality Mode | The system allows each question to be designated as confidential or public/non-confidential. For confidential questions, the system does not associate cast votes with individual voter identities and admins can only view aggregated results. Public/non-confidential questions may be used for cases such as presence or quorum checks. | |
There was a problem hiding this comment.
I'm not sure if voters' anonymity should be determined on question-level, rather than session-level. On event diagram, it was clear that token generation (which also includes checking if voting is confidential) is done right after voter authentication. Making that change will force us to check confidentiality after each question, and generate new token every time. It isn't impossible to implement, but I can't imagine scenario where admin needs to know voters' choices in one question, and doesn't in next one.
No description provided.