Glossary

A

ABAC

Attribute-based Access Control is an access model driven by access policies that take attributes of the user, the target application and the context into account. The policy-driven nature of TrustBuilder.io enables ABAC. Additionally, TrustBuilder.io can also consume Derived Attributes.

Access Token

A security token according to the OAuth2 standard used to access the API of a provider. According to OAuth2, an Access Token can be in any format. TrustBuilder.io issues bearer Access Tokens in JWT format. In this context, an Access Token informs a service provider that the bearer of the token has been authorized to access its API and execute specific methods.

Access Policy

In the context of TrustBuilder, equivalent to policy.

Access Right

In the context of TrustBuilder, equivalent to entitlement.

Account

In the context of TrustBuilder, an account refers to the record of a digital user that is maintained in a directory, a CRM, an e-commerce system, a banking system, or other provider. As the name implies, an account is used for bookkeeping: it keeps track of transactions and keeps track of entitlements that have been assigned to the user. TrustBuilder.io grants access policy-driven using user characteristics rather than pre-assigned entitlements. It therefor maintains a user profile and not a user account, and allows this profile to refer to accounts in other systems using account linking.

Account Linking

In the context of TrustBuilder, Account Linking means linking the user profile with corresponding accounts held by providers. Connecting the user profile with accounts across multiple platforms provides users a seamless access experience across multiple applications and platforms. TrustBuilder.io also maintains the user consent concerning the use and information exchange of account linking.

Adaptive Authentication

An approach to trigger Multi-factor Authentication for user only in case an attempted login is determined to be a low confidence login. Using this approach, TrustBuilder.io triggers additional authentication factors only when needed to add friction for bad actors while keeping the login experience unchanged for good actors. It is thanks to its unique session concept that TrustBuilder.io enables adaptive authentication to be fully policy-driven and customisable.

Admin API

TrustBuilder's API to configure TrustBuilder.io services and perform administrative tasks programmatically, and providing similar functionality as the Admin Portal.

Admin Portal

TrustBuilder’s primary administrator interface in which configure your TrustBuilder.io tenants, define the user profile and policies, and register and connect your applications and providers. The second use of the Admin Portal is user administration, typically used by the service desk to help out users and to pre-register users manually. All functionality is also made programmatically available through the Admin API. Access to the Admin Portal is policy-driven, and for configuration work the user must have the persona config.admin, and for user administration the persona user.admin is required, in addition to the correct scope, as configured by you.

Application

Your software that relies on TrustBuilder.io for authentication, identity and authorization management. TrustBuilder.io supports single-page, regular web, native, and machine-to-machine applications.

Assertion

Claims concerning an entity, made by that same entity in a self-service model, or by a mandated person or authoritative source, or by a system such as TrustBuilder.io in the form of a verifiable presentation.

Attestation

A process of periodically requiring people like managers and resource owners to review and certify the entitlements that enterprise users have (also know as Access Certification). Because entitlements are being assigned to people beforehand and are not determined and re-evaluated in real-time, this process is required for RBAC and aims to ensure that access continues to comply with written (or assumed) policies.

Attribute

Represents an atomic piece of information or a composed set of information about a digital user. TrustBuilder.io maintains attributes in the single user profile of a person.

Audience in OAuth2

The unique identifier of the audience for an issued token, identified within an access token and id token as the aud claim. The audience is either the application (Client ID) for an id token or the API that is being called for an access token.

Authentication

See User Authentication.

Authentication Factor

A method of user authentication, whereby the credentials needed to provide proof have been uniquely linked to the user profile beforehand.

Authentication Provider

In the context of TrustBuilder.io, an Authentication Provider is a type of provider that provides an authenticator factor. The function of authentication provider is often combined with that of an identity provider.

Authentication Server

The functionality that confirms or denies a user’s identity. An authentication server does not limit the actions or resources available to the user (although it can provide context for this purpose).

Authenticated Identity

A security token that represents the fact that an identified user has been authenticated for a domain in a documented context. TrustBuilder.io issues such tokens as a JWT according to OIDC1, or as a SAML token.

Authorization

The process of taking a decision whether a user or an application should get access to a particular application, service provider, function, resource and/or record. In TrustBuilder.io, such decisions are policy-driven.

Authoritative Source

Is a provider that manages master information of a user and that is referred to as the ultimate (“authorative”) source of truth regarding specific attributes or other user-related data.

Authorization Server

The functionality that contributes to defining the boundaries of a user’s access. For example, your authorization server can control the data, tasks, and features available to a user. An authorization server does not authenticate users; that is the role of the authentication server. The Authorization Server plays an explicit role in the OAuth2 protocol, see

B

Bad Actors

Also known as threat actors. An entity (a person or group) that poses a threat to your business or environment with the intention to cause harm. Harm can constitute physical or cyber damages, from breaking into a data center to hacking into systems with stolen credentials.

Bearer Token

Since the Access Token issued by TrustBuilder.io is a bearer token, it must be forwarded to a provider’s API in the "Authorization" request header field using the "Bearer" authentication scheme as defined by

RFC 6750: The OAuth 2.0 Authorization Framework: Bearer Token Usage.

C

Callback

The URL to which TrustBuilder sends its response after authentication. It is often the same URL to which a user is redirected after authentication.

Claim in OAuth2

An attribute packaged in a JWT token which represents a claim that the issuer of the token is making about the user.

Client ID

Identification value assigned to your application after it is registered with TrustBuilder.io This value is used in conjunction with other third-party services and can be found in the TrustBuilder Admin Portal.

Client Secret

A secret used by a client (application) to authenticate with the Authorization Server; it should be known to only the client and the Authorization Server and must be sufficiently random to not be guessable.

Confidential Client

According to the OAuth 2.0 protocol, clients (applications) can be classified as either confidential or public depending on whether or not they are able to hold credentials (such as a client ID and secret) securely. Confidential clients can hold credentials in a secure way without exposing them to unauthorized parties and require a trusted backend server to do so. They can use OAuth2 flows that require them to authenticate by specifying their client ID and secret when calling the token endpoint and can have tokens issued to them that have been signed either symmetrically or asymmetrically.

Coarse-grained Access Control

Coarse-grained access control is the ability to grant or deny access to resources based on a single factor, e.g. ‘having an account’, ‘having a role or an entitlement’.

Confused Deputy

The term Confused Deputy refers to a situation in which an attacker tricks a client or service into performing an action on the user’s behalf.

Traditionally, represents the fact that a user agreed that their personal data is being processed. From a GDPR perspective, consent means that the user has agreed that their data is being processed, and also that the purpose and scope is limited and was unambiguously made clear, and that the agreement was given without undue pressure. As opposed to just collecting a generic consent, TrustBuilder.io fully adheres to the GDPR philosophy and manages different types of specific consents: consent to process persona data in the user profile, consent to obtain personal data from a particular identity provider, and consent to share personal data with a particular service provider.

Consent Enforcement

TrustBuilder.io is both policy-driven (to protect your interests) and user-centric (protecting the end user’s interests). Whenever TrustBuilder.io decides it is allowed to access personal data from a policy perspective, it also verifies whether the holder has given their consent for that type of access. TrustBuilder.io is fairly unique in enforcing not only a security policy but also user consent, implementing user managed access on top of policy-driven access.

Consent Lifecycle Management

TrustBuilder.io enables the user to manage their consents so that they can revoke and reactivate a given consent. A given consent goes through stages of pending and accepted (also called consent registration), and potentially the stages revoked or suspended.

Consent Registration

One of the steps in Consent Lifecycle Management.

Credential

In the context of authentication, a credential is something a user (a person or a device) must provide to prove their identity within a given context. In a digital context where a person needs to prove they hold a user profile, this can be something only they know (like a password), something only they have (like a security dongle or a secret key on a device), or something only they are (like biometric scans of a fingerprint, face or iris).

Custom Domain

A third-party domain identified with a CNAME.

D

Decentralized Identifier

A portable URL-based identifier, also known as a DID, associated with an entity. These identifiers are most often used in a verifiable credential and are associated with entities such that a verifiable credential itself can be easily ported from one repository to another without the need to reissue the credential. An example of a DID is did:example:123456abcdef.

Delegated Administration

Delegating the administration of security access to your customers. TrustBuilder.io is unique by turning this type of administration into persona administration that can effectively be delegated because it resembles the business context of those customers. This is in sharp contrast to having a sysadmin assign entitlements, permissions, roles and groups. Delegating security administration to the people themselves, fosters timeliness, accuracy, appropriateness, and freshness and reduces the need for periodic attestation vastly.

Derived Attribute

An attribute obtained from a source external to TrustBuilder.io, i.e. a provider. The information may have been processed by TrustBuilder.io before it is made available as Derived Attribute. For example, it can be the result of a conversion (to map formats and/or semantics), or a calculation in so-called zero knowledge assertions.

Device Profile

A Device Profile is basically a User Profile that contains a persona to represent an IoT device. Using this profile, an IoT device can be identified, authenticated and receive authorisation. A device persona can be linked to its digital twin. Different devices may have different personas to reflect different types of IoT devices with different levels of authority and different types of data (e.g. a sensor streaming data points versus a hub maintaining configurations).

Digital Identity

In the context of TrustBuilder, equivalent to identity.

Digital Twin

The User Profile that uniquely represents an entity in the digital realm of a TrustBuilder customer.

DCIP

Document Centric Identity Proofing is a term coined by Gartner to refer to a technique for Person identification.

E

eIDAS

eIDAS (electronic IDentification, Authentication and trust Services) is an EU regulation on electronic identification and trust services for electronic transactions in the European Single Market. It was established in EU Regulation 910/2014 of 23 July 2014 on electronic identification and repeals 1999/93/EC from 13 December 1999 - see EUR-Lex - 31999L0093 - EN.

Entitlement

A privilege, a permission, a role, a group or another type of access right that is pre-assigned to an enterprise user to reflect their pre-determined right to access certain functions and/or certain records. The fact that it is pre-assigned means it is rather static (typically stored in a user account) and must be periodically reviewed in an IGA process.

Entitlement Management

The process of managing entitlements of enterprise users in relation to systems, applications and digital services. RBAC-driven systems, applications and digital services need entitlements that are maintained with the respective user accounts. Even though the PBAC-driven nature of TrustBuilder.io does not need pre-assigned entitlements, it can provision them to systems, applications and digital services that need them.

Entity

An item that has a recognizable, distinct existence and that can thus be identified individually.

F

Federated identification

The process of identifying a user by an external system with which a trust relationship has been established.

FIDO2

Is a standard for strong web authentication based on joint efforts between the Fast Identity Online (“FIDO”) Alliance and the World Wide Web Consortium (“W3C”). At its core, FIDO2 consists of the W3C Web Authentication (“WebAuthn”), the FIDO Client to Authenticator Protocol (“CTAP”) and the FIDO Universal 2nd Factor (“U2F”) standards. FIDO2 is embraced by major OS vendors such as Apple, Google and Microsoft.

Fine-grained Authorisation

Fine-grained access control is the ability to grant or deny access to critical assets, such as resources and data, based on multiple conditions and/or multiple entitlements.

Flow

See Workflow.

G

The General Data Protection Regulation (“GDPR”) is one he toughest privacy and security law in the world. Though it was drafted and passed by the European Union (EU), it imposes obligations onto organizations anywhere, so long as they target or collect data related to people in the EU. The regulation was put into effect on May 25, 2018, see General Data Protection Regulation (GDPR) Compliance Guidelines .

Git repository

Is free and open source software for distributed version control: tracking changes in any set of files, usually used for coordinating work among developers and administrators. Its goals include speed, data integrity, and support for distributed, non-linear workflows (thousands of parallel branches running on different systems). See Git. TrustBuidler_io uses a Git repository to manage tenant configurations, including the policies for its policy-driven access management.

H

Hosted Login

A term often used to refer to “one place to login your users”. For reasons of security, TrustBuilder.io logs in a user at a single place and manages the rendering and hosting in its own platform so that no credentials and secrets can leak. Hosted Login refers to this central and hosted UX.

I

ID Token

An authenticated identity meant for the client itself, rather than for accessing a resource. OIDC1 standardizes its format and semantics so that clients can parse and validate the ID Token.

Identification

See User Identification.

Identifier

A string assigned by an issuer to uniquely identify a person in the issuer’s domain. For example, a CRM identifier is the customer-id or partner-id assigned by a company’s CRM. An HR identifier is the employee number assigned by HR. An IAM identifier is the universal unique user id (uuid) assigned by the IAM, such as the id in the TrustBuilder.io user profile. An identifier can also be a foreign key in TrustBuilder.io to link to the corresponding account at a provider after account linking.

Identity

A virtual set of attributes (characteristics and properties) that identify an entity, like a person or an IoT device, according to ISO/IEC 24760-1:2019. TrustBuilder.io captures a person’s identity in the user profile and a device’s identity in the device profile. Additionally, TrustBuilder.io acknowledges that people can operate in different capacities relative to an organization and its digital services, for which it introduced the concept of persona.

Identity Management

The process of managing the identity of a digital user in the context of an organization and its digital services. Note that assigning entitlements to users (such as permissions, roles and groups) is the subject of Entitlement Management.

Identity Proofing

Validating a user’s identity against an authoritative source, declared as provider in TrustBuilder.io.

Identity Provider

In the context of TrustBuilder.io, an Identity Provider is a type of provider that stores, manages and provides digital identities and can optionally issue verifiable credentials. TrustBuilder makes social, enterprise, public identity providers and self-sovereign identifiers available through its Service Catalog. The connection between a user profile and an account at an identity provider (so-called account linking) is policy-driven and subject to consent enforcement using the consent_to_obtain flag managed by the user. The function of an identity provider is often combined with that of an authentication provider, and TrustBuilder.io allows to make this distinction if and when needed. TrustBuilder.io itself can also function as an identity provider to your application and to your partner’s platform issuing verifiable presentations.

IGA

Identity Governance & Administration (“IGA”) is the process of managing user accounts and entitlements across multiple systems, applications and digital services. IGA encompasses Identity Management, Entitlement Management, RBAC management and periodic audit, reporting, and attestation.

IoT device

Internet of Things (“IoT”) refers to an internet-connected device ranging from printers, thermostats and security cameras to televisions, medical devices, and cars. IoT devices have a unique IP address, enabling them to connect to other servers and other IoT devices to send and receive data and software updates. IoT devices must be secured; to enable this, TrustBuilder.io manages a Device Profile for each IoT device based on its unique identity, either a serial number of a cryptographically protected device-id.

J

Just-in-time migration

In the context of TrustBuilder, a user migration using just-in-time registration.

Just-in-time registration

A form of user registration whereby your users are registered in TrustBuilder.io the first time they log in based on a user account in another IAM platform, Active Directory or LDAP Directory, or Certificate Authority. When used to implement user migration, people are hereby not asked to reset their password as a result of the migration. This type of user migration avoids a big bang in which all users would be migrated in one go, with concerns around changes that happen during the actual migration.

JWT

JSON Web Token (“JWT”) is an open, industry standard RFC 7519: JSON Web Token (JWT) method for representing claims securely between two parties. At TrustBuilder, id tokens and access tokens are always returned in JWT format. You can decode well-formed JWTs at JWT.io to view their contents.

L

Lazy Migration

In the context of TrustBuilder, a user migration using just-in-time registration.

Localization

Ability to render the Self-Service Portal experience into different languages.

M

Maturity

TrustBuilder developed a Digital Ecosystem Maturity Model to measure the digital transformation of an enterprise in IAM terms.

Methods

Methods extend TrustBuilder.io functionality and enables tight integration with providers and are secure functions provided by a provider. A method can be invoked by a trigger from a policy. Conversely, the invocation of a method (through an API call by the user agent) may trigger an associated policy. Methods include predefined microservices made available through the TrustBuilder Service Catalog, predefined functions within TB.Connect, and custom-built functions run by TB.Connect or by a separate cloud-based microservice.

Multi-factor Authentication

An authentication process that considers multiple authentication factors. Typically at TrustBuilder, the first factor is the standard username/password exchange, and the second is a code or link via email or SMS, a one-time-password via an app such as Authy or Google Authenticator, or a push notification via a phone app such as Guardian or Duo. Using multiple factors allows a user profile to remain protected even if someone captures one of the factors, e.g. gets hold of a password or steals a phone.

N

Nonce

An arbitrary (often random or pseudo-random) number issued in an authentication protocol that can help detect and mitigate replay attacks using traditional communications. In other words, the nonce is only issued once, so if an attacker attempts to replay a genuine transaction with a different nonce, its false transaction can be detected more easily.

O

OAuth2

An authorization framework that defines authorization protocols and workflows. OAuth2 defines roles, authorization grants (or workflows), authorization requests and responses, and token handling. The version of OAuth2 adopted by TrustBuilder is The OAuth 2.1 Authorization Framework.

Obligation

In the context of TrustBuilder.io and XACML3, an Obligation tells the requestor of a policy decision to undertake action after a policy has been executed (in contrast to a policy trigger). An example is something a user needs to do, such as selecting a different persona, before a “permit” can be granted.

OIDC1

An open standard for authentication that allows applications to verify users are who they say they are without needing to collect, store, and therefore become liable for a user’s login information. The version of OIDC adopted by TrustBuilder is Final: OpenID Connect Core 1.0 incorporating errata set 1.

Orchestration

In the context of TrustBuilder.io, Orchestration is the configuration and execution of workflows related to managing identities and authorizations, whereby the individual steps can represent a policy decision, a call to a method of an external system or a task being delegated to an end user.

P

Passwordless

A form of authentication where the first authentication factor is not a password. Instead, it could be a cryptographic exchange with a mobile device, a one-time password received by email or SMS, a push notification, or a biometric sensor. With passwordless authentication, users are less susceptible to the typical password-based attacks, such as dictionary attacks, password spraying attacks and credential stuffing attacks than with traditional username/password logins. TrustBuilder.io offers a number of passwordless authentication factor through its Service Catalog.

PBAC

Policy-based Access Control is an access model driven by externalized, centrally governed access policies. TrustBuilder.io essentially implements PBAC by converting your company’s interests into ABAC and RBAC policies and enriching these with consent enforcement to also take the user’s interests into account.

Perimeter

A set of boundaries that encompass a directory, all of its users, and all of the applications which use the directory. In some implementations, this perimeter is a physical location; in others, it is a set of networks or devices connected via VPN.

Person Identification

The process of establishing a person’s identity as a citizen, registered by a public authority. The techniques used to establish this identity vary from scanning physical, formal documents, to verifying verifiable credentials with a public authority in combination with biometric matching, to verifying that the user’s eID card.

Person Authentication

The process of establishing the presence of the person that was identified and registered before using person identification.

Persona

A Persona in TrustBuilder reflects the type of activities a users (e.g. people or devices) want to undertake and allows these activities to be clearly segregated, for reasons of user convenience and/or for reasons of separation of duties. A Persona also gives a user an identity specific for a given context and purpose, and as such has its own set of attributes. TrustBuilder.io policies use the selected Persona to decide whether certain access can be granted or not. Thanks to the concept of Persona, TrustBuilder.io also enables Delegated Administration in a very natural and secure way.

Persona Lifecycle Management

TrustBuilder.io enables the user to manage their personas whereby one of the personas can be revoked, expired, and reactivated. The lifecycle of a given persona goes through stages of pending and accepted, and potentially revoked, expired or suspended. Important to highlight is that a user profile can remain active, while its personas have their own lifecycle in which they can be revoked. For example, a user may keep their user profile, while all personas are inactive so that the user is de facto blocked from all access.

Policy

TrustBuilder.io offers the processes of authentication, authorization, attestation and provisioning to be fully policy-driven, whereby a Policy is configured in a policy language that does not require any coding. When configuring service providers and identity providers, the Admin Portal allows you to attach a policy to every method exposed by the provider. A policy is basically a set of rules that can take any attribute into account (user profile attributes, derived attributes, persona-related attributes including RBAC roles) as well as the context, such as session and device parameters. A policy in TrustBuilder.io is fundamentally declarative and describes “under which circumstances can access be granted”. A policy also contains triggers for further user action or other type of action such as provisioning.

Policy-driven

A unique characteristic of TrustBuilder.io is its policy-driven approach to authentication, authorization, attestation and provisioning.

Policy Administration Point

According to XACML3, this is the service where the policies are actually administered. The Policy Administration Point in TrustBuilder.io is the Admin Portal and Management API that use a Git repository across your tenants.

Policy Decision Point

According to XACML3, this is the service that actually takes decisions using the policies, and corresponds to the Authorization Server in OAuth2. In TrustBuilder.io, these decisions serve authentication, authorization, attestation and provisioning flows and can be consumed by a Policy Enforcement Point. Decisions are taken using a variety of information sources, the so-called Policy Information Points.

Policy Enforcement Point

According to XACML3, this is the service that uses the decisions of the Policy Decision Point to forward a request or not. Using TrustBuilder.io, the Policy Enforcement Point can be implemented using the TrustBuilder Gateway that is locally installed, can be your own API Gateway or Enterprise Service Bus, or can be implemented by the provider itself.

Policy Information Point

According to XACML3, this is the service that provides the Policy Decision Point with information about the user, the requesting application, the target application and the context. TrustBuilder.io, uses the User Profile and the User Session, as well as Provider data and derived attributes obtained through the Policy Information Broker.

Policy Information Broker

A service uniquely provided by TrustBuilder.io that obtains derived attributes as a kind of virtual Policy Information Point acting as broker between Policy Information Points.

Policy Language

Formal language used to configure a policy in the Policy Administration Point to foster the Low Code / No Code philosophy. TrustBuilder.io adopts a derivative of the XACML3 Policy Language.

Policy Retrieval Point

The service where the policies are stored for real-time use as part of the Tenant Manager. The TrustBuilder.io Policy Retrieval Point contains the policies for a specific tenant that were administered, configured, versioned and released by your administrators using the Policy Administration Point.

Policy Trigger

By being a policy-driven platform, TrustBuilder.io offers different ways for triggering a policy: a policy can be trigger after an event (such as a user login, a user self-registration, a user migration, or a user switching personas), or just before a method of a service provider is being invoked.

Preview

Product release stage during which the referenced feature or behavior is provided to subscribers to give them time to explore and adopt new product capabilities prior to availability of in the Production environment. Functionality is code-complete, stable, useful in a variety of scenarios, and believed to meet or almost meet quality expectations of a Production environment. Preview releases may be restricted to a select number of subscribers (private) or open to all subscribers (public).

Profile

In the context of TrustBuilder.io, equivalent to User Profile and Device Profile.

Progressive Profiling

The process to gradually enrich the user profile with attributes and assertions. In fact, TrustBuilder.io allows a user to register a user profile with very little data initially (basically only a username and consent_to_process to minimize registration friction, and to add attributes whenever it is needed and relevant at later stages. Adding or (changing) attributes, however, needs a proper user session to be authorized to do so.

Provider

TrustBuilder groups Identity Providers and Service Providers under the term “Provider”. A Provider refers to a back-end application, a resource, an external identity provider, a user repository, an LDAP directory, an authentication factor, a relying party, or an authoritative source. Note that Service Providers, such as a CRM and HRM may also provide identity information and even be the authoritative source of identity information, so they can also qualify as Identity Provider. Also, an Identity Provider may only provide identity information, or may provide identity information as well as an authentication factor, while certain providers only provide authentication services. As such, TrustBuilder adopts the generic term “Provider.” TrustBuilder maintains a Service Catalog to enable configurable connections with SaaS platforms, commercial digital service providers and public service providers, and offers TB.Connect to enable connections with your own applications and custom platforms.

Provisioning

A fulfilment process to propagate user accounts and entitlements to the systems , applications and digital services that need them. TrsuBuilder_io maintains a single user profile for every digital user and a set of policies that governs the provisioning of accounts and entitlements.

Public Client

According to the OAuth 2.0 protocol, clients (applications) can be classified as either confidential or public depending on whether or not they are able to hold credentials (such as a client ID and secret) securely. Public clients cannot hold credentials securely, so should only use grant types that do not require the use of their client secret. ID Tokens issued to them must be signed asymmetrically using a private key (RS256) and verified using the public key corresponding to the private key used to sign the token.

R

RBAC

Role-based Access Control is an access model with explicit entitlements that should reflect implied access policies. Entitlements are pre-assigned to users in the form of ‘roles’. While TrustBuilder-io supports RBAC and pre-assigned roles, it can provision these roles using a provisioning policy, or can avoid the need for roles using the persona concept.

Refresh Token

A special kind of security token that can be used to obtain a renewed Access Token. It is useful for renewing expiring Access Tokens without forcing the user to log in again. Using the Refresh Token, you can request a new Access Token at any time until the Refresh Token is blacklisted. See Refresh Tokens.

Refresh Token Rotation

A strategy of frequently replacing refresh tokens to minimize vulnerability. With refresh token rotation, every time your application exchanges a refresh token to get a new access token, TrustBuilder also returns a new refresh token.

Registration

In the context of TrustBuilder, equivalent to User Registration.

Relying Party

In the context of TrustBuilder.io, a Relying Party is an entity (such as a provider) that depends on TrustBuilder.io to obtain trustworthy information.

Request Token

A unique, one-time, opaque security token that refers to a task to be done and that is sent to a user, the actioner. With TrustBuilder.io, this token can be used to construct a magic link to the user in an email, in a mobile text message, in an SSE push notification, or a QR code displayed on a TV screen. When embedded in a URI, the user can click on it for out-of-band authentication, profile activation, consent, approval, email change confirmation etc.

Resource Owner

In OAuth2 terms, an entity (such as a user or application) capable of granting access to a protected resource.

Resource Provider

In the context of TrustBuilder, a Resource Provider is a type of provider that provides IT service functionality and for which authorization is needed before it can be called upon.

Resource Server

In OAuth2 terms, a server hosting protected resources, such as a back-end application, a database, a service provider, an identity provider, or a system. Resource servers accept and respond to protected resource requests.

Risk score

The risk level of a session that represents the chances that the user is no longer present or that a bad actor has taken over their session. TrustBuilder.io re-evaluates the risk score with every token request.

Risk-based Authentication

An approach to trigger re-authentication for users in case the risk score of a session is deemed too high. It is thanks to its unique session concept that TrustBuilder.io enables risk-based authentication to be fully policy-driven and customizable.

Role in RBAC

An aspect of a user to indicate the level of access they should have to a system, application or digital service. Roles are essentially collections of entitlements and group permissions, access rights and potentially subordinate role definitions.

S

SAML

Security Assertion Markup Language (“SAML”) is an XML-based standardized protocol by which two parties can exchange authentication information without the use of a password.

Scope in OAuth2

A mechanism that defines the specific actions applications can be allowed to do or information that they can request on a user’s behalf. Often, applications will want to make use of the information that has already been created in an online resource. To do so, the application must ask for authorization to access this information on a user’s behalf. When an app requests permission to access a resource through an authorization server, it uses the scope parameter to specify what access it needs, and the authorization server uses the scope parameter to respond with the access that was actually granted.

Security Token

A tamper-evident (digitally signed) artefact that proves the result of a certain process.

Self-Service

TrustBuilder.io fosters an identity management model whereby the initial registration (as well as updating attributes) is delegated to the users themselves as much as possible. To enable this, users can make assertions that can be identity proofed, either by having a mandated person approving the assertions or by an authoritative source confirming the assertions.

Self-Service Portal

TrustBuilder’s implementation of the self-service registration, authentication and edit-profile flows. Each time a user needs to prove their identity, your applications redirect to the Self-Service Portal. The Self-Service Portal can be fully Localized and customized using Web Components.

Self-Sovereign Identifier

A Self-Sovereign ID (“SSID”) is a digital identity that gives individuals complete control over the information they use to prove who they are to providers, independently of any provider. For an identity to be self-sovereign, users control the verifiable credentials that they hold, and the scope, consent and form for sharing verifiable presentations. This reduces the unintended sharing of users' personal data. This is contrasted with a federated identity paradigm where identity is provided by an identity provider, not necessarily under full control of the user. TrustBuilder.io does support SSID as well as federated identity with a consent enforcement model under full control of the user. The EU recently created an eIDAS compatible European Self-Sovereign Identity Framework that makes use of decentralized identifiers and the European Blockchain Services Infrastructure.

Service Catalog

A set of identity, authentication and service providers that are pre-integrated by TrustBuilder.io and for which default configuration templates are made available.

Service Provider

In the context of TrustBuilder.io, a Service Provider is a type of provider that provides digital services and for which authorization is needed before it can be called upon. TrustBuilder maintains a Service Catalog to enable configurable connections with SaaS platforms, digital service providers and offers TB.Connect to enable connections with your own applications and custom platforms.

Session

A Session represents a period during which the authentication of a user is considered valid and sufficiently reliable. TrustBuilder.io maintains a Session as a record that contains all authentication factors supplied by the user during the session, and the persona that is last selected by the user. A TrustBuilder.io session has a lifecycle: the risk score of a session can evolve over time, both positively (after supplementary authentication) and negatively (when the session has aged too much). The Session concept as designed by TrustBuilder provides policy-driven authentication that enables in a natural way adaptive authentication, step-up authentication and risk-based authentication.

Session Cookie

A cookie that a user application may set after it establishes that the id token it received is signed, valid, and comes from a trusted source, e.g. TrustBuilder.io. This cookie represents the fact that successful authentication occurred and reduces the need to repeatedly ask for id tokens. TrustBuilder.io keeps its sessions server-side and does not rely on cookies: it only uses session cookies to enable single sign-on between different applications.

Shadow Accounts

A difficult to sustain practice of manually provisioning a user from a local directory separately in a remote directory (essentially creating a copy, or shadow, of the original account) when they need access to remote applications.

Signing Algorithm

A hashing algorithm used to digitally sign tokens to ensure the token has not been tampered with by bad actors.

Single Sign-On

Single Sign-On (“SSO”) is service that, after a user logs into one application, automatically logs that user in to other applications, regardless of the platform, technology, or domain the user is using. The user signs in only one time. TrustBuilder.io offers refined SSO allowing you to control under which circumstances a user may need to re-login or authenticate with a different factor, see adaptive authentication, step-up authentication and risk-based authentication.

Single Logout

Single Logout (“SLO”) occurs when, after a user logs out from one application, they are logged out of each application or service where they were logged in. TrustBuilder.io makes SLO possible through the use of sessions.

Step-up Authentication

Step-up authentication enables you to provide easy access to one layer of non-critical resources and multi-factor authentication to a more critical / sensitive layer of resources. Thanks to its unique session concept, TrustBuilder.io enables step-up authentication to be fully policy-driven and customizable.

Subscription

The agreement with TrustBuilder that defines the features and quotas available for each of your tenants. TrustBuilder has multiple subscription levels to meet the needs of different customers.

T

Task

A request for an end user to accept, confirm, or reject a particular change. Tasks and associated triggers are the fundamental building block of TrustBuilder.io for flows and delegation administration.

TB.Connect

The single-tenant component that is deployed close with your IT environment and that enables TrustBuilder.io to execute methods directly inside your IT environment with security under your control.

Tenant

Tenant, in general, is a term borrowed from software multi-tenant architecture. In TrustBuilder.io, a Tenant is a logically-isolated group of users who share common access with specific privileges to a single software instance. No tenant can access the data of another tenant, even though multiple tenants might be running in the same cloud.

Trigger

An event triggered by a session change, a user profile change, or policy evaluation, and that invokes one or more methods, tasks or policies. Thanks to the their event-nature, Triggers enable asynchronous No Code / Low Code workflows and delegation administration.

TrustBuilder.io

The SaaS platform provided by TrustBuilder for Identity & Access Management.

U

Universal Directory

A term often used to refer to “one place to manage all your users, groups and devices”. TrustBuilder.io provides a single user profile for every person with links to one or more accounts in various systems when needed. As such, TrustBuilder.io can be considered a Universal Directory even though it offers so much more thanks to its persona lifecycle management.

User

An entity, such as a person or an IoT device, that uses a resource, such as a back-end application, a database, a service provider, an identity provider, or a system. Also called principal.

User Account

See Account. Note that TrustBuilder.io adopts the term User Profile to avoid confusion with user accounts in various systems and to enable also IoT devices to be represented by such profile.

User Authentication

The process of verifying whether a user can prove they hold the user profile for whom tokens are requested. In contrast to Person Authentication, the process of User Authentication does not prove ‘identity’ in the broad sense: it only proves that the user holds the identified user profile.

User Identification

The process of associating a user, such as a person or an IoT device, with a registered user profile. User authentication will verify whether the association can be proven. If there was no prior registration, User Identification prepares the actual registration, which may involve person identification or federated identification.

User Migration

A process to migrate users from a directory or other IAM platform to TrustBuilder.io, e.g. using just-in-time registration.

User Profile

Represents an entity, such as a person or a device, to be the “user” of a digital service as its Digital Twin. TrustBuilder.io fosters the model whereby a user has one and only one User Profile. A User Profile, however, can contain one or more personas. A User Profile additionally contains attributes, consents and account linking information. TrustBuilder adopts the term “User Profile” as opposed to “User Account” (see here) to avoid confusion and to acknowledge that an account typically refers to transactions and are typically managed outside TrustBuilder.io. A User Profile in TrustBuilder.io can be linked to one or more accounts, one for every identity provider or service provider when needed.

User Registration

A process to create a user profile after user identification. TrustBuilder.io supports self-registration using the Self-Service Portal, manual registration by e.g. a Service Desk, programmatic registration via API, just-in-time registration and registration after federated identification. In case of self-registration, identity proofing helps to validate certain claims that the person may make about themselves.

User Session

See Session.

V

Verifiable Credential

A credential that contains assertions about an entity made by an authoritative issuer. The credential made tamper-evident and the authorship can be cryptographically verified. Verifiable Credentials Data Model v1.1 defines a standard for this. TrustBuilder.io can consume Verifiable Credentials during the user registration process, and also later during a user session as a matter of progressive profiling. TrustBuilder.io can also issue a Verifiable Presentation using Derived Attributes that are based on one or more Verifiable Credentials.

Verifiable Presentation

A set of assertions about an entity as a derivative of assertions made by an authoritative issuer. The presentation is made tamper-evident and is encoded in such a way that authorship of the data can be trusted after a process of cryptographic verification. Verifiable Credentials Data Model v1.1 defines a standard for this. TrustBuilder.io also uses OAuth2 and OIDC1 to represent this in JWT tokens. Verifiable Presentations may contain data that is synthesized from, but do not contain, the original assertions of the Verifiable Credential (for example, zero-knowledge assertions and Derived Attributes).

W

Web Components

The TrustBuilder Self-Service Portal is made of Web Components, introducing a set of web platform APIs as reusable, encapsulated HTML tags for use in web pages and web apps. The concept of Web Components is standardized by webcomponents.org - Discuss & share web components.

Workflow

A series of steps that defines a process. Each workflow starts with a single trigger, after which you must add an action, i.e. a method, a policy or a task. Actions can be chained using triggers.

WS-Fed

Web Service Federation (“WS-Fed”) is a protocol for managing user identities between systems, domains, and identity providers with established trust using WS-Trust. This protocol is mainly used for Microsoft products and defines policies on how to share federation metadata.

X

XACML3

An OASIS standard that defines a reference access and authorization architecture adopted by TrustBuilder.io and that defines a policy language also partially adopted by TrustBuilder.io. See eXtensible Access Control Markup Language (XACML) Version 3.0.

Z

Zero Knowledge Assertion

An assertion made about a user, calculated using personal data and without revealing the precise details. For example, the assertion “is adult” is a binary result using the actual birth date.

Zero Trust

A Zero Trust security model does not assume any trust in the infrastructure and grants access to resources based on the continuous evaluation of the user’s or IoT device’s identity, device posture, and fine-grained access policies. A Zero Trust model as offered by TrustBuilder.io enables strong security of cloud applications, bring-your-own-devices, remote work and ecosystem integration.