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

Deprecate EIP712 authentication provider #532

Merged

Conversation

piotr-roslaniec
Copy link
Contributor

@piotr-roslaniec piotr-roslaniec commented Jun 21, 2024

Type of PR:

  • Feature

Required reviews:

  • 1

What this does:

  • Marks EIP712AuthProvider as deprecated

Issues fixed/closed:

Notes for reviewers:

Copy link

netlify bot commented Jun 21, 2024

Deploy Preview for taco-nft-demo ready!

Name Link
🔨 Latest commit 9c7fdcd
🔍 Latest deploy log https://app.netlify.com/sites/taco-nft-demo/deploys/66756c6a87ec520008488dcc
😎 Deploy Preview https://deploy-preview-532--taco-nft-demo.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

Copy link

netlify bot commented Jun 21, 2024

Deploy Preview for taco-demo ready!

Name Link
🔨 Latest commit 9c7fdcd
🔍 Latest deploy log https://app.netlify.com/sites/taco-demo/deploys/66756c6abafeaf0008fcd4a3
😎 Deploy Preview https://deploy-preview-532--taco-demo.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

@piotr-roslaniec piotr-roslaniec changed the base branch from main to epic-auth June 21, 2024 12:05
@piotr-roslaniec piotr-roslaniec marked this pull request as ready for review June 24, 2024 12:38
Copy link
Member

@derekpierre derekpierre left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we outright remove EIP712 support instead of deprecating it? If not, what is a good timeline to allow taco-web users to adjust?

Since it was implicit before I think it can just be removed. The associated new context variables can also be removed because they were never publicly released.

I think (?) the concern you are raising is a question for nucypher code instead of taco-web because everything was so implicit in the past - see the notes for reviewers in nucypher/nucypher#3515.

Let me know if I'm missing something.

export const EIP712_AUTH_METHOD = 'EIP712';
export const EIP4361_AUTH_METHOD = 'EIP4361';

export const USER_ADDRESS_PARAM_DEFAULT = ':userAddress';

/**
* @deprecated Use USER_ADDRESS_PARAM_EIP4361 instead.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These context variables were never publicly released - just the epic, right? If so, then a removal can be done instead of deprecation.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They were never exposed to the taco API, but the values they represent were in use, hence they should be deprecated.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure I follow. Who used them in a released version? AFAIK they were only used internally for examples, and only in the epic. Am I mistaken?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, I think you are right. I think that was my mistake. I will fix it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

^ Is the goal to remove these additional context variables in a separate PR then?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, there's a follow-up issue for that: #536

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But these don't need to wait T+2 releases to be removed ... ?

Comment on lines 70 to 73
console.warn(
'DeprecationWarning: The default authentication provider, EIP712AuthProvider, is deprecated. ' +
'Please use EIP4361AuthProvider instead. Refer to the documentation for more details.'
);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since the use EIP712 was implicit until now, is this necessary?

EIP712AuthProvider was not actually used/specified by anyone in prior releases. Can we simply remove it?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMHO it doesn't matter if behavior is implicit or explicit, only whether the changes in the API are breaking, and this is a breaking change

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with the intention of the warning, but should we refrain from still calling it the "default"?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I follow. I believe this file/module and the class was only added as part of the unreleased epic (the epic we are merging this PR into), so why keep the file/module and the class that we no longer intend to use as part of that epic and was never released...

By "implicit" I mean that no user has ever specified or created a EIP712AuthProvider object, because it was never released. So there is no real "breaking" for this class/module since has never been released. The broader API (decrypt) will indeed have "breaking" changes but that is irrespective of this particular auth provider, or the scheme used for validating wallets.

It's possible that a warning could be used somewhere, but I don't think this is the spot, since it seems like this file/module should just be deleted.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We've released an API with a documented behavior (using EIP712 by default) and are now replacing that behavior with another (EIP4361). I don't know specifically how this change can affect our users (is it going to "break" anything) but changing the implicit (or explicit) behavior of an API is a breaking change (according to semver).

Deprecating EIP712 in T+1 major version will allow us to communicate this breaking change to users who are currently using EIP712. Again, I don't know whether it will actually break something, but it makes sense to announce it and only remove it in T+2 after this upcoming change is communicated.

Copy link
Member

@derekpierre derekpierre Jun 28, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. Ok, so the goal of keeping the file is more to keep this (EIP712) as an option (albeit a pending deprecating one), in case some adopter decides they want to use EIP712 instead of EIP4361 for :userAddress for now until we fully deprecate. That's the reason for keeping this module for now.

If we are affording that option, then the server-side will need to be adjusted to accept both EIP712 and EIP4361 for :userAddress and nucypher/nucypher#3515 will need to be adjusted.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So the server side verification will be broken for EIP712 in the next release? Not deprecated, but outright removed?

In that case, these changes have no sense and we should remove EIP712 from the client too. I will address it in this PR.

Copy link
Member

@derekpierre derekpierre Jun 28, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So the server side verification will be broken for EIP712 in the next release? Not deprecated, but outright removed?

That's still a discussion for #3515, and not currently set in stone. We still need to make an official decision there.

@piotr-roslaniec
Copy link
Contributor Author

Accidentally closed during a rebase

@piotr-roslaniec piotr-roslaniec merged commit e9ce886 into nucypher:epic-auth Jul 2, 2024
8 checks passed
@piotr-roslaniec piotr-roslaniec deleted the deprecate-eip712 branch July 2, 2024 10:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants