Back to All

What do issuers do?

As mentioned before, all functionalities in the Issuer API can be categorised into DID issuance and management and Verifiable credential issuance and management. Below there’s a description of all functionalities and features.

DID’s features

So... What is a DID?

DiD, as mentioned before, stands for Decentralised Identifier. nChain Identity follows the World Wide Web Consortium’s Decentralized Identifier (DID) Standards. Decentralized Identifiers (DIDs) serve as unique identifiers globally, comprising an alphanumeric sequence functioning as an identifiable marker on a blockchain for any entity—whether a verifier, issuer, or holder—the Decentralized Identity (DiD) represents a unified subject. The actions you undertake with it, such as issuance or presentation, are contingent on your role within the ecosystem. DIDs enable the digital signing and issuance of Verifiable Credentials, such as educational certificates, facilitating instant credential verification.

DIDs encompass cryptographic key pairs and remain entirely within your control. Historically, our predominant means of accessing websites, apps, and services involved centralized identifiers like emails, usernames, and passwords. With a DID, online identity verification becomes feasible without sharing unnecessary information with websites or applications— imaging a digital version of a driver's license that can only be used by the person it's issued to.

  • User (individual or organization) autonomy for creation and management, without reliance on any external entity.

  • Empower owners to assert control over them securely.

  • It is detached from personal data or wallet information.

How does nChain Identity assign DiDs?

  • For Issuers: Issuers get their DiDs by creating an account on our Product Suite Platform. This unique DiD allows secure interactions within the decentralized identity framework. Issuers can also link verifiable proofs, like KYC/KYB processes, to their DiD using the nChain Identity system's DiD controller module, ensuring a secure and auditable identity verification record.

  • For Verifiers: Verifiers complete a simple DiD assignment by creating an account. This grants each verifier a unique identifier. The system enables verifiers to link proofs of their verification activities, improving transparency and trust. The nChain Identity system's DiD controller module makes this process secure, maintaining a reliable record of verification processes.

  • For Subjects: Individuals in the nChain Identity ecosystem access DiDs through their wallets. When downloading the wallet and creating an account, the wallet requests a DiD. Verification and proof of claims and attributes are provided to the holder by assigning Verifiable Credentials (V.C.) to the given DiD. V.Cs are held securely in the wallet, ensuring a streamlined and secure management of identity-related information.

What can issuers do with DiDs?

  • Create DID/DID Document

    • Anyone can view the published DID on the blockchain.

    • DID has no Personal information (PII), so it can never be associated with any individual or entity.

    • DID are generated by the DID Subject or DID controller.

  • Issuance of a DID document for a given DID published on blockchain as a data registry.

    • DID Controller will construct the DID document based on the keys provided to them by the DID Subject.

    • DID Document properties will be a template that will be standardised based on the use case. In MVP, this will issue a pseudonymous DID for a given public key.

    • The public keys associated with the DID of the DID subject and DID Controller are published in the DID Document.

    • The Authentication method will contain the required algorithm for generating a public key, including any encoding done.

    • The verification method shall describe the process and the endpoint of the DID Controller, which a verifier can use to authenticate the identity stored with the DID Controller.

  • Check the Status of DID

    • An entity can check the status of DID directly on the blockchain.

    • Check the DID and take the UTXO Tx value present in the DID.

    • Use a blockchain node API / Explorer to view transactions (TX).

    • Find the output and the Tx spending this output. That TX shall contain the DID Document.

    • If the status of the TX is unspent (output which contains DID Document), the status is valid.

    • This could be run at DID Subject wallet, Verifier wallet, chain’s service or DID Controller's service.

  • Resolve DID

    • Resolve DID Document to verify the Identity of a DID Subject.

    • Perform Check status of DID steps to access DID Document from TX1

    • Get the Public key information from the DID Document

    • Get DID Controller/Controller location/endpoints and public key.

    • Send encrypted message (DID Subject's presented PII) to DID Controller to verify identity.

    • Get a response from the DID Controller, and respond to the DID Subject based on this response.

  • Update DID

    • Update DID keys will involve the creation of a new DID (initiated by the DID Subject or DID Controller)

      • The current UTXO (Tx1) was spent to create a new Tx (Tx2) containing a new DID document with new DID Subject keys.

  • Revoke DID

    • Revocation can be done either by the DID Subject or the DID Controller

    • DID Subject creates a new transaction by spending the DID.

    • Document UTXO (Tx1) without any information in the spending Tx

    • DID Controller creates a new transaction by spending the DID Document UTXO (Tx1) without any information in the spending Tx.

Verifiable Credential’s features

What is a Verifiable Credential?

Verifiable Credentials (VCs) represent secure, digital versions of both traditional and digital credentials, providing cryptographic assurance about aspects of oneself, such as identity or earned qualifications. These credentials can be presented to organizations for trustworthy verification, envisioning digital and instantly confirmable renditions of identity papers, academic accomplishments, licenses, and more. Entities can issue their degrees, IDs, licenses, and other credentials in a verifiable digital format, which can be stored in the nChain identity wallet. Like a mobile application, this wallet allows individuals to carry it on their phone, computer, or even on a cloud-based server.

Organizations depend on tangible credentials such as employee badges, certifications, and passports to establish identities and confirm details like age for entry into venues like nightclubs or proof of academic achievements. However, with the increasing digitization of information, individuals engage with numerous online businesses. The broader challenge is how individuals and organizations can trust the authenticity of those they interact with in a digital environment. The critical issue extends beyond merely verifying digital documents; it encompasses establishing a reliable means for ascertaining the genuineness of identities and assertions in the digital realm. Without the ability to discern between authentic and counterfeit digital assets, organizations face potential liabilities, including the risk of hiring unqualified individuals. Verifiable credentials emerge as a crucial solution, providing a trustworthy method for individuals and organizations to securely establish and share their identities and assertions in the digital landscape.

What can issuers do with VCs?

nChain identity Issuers API is integrated with the nChain Identity wallet through the Sphereon SSI SDK, an open-source SDK to build SSI and Verifiable Credential applications. Sphereon SDK is based on the great work done by Veramo and on the open W3C standards specifications for decentralized identities (DID) and verifiable credentials (VC). This implementation uses OID4VC. The nChain Identity Issuers API allows users to:

  • Issue a Verifiable Credential

  • Revoke a Verifiable Credential

Schemas

A schema defines the structure and constraints of the data format used for Verifiable Credentials. It specifies the allowed properties, their data types, and validation rules. In V.C., the format chosen to support that data is JSON schemas. Consensus for the data structure is crucial for ensuring consistency and interoperability in exchanging verifiable credentials, as they serve as a blueprint for the expected data format. A JSON schema outlines the rules that data must follow to be considered valid within the verifiable credential ecosystem. Here is an example of the information that a Verifiable Credential Schema contains in simple words.

  • Context: Defines the context for the verifiable credential, including credential-related and example-specific namespaces.

  • ID: Uniquely identifies the verifiable credential, in this case, representing a credential from a university.

  • Type: Indicates the type of the credential, specifying that it is a VerifiableCredential and an ExampleAlumniCredential.

  • Issuer: Specifies the entity (in this case, a university) that issued the verifiable credential.

  • Valid From: Indicates the timestamp from which the verifiable credential is considered valid.

  • Credential Subject: Represents the primary entity to which the credential is associated, providing an identifier (DID) and information about their alumni status.

  • ID: The Decentralized Identifier (DID) of the credential subject.

  • Alumni Of: Contains information about the entity (For example, University) to which the subject is an alumnus or alumna.

Let’s use it in an example: This completion adds information about a fictional student named Alice Doe, including her student ID, enrollment status, and expected graduation date.

// {
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "http://university.example/credentials/1872",
  "type": ["VerifiableCredential", "ExampleAlumniCredential"],
  "issuer": "https://university.example/issuers/565049",
  "validFrom": "2010-01-01T19:23:24Z",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "alumniOf": {
      "id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
      "name": "Example University"
    }
  },
  "studentName": "Alice Doe",
  "studentID": "123456789",
  "enrollmentStatus": "Enrolled",
  "graduationDate": "2023-05-15"
}

Schema data contains the following information:

  • Student Name: "Alice Doe"

  • Student ID: "123456789"

  • Enrolment Status: "Enrolled”.

  • Graduation Date: "2023-05-15"

What Schemes does nChain Identity support currently?

Currently, nChain Identity supports Know Your Customer (KYC) data schemas with the following attributes:

  • Full Name

  • Date of Birth

  • Address

  • Nationality

  • Identity Document

  • Photograph

  • Contact Information

  • Occupation

  • Source of Funds

  • Tax Identification Number (TIN)

  • Proof of Address

  • Biometric Data

Providing essential information for identity verification, we're actively enhancing our support by making KYC data schemas fully customizable. We aim to accommodate a broader range of attributes, ensuring our platform meets diverse identity verification requirements. This ongoing development reflects our commitment to delivering a robust and adaptable solution for identity management within the nChain Identity ecosystem.

PreviousOperating an issuerNextIssuer API

Last updated