As our service is expanding into CRM functionalities, we now require not only the “gmail.send” permission but also the “gmail.read” permission to fetch our customers’ email content. To handle this, I was considering creating a new GCP project, completing the verification and security assessment (CASA), and then modifying our existing production GCP project and Nylas connector settings once the approval process is complete. The process I have in mind is roughly as follows:
[TL;DR] Create a temporary new GCP/Nylas App to go through the entire process. Once approved, update the scope in the existing production GCP project and then also update the scope in the Nylas app.
a) [Test Phase] Create a new GCP project and a new Nylas app. Based on this new setup with the expanded scope, produce and submit a demo video to start the verification process.
b) [Test Phase] Once the app is verified by Google and they request a CASA Letter of Validation (LoV), work with Tac Security to implement security feedback, complete the Statement of Assessment (SOA), and obtain the validation letter.
c) [Production Phase] Expand the scope of our existing production GCP project (which currently only uses the send scope) to include the read scope. Then, for this production project, produce and submit a demo video again and complete the verification process and security assessment.
d) [Production Phase] After receiving successful verification from Google, expand the scope in the connector of the existing production Nylas app.
I have a few questions regarding this process:
In step (c), I understand that even if we already passed most of the verification in the test phase, modifying the scope of our production GCP project will revert its status to “unverified.” While the process should be shorter since we will have prepared all materials, I’m concerned that until the scope expansion is finalized in production, there could be issues with existing customers’ authentication or email sending. Could you clarify if this would be a problem?
Once step (d) is complete, I understand that new users will be onboarded with the expanded scope. However, for existing users who only granted the send scope, do we need to request re-authentication only from the users who wish to use the new features, or must all existing users go through re-authentication?
Although we can reuse results and materials, the entire process from (a) to (d) requires going through verification and security assessment twice. I wonder if this is the most efficient method. Is there a better approach or best practice you would recommend?
Your understanding is largely directionally accurate, but our recommended best practice is to utilize a single, existing GCP project in production rather than creating a duplicate prod project. (It is, however, prudent to build in a staging/dev app along the way!)
You are correct that requesting a new scope in your existing project will temporarily render the project in ‘unverified’ status, however your existing users that have already authenticated with pre-approved scopes (and are not calling for the new restricted gmail.read scope) will not be prompted to re-auth until their tokens expire, and will not experience limitations in existing send functionality. Only net-new authentications would receive the ‘app not verified’ warning during this limited window.
Once your new scope is approved, any existing users desiring that functionality would need to re-authenticate to grant your application access to read their email data. Those only desiring send capabilities would be able to retain their existing auth tokens.
I recommend checking out our Google Verification playbook, with special attention to section 7 starting on slide 48!
Hi Chris,
First, thank you for your kind and prompt responses.
Based on your explanation and the materials you provided, I’ve summarized the process again. Could you please check if my understanding is correct?
Configure a separate development GCP project and a development Nylas app to develop the features based on the gmail.read scope.
This setup will be operated solely for development, testing, and creating the demo video, not for the official verification. The final verification will be processed through our existing production GCP project and production Nylas App.
Start the re-verification process by expanding the scope on our existing GCP project (which currently only has gmail.send).
We understand that existing users will not be affected, but new users might see an ‘app not verified’ warning.
During the verification process, we will implement a method to ensure that the gmail.read scope is provided only to whitelisted users. This means we will not directly modify the scope in our production Nylas app’s connector; instead, the request will include the expanded scope only for this limited set of users.
Obtain the CASA certification (Security Assessment) through Tac Security, receive the Letter of Validation, and submit it to Google.
We will proceed with the CASA process, which includes conducting a preliminary security assessment (e.g., with ZAP) before the official request and completing the Statement of Assessment (SOA) with its 50+ questions.
Finally, once the verification process from Google is complete, we will expand the scope in our production Nylas app’s connector and then request re-authentication from existing users who wish to use the new features.
