CSE Guest Access Support for Google Meet and Google Drive

Client-side encryption in Google Workspace enables encryption operations within the client, storing only encrypted files and encrypted keys in the cloud. AES symmetric keys are used to encrypt the user content. Google Workspace Client-side encryption (CSE) allows the user to secure Gmail messages, Meet Calls, Calendar event data, and Google Drive (Docs, Sheets, and Slides data) with an external encryption key that Google servers cannot access.

File contents are encrypted on the browser before being sent to Google servers for storage. With Google Workspace CSE, key ACL service (KACLS) controls the top-level encryption keys that protect users' Drive, Docs, Sheets, and Slides data.

Google Meet CSE provides a way to have end-to-end encrypted meetings by allowing enterprise workspace customers to use their own Identity Provider (IdP) and KACLS. Using their own IdP and KACLS infrastructure, users from a customer domain can participate in end-to-end encrypted meetings. Unfortunately, external accounts that do not belong to the customer domain, and cannot be authenticated using the internal IdP used by the customer, don't have a way to join CSE meetings which limits the usefulness of the CSE feature in its current form.

This problem will be addressed by allowing guest accounts that are authenticated using additional IdPs like Microsoft Azure ID, Google's Identity platforms or an alternative guest IdP provided by the host domain. The solution for Guest Access uses two ID tokens. This allows for the simultaneous operation of a primary IdP service while using a separate service to authenticate external guests.

Eligibility for Guest Accounts

In this feature, you will add support for external guests (outside the host's domain) to join Google Meet CSE calls. In this context, guest accounts are external participants that do not have:

• Any Google Account, any account registered with Google's identity service, regardless of actual domain or account license type (free or paid).

• A Google consumer account.

• A Google account that doesn't belong to the organizer's domain.

These accounts will instead rely on external IdP to access Google Meet to join calls such as "Sign in with Microsoft" and "Sign in with Google".

CSE Guest Access Workflow

A New CSE Join Flow for CSE Guest Accounts

This feature introduces a new join flow for anonymous CSE guest accounts. It allows an initially anonymous user to authenticate with a guest IdP and thereby establish an identity that Google can use to get access to the KACLS server (to encrypt/decrypt media) and authorize access to the meeting. Authenticated and unauthenticated Google users not logged in to the host domain's IdP are treated equally.

Allowed IdP Configurations are Provided when Loading the Meet page

Currently, an anonymous or non-invited user is directly rejected when loading a CSE meeting. This will now change to allow the user to authenticate with the guest IdP.

Upon loading the green room a guest account is presented with the IdP selection screen. In it, the user is challenged to authenticate using a guest IdP as configured by the meeting host organization.

The host organization name is displayed to the guest, and the guest is warned that they will be redirected to a third-party login page where they need to authenticate with the same email address as they were invited.

New Field Introduced in the Authorization Token

The Authorization token (AuthZ) generated by Google Drive (docs/slides/sheets) and meet is extended with a new claim "email_type". The possible values for the claim are:

• google: This email belongs to a Google account.

• google-visitor: This email does not belong to a Google account, but was PIN-code verified by Google. It is associated with guest access for Google Drive.

• customer-idp: This email does not belong to a Google Account, but the user's email was extracted using a customer-configured IdP. It is associated with guest access for Google Meet.

This claim may be unset. In this case, the default value is google.

Token Matching Logic

The email_type claim is guaranteed to be present when Google issues an AuthZ token for an email that does not correspond to a Google Account. This is introduced as a part of the "Guest Access" feature.

If a customer does not have Guest Access configured, all requests where email_type is set to google-visitor or customer-idp will be rejected. Requests with an email type of google or with an unset email type should continue to be accepted.