The three parties that enable decentralized identity are:

Issuer
The proprietor and issuer of official sources of data, such as college transcripts, vaccination status, or employment history.
Verifier
Any individual or institution (service provider) with which a user chooses to share data that requires verification, such as sharing a driver license as proof of age or credit card information when applying for a loan.
User
An individual who matches the issuance rule of a group, population, or SCIM filter with a PingOne Credentials profile. Users can receive credentials from issuers, store them securely in their compatible wallet app, and use it to share their credentials with verifiers.

Illustration showing examples of issues, such as universities, credit bureaus, and vaccine providers, verifiers, such as businesses, healthcare providers, and other individuals, with the user at the center, using the compatible wallet app to receive credentials from issuers, store them securely in the wallet app, and share details with verifiers.

Issuers and verifiers can be any entity that the user engages with, such as a university, an insurance company, employer, health provider, or a financial institution.

Users that need to receive or provide proof of a credential to these institutions might already have a record of their activity with that institution, which won’t change. However, if the user needs to share that record with another entity, traditionally they must allow the other entity (a verifier) to contact the original institution (the issuer) to get the information and confirm that it’s valid. This can be cumbersome, expensive, and time-consuming and could violate the user’s privacy if not managed properly.

Using decentralized identity, it’s possible for an issuer, such as a university or employer, to provide a verifiable credential about the user’s qualifications or employment to the user in the form of a digital credential that the user can store in their compatible wallet app. Because the credential is always with the user, the user can share that information with the new business to seek employment. The potential employer can verify the data for its authenticity in real-time without contacting the issuer, so there's no further friction or exposure of privacy.

The issuer creates a credential in PingOne Credentials using the automated issuance rules that automatically issues a verifiable credential to all users who match a provided filter. The filter is based on Groups, Populations, or a SCIM filter. The issuer can also define individual fields on the credential in the form of key-value pairs to provide the appropriate details for the service credential they are offering to their users.

Credential details will vary according to the industry and the specific credentials the issuer wants to offer. For example, in addition to name and date of birth, an insurance company might want to provide the type of insurance, policy number, and expiry date. A bank might want to include the bank account number and date of issue, and a university might want to include the type of degree obtained.


Screen capture showing an example of a credential for a finance company.

The PingOne Credentials service maintains a unique private-key for each issuer within the PingOne environment. It uses the PingOne Neo SDK to allow creation of verifiable credentials in the backend.

To simplify the creation and issuance of credentials, PingOne Credentials wraps the API calls in a more consumable and user-friendly interface within the PingOne administrative console. This service also provides APIs that allow customers to interact programmatically and with additional customizations.

Credentials issued by this service can be shared:

  • With other users through a compatible wallet app
  • With custom QR codes that can be generated with the API calls

The following diagram shows examples of three different issuers, providing credentials to an individual user and the various ways a user can provide information to verifiers using these credentials:

  • A medical provider issues a primary provider credential that includes details of the provider, date of last vaccination, and personal medical details. The user stores the certificate as a credential in their compatible wallet app. When a blood drive event requests proof of a primary care provider, the user can send it to them without providing all of the personal details it contains.
  • A car insurer provides an insurance policy as a credential to a user. Credentials might include the user's ID, date of birth, and medical status, but when a car rental service asks for the user's insurance policy, the user can share just the policy number and expiry date.
  • A university provides a degree certificate as a credential to the user. The user stores the credential in their compatible wallet app. The user can provide a potential employer with the full degree certificate (as well as any other qualifications their wallet app holds) immediately.

    Illustration showing examples of issuers, verifiers and user's digital wallet app.

PingOne Credentials, along with a compatible wallet app, makes this verifiable exchange of data possible. You can use PingOne Credentials through the PingOne unified administrative console or through its API.