Attributes

Attributes offer the option to securely store, capture and share personal data. It's use is completely optional - as customers can choose to keep all personal data in an external location and use Quasr without any personal data.

Before we start let's tackle an important terminology:

• Attribute - When we refer to an attribute we generally refer to an attribute configuration and not a specific value itself. For example the configuration of an email attribute. Sometimes we do use the term as well for a specific value.

• Claim - When we refer to a claim we refer to an individual instantiation of an attribute. For example a specific email address. We always use this term to refer a specific value.

Please note that claims have immutable values, i.e. you can't change the value (data) of a claim after it's been created. If you like to update the claim you must:

• Create a new claim with the updated value.

• Disable or delete the old claim with the previous value (if desired).

The philosophy behind this approach is as follows:

• An enabled claim resembles a valid piece of data. You can have multiple enabled claims for the same user and attribute indicating all values are (still) valid.

• A disabled claim resembles a currently invalid piece of data but one that was historically valid.

Hence the following approach is recommended:

• If you update the value because of a change, or you need to be able to recover the old value, then keep the old claim but disable it.

• If you update the value because of a correction, and you don't need to be able to recover the old value, then delete the old claim.

Please note that the value (data) of a claim is stored securely encrypted and never logged. Hence if you delete the claim you won't be able to recover the value.

Types

Quasr supports various types of attributes:

• Standard Attributes - These are attributes as defined by the OpenID Connect 1.0 specification:

  • (Full) Name - this is a string with max 100 characters

  • Given (First) Name - this is a string with max 100 characters

  • Family (Last) Name - this is a string with max 100 characters

  • Middle Name - this is a string with max 100 characters

  • Nickname - this is a string with max 100 characters

  • Preferred Username - this is a string with max 100 characters

  • Profile - this is an URL

  • Picture - this is an URL

  • Website - this is an URL

  • Email - this is a string complying with email format

  • Gender - this is a string with max 100 characters

  • Birthdate - this is a string in YYYY-MM-DD format

  • (Time) Zone Info - this is a string in Europe/Paris format

  • Locale - this is a string in en_US or en-US format

  • Phone Number - this is a string with max 100 characters

  • Address - this is a JSON object

    • Formatted Address - this is a string containing the full address in 1 line with max 100 characters

    • Street Address - this is a string with max 100 characters

    • Locality (City/Town) - this is a string with max 100 characters

    • Region (State/Province) - this is a string with max 100 characters

    • Postal Code - this is a string with max 100 characters

    • Country - this is a string with max 100 characters

• Custom Attributes - These are attributes as defined by yourself and can be of various subtypes:

  • String - you can set a regular expression (RegEx)

  • Number - integers only

  • Boolean

  • URL

  • JSON

Configuration

For each attribute you can specify the following:

• Score - Each attribute will have a score indicating what (security) score a user needs in order to see or provide claims via the Authentication API during signup or login. This allows shielding data from users that haven't sufficiently authenticated.

• Internal - This indicates that the attribute should only be used by internal accounts. For example an internal employee number, badge number or unit.

• Restricted - This indicates that the attribute can only be created by the system or an admin. Hence not allowing accounts to create their own. For example a loyalty tier or membership.

• Value - This is the key by which the attribute will be injected into an identity or access token. Please note that no uniqueness check is performed on the value hence any key collisions will result in some attribute being overwritten.

{
    // other ID or access token claims
    "<attribute_value>": "<claim_value>"
}

• Regex - This is only applicable to string attributes and is a regular expression (RegEx) to which any input must comply. Once set you can't set change the regex.

• Unique - This indicates whether each individual value (claim) for the attribute must be unique. So if you say for example that the email attribute is unique than only 1 account can have a specific email.

• Case Sensitive - This indicates whether input must be considered case sensitive. Only relevant if the attribute must be unique.

• Require Validation for Enablement - This indicates whether any individual value (claim) must first be validated before it gets enabled. The validation can happen in 2 ways:

  1. Automatic validation by the system. For example for an email attribute you can perform email validation via a One-Time Password (OTP). This can be setup using sources.

  2. Manual validation by an admin. Here an administrator validates the attributes and confirm this via the Admin UI or Management API.