Google Verification & CASA Tier 2
The Complete 60 Playbook

Everything needed to take 60 (use60.com) through Google OAuth brand verification, restricted-scope review, and the CASA Tier 2 security assessment — and to repeat it for any future application. Prepared 11 June 2026.

Contents

1. The 60-second glossary
2. Timeline & what to expect
3. What 60 has already done (our evidence pack)
4. Phase 0 — Pre-flight checklist
5. Phase 1 — Configuring the Cloud Console
6. The scope list & written justifications (copy-paste ready)
7. Phase 2 — The demo video (full shooting script)
8. Phase 3 — Submitting & surviving the review
9. Phase 4 — The CASA Tier 2 security assessment
10. Phase 5 — After verification
11. The rejection playbook
12. Reference links

1. The 60-second glossary

2. Timeline & what to expect

Google's official guidance says "up to 6 weeks" for restricted scopes. Real-world reports (app already secure, evidence ready) run as fast as 8 working days end-to-end. Our remediation work (section 3) is what buys the fast path.

3. What 60 has already done — our evidence pack

This is why we expect to pass with flying colours. Everything below is merged and live in production (PR #1660 → promotion PR #1676, deployed 11 June 2026). Each row doubles as SAQ evidence in Phase 4.

4. Phase 0 — Pre-flight checklist

Do not click "Submit for Verification" until every box is ticked. Google reviewers check these mechanically and a miss restarts the cycle.

• Privacy policy live on the app domain with Limited Use disclosure → https://app.use60.com/privacy ✓ deployed 11 June
• Terms of service live → https://app.use60.com/terms ✓
• HTTPS + security headers on production ✓
• Homepage requirements — the homepage you list in the console must: (a) be publicly accessible without login, (b) describe what the app does (not just a login page), (c) link to the exact same privacy policy URL you put on the consent screen, (d) sit on the verified domain. Action The marketing site (separate repo) needs a footer link to app.use60.com/privacy, and ideally this sentence on the page: "60's use of information received from Google APIs will adhere to Google's Limited Use Requirements."
• Domain verified in Google Search Console for use60.com, with the Cloud Console project owner having access. (Check: Search Console → Settings → Users.)
• App published to Production in the console (Audience page: "Publish App", not Testing). Apps in testing mode cannot be verified.
• Scope list final (section 6) — and the production codebase requests exactly those scopes, nothing more. Reviewers diff the consent screen against your submission.
• Support email valid and monitored — all verification correspondence goes there. Missing an email stalls everything.
• Logo ready — 120×120px, square, professional. Note: changing the logo later forces brand re-verification.
• ZAP baseline run early — run the CASA-config ZAP scan against production now (commands in Phase 4) so any finding is fixed before TAC ever sees it.
• Confirm the legal contact email shown on /privacy ([email protected]) is correct and monitored.

5. Phase 1 — Configuring the Cloud Console

All of this lives in Google Cloud Console → APIs & Services → OAuth consent screen (rebranded "Google Auth Platform" in newer consoles). Use the production project — the one whose client ID the live app uses. Never request unverified scopes from this project while the review runs.

5.1 Branding page

5.2 Audience page

User type External, publishing status In production. This is also where the 100-user cap is displayed while unverified.

5.3 Data Access page (scopes)

Click Add or remove scopes and declare the exact list in section 6. The console will bucket them into non-sensitive / sensitive / restricted automatically — that bucketing drives the requirements. Paste a per-scope justification (section 6 gives you copy) into the justification fields when prompted at submission.

6. The scope list & written justifications

The principle is narrowest scopes: every scope needs (a) an implemented user-facing feature, (b) a justification, (c) an explanation of why a narrower scope won't work. Here is 60's full declaration with submission-ready copy:

Restricted (these trigger CASA)

Sensitive (verification, no CASA)

7. Phase 2 — The demo video

7.1 The rules (Google's hard requirements)

• One video showing the end-to-end flow including the OAuth grant, on the production app with final branding (name "60" visible).
• The complete consent screen must appear, listing exactly the scopes being submitted, with the consent screen language toggled to English (bottom-left of the consent page).
• The browser address bar must be visible while on the consent screen so the reviewer can read the OAuth client ID in the URL.
• Every sensitive and restricted scope must be demonstrated by the feature that uses it. Miss one and you'll get the "video does not sufficiently demonstrate functionality" rejection.
• Upload to YouTube as Unlisted; paste the link in the submission's YouTube field.
• Not required but strongly advised: narration, 1080p screen recording, 3–7 minutes. Silent 30-second clips get bounced.

7.2 How many videos?

One video — 60 has a single web OAuth client. (If we ever submit multiple client IDs — e.g. a Chrome extension — the video must show the grant + data access on each client.) Keep a copy of the recording; the annual re-verification reuses or refreshes it.

7.3 The shooting script (for Rishi)

Setup: clean Chrome profile · test Google account with realistic data (a few meetings, some email threads with a "prospect") · production app.use60.com · screen recorder with mic (Loom/OBS/QuickTime) at 1080p · consent screen language set to English · do a dry run first.

8. Phase 3 — Submitting & surviving the review

1. On the consent screen page click Prepare for Verification. Confirm branding, scopes, domains.
2. Paste the scope justifications (section 6) and the YouTube link. Select the permitted application-type from the "What features will you use?" list (60 = CRM / productivity workflow).
3. Click Submit for Verification.
4. Brand verification resolves first (~2–3 business days). Watch the developer-contact and support inboxes.
5. The OAuth review team emails with questions or requests. Rules of engagement: reply to the same thread, within 24h if possible; if they recommend downscoping, answer "Confirm Downscoping" or "Unable to use narrower scopes" + reasons; if they fault the video, fix and reply with the new link. A paused review (waiting on you) shows on the consent screen page.
6. When the restricted-scope review is satisfied, Trust & Safety triggers the security assessment — the CASA notification email. That's Phase 4's starting gun.

9. Phase 4 — The CASA Tier 2 security assessment

9.1 The shape of it

Tier 2 = you scan your own app + answer the SAQ; the lab validates and issues the LOV. The lab never touches our code or infrastructure. To pass: the scan must show no findings mapped to CWEs with high likelihood of exploit (mediums also count on revalidation years — fix them anyway).

9.2 Run the ZAP scan (do this before TAC asks)

# 1. Get the CASA ZAP config from the ADA AST guide
#    https://appdefensealliance.dev/casa/tier-2/ast-guide/dynamic-scan
# 2. Run the full scan via Docker against production:
docker run -v $(pwd):/zap/wrk/:rw -t zaproxy/zap-stable \
  zap-full-scan.py -t https://app.use60.com \
  -c zap-casa-config.conf -r zap-report.html

# Keep BOTH: the config file used and the plain-text results —
# they're uploaded as evidence ("AST configuration file(s)" +
# "AST scan result(s) in .txt format").

Note: ADA's pre-configured static scanner (FluidAttacks) doesn't support TypeScript/JavaScript — for 60 the DAST ZAP scan is the primary artifact; a custom CWE-compatible SAST (e.g. Semgrep with CWE output) is the fallback if asked.

9.3 Engage TAC Security

1. Buy the ESOF AppSec ADA CASA Basic plan — $540/app/year (includes 2 revalidation cycles + remediation support). Premium ($720–855) only adds hand-holding we won't need. Portal: casa.tacsecurity.com.
2. Provide the prerequisites: app URL, login credentials for a test account, a simple data-flow diagram (user → 60 frontend → Supabase edge functions → Google APIs; tokens encrypted in Postgres), and the list of Google scopes used.
3. For a web app, choose the DAST scan path (URL + test credentials), or upload our own ZAP results.

9.4 The SAQ — our answers are pre-built

~54 requirements across the ASVS categories. Map straight to section 3 of this doc plus docs/security/:

9.5 Finish

TAC validates → may request 1–2 evidence items → issues the LOV and submits it to Google directly. Google sends the approval email within ~5–6 business days. Done — restricted scopes unlocked, user cap removed.

10. Phase 5 — After verification

• Consent screen goes clean: no more "unverified app" warning; the 100-user cap is gone.
• Annual re-verification is mandatory for restricted scopes — CASA revalidation every 12 months from the LOV date. Action calendar a reminder at month 10 (TAC Basic includes the revalidation cycles). Remember mediums fail on revalidation scans.
• Changing branding (name, logo, homepage, privacy URL, domains) → brand re-verification before the change shows to users.
• Adding a new restricted scope → re-verification and possibly a fresh security assessment. Plan scope additions around the annual cycle.
• Never remove approved scopes from the console without review-team instruction (token revocation risk).
• Codebase discipline: production must only ever request approved scopes — requesting an unapproved one re-triggers warnings/cap. Test new scopes in a separate GCP project (we have staging ref caerqjzvuerejfrdtygb + a dev project for this).
• Limited Use is a living obligation: Gmail data → user-facing features only, no ads, no human reads (except support-with-consent/security/aggregated), no generalized AI training. Any new feature touching Gmail data gets checked against this before shipping.

11. The rejection playbook

12. Reference links

• Verification requirements (the canonical list)
• Restricted scope verification guide
• Demo video requirements + rejection reasons
• Submitting your app for verification
• CASA Tier 2 process · Scan your app · Approved tools
• TAC Security CASA plans · portal: casa.tacsecurity.com
• Google API Services User Data Policy (Limited Use)
• Internal: docs/security/ · privacy page source src/pages/legal/PrivacyPolicy.tsx · remediation PRs #1660, #1676

Prepared by Claude Code for the 60 team, 11 June 2026. Reusable for future apps via the google-verification skill in .claude/skills/.