Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Flip for identity on auth account #945

Closed
wants to merge 8 commits into from
56 changes: 56 additions & 0 deletions flips/20220518-authaccount-identity.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,56 @@
# Title of FLIP

| Status | (Proposed / Rejected / Accepted / Implemented) |
:-------------- |:---------------------------------------------------- |
| **FLIP #** | [NNN](https://github.com/onflow/flow/pull/NNN) (update when you have PR #) |
| **Author(s)** | Bjate Stien Karlsen (bjarte@find.xyz) |
| **Sponsor** | AN Expert (core-contributor@example.org) |
| **Updated** | 2022-05-18 |

## Objective

One of the most asked questions regarding access control in Cadence is: "How do I know what user called this method?". In Solidity the answer is `msg.sender`.
However, [this pattern has several problems](https://docs.onflow.org/cadence/msg-sender/) and it is not recommended.

One of the reasons it is not recommended is that there is no secure way of doing that. This FLIP aims to create a way to do it securely.

*Note: This FLIP does not cover __when__ you should use this instead of other patterns for identifying the sender, it only provides a way to do it safely _if_ you need to do it.

## Motivation

Add a secure to identify if a particular auth account signed a transaction.

## User Benefit

It makes it possible to use patterns that are common to Solidity developers in Flow.

## Design Proposal

The design proposal and a implementation is provided in the following PR
https://github.com/onflow/cadence/pull/1363/files

### Drawbacks

Currently the documentation states that this pattern is not a best practice. Should this documentation be changed?


### Best Practices

It makes it possible to do something that it is documented is not best practice. Should this documentation be changed?

### Tutorials and Examples

See PR for examples and changed docs

### User Impact

A user will be able to call `authAccount.identity` and get a token representing the ability to access to an account, without it being obtainable any other way, i.e. it cannot be forged, as there is no constructor function for the `AuthAccount.Identity` type.


## Related Issues

https://github.com/onflow/cadence/pull/1363/files

## Prior Art

Solidity provides the `msg.sender` field which allows identifying who signed the currently running transaction.