Verifiable credentials (or VCs) are a standard format for the digital representation of credentials (documents that collect attributes about a subject) that are cryptographically secure, verifiable through machines, and that guarantee privacy by enabling methods such as minimum disclosure.
VCs can be used to describe identity credentials, such as academic diplomas, driver's licenses, passports, insurance cards, vaccination records (and so much more).
With Gataca Studio, create, validate, and digitally sign identity credentials according to W3C standards for global interoperability. To ensure credentials are shared and interpreted correctly, each of these credentials requires a template.
You can easily create credential issuance templates to be implemented in your website and enjoy the flexibility of choosing the type of credential to issue, the information it will contain, as well as when to revoke it.
Below you can see the step-by-step tutorial on how to issue your first credential.
1. Create an Issuance Template
The issuance template is used to verify user information for the issuance of credentials.
When accessing Gataca Studio, you can create a new issuance template from the main dashboard or click "Create issuance template " in the issuance templates section.
Issuance ID - Name the issuance template
The first step is to select your issuance template name (Issuance template identifier).
This name will be associated with the issuance process for users and will also serve as a reference to the credential the user is requesting when interacting with your platform.
Example:
General configuration
Requester DID
In some cases, you may need to create a DID first (See the tutorial on creating DIDs).
Verifiable Credentials are associated with a specific DID as the owner or holder of that credential. In an SSI ecosystem, Issuers, Users, and Verifiers are all represented by one or more DIDs. As an issuer, you will have to select the DID you want to associate with this credential.
Example:
Select DID method
This field specifies how to deal with this DID. Computers understand where to fetch the DID when reading this part of the DID. For example, GATACA's DID method is denominated "gatc"
You can select between two different DID methods:
EBSI https://ec.europa.eu/digital-building-blocks/wikis/display/EBSIDOC/EBSI+DID+Method
GATACA https://github.com/gataca-io/gataca-did-method
Example:
QR Code viewing duration - How much time should the user view the QR code?
Amount of time that the user has to scan the QR Code, in seconds.
Usually between one and two seconds.
Example:
Consent duration - How much time should my company store and process data shared by users?
Amount of time your company has to store and process data shared by users in days.
According to the GDPR, the storage limitation principles state that you should keep personal data for as long as the purpose is unfulfilled. Once the data has served its purpose, you should then delete it.
However, this goes beyond data just serving its purpose. If you are collecting data and it is just sitting around, you will need to consider deleting it and stop any further collection of that specific data category.
Please check with your corresponding data privacy regulations if your organization is outside the EU.
Example:
Callback
URL of a service that is notified by a post notification with the session data when the session has been validated.
Example:
Service description - What to include in the service description?
Include briefly all relevant information about the service associated with the verifiable credential.
Example:
Issuance
Credential Types - How to select the credential type to be issued?
All verifiable credentials must declare their type in their template. The credential type distinguishes a verifiable credentials structure from other credentials and it ensures interoperability between issuers and verifiers.
Gataca Studio covers a great number of credential types. Depending on the service you provide, select the most appropriate one.
Example:
Credential Attributes - What credential attributes should be included?
Credential attributes are stored in the authorization credential of a user. These attributes contain information about the identity and authorization capability of the subject of the credential.
Select which attributes or information will be contained in the credential that you will be issuing.
Example:
Credential Issuance Requirements
Credentials requested - What credentials should I request from the user?
Establish the data you will be requesting from your users in order to issue the credential.
This data must be necessary for you to verify your user before issuing the credential.
Scroll the list and tick those you want to select, or use the search bar.
Example:
How to select required credentials and optional credentials
From the list of credentials, you will be requesting, select those that will be required or will remain optional.
Required credentials mean that the information is critical to fulfilling the credential issuance. Any other “nice to have“ information should be marked as optional.
Example:
Restrictions
Credentials trust level - How to determine which credentials are trusted?
In this section, you will determine the level of trust you require from the requested credentials.
What does this mean?
Purpose of credentials requested - How to select the credential purpose
In this section, you will determine the reason why you are requesting the previously established credentials from your users. This will be shown to your users.
Explain list
How to create a custom purpose
Security configuration
Add app authentication
Add two-factor authentication