Page Comparison

Organizations

Reference to the GRCschema definition => GRCschema - Organization

Ability to create and setup a new Organization with all required information as identified in the standardized account definition

Includes: legal name, name, description, domain, phone number, email address, founded year, phone number, address, social address, and classifications (e.g., NAICS Code, SIC Code …)

Ability to update an existing Organization for all relevant information identified in the standardized account definition

Same as above

Ability to upload and change the Organization logo

Ability to delete of an Organization

If users can’t delete on their own, it is fine if UC deletes on their behalf

Accounts

Reference to the GRCschema definition => GRCschema - Account

along with

GRCschema - Group

GRCschema - Team

GRCschema - Initiative

Ability to create and setup a new Account with all required information as identified in the standardized account definition

Includes: name, phone number, and address

Ability to update an existing Account for all relevant information identified in the standardized account definition

Ability to upload and change the Account logo

Ability to delete of an Account

If users can’t delete on their own, it is fine if UC deletes on their behalf

Ability to invite additional users to an account

Ability to deactivate users assigned to an account

Ability to delete users from an account

If users can’t delete on their own, it is fine if UC deletes on their behalf

Ability to create, update, update, and delete Groups and add/remove users to those Groups

Ability to create, update, update, and delete Teams and add/remove users to those Teams

Ability to create, update, update, and delete Initiatives and add/remove users to those Initiatives

Register for mapper and gain access to profile and email

RBAC for at least admins vs others

Ability to create, update, and delete one or more accounts associated to an organization

Ability to create, update, and delete a user

Ability to associate / disassociate a user from an account

Ability to request / remove rights for a user to publish to the UC Federated Database

Multiple user names

Make one name primary

Remove all names but one

Define aliases

remove all aliases

phone numbers

email addresses

social media addresses

street addresses

teams

roles

contributor gating / approval governance

RBAC for at least admins vs others

Users / Persons

Reference to the GRCschema definition => GRCschema - User and GRCschema - Person

Ability to register as a new user with all required information as identified in the standardized account definition

Includes all the basic user information defined on the User object includes first name, last name, middle name, and e-mail address

Ability to register a user as a Contributor by supplying additional trust information

Includes how to contribute as (org, person, or both), two social addresses, and phone number.

Ability to supply additional optional information to help further identify the user

Includes alternative names, aliases, additional email addresses, additional phone numbers, additional social addresses, postal addresses,

Contribution Managment and API Protection

There needs to be a workflow in place to manage who can contribute, what they can contribute, and guardrails if broken to revoke rights

Ability for UC to allow or revoke rights for an account to approve own users for contribution

As a UC Administrator I want to allow or revoke the ability of an account to determine who can contribute to the federated database so that UC can control the quality of the federated database

It could become burdensome on UC to do all the approving. Initially we can keep it simple where UC must always approve. In later releases, we introduce the toggle to allow customers to decide who on their teams can contribute

Ability for an Account administrator to request that a user be allowed to contribute

As a UC Administrator I want to allow or revoke the ability of any user to contribute to the federated database so that UC can control who can contribute

If UC doesn’t allow an account to decide on their own, then there must be a request process

Ability for an Account administrator to revoke or allow users to publish to the federated database

As an account Administrator I want to allow or revoke the ability of a user to contribute to the federated database so that I can control who on my team can contribute

If we allow an account, then account administrators should be in control. Some users will only be researchers and not need to contribute

Ability for UC to revoke or allow users to publish to the federated database

As a UC Administrator I want to allow or revoke the ability of any user to contribute to the federated database so that UC can control who can contribute

Even if allow accounts or third-party application to control who on their team can contribute, UC must be able to revoke the rights of a bad actor

Role Based Access Control

Not everyone can be an admin

There are two areas we need to control:

1. permissions to perform functions like delete users

2. control contribution workflows

The first is an obvious candidate for RBAC. But controlling contribution workflows initially “feels” like a set of toggles with a bit more meaning that purely a permission.

Ability for UC to create, update, and delete a set of default / global roles

Ability for UC to turn on / off permissions within global roles

Ability for UC to add new permissions and include them in default roles

Ability for UC to designate which role is assigned to the initial user of an organization

Ability for UC to designate which role is assigned to subsequent users in an organization

Ability for account administrators to create, update, and delete a set of custom roles

Ability for account administrators to turn on / off permissions within custom roles

Ability for account administrators to assign roles to users

Ability for account administrator to determine which role is automatically assigned to new users