so then

if you wrote a relationship from

widget

to

email

BUT idk about google groups or service accounts

and then from

email

to

user

when you issued a

Check

on the widget for the user

or workspace or non gmail domains on google

it would resolve through the email

exactly

that's my only concern... and one I'm not 100% certain to answer

but IF you could confirm they are never reused (with 100% certainty)

then the above design works

and then you just make sure whenever a user logs in, that a relationship exists between their email and their user account

and you're golden

yeah, it doesn't give me warm fuzzy feelings security wise

yeah, I have the same hesitation as well

if email is an unstable identifier, then it cannot be used as a stable Object Id

not a huge deal for internal/workspace stuff because it looks like you can get a user's ID from their email with a workspace API (even without them OAuth granting permission)

yup; I imagine Google doesn't allow the API for public use to prevent people building "is this email valid" databases

that was what I guessed as well

FYI @User if you structure your schema correctly, you could actually store the GAIA email mappings as relationships and walk them directly

but if the email does change, you'd have to rewrite some of them

so using an internal ID is the "safest"

yeah, just need the user that is logging into the app to give email scope + actually login

so you can only share objects to users that have logged in instead of just "any" google identity

one option is to have non-actually logged in become an invite to the email

with a token

and then when they login, they are granted the permission

good idea, but doesn't work for service accounts or google groups

unless you can convert google accounts -> google group.

Google Group can receive the email; I have no idea about service accounts offhand