Credentials
Last updated
Was this helpful?
Last updated
Was this helpful?
You can create and sign Verifiable Credentials using Truvera API. By default, Truvera does not store the credential - only its metadata. You can choose to persist a credential, in which case we will encrypt and store the credential for later retrieval using a password. Verifiable Credentials are cryptographically secure and tamper-proof. Once issued, they cannot be edited.
Creates and issues a JSON-LD Verifiable Credential that conforms to the . The type
values and subject properties must be represented by a schema URI in the context
property. If you do not specify a context
property, the API will automatically generate an embedded JSON-LD context based on the properties within your credential. You can read more about JSON-LD and contexts .
To sign a credential, an issuer
must be supplied as either a fully qualified DID string or an object with at least an id
property which is a fully qualified DID. (e.g: did:dock:xyz
)
The issuer
property must be a DID that you control with your Truvera account.
By default, Truvera does not store the credential contents at all - only minimal credential metadata. You can choose to set the persist
value to true
and provide a password
string which will store the credential contents encrypted on our platform. The following metadata is stored on each issuance:
Credential ID property
Credential size in bytes
Issuer DID
Issuance date
Truvera credentials support using Zero Knowledge Proofs and by using the BBS2023 signing algorithm when issuing the credential. To enable this functionality, simply set the algorithm
field in the request to dockbbs
.
Truvera's API has built in credential distribution on issuance, allowing you to send credentials directly to a holder's email and/or Truvera-compatible wallet. You can achieve this by supplying the recipientEmail
field and distribute: true
in your request. For DID distribution, simply set the credentialSubject.id
property to the holder's DID.
At the moment it is not possible to add a file to the credential itself. If a credential has to have a file associated with it, the file will need to be placed in public storage and the link to that location and a hash of the content should be added to the attributes of the credential.
When you issue a credential with us, persistent or not, we will store certain metadata about the credential to make it easier for you to reference. You can pull a list of credential metadata using this route. To return the content of a persisted credential, you should use the GET /credentials/{id}
route.
When a credential has been persisted on our systems, you can fetch the credential data by supplying a credential ID and the password used at issuance to encrypt the credential.
Creates a request to gather certain claims and then issues the holder a credential after submission. The claims are user provided and type is based on the schema provided. This can be useful to catch a subject's DID without knowing it beforehand, name or other field. It should only be used when you do not already know this data or cannot find it by other means. There is a risk that a user may enter false data - so use it sparingly and not for fields that are important.
Typically, once the request has been created, you would show the holder the QR URL as an image or deep link for them to scan with a wallet and enter claims. After the holder submits the requested information the credential is automatically issued.
Lists all created request claims that are open (the holders have not submitted the requested information).
A credential can have its metadata deleted, and if persisted the contents will also be deleted. Deleting a credential will remove any reference to it and its contents from our systems. This action cannot be undone. This action will not revoke or invalidate the credential in any way.
In order to support revocation the credential must be linked to a at the time of issuance. To link the revocation registry to the credential set the status
field in the body to the registry.id
value.
Get all credential metadata
How many items to offset by for pagination
0
How many items to return at one time (max 100)
64
Filter by specific Credential ID, Subject Ref, Issuer, Type, Created Date or Issue Date
Represents metadata related to a verifiable credential. This includes information about the credential's issuer, issuance and expiration dates, revocation status, and additional properties such as size and subject reference.
Get credential metadata and contents if persistent
Valid URI
https://credentials.truvera.io/1234
The encryption password used when issuing/storing the credential
Represents metadata related to a verifiable credential. This includes information about the credential's issuer, issuance and expiration dates, revocation status, and additional properties such as size and subject reference.
Deletes all credential metadata and contents from the client. More info about Delete Credentials
Valid URI
https://credentials.truvera.io/1234
The encryption password used when issuing/storing the credential
Creates and issues a verifiable credential with supplied data. More info about Issue a Credential
Whether to store an encrypted version of this credential with us. Defaults to false, if true you must supply password.
false
Example: true
Password used to encrypt the credential if you choose to store it. The same password must be used to retrieve the credential contents. Truvera does not store this password.
securepass
Anchor the credential on the blockchain or not
false
Example: false
The credential template UUID, only required for PDF and web rendering customization
The holder's email for email distribution, optional. Not required for OpenID flows.
Optional. Specifies which signing algorithm to use to sign the issued credential. Defaults to ed25519, for ZKP credendials use dockbbs.
ed25519
Example: dockbbs
Whether to distribute the credential or not based on subject DID or email address. Not required for OpenID flows.
false
Example: false
Specifies the output format of the credential, either jsonld or jwt. Defaults to jsonld.
jsonld
Available options: Format to create credentials with the API
Whether the credential can be revoked or not. If true the revocation registry will be automatically provisioned.
false
Example: true
Verifiable (signed) Credential returned by API. The current set of properties is almost complete
Creates and issues a verifiable credential with supplied data + claims from the user.
true
https://docknetwork.github.io/vc-schemas/basic-credential.json
name
Represents the configuration and options for an OpenID issuer, including credential options, authentication provider details, and claim mappings.
Get all credential metadata
How many items to offset by for pagination
0
How many items to return at one time (max 64)
64
Represents the configuration and options for an OpenID issuer, including credential options, authentication provider details, and claim mappings.