5.2 IDP Attestations

IDP attestations are generated and verified according to the OpenID Connect (OIDC) protocol. OIDC is an extension of the widely used OAuth 2.0 authentication protocol, an industry standard that many IDPs and Single Sign-On providers already support. OIDC provides a standardized format, the ID token, to express claims about identities and their attributes. It also specifies how users can request attestations for their own identity and verify ones obtained from other users. We customize the protocol by:

  1. Introducing an additional attribute "zoom-identity-snapshot" to the ID token in order to encode the state of a user’s identity on Zoom. The IDP keeps track of the latest value of this attribute for every account user.

  2. Specifying how this attribute can only be updated by the authorized user, and not by any other user or entity, including Zoom servers.

  3. Specifying how this customized ID token for a specific user identity can be validated by other users. Our modified OIDC ID token (which we will also refer to as an IDP attestation) is a signed JSON Web Token (JWT) data structure which contains claims about a user’s Zoom identity. The payload might look like the following: { "iss": "https://examplecorp.generic-idp.com", // issuer "email": "alice@example.com", "zoom-identity-snapshot": "409788...", "exp": 1311281970 // expiration time "iat": 1311280970, // issue time [...] } The token contains an issuer field which identifies the OIDC issuer of the token (the IDP). In order for Zoom clients to accept an identity claim, the issuer field must match the IDP domain associated with the account. iat and exp specify the validity of the token. The zoom-identity-snapshot field encodes the state of a user’s identity, such as the user’s sigchain-backed identity; it is treated by the IDP as an opaque string, and the IDP does not need to check its validity (the identity snapshot is further described in Section 5.5). The fetched attestation may be shared with and validated by anyone, so it doesn’t include the aud field. Unlike standard OIDC ID tokens, which are “bearer tokens” in that they can be presented by a user to prove their identity to the party indicated in the token’s aud field, our attestations are meant to be exchanged with potentially many other clients to prove a binding of a particular client’s identity to their keys. Because compliant OIDC implementations enforce that the aud field contains their own identifier, they will not accept our attestations (which lack this field) as a standard ID token for authentication purposes. The email value must match the email address that the user logged into Zoom with (and that the server gives to the verifying client) in order for validation to succeed. Currently, the email field is required; in the future, we might make this field optional to allow for proving that a user is a member of a specific account without revealing their full identity.

Last updated