Having a generic authorization contract for each key about unilogin HOT 28 OPEN

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

This issue now has a funding of 0.001 DAI (0.0 USD @ $1.0/DAI) attached to it as part of the Ethereum Community Fund via ECF Web 3.0 Infrastructure Fund fund__.__

• If you would like to work on this issue you can 'start work' on the Gitcoin Issue Details page.
• Want to chip in? Add your own contribution here.
• Questions? Checkout Gitcoin Help or the Gitcoin Slack
• $37,333.16 more funded OSS Work available on the Gitcoin Issue Explorer

from unilogin.

Issue Status: 1. Open 2. Cancelled

The funding of 0.001 DAI (0.0 USD @ $1.0/DAI) attached to this issue has been cancelled by the bounty submitter

• Questions? Checkout Gitcoin Help or the Gitcoin Slack
• $37,333.16 more funded OSS Work available on the Gitcoin Issue Explorer

from unilogin.

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

This issue now has a funding of 350.0 DAI (350.0 USD @ $1.0/DAI) attached to it as part of the Ethereum Community Fund via ECF Web 3.0 Infrastructure Fund fund__.__

• If you would like to work on this issue you can 'start work' on the Gitcoin Issue Details page.
• Want to chip in? Add your own contribution here.
• Questions? Checkout Gitcoin Help or the Gitcoin Slack
• $37,683.16 more funded OSS Work available on the Gitcoin Issue Explorer

from unilogin.

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

Work has been started.

These users each claimed they can complete the work by 6 months, 4 weeks from now.
Please review their action plans below:

1) shine2lay has been approved to start work.

• Create the General Authorization Contract interface (already have a version of it that I've been working on with Alex Van de Sande)
• Create the two General Authorization Contract mentioned (each one using the interface + any specific functions to modify the authorization parameter)
• Modify the SignedExecutionScheme.sol so that ACTION_KEY will always check authorization contract to see if the action provided is authorized before execution

Learn more on the Gitcoin Issue Details page.

from unilogin.

@alexvandesande Here is my implementation plan, would love some feedback on it!

Additions:

• GeneralAuthorizationInterface.sol
  • isActionAuthorized() (param list for each will be updated later)
  • initAuthorization()
  • addAuthorizedAccount()
  • revokeAuthorizedAccount()
  • actionExecuted()
• AuthorizationWhiteListedAddress.sol (Checks if address is interacting with a whiteListed address)
• AuthorizationKeyAdditionLimit.sol (Checks and keeps track of how many keys have been added by a certain address)
• SignedExecutionScheme.sol:
  ** Modifications **
  • add a new parameter bytes extraData in executeSigned() similar to what is mentioned in https://eips.ethereum.org/EIPS/eip-1077 for future compatibility. This extraData parameter will include an address which points to authorizationContract to check.
  • before any action is executed, the contract will check the authorizationContract, with the approvers and action provided in the call,
  • if action is successfully executed, the actionExecuted() function in the authorization contract which will update the state in authorization contract.

Rationale:
This solution avoid any conflicts with the existing requiredApprovals construct already implement in the code base and since each key is not tied to a specific authorization contract, each key can be given many different authorized actions (using different authorization contracts)

from unilogin.

@shine2lay you have been approved to start work on this bounty :)

@alexvandesande please provide feedback on @shine2lay's action plan at your earliest convenience. Thanks!

from unilogin.

@shine2lay Hello from Gitcoin Core - are you still working on this issue? Please submit a WIP PR or comment back within the next 3 days or you will be removed from this ticket and it will be returned to an ‘Open’ status. Please let us know if you have questions!

• warning (3 days)
• escalation to mods (6 days)

Funders only: Snooze warnings for 1 day | 3 days | 5 days | 10 days | 100 days

from unilogin.

@shine2lay Hello from Gitcoin Core - are you still working on this issue? Please submit a WIP PR or comment back within the next 3 days or you will be removed from this ticket and it will be returned to an ‘Open’ status. Please let us know if you have questions!

• warning (3 days)
• escalation to mods (6 days)

Funders only: Snooze warnings for 1 day | 3 days | 5 days | 10 days | 100 days

from unilogin.

I support Shine's action plan and we've talked previously about it. I would like to share a diagram description of the functions he describes:

from unilogin.

@alexvandesande Diagrams look awesome! Great way to share info 👍

from unilogin.

Something that we need to think about, which @mkosowsk raised, is how to handle multiple authorization contracts. If key A needs to call authorization contract A1 and key B calls authorization contract B1, then how does the identity handle when user A and B try to do action C? Does the contract call each authorization contract with both users on it? What if A1 doesn't know anything about user B? What if they are both authorized to do it in A1 but not in B1?

We could only allow one authorization contract per identity, but I feel it would be less flexible. Another option would be to make actionExecuted a function that is only "write only" meaning that the authorization contract is never supposed to "throw" it, only to acknowledge.

The idea here being that auth contracts act as advisors, it's ultimately the identity's job to decide either to do something or not, so each identity contract could decide how to deal with that. In this case, they could simply ask all auth contracts for all users and if a single auth contract authorizes it, then it proceeds with the action, and lets the other know that the action was performed anyway

from unilogin.

@alexvandesande that is an interesting use case, I agree with your point that it is identity's job to decide on the final verdict. actionExecuted should just return true or false instead of throwing.

When I thought about implementing this, I was thinking about adding a new field called authorizationContract to struct Execution and right before execution, we'll call this authorizationContract with all the approvers list and check if the action is authorized.

If key A needs to call authorization contract A1 and key B calls authorization contract B1, then how does the identity handle when user A and B try to do action C?

Maybe I'll need to rethink how to handle the scenario you mentioned

from unilogin.

@shine2lay Hello from Gitcoin Core - are you still working on this issue? Please submit a WIP PR or comment back within the next 3 days or you will be removed from this ticket and it will be returned to an ‘Open’ status. Please let us know if you have questions!

• warning (3 days)
• escalation to mods (6 days)

Funders only: Snooze warnings for 1 day | 3 days | 5 days | 10 days | 100 days

from unilogin.

@shine2lay Hello from Gitcoin Core - are you still working on this issue? Please submit a WIP PR or comment back within the next 3 days or you will be removed from this ticket and it will be returned to an ‘Open’ status. Please let us know if you have questions!

• warning (3 days)
• escalation to mods (6 days)

Funders only: Snooze warnings for 1 day | 3 days | 5 days | 10 days | 100 days

from unilogin.

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

@shine2lay due to inactivity, we have escalated this issue to Gitcoin's moderation team. Let us know if you believe this has been done in error!

• warning (3 days)
• escalation to mods (6 days)

Funders only: Snooze warnings for 1 day | 3 days | 5 days | 10 days | 100 days

from unilogin.

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

@shine2lay due to inactivity, we have escalated this issue to Gitcoin's moderation team. Let us know if you believe this has been done in error!

• warning (3 days)
• escalation to mods (6 days)

Funders only: Snooze warnings for 1 day | 3 days | 5 days | 10 days | 100 days

from unilogin.

Hey @shine2lay, Ryan from Gitcoin here. How is this coming along? I saw your PR, #119, but haven't seen much activity on this thread or the PR in a week or so.

from unilogin.

@ryan-shea I was at DevCon last week, met some folks there and discussed solution for this PR. We are not entirely sure what is the best solution yet.

from unilogin.

@shine2lay Hello from Gitcoin Core - are you still working on this issue? Please submit a WIP PR or comment back within the next 3 days or you will be removed from this ticket and it will be returned to an ‘Open’ status. Please let us know if you have questions!

• warning (3 days)
• escalation to mods (6 days)

Funders only: Snooze warnings for 1 day | 3 days | 5 days | 10 days | 100 days

from unilogin.

@shine2lay Hello from Gitcoin Core - are you still working on this issue? Please submit a WIP PR or comment back within the next 3 days or you will be removed from this ticket and it will be returned to an ‘Open’ status. Please let us know if you have questions!

• warning (3 days)
• escalation to mods (6 days)

Funders only: Snooze warnings for 1 day | 3 days | 5 days | 10 days | 100 days

from unilogin.

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

@shine2lay due to inactivity, we have escalated this issue to Gitcoin's moderation team. Let us know if you believe this has been done in error!

• reminder (3 days)
• escalation to mods (6 days)

Funders only: Snooze warnings for 1 day | 3 days | 5 days | 10 days | 100 days

from unilogin.

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

@shine2lay due to inactivity, we have escalated this issue to Gitcoin's moderation team. Let us know if you believe this has been done in error!

• reminder (3 days)
• escalation to mods (6 days)

Funders only: Snooze warnings for 1 day | 3 days | 5 days | 10 days | 100 days

from unilogin.

Hey @shine2lay any additional updates on this? Snoozing the bot :)

from unilogin.

Hey @shine2lay and @alexvandesande, any news here? Want to check in 😄

from unilogin.

@ryan-shea no updates, can't progress until marek and i have a chat.
@ryan-shea could you remove me from the task? I feel bad that i can't put much time on it now. I don't want to hold up if anyone else wants to take on this task.

from unilogin.

@shine2lay do you have a rough estimate of how long it would take you if you were to stay on?

from unilogin.

@ceresstation unknown. like i mentioned the main reason is that i am blocked. We are attempting to unblock it but communication has been very slow.

from unilogin.

hey @shine2lay any updates here?

from unilogin.