Deprecate :userAddressExternalEIP4361

[derekpierre]

Background

When authentication via context variables was first introduced in taco-web, it was designed as an implicit and automated process. The workflow was as follows:

• A user would initiate a decryption request to the library.
• taco-web would parse the condition to check for reserved context variables (e.g., :userAddress).
• If any reserved context variables were found, the user would be prompted for an authentication signature—typically triggering a MetaMask window for signing and confirmation.

This worked fine and led to expansion of the :userAddress to :userAddressEIP712 and :userAddressEIP4361. Although this was the beginning of a mistaken path. Because the prompting was implicit, these separate context variables indicated the type of signature to use, as opposed to the application controlling it themselves; the condition dictated it.

Later, the need arose to implement EIP-4361 single sign-on (SSO). Initially, we attempted to introduce a separate context variable, :userAddressExternalEIP4361, to bypass the authentication prompt. However, this approach posed a fundamental problem - the implicit authentication logic in taco-web had no way of determining where the SSO data resided within the application.

To address this, we introduced AuthProviders (PR #531), encapsulating authentication and signing logic within dedicated objects. This shift made the process explicit, allowing applications to define their own authentication providers to generate the required signatures. Applications could choose to support SSO if desired, or fall back to prompting the user for authentication—without taco-web having to make that decision or rely on additional flags. This was a significant improvement in flexibility and maintainability.

The Mistake: Introducing :userAddressExternalEIP4361

When implementing SSO, we made an oversight in PR #529. We introduced :userAddressExternalEIP4361 to indicate when only SSO should be used. However, this had unintended consequences: any condition using this variable was restricted to SSO exclusively, precluding regular EIP-4361 authentication.

What we actually needed was for :userAddress to support both standard EIP-4361 and SSO-based EIP-4361 authentication seamlessly. Instead, introducing :userAddressExternalEIP4361 needlessly added an extra context variable, when :userAddress alone could have handled both cases. This approach unnecessarily restricted any condition using :userAddressExternalEIP4361 to only support SSO, making it overly rigid and limiting.

Why Deprecation is Necessary

The need to deprecate :userAddressExternalEIP4361 has become even clearer with the introduction of EIP-1271 support. Notably, adding EIP-1271 did not require the creation of a new context variable, but rather expanded the support of EIP1271 for use with :userAddress. If we had introduced a separate variable for EIP-1271, it would have resulted in nonsensical constraints—forcing conditions to work only with smart contract accounts, which was never the intent.

Since :userAddressExternalEIP4361 is redundant and limits flexibility, we should officially deprecate it. It's unclear whether any adopters are using it in production, but we can check. Regardless, its use should be discouraged, and it should ultimately be removed from the library.

The deprecation would be needed on both taco-web and nucypher/nucypher.

[derekpierre]

(kudos to @manumonti and @theref for discussions that brought this issue to light)