Flip for identity on auth account

[bjartek]

trafficstars

[vercel[bot]]

@bjartek is attempting to deploy a commit to the Flow Team on Vercel.

A member of the Team first needs to authorize it.

[bluesign]

One of the most asked questions in the discord server is "how do i know what user called this method".

Instead of putting &Identity to function signatures, why we don't give access to information with some Environment Information function like getTransaction and have a field like authorizers ?

[bluesign]

We should emphasize that this feature should not be used for typical access control use-cases, and capability-based access control should be preferred.

To be totally honest, when you have this, using capability based access seems little stupid. This is too powerful. As I said before when we put resources owner, game was already over.

There is no need to still try to push capability based control. It is a lost cause.

For example: Capabilities:

• When I give you private capability, I should use capability receiver pattern ( otherwise you can copy the capability )
• There is no way to revoke the capability

With this system:

• I can be almost sure, you are the person running the transaction.
• I just need to hold an {Address:Int} dictionary, I can have multiple access levels.
• Revoking is super easy
• Pull Airdrop ( dictionary : Address -> NFTID }

We are becoming more and more ethereum. ( nothing bad though )

[bjartek]

I have commited all of the suggestions will see if I can find time next week to do a more in-debt pass over this.

@bluesign I still think there are rooms for both options TBH. This is kind of like a last resort.

[bluesign]

@bjartek i think this is really good btw. I meant there shouldn’t be push for capability when it is not needed. A lot of contract code can be simplified with this. ( with security in place )

Though I also think scoping this can be little tricky. It should be valid on the first call scope only. ( contract function shouldn’t be able to pass this to another function of another contract )

[turbolent]

After further discussion it is the consensus that this proposal should be rejected.

The language feature was proposed mostly as a solution to the bootstrapping problem of sharing a capability. The feature would indeed solve this problem, but would likely also be used to implement identity based access control.

Instead, the plan is to create a new FLIP for a solution to the capability bootstrapping problem. This ties in nicely with the ongoing effort to improve the capability API in FLIP #798.

Thank you everyone for your feedback, a productive discussion, and especially @bjartek for the prototype implementation.