PingOne Platform APIs

Credential Issuers

Use the Credential Issuers operations to retrieve or update the credential issuer information. A default credential issuer profile, which enables issuance of credentials, is automatically created when the credential service is added to an environment.

Credential Issuers data model

Property Type Required? Mutable? Description

applicationInstance.id

String

N/A

Read-only

Identifier (UUID) of the application instance registered with the PingOne platform service. This enables the client to send messages to the service.

credentialSigning

Object

Optional

Mutable

Object with the configuration for sending verifiable credentials (VC-JWT or SD-JWT) to the customer’s remote signing service at credentialSigning.url for signing with their private key.

credentialSigning.url

String

Required

Mutable

URL to which to send verifiable credentials (VC-JWT or SD-JWT) for signing with their private key. Must be a valid URL with a protocol of HTTPS.

credentialSigning.headers

Object

Optional

Mutable

Object of headers as key-value pairs, where the key is the name of a header field and the value is the value of the header field, to send with the verifiable credentials (VC-JWT or SD-JWT) for signing.

credentialSigning.headers.<field>

String

Required

Mutable

The placeholder, <field>, is the name of the header field to add to the request. The value assigned to this becomes the value of the header field created.

createdAt

DateTime

N/A

Read-only

Date and time the issuer profile was created.

did.method

String

Optional

Mutable

Decentralized Identifier (DID) method for the issuer. Can be WEB or WEBVH. Initially set to WEB. Refer to DID WEBVH (did:webvh).

did.value

String

N/A

Read-only

The entity that controls the DID in DID Syntax. In PingOne Credentials, the method-specific data is always equal to the domain part of the request URL

did.web.host

String

N/A

Read-only

The hosting provider; always "PING"

did.web.useCustomDomain

Boolean

Optional

Mutable

Whether or not the credential issuer uses its custom domain in its DID when the issuer has Custom Domains enabled. Defaults to true and uses the custom domain, whereas false uses auth.pingone.com

id

String

N/A

Read-only

Identifier (UUID) of the credential issuer.

logo

String

Optional

Mutable

A URI containing the logo for the issuer. Restricted to a valid URL with a scheme of https: or a scheme of data: with a base64-encoded image. Included in credentials issued.

name

String

Required

Immutable

The name of the credential issuer. Included in credentials issued.

siteUrl

String

Optional

Mutable

URL, chosen by the issuer, that references the issuer in issued credentials.

updatedAt

DateTime

N/A

Read-only

Date and time the credential issuer profile was last updated; can be null.

In the credentialSigning object, the credentialSigning.headers object defines headers to add to the signing request sent to the customer’s credentialSigning.url. For example:

    "headers": {
        "ClientID": "016e1474-7c62-b944-0a96-b467731ef0bd"
    }

Creates a header on the signing request such as:

ClientID: 016e1474-7c62-b944-0a96-b467731ef0bd

The logo and name can be shown to the user when indicating the credential issuer by the wallet app using using the PingOne Neo Native SDKs with getIssuerMetadata for Android and getCredentialIssuerMetadataFromClaim(_:) for iOS.

DID WEBVH (did:webvh)

The WEBVH DID method, where VH stands for Verifiable History, extends did:web. It maintains simple domain-to-DID resolution (via HTTPS) of did:web while adding a cryptographically verifiable history to the DID without blockchains or ledgers. The Verifiable History records all changes (DID Document versions) in a JSON Lines log (did.jsonl), chained via hashes and signed proofs, allowing anyone to verify the full lifecycle from creation to deactivation. A unique, history-bound identifier, called a Self-Certifying Identifier (SCID), derived from the first DID log entry ensures tamper-resistance and enables portability. The SCID appears between did:webvh and the domain in the DID identifier. For example:

  1. The DID of an issuer hosted on the standard auth.pingone.com domain is in the format:

    • did:webvh:

    • SCID of the did:webvh

    • auth.pingone.com:

    • UUID of the issuer’s environment

    • #

    • UUID of the signing key

  2. The DID of an issuer hosted on a custom domain is in the format:

    • did:webvh:

    • SCID of the did:webvh

    • :

    • issuer’s custom domain

    • #

    • UUID of the signing key

The shortcoming of did:webvh is that it is not as widely accepted by verifiers as did:web.

Response codes

Code Message

200

Successful operation.

400

The request could not be completed.

401

You do not have access to this resource.

403

You do not have permissions or are not licensed to make this request.

404

The requested resource was not found.

500

Unexpected server error.