Using ESR Identity Request for Additional Authentication

Hi!
We use Anchor desktop/mobile and ESR with the Hypha dapp (and others). We have a current process that enables the user to authenticate to additional resources (e.g. off-chain profile data store) after signing/submitting an action. The backend checks the chain and triangulates the session to grant access. The Anchor identity request that occurs does not submit an action.

Can we also use this identity request to authenticate the user to the additional resource? Is this part of UAL or ESR? Is it secure, meaning the client can fully trust that the identity request was signed via the user’s private key, or is it a non-cryptographic acknowledgement that “this is the account I want to use” (which would not be secure)?

thank you!
Max

It is cryptographically secured, the response to an identity request returns a signature which can be used to validate that a specific private key signed the request and proves ownership over the account. These identity requests are a specific type of ESR payload, which more information on can be found here.

We do expose these values through UAL upon initial login, but they are not persisted. An example using the ual-reactjs-renderer can be found here on what these values are named and how to verify them.

Currently with how UAL works, this isn’t the most friendly of processes. We have plans to eventually replace UAL with a more robust solution that allows better access to this data - but that code is still in the works and is still unreleased.

Excellent, thank you! We will look at this.

In addition to the authentication step of the profile service, we are reviewing a few options for encrypting private profile data (or user-specific dapp-settings/preferences), primarily to be stored off-chain. One potential compelling option may be to pass the data to the signer, have the signer encrypt it with the accounts key, and then the signer would pass the encrypted payload back to the application to be persisted.

One challenge of this is, of course, that the account may change their key unbeknownst to the encrypted data, losing it as a result. Regardless of this challenge, do you think that handling encrypted data would fall into the scope of ESR?

We are still researching, and sometimes look to 3box (https://3box.io/products/profiles) as a model. Would love to know if you have any thoughts on approaching this type of functionality in EOSIO/ESR ecosystem.

thanks!
Max

We currently don’t have any plans to go that route - but it doesn’t mean we wouldn’t in the future. It’s primarily a matter of our plates just being so full as it is.

I would probably avoid using the keys associated to the permissions of an account for the reasons you outlined though. If an account is compromised or for some other reason the keys have to be changed, it’d be unfortunate for them to lose access to that data.

I’m not sure I have a great solution - but the first thing that came to my mind (if you wanted to use shared secrets + keys) was using a table entry (as opposed to a permission) to keep a public key for the user, and then use the private key associated to it either from the browser itself or based on something they input. This would at least keep it out of the account layer and not pose any risk to whatever permissions those keys are associated with. It’s not a good solution though, as that could be easily lost as well unless backed up properly.

I know one of our low priority projects has some needs like this and we’ll be facing a similar challenge sometime in the future, so eventually we may try to come up with something to solve this challenge. We just don’t have that solution ready yet.

If you felt like this was inline with the spirit and strategy of ESR and Anchor, we have dev resources to build it. Would you be supportive of a PR for something like this to Anchor?

The proposal is like this one, adding a few methods to the API: https://eips.ethereum.org/EIPS/eip-2844

It would enable use cases described here: https://blog.ceramic.network/how-to-store-signed-and-encrypted-data-on-ipfs/