Closed NateWilliams2 closed 2 years ago
I'm worried that this is going to bite us in the long term - now we have two definitions of what a process ID is?
A process has many characteristics and options, so I think it's not a good idea to start cramming some of those as prefixes or suffixes to the hex ID :)
What are you actually trying to do that led you to this solution? If you're using SQL for example, you can fairly easily write a SQL query that filters by vote type or any other column.
What are you actually trying to do that led you to this solution? If you're using SQL for example, you can fairly easily write a SQL query that filters by vote type or any other column.
The main idea is that the CSP currently does not query the database or the vochain. We want it to be a free-standing component that only needs to determine if a user is eligible to vote, and signing a package for that user. The problem is, if the user determines whether they want a blind or ecdsa signature, we can't enforce public or anonymous voting processes. So the point of this proposal is that the CSP can derive this information from the processID, which is the only information about the process it has.
Sorry, no idea what CSP stands for :)
does not query the database or the vochain. We want it to be a free-standing component
Perhaps I'm missing some context regarding CSP, but I thought vaas-api would have access to its own database as well as talking to the gateway API - so shouldn't it have all the information about processes that's needed, e.g. via processInfo/getProcess?
@p4u could this information be retrieved form the vochain?
Sorry, no idea what CSP stands for :)
@mvdan, the CSP is the credentials provider service. It is an external piece from the VaaS API itself and it is only in charge of issuing (plain/blind) signatures to voters with valid census proofs. The rationale behind this is that going to the Vochain or DB may pose a performance impact on the CSP responses (which should ideally act as pure functions). But solving this by adding hidden dependencies on the API-CSP is also a convern IMO.
The current status of this is that we've decided blind vs. signed votes is not a blocker, as for the time being we will only use blind signatures for votes. When we add support for transparent voting processes via ecdsa rather than blind signatures, we can re-analyze this proposal or fetch the process from another source of truth.
I miss some comments in your code @NateWilliams2
If we don't add comments the next developer that takes this will be lost (why prefixing with 0/1 the processId?)