Appendix V: Migration From Previous Passports

If you're using previous versions of Passport, you'll find that we've implemented significant changes in the latest release, introducing major enhancements over previous iterations. If you've already perused the documentation introduction, you've likely noticed a vast array of new features and functionalities aimed at making us the most effective Universal ID solution on the market.

The good news is that we've prioritized maximum flexibility and customizability of our authentication and authorization platform. However, as we've transitioned technologies to enable this customization, there are notable changes in how we instantiate our Passport object. Furthermore, driven by developer feedback, performance optimizations, and the ongoing evolution of underlying blockchain libraries, there have been significant modifications reflected in the documentation.

For those already deployed on previous versions, fret not. We've compiled a set of best practices to facilitate a quick and seamless migration from the previous version of Passport to v8. This Appendix will outline the most crucial points to consider as you update your code to leverage the new feature set.

Add client ID - The Passport initialization schema of undergone some pretty significant changes since Credenza has implemented its own provider. While most of the configuration variables are optional, the one new required is based on activating the Credenza OAuth system--and that authorization requires a client ID. The client ID, which is issued by Credenza, will also have a set of whitelisted you are elsewhere where the Passport authentication system will work.

const passport = new window.CredenzaPassport({ chainId: CHAIN_ID, clientId: CREDENZA_ISSUED_CLIENT_ID})',

Blockchain Addresses - Because we were exclusively EVM before, we referred to all addresses as address. Credenza's new authentication system and provider model allows us to have multiple addresses across blockchains associated with each account. Therefore, to distinguish blockchain addresses, we have prepended the blockchain ID before the word address. evm_address

Passport v1-7	Passport v8
const userID = passport.user.address	const userID = passport.user.evm_address

Using "on" As The Main Construct - Previously, we supported adding the name of the event, attended to the word on for each of our events. Starting with Passport v8, we have shifted the on so that the event being capture is parameterized. As an example, this is how capturing a login has changed in Passport v8:

Passport v1-7	Passport v8
passport.onLogin(async (data) => { ...call post-login code... })	passport.on('LOGIN', async (data) => { ...call post-login code... })

Setting The RPC Node Link - With our EVM systems, older versions of Passport applications that use use Ethers v5 will need to change the way they generate an RPC provider. Most instances of v6 and v7 made this change already as we tried to migrate most customers to Ethers v6, but it's worth calling out.

Passport v1-5	Passport v6-8
const scriptProvider = new ethers.providers.JsonRpcProvider(RPC_URL)	const scriptProvider = new ethers.JsonRpcProvider(RPC_URL)