Industry Terms

The Sovrin Foundation publishes and maintains a glossary of industry terms. IBM products and offerings build on these industry concepts.

IBM Verify Credentials Terms

Agency Domain Name

Our fixed domain name for our Alpha K8 Cluster.

For example:

Account Name

An account on our Public Agency Offering as represented buy an IBMid. Since IBMid equates to an email address, we can not use that in a URL. As such our Agency Offering will keep a database that maps IBMid to an Account Name. The Account Name should be alphanumeric and can be autogenerated. We have decided that we will use the MD5 Hash of the IBMid for this autogenerated Account Name. This implies we do not need to ask for this data element on the REGISTER ACCOUNT FORM. There can be “n”agents to a single Account.

Account URL

The URL that is assigned to an account on our Public Agency and associated with a single IBMid. The syntax by example is as follows:

  • https://<account_name>.<agency-domain-name>
  • https://<account_name>.<alpha-domain-name>

Agent Name

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

Agent URL

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

* Syntax: <agent_name>:@<Account_URL>
* Example: ``````

#### Agent Login URL
*The unique url that can access a specific Agent within a user's Agecy Account.*

  • Syntax: :@
  • Example: ```

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

An identity reader can be 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.


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.


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

An Owner is also referred to as a Holder.


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


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.