7.10 IDP Attestations for E2EE Meetings

If a user’s account is configured to support IDP attestations (Section 5), they can use an attestation in E2EE meetings to prove to other meeting participants that they are part of a specific organization (identified by its ADN) in which they hold a specific email address (as vouched for by the organization’s designated IDP, and which they logged into Zoom with). Attestations by a trusted IDP reduce the need to explicitly check security codes. Upon joining a meeting, each device obtains an IDP attestation, which authenticates the signing key IVK used to join the meeting as described in Section 5.3. Currently, the zoom-identity-snapshot field of the attestation includes the IVK; once we start leveraging sigchains in meetings (see Section 7.11 for details), we plan to extend the snapshot with the tails of the given user’s sigchains. The user signs the IDP attestation and their ADN with their IVK, and temporarily stores the attestation and signature on the Zoom servers. To share this information only with the intended meeting participants, the user posts to the meeting bulletin board an “identity sharing token” (along with the signed Bindingi described in Section 7.6.2 “Participant Key Generation”), which other participants can present to the server in exchange for the attestation. Identity sharing tokens are computed as an HMAC of some metadata about the attestation (such as whether it contains the user’s email address), using a random 32- byte symmetric key generated by the Zoom servers for each user’s device in each meeting. Identity sharing tokens have a lifetime of 24 hours, and can be used to fetch any matching attestation for that user’s device. An IDP attestation can be used across multiple meetings but has a relatively short lifetime, which is set by the IDP, defaulting to 48 hours. When displaying another participant’s identity in the user interface during a meeting, clients that successfully fetch an identity attestation will verify the signature of ADN and attestation by ISK, verify that this ADN (in addition to the email address in the attestation) matches what is provided by the Zoom server, and verify the attestation as detailed in Section 5.4; in particular, the IVK in the Binding must be consistent with the contents of attestation’s zoom-identity-snapshot field. If the checks are successful, the interface displays to the user the email address from the attestation and details about the authenticating ADN and IDP. The verifying user should review the displayed email address and ADN and confirm that they are the expected identifiers for the user they are meeting with. Meeting participants’ clients may perform these checks asynchronously during a meeting, but in the future we may offer the option to configure a meeting such that the host must complete this verification before admitting a joining participant. Requiring this verification before key exchange can help increase the security of meetings that are, for example, restricted to users in specified accounts.