Industry Terms

The Industry working on a convergence of industry terms between several glossary efforts, namely:

The contents herein are considered additional terms specific to IBM Security products and offerings.

If an industry term is redefined herein, this document definition supersedes all others with respect to the use and or operation of IBM's offerings.

Architecture Terms

Wallet

A software module, and optionally an associated hardware module, for securely storing and accessing Private Keys, Link Secrets, other sensitive cryptographic key material, and other Private Data used by an Entity.

A Wallet is accessed by an Agent. Wallets implement the emerging DKMS standards for interoperable decentralized cryptographic key management. The most granular decentralized identity architecture component.

Agent

The actual resource being created within the process that is tied to a wallet. This process manages a wallet (containing pairwise connection and credential artifacts), accesses ledgers, and generally does everything needed to manage connections, issuance, verification, etc.

There can be many agents within an Account. Agent software may reside on an edge device or in the Cloud. Agent software acts behalf of an Entity to interact with other Agents or with public identity utilities. Agents are of two types:

  • Edge Agents run at the edge of the network on a local device
  • Cloud Agents run remotely on a server or cloud hosting service.

Agents require access to a Wallet in order to perform cryptographic operations on behalf of the Entity they represent.

Account

Hierarchical mapping of an entity to unique wallet instances.

Client abstraction that allows for grouping of agents and can span across multiple processes.

lib-agency

The IBM Security asset responsible for abstracting API calls into both Hyperledger Aries and Hyperledger Indy SDKs.

Written in typescript, this software component can be used on edge and cloud devices, by mobile and web apps, respectively.

Kubernetes Cluster

A set of worker machines, called Kubernetes Nodes, that run containerized applications.

Every cluster has at least one Kubernetes Node, which hosts Kubernetes PODs that are the components of the application workload. A cluster usually runs multiple nodes, providing fault-tolerance and high availability.

Contains an Application Load Balancer (ALB).

Kubernetes Deployment/Namespace

Maps of deployment infrastructure to DB configuration.

Agency Process

A long-running instance of lib-agency software.

Compute process that runs indy-sdk, wallets, etc. An OpenId Connect Relying Party. Supports namespace and volume separation within a Kubernetes Cluster.

Indy SDK

Hyperledger Indy.

Open source protocols invoked to perform decentralized identity actions (wallet, keys, messaging, issue/verify, etc).

Kubernetes Pod

A Pod is associated with a single agency process.

Provides isolation of running Indy SDK instance.

Kubernetes Node

Compute capacity required to run and host software programs

Contains multiple Pods and can span multiple namespaces.

Postgres

The DB that is shared across multiple accounts, isolated by tables.

Holds connections, credentials, and other meta data. The storage of data for agents.

Database Process

Compute process that runs Postgres.

Agent meta data

Meta data associated with each wallet instance.

Domain

A group of agents which function on behalf of a single identity.

Alice may have a cloud agent and an edge agent for each of her devices).

Agency

A service provider that hosts Cloud Agents and may provision Edge Agents on behalf of Entities.

Agencies may be Unaccredited, Self-Certified, or Accredited.

Agency Lifecycle Manager (ALM)

Supports varying levels of sharing verses isolation between accounts at cluster, namespace, and process boundaries.

An account consists of multiple wallets in a Postgres DB. Some wallets have active agents and others do not.

An agent may be active or inactive based on traffic. Activating an agent requires simply opening the wallet associated with the agent.

Account Wallet

The storage object in the Database Process that manages the Wallets for a specific Account.

Agent that is in-process due to some type of activity within an Active Account.

Active Account

An Account that is in-process due to some type of activity by the identity owner.

This active compute process is bound to an Account Wallet.

Example activity types include but are not limited to:

  • Sign-in * *

Agent Wallet

The storage object in the Database Process that manages the Wallet for a specific Active Agent.

Agent that is in-process due to some type of activity within an Active Account.

Active Agent

An Agent that is in-process due to some type of activity within an Active Account.

This active compute process is bound to an Agent Wallet.

Example activity types include but are not limited to:

  • Sign-in * *

In-Active Agent

An Agent that is not bound to an Active Account.

Inactivity is trigger by identity owner actions such as:

  • Log-out
  • Time-out (xxx seconds) *

Agent Pool Size

The total available Agents (Active and In-Active) across all Kubernetes Node within an Agency Process.

Sometimes this may be referred to as Total Agents.

IBM Verify Credentials Terms

Agency Domain Name

The domain name for a specific deployment of agency software.

IBM may manage several agency environments both publicly and privately. For example:

Environment Domain Name
2019 Technology Preview (Developer's Sandbox) agency.verify-creds.com
2020 Technology Preview (Developer's Sandbox) agency.ibmsecurity.verify-creds.com

Account Name

An account on our Public Agency Offering as represented by an IBM ID.

The account name is just simply the email address tied to an IBM ID. There can be “n” agents to a single Account.

Account URL

The URL that is associated with an account on our public agency.

The syntax by example is as follows:

* Syntax: <Account_URL>
* Example: https://<agency-domain-name>

Agent Name

The unique name of a Cloud Agent within a customers IBM ID (Account Name).

* Syntax: <agent_name>
* Example: 87htR2TT596948373RR739434033

Agent URL

The unique url that can access a specific Agent within a user's Agency Account.

* Syntax: <username>:<password>@<Account_URL>
* Example: https://thrift:@<agent_name>.verify-creds.com

Agent Login URL

The unique url that can access a specific Agent within a user's Agency Account.

This URL always requires a username and may require a password.

* Syntax: <agent_name>:<password>@<Account_URL>
* Example: https://thrift:@87htR2TT596948373RR739434033.verify-creds.com

Notification Email

An email address used for an introductory email.

Since this email contains a link that can be used to download the Mobile App, it would be convenient if this email is accessible on the device that is going to be used by the Mobile App.

IBM Verify Credentials Agency

IBM's offering suite for the lifecycle management of digital credentials within a decentralized identity ecosystem.

The agency component is a cloud-based solution that manages entity accounts which contain one or more agents. Agent code resides on one or more edge (device) layers that are associated with a cloud agent (cloud layer). Cloud and edge layers are comprised of agent software that manages the endpoint user experience (UX) and functional control plus wallet software that manages local storage. The cloud layer portion of an individual or organization is hosted by an agency.

Identity Reader

A physical or programmatic device that understands how to process information contained within an identity instrument.

Traditional readers, like a hand-held scanner, interpret machine readable data formats available on a physical identity instrument like barcodes or QR codes. Emerging readers (or digital readers) focus on the programmatic processing of a digital identity instrument using peer-to-peer communications in a manner that assures privacy as well as document validity. These readers can be described as mobile applications that reside on a device that can communicate with an identity instrument. Unlike traditional readers, these emerging readers specialize in the processing of a digital representation of an identity instrument. These readers represent the whitespace area where standards are lacking. Since the digital identification industry is still emerging there will be a timeframe where interoperability between the possible digital representations is a challenge.

Institution

An entity (organization or company) that provides Verification Documents to Verifiers and Identity Documents to Owners.

An Institution defines Document Types that represent identity information. An Owner uses Institution services to register for Identity Documents that are provided by an authorizing Institution. Potential Institutions include a Department of Motor Vehicles providing driver’s licenses, a retail chain providing a rewards card, and a university providing student identification cards.

An Institution defines Roles that represent verification information. A Verifier uses Institution services to register for Verification Documents that are provided by an authorizing Institution. Potential Institutions include a Department of Motor Vehicles providing law enforcement officer roles, a retail chain providing a cashier role, and a university providing an examination proctor role.

Owner

An individual that holds one or more digital credentials from one or more Institutions.

An Owner is also referred to as a Holder.

Role

An abstract definition of a Verification Document.

A Role, like a Document Type, is a collection of identity characteristics. In the case of a Role, however, the set of characteristics serves as a list of data that the Institution has authorized each of their Verifiers carrying an instance of that Role to collect from an Owner.

A Role must specify:

  • Name - a name to identify the Role (e.g. “Traffic Officer”)
  • URL - address of the Issuer Server that provides methods (e.g. web services) to a Verifier to create an instance of the Role

Trait

A key-value pair corresponding to an individual characteristic of identity data.

Often referred to as Identity Traits or Attributes. These are the most granular identifying descriptors of personal data for an entity. These Trait collectively form the properties about a digital credential when used in a Schema. Traits can pertain to physical as well as assigned data characteristics. For example, a Trait can corresponds to a characteristic of identity such as name, appearance, or account number. Traits and their values can be viewed by Owners reviewing their digital credentials, and by a Verifier during the Verification Process.

Verification Process

The process whereby a Verifier uses the Mobile Identity Verifier Application to digitally request Verification of the identity of an Owner who has installed the Mobile Identity Owner Application.

The Verification Process is initiated by a Verifier to securely view identity characteristics of an Owner in order to verify his access to services protected by the Verifier. Examples include a police officer verifying a driver’s identity during a traffic stop or a university proctor verifying student identities prior to an exam. The Verifier initiates a Verification Request by selecting which Traits are needed for identity verification. The Owner is prompted to approve the request for access to the Traits. The selected Traits are then sent by a cryptographically secure transmission to the Verifier. The Verifier can then validate the information, completing the Verification Process.

A Verifier may have Verification Documents that indicate they have been granted permission to access information which may be considered private by the Institution. The Owner can determine at the time of the Verification Request whether or not to release this information.