Email-based authentication/identity

[gfodor]

Proposal for conference use case, etc:

• API to allow administrator to assign "forced names" to specific accounts, by email address. Accounts may not exist yet
• API to allow administrator to grant global access to rooms based upon email address (deny otherwise.) Accounts may not exist yet.

┆Issue is synchronized with this Jira Task

[blairmacintyre]

The only thing I'd add (again, from a practical viewpoint) is we might want a 3rd API to somehow specific accounts that are admins, and can, therefore, choose their names. At least for events I attend, everyone "registers", so everyone would be in the list of forced names. If the system is automated, removing those users from that list would be difficult.

This matters because admins might want to log in multiple times and have multiple accounts with different names.

Of course, perhaps just removing them from the "forced name list" on the automation side would be more appropriate.

Is there any notion of admins that we'd want to leverage? Eg.g., giving different accounts different privileges on the instance?

[gfodor]

Yeah I think the idea would be you'd have a fixed, authorized name iff it is on the registered list. So what you'd want to do is just explicitly remove those who will retain flexibility in their name.

Right now we have two levels of role based access control:

• Admin or non-admin: this grants access to administrative functions like app configuration, server configuration, and content curation tools. Also gates use of Spoke if Spoke is disabled for non-admins. Currently this bit does not confer any privileges related to room state.
• Room level role based access control. There are a few levels here:
  • Room owner. Single person, who created the room, must be logged in. They have full permission for everything, as well as the ability to control the security configuration of the room and promote others.
  • Promoted users. Multiple people, promoted by room owner, must be logged in. They have full permissions except for the ability to promote other users and set room permissions.
  • Logged in users. Have access to the permissions granted by the room owner.
  • Logged out users. Have access to permission granted by the room owner, except those which require log in like pinning.

For the admin/non-admin role based access control, it seems sane to think about ways to carve out more system-level roles. The one that came up previously is one that grants access to the content management tools but not server/app configuration.

[blairmacintyre]

ok, that sounds good for now. More roles would be good.

The obvious ones are to have server Admin's get all the permissions of Room owner's. I'm imagining that I get people to create rooms; I'd like myself and other admins to be able to change/manage/fix updating things, and promote others.

[gfodor]

Yep that makes sense. One reason we didn't do that, is we didn't want (for example) Mozilla employees who happened to be hubs.mozilla.com administrators (to any degree) to also get full permissions to all users' rooms. So in practice, what you're referring to is arguably a more powerful role than our current admin role, which does not grant any privileged access to rooms.

[blairmacintyre]

Would it make sense to somehow combine this with the current account list in hubs cloud? You already have a list of accounts, if you could import and add an optional "always use this name" field, it might be sufficient?

No, of course not: the server only remembers a hash of the email, not the actual email. I'm leaving this here just as a reminder.

[gfodor]

For the display name thing, we have an analog in this for the discord use case. Specifically, when you are using hubs in a discord-bound room, you still have the flexibility to choose your display name. However, when the spacebar is held down, you can see the "verified" identifying name for that user (in this case, their discord id.)

Instead of introducing a new concept of "verified display names" (which doesn't exist in our current system), would it be sufficient to re-use the discord concept in this case? The net effect would be:

• The administrator can use an API to set (pre-emptively) account/email address to "identifying names" as mentioned
• When users join the room, they can still choose their display name. If they have a identifying name, it will be set as the default value in the avatar picker, but they can override it.
• When spacebar is held, you will be able to see the identifying name (if one is available) for that person.

Over time, we can increase the visibility of the 'identifying name' of a user, but by maintaining it as distinct from the display name (which contractually is something a user can set to whatever they want, at any time), it will help minimize the number of concepts we need to keep track of over time.

[gfodor]

The main downside to the approach above is that it would still give people a way to, perhaps dishonestly, represent themselves in-part with a name other than the known real world name they have associated with their account. However, we can probably mitigate that problem by evolving the UX, instead of introducing new concepts.

[blairmacintyre]

I think that would be pretty good, actually. Conferences often ask what your name is, and what you want on your badge, so we'd just want to pass in the "want on your badge" as the identity.

I think different communities have different standards, so making it possible for the admin to set the names, and then perhaps having the option to change it or not, would be completely reasonable. For this current use, I'm ok with either "you can change it" or not, whichever is easier. I'd probably lean toward exactly as you describe, since that will eliminate having to deal with people asking to have it changed.

[gfodor]

ok cool, that's great, thanks!

[gfodor]

OK I did a bit more thinking here in trying to come up with a generalized solution here. How about this proposal:

Add two new options for site administrators:

• Disallow account creation
  • If enabled, users will not be able to create accounts (the sign in dialog will silently fail, since to do otherwise would be a security hole)
• Require accounts to join rooms
  • If enabled, users will be forced to log in before joining a room

We add a new field to accounts, 'identifier' which can be set by the site administrator (not the owner of the account at this time.)

Then, we provide a UI that lets you create/update accounts (by entering an email address, and an optional identifier.) And/or an API to do so.

The net effect of this would be that for your use case, you flip the new admins flag to disable account creation and force login to enter rooms, and then use the API or UI to create accounts w identifiers. (You'd also disable 'allow users to create rooms flag', not covered here.)

The effect for users is they will be prompted to sign in before they can join any rooms listing on the homepage, and then when they are in the room, their identifier will be seen above their avatar when spacebar is held. They'll still be able to set their display name. People who have not had accounts created previously by the site administrator will not have access to the rooms.

This is nice because it removes the need for any kind of new abstraction in the system (like an email whitelist, etc.) and also pushes more flexibility into the system by exposing it as a room option.

[blairmacintyre]

That seems to cover things.

I don't understand the "Disallow account creation" ... is account creation what happens when you are not logged in (an anonymous account is created on the fly)? Or does that mean that only existing accounts (the ones we create via the API) are allowed? (As I type this, I think that's what it means).

I assume we are building on the existing account list? Will we need to add an email field, or when it's created/modified, it'll just has the email into the ID?

I like this a lot, if I'm understanding.

One big question, though, will be the API. On the conference end, I'll need a way to say "here's the current list of attendees, update the accounts", which will probably do this:

• if an account is there already, do nothing (perhaps tell me if the account identifier is different from the name I have)
• if an account isn't there, create
• if an account is there that's not in the list, tell me (but otherwise do nothing)

Since we may edit manually in hubs, we don't want to change existing ones without checking. Similarly, there may be admins/helpers that we added that we don't want removed.

This will probably want to be done with an external program that makes API calls like "get ID for email", "get identifier for ID", "add", "delete", and so on. I can imagine a little node program that does this and has a little webpage to control it, such as to log in and to show the output (although I'd need someone to show me how to do it)

[gfodor]

Yeah, when you enter an email in the sign in form, we create an account if one doesn't exist. That would disable the behavior, making it so if you entered an email for an account that didn't exist, the login email would just never show up.

The email will basically be 'baked in' to the account, so there will be a "create account" page in the admin console, or an API. You'll be able to see/update the identifier name for the account tho once its created, just not the email.

Good point on the API edge case of updated identifiers. I'll think about the API design a bit more. Also, would an API or UI be preferable here under this new model? I'm assuming API is still a better approach, but since the UI now is less hairy to think about, one could imagine this turning into a "grad-student-labor-complete" problem :)

[gfodor]

(the downside of the API ofc being having to write a piece of code on your side to do the wrangling.) We'll probably do the UI regardless, so this feature is available to non-programmers, so maybe we should start there and see how much additional value the API adds.

[gfodor]

In practice, I think there's a really wide spectrum of cases where the ability for lobby viewers to move around the room can fall from "a total non-starter" (eg, if there are confidential conversations known to be happening) to "not a big deal at all" (eg if it's a VRChat-like situation of public rooms full of strangers)

[blairmacintyre]

So, UI + API probably. Esp if UI is just "extend the current account UI".

The problem with only UI is that manual management of hundreds of accounts (or more) is a nightmare. My hypothetical little node app would fetch the data from somewhere (e.g., a google sheet or json file) and then do everything, providing feedback via "add some output to the HTML page" as it goes.

It may be that you want to provide some basic "upload a CSV in this format" capability to the console, that implements some well defined semantics w.r.t. existing accounts. But it might be just as easy to provide that in a glitch (for example) that shows how to use that API. Then people can customize to their system easily, and share ("Here's a glitch that pulls from sheets; enter your keys in the private glitch file, and go!")

[gfodor]

Cool that makes sense. UI will probably be optimized for the case of being able to adjust an account's identifier, not for bulk entry.

[robinkwilson]

https://github.com/mozilla/hubs/pull/2481 This functionality to bulk create accounts + identities is merged.