> For the complete documentation index, see [llms.txt](https://docs.1kosmos.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.1kosmos.com/identity-verification/verifiable-credentials/overview.md). # Overview *** ### Fundamentals of Verifiable Credentials A credential is any document that details a qualification, competence, or authority issued to an individual by a third party with the relevant authority to do so. Because credentials are typically issued by authorities that hold the public's trust, they are often used to support proof of an individual's qualification or competence for a given subject. #### Credentials in the Real World In the physical world, a credential might consist of: * Information identifying the **subject** of the credential (for example, a photo, name, or identification number) * Information related to the issuing authority (for example, a city government, national agency, or certification body) * Information related to the type of credential (for example, a Dutch passport, an American driving license, or a health insurance card) * Information related to specific attributes or properties being asserted by the issuing authority about the subject (for example, nationality, the classes of vehicle entitled to drive, or date of birth) * Evidence related to how the credential was derived * Information related to constraints on the credential (for example, expiration date or terms of use) A **verifiable credential** can represent all of the same information that a physical credential represents. The addition of technologies such as digital signatures makes verifiable credentials more tamper-evident and more trustworthy than their physical counterparts. #### Why Are Verifiable Credentials Needed? It is currently difficult to express education qualifications, healthcare data, financial account details, and other third-party verified, machine-readable personal information on the Web. This difficulty makes it challenging to receive the same benefits through the Web that physical credentials provide in the physical world. The VC specification provides a standard way to express credentials on the Web in a way that is cryptographically secure, privacy respecting, and machine-verifiable. #### An Emerging Standard Verifiable credentials allow for the digital proofing of user claims data through public-private cryptography, privacy-preserving, and semantic disambiguation techniques. The **VCs Data Model**, defined at the [W3C](https://www.w3.org/), is a universal data format that lets any entity express anything about another entity. It provides a common mechanism for the interoperable implementation of digital credentials that are cryptographically secure, tamper-evident, privacy respecting, and machine-verifiable. A common standardized data model enables standardized credential packaging, cryptographic signing, and proof expression, creating a VC ecosystem with interoperable credentials that can be processed and understood across disparate systems. #### Ecosystem Overview The key actors in an ecosystem where verifiable credentials are used: | Role | Description | | ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Holder** | A role an entity performs by possessing one or more verifiable credentials and generating verifiable presentations from them. Example holders include students, employees, and customers. | | **Issuer** | A role an entity performs by asserting claims about one or more subjects, creating a verifiable credential from these claims, and transmitting it to a holder. Example issuers include corporations, non-profit organizations, trade associations, governments, and individuals. | | **Subject** | An entity about which claims are made. Example subjects include human beings, animals, and things. In many cases the holder of a verifiable credential is the subject, but not always — for example, a parent (the holder) might hold the verifiable credentials of a child (the subject). | | **Verifier** | A role an entity performs by receiving one or more verifiable credentials, optionally inside a verifiable presentation, for processing. Example verifiers include employers, security personnel, and websites. | | **Verifiable Data Registry** | A role a system performs by mediating the creation and verification of identifiers, keys, and other relevant data — such as verifiable credential schemas, revocation registries, and issuer public keys. Examples include trusted databases, decentralized databases, government ID databases, and distributed ledgers. | #### Issuing and Verifying Credentials There are four roles supported by verifiable credentials — **Issuer**, **Verifier**, **Subject**, and **Holder**: * **Issuer** — The entity that creates a claim and associates it with a particular subject. * **Verifier** — The entity verifying a claim about a given subject. * **Subject** — The entity about whom a claim is issued. * **Holder** — A role an entity may perform by possessing one or more verifiable credentials. A holder is usually, but not always, the subject of the verifiable credentials they hold. Holders store their credentials in credential repositories. #### Tasks Users of verifiable credentials have common needs across domains. Examples of tasks that issuing authorities, holders, and verifiers might perform include: * Issuing a claim * Asserting a claim * Verifying a claim * Storing or moving a claim * Retrieving a claim * Revoking a claim *** ### Verifiable Credentials Use Cases #### Multi-Domain Use Case Map Use cases for verifiable credentials can span several key domains: * Education * Retail * Finance * Healthcare * Professional Credentials * Legal Identity * Devices #### Finance **Reuse KYC and Anti-Money Laundering** Consider the following scenario: a woman wishes to open an account at a bank, and as part of that process the bank asks her to provide two sources of ID to confirm her identity — the "Know Your Customer" (KYC) check. She selects government-supplied verifiable credentials to ensure she receives mail at a specific address where she has a national ID card. These government-issued documents help the bank confirm her identity, and an account is opened for her. The bank then issues her a digitally-signed credential for her account. This credential verifies that the user: 1. Has an account at the bank and sufficient permission to access the account. 2. Has completed a KYC check. Furthermore, the issued credential may also be used as sufficient verification by other financial institutions. It assures other banks that the user is verified, alleviating concerns about misdirected transactions and money laundering. **Money Transfer** A user with a bank account at one financial institution wants to send funds to his family in another country via a money transfer service. He has verifiable credentials in his credential repository that can be used to share his identity profile, as well as a credential from his family verifying the destination bank account. By sharing these verified credentials with the money transfer service, both the source and the destination of funds can be verified. This adds confidence to the delivery of the funds and meets the regulatory requirements to prevent money laundering. #### Education In this scenario, the VC issuer is an educational institution that issues a VC representing the completion of degree requirements to graduating students. The institution decides what information should be packaged in the credential, and attributes will have values expressed. **Student Requesting a Digital Transcript** A university issuing an "extended transcript" that includes course grades could, upon the request of students, issue a digital credential representing the degree awarded to the student. Examples of what might be in such a credential: * First Name * Last Name * Degree Type * Date of Issue **Student Transferring Claims from School to Bank** Students in schools that offer a credential repository service to all students and alumni could use another entity — such as a bank offering a similar service — to move their claims to the service provided by the bank, without needing to have them reissued by the school. *** ### Verifiable Credentials Data Model #### Zero-Knowledge Proof A Zero-Knowledge Proof is a method of authentication that, through the use of cryptography, allows one entity to prove to another that they know certain information or meet a specific requirement without disclosing any of the factual information that supports that proof. The entity that verifies the proof has "zero knowledge" about the data supporting the proof but is "convinced" of its validity. This is especially useful where the prover entity does not trust the verifying entity but still has to prove that it knows specific information. #### Derived Credentials and Credential Presentations A derived credential is an assertion about the value of another attribute (or set of attributes) in a verifiable credential. Derived credentials are valuable in zero-knowledge-proof-style verifiable presentations because they can limit information disclosure. For example, suppose a verifiable credential contains an attribute expressing a specific height in centimeters. A derived predicate might reference the height attribute in the verifiable credential, demonstrating that the issuer attests to a height value meeting the minimum height requirement — without actually disclosing the specific height value (for example, the subject is taller than 5 feet). A subset of one or more verifiable credentials can make up the presentation. #### Metadata Cryptographically signed by the issuer. As described in the W3C standard [Verifiable Credentials Data Model v1.1](https://www.w3.org/TR/vc-data-model/), metadata "describes properties of the credential, such as the issuer, the expiry date and time, a representative image, a public key to use for verification purposes, the revocation mechanism, and so on." #### Claims A statement made about a subject. Example: *"John Doe's date of birth is 01/01/1990."* #### Proofs A proof is data about yourself (the identity holder) that allows others to verify the source of the data (the issuer), check that the data belongs to you and only you, confirm that the data has not been tampered with, and finally confirm that the issuer has not revoked the data. *** ### 1Kosmos's Implementation of Verifiable Credentials #### Lifecycle * Issuers issue credentials to users. * Users are holders of a verifiable credential. * Holders may present the verifiable credential to an entity. * The entity may request verification of the presented credential. * The verifier confirms the validity of the presented credential with the requesting entity. #### Issuance Portal The order of operations remains the same even if 1Kosmos issues the credential on behalf of the issuing authority. #### Verification Portal 1Kosmos provides a verification portal to confirm the validity of presented credentials. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.1kosmos.com/identity-verification/verifiable-credentials/overview.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.