💡 Support CLI DRep votes in proposal pillar API

[Ryun1]

Area

Proposal Pillar

Is there new design needed?

No

What?

Background

GovTool is built for interacting with web-based wallets, communicating over CIP-30/CIP-95 to read user’s public credentials and request signatures from secret credentials.

GovTool uses .signData() to prove a wallet controls the secret credentials associated with the presented public credentials. Via the GovTool Proposal Pillar frontend, users produce signatures for Stake and DRep keys which if valid, grant them JWT access token to comment and vote on proposals.

For the life of the JWT token (currently set as XXX), Proposal Pillar knows that the connected wallet/user is who their wallet claims them to be. Proposal Pillar’s backend APIs require this valid JWT token to allow interaction.

GovTool’s Proposal Pillar backend is the only source of truth for proposals. This makes coordination with other tools reading and writing to this data harder, than if this data was stored on-chain.

Why?

Some DReps don't use standard wallets to control their DRep credentials, and so cannot connect to the Proposal Pillar’s frontend to be authenticated. This means that these DReps are excluded from being able to participate in Budget Proposal discussions. This is bad as the Budget Process aims to include all DReps in reviewing proposals.

How?

Since CLI DReps are unable to authenticate themselves via Proposal Pillar’s web interface/JWT, we must use another method to prove their key ownership (which is a prerequisite to be able to POST comments and votes.

For a minimum approach we could introduce new backend endpoint(s) which allow CLI (or anyone) to POST comments/polls too. Something like bd-external-poll-vote.

This endpoint would expect the normal comment/poll parameters, but would also require a way to authenticate/verify the associated DRep credentials. We could do this by having the DRep supply a ‘.signData()’ style signature with each POST request. The Proposal Backend can then verify the signature, and if valid the DRep’s comment/vote will be added to the database.

The signature per POST request replaces the need for the creation of an authenticated JWT token.

In an ideal world, the Proposal Pillar frontend would be able to give the DRep the required JSON object that they have to sign over. Similar to how Summon does it, see in video here. For MVP we can rely on a documentation page with boilerplate.

basic flow

• CLI DRep browses the Budget Discussions frontend and finds a proposal they want to submit a poll vote on
• (They follow some instructions on how to submit a poll)
• They create a vote JSON object, which contains data on what they are voting on and their voting choice
• They use their CLI keys to produce a signature over this data/ hash of data
• They POST this vote object and signature to bd-external-poll-vote
• The Proposal Pillar backend verifies the data and signature is valid
• If all is valid then the data is saved to the Proposal Pillar Database

Open Questions

What signature scheme should/could be used for CLI users?

There are two options here, either we use the CIP-08 standard, which matches the .signData() method, OR we have CLI uses include the object within transaction metadata and sign that.

The CIP-08 standard signatures would be easier for the Proposal Pillar to validate as this is how current .signData() is validated. But this is likely harder for CLI users, because this standard is not a part of the cardano-cli, so users would need to install and use other tools such as cardano-signer. This may be annoying for them.

Asking CLI users to create a invalid transaction (so it can’t be submitted) with the metadata is likely easier for CLI users to do, and matches how they have used tools such as Summon platform before. But this adds some additional overhead for how Proposal Pillar validates the requests, but this isn't something too difficult.

What is the needed data to be included in the POST request?

We will need to decide the exact information required for a DRep to post a comment or a vote into the Proposal Pillar database. The content is straightforward, but we will just have to document it properly.

As mentioned above ideally, we would integrate this into the frontend somehow, offering DReps the JSON object they will need to sign over, allowing them to copy and paste.

(Optional) User Story with acceptance criteria

No response

[profd2004]

What signature scheme should/could be used for CLI users?
CIP-08
This makes the most sense. While downloading cardano-signer is nuisance we can help by including the curl they can copy and paste. If they are already on the cli, this shouldn't be a big huddle, if any at all.

Considerations for not using the tx hack.
A good number of wallets already don't allow their users to interactive with false-y transactions for security reasons. The latest version of eternl join this class of wallets. The original hack was to accommodate hardware wallets but we since added cip-08 support to ledger. Also if we can avoid touching cli users (a rightfully paranoid class of users) spending keys, the better.

[profd2004]

What is the needed data to be included in the POST request?

The proposed approach makes sense to me--same data as the web client. This will keep the code bases simpler for tool makers. I would even suggest that the outcome of a .signDate() data equipment be put in the header instead of the POST body.

[ptrdsh]

Thanks @Ryun1 for creating this.

agree with @profd2004's statements. Signing an invalid tx with a spending key is a nono.
I also think CIP08 or CIP30 via cardano-signer or cardano-hw-cli isnt shouldnt be a big deal for most.. it certainly is better than no option at all.

Before I make a suggestion, I want to bring another class of voters to attention: multisig script Dreps. Fulfilling such a script requires 1-n signatures of keys defined in the script - there is no one key associated with the Drep, and also no stake credential. If the eventual solution is not generic enough, script DReps are left out again.

The POST voteChoice.json to backend idea is neat, but I fear that we may run into limitations what the various (hardware) wallets can handle if the json is to be signed unhashed. Albeit submitting the unhashed voteChoice.json alongside the signature should be simple. In order for that solution to scale and not become a nightmare to use (creating one json by hand per vote would be such a nightmare), all proposals should be downloadable as one json and ideally contain a vote choice field already (yes/no/abstain), so that a DRep voting via JSON can work with one single file and not dozens of small ones that need to be individually signed.

Alternative idea:
How about presenting a simple challenge that needs to be signed (CIP8/CIP30) in whatever way a DRep manages their key(s)? This challenge appears upon clicking a new login option "Verify as DRep offline" and is custom to a specific DRep (so the DRep should also enter their DRepID/pubkey). The DRep pastes the signature and gov.tools verifies if it matches the DReps pubkey for said challenge. No idea if the DRep registration certificate contains the pubkey for onchain verification that the DRepID matches the pubkey, but if not, then the DRep is required to have at least voted once, which would be a reasonable requirement..
Upon successful verification, the user is granted the jwt token.. For multisig scripts, the verification part probably needs some additional magic, but should be doable.
Problems:

• if the challenge is not deterministically created, the jwt token is quite volatile, and this procedure needs to be done every time the jwt tokens expires or disappears (like upon cookie clearance for example).
• if the challenge is deterministically created, the signature becomes the login secret. That has a few advantages, but could likely not be appreciated by particularly paranoid folks.

Going off of the alternative idea, a second variation, which I find reasonable, solves the problems above and is very flexible:
The whole challenge/signature dance could be used to delegate budget vote rights of a DRep to a webwallet key thats specifically limited to actions on gov.tools. This would also allow SPOs to join the conversation.

[ptrdsh]

As mentioned above ideally, we would integrate this into the frontend somehow, offering DReps the JSON object they will need to sign over, allowing them to copy and paste.

didnt see that sentence in Ryans text.. disregard my comment on JSON content and downloadability.