The following tables provide information about the default schema employed by the user entity type, the entity type included with each new Identity Cloud application (and, as such, each new Hosted Login implementation). Although you can add new attributes to the schema, ​Akamai​ strongly recommends that you do not remove any of the default attributes: in some cases, at least, removing attributes can disable Hosted Login functionality. For example, if you remove the [egal acceptances plural then you won't be able to employ the authorization.rules.legal_accepted authorization rule.

The new default schema differs from previous Identity Cloud schemas in at least two ways:

• A number of user profile attributes (database fields) – including such attributes as  profiles.profile.bodyType.hairColor, profiles.profile.turnOffs, profiles.profile.happiestWhen, profiles.profile.scaredOf – have been removed from the schema. By removing these seldom-used attributes, the current schema contains about one-fourth the number of attributes found in the previous schema.

  But what if you need the profiles.profile.turnOffs attribute? That’s fine: you can add an attribute to a schema anytime you want.

• A handful of new attributes – accountDeleteRequestTime, consents.marketing.granted, etc. – have been added to the schema. These new attributes are typically used with Hosted Login.

Let’s take a closer look at the attributes found in the new user schema.

Default attributes

Attributes (and attribute values) that the Identity Cloud automatically adds to all new user profiles. These attributes are added when a user profile is created, and the attribute values can never be changed: if a user is given the uuid 3580bf7c-0a73-4bc0-9636-b4193f810e74 then that user will always have the uuid 3580bf7c-0a73-4bc0-9636-b4193f810e74.

Top-level attributes

Top-level attributes are “stand-alone” attributes: attributes that are not part of a plural or object. To refer to one of these attributes, use the attribute name: accountDataRequestTime, accountDeleteRequestTime, birthday, etc.

Clients plural

The clients plural tracks the different API clients that a user has employed when being authenticated. When referring to an individual attribute, be sure to use the full attribute path: clients.clientId, clients.firstLogin, etc.

Consents object

Tracks the consent agreements used in your organization, and indicates whether the user agreed to any of those consents. By default the schema includes a single marketing object provisioned as part of the consents object. That means that, to refer to an individual attribute, you’ll need to use syntax like this: consents.marketing.granted. The consents object is required in order to implement the authorization.rules.consents.

Legal acceptances plural

Tracks the legal agreements used in your organization as well as whether a user has  accepted any of those agreements. To refer to an individual attribute, use syntax like this: legalAcceptances.dateAccepted. The legalAcceptances plural is required in order to implement the authorization.rules.legal_accepted](doc:hosted-login-authorization-rules).

Photos plural

Maintains information about the photos used in a user profile. To refer to an individual attribute, use syntax like this: photos.value.

Primary address object

Provides information about a user’s preferred address. To refer to an individual attribute, use syntax like this: primaryAddress.country.

Profiles plural

Represents any third-party identity providers a user has employed to authenticate with your site: if you  haven’t enabled social login (e.g. allowing users to log on with Facebook or Twitter) then none of your users will have entries in the profiles plural.

To refer to an individual attribute, use syntax like this: profiles.domain.

Roles plural

Maintains information about roles used by your organization to group and categorize users. Note that roles are arbitrary: you can create any kind and any number of roles you want. In addition, roles are optional: if you don’t want to use roles you don’t have to.

To refer to an individual attribute, you’ll need to use syntax like this: roles.value.