Welcome to the December edition of our monthly digital identity series! This month, we explore how digital identity technology is safeguarding academic integrity, ensuring the credibility of research in an era of rising identity fraud. Dive into the GAO’s call for robust civil rights protections as federal agencies increasingly rely on AI and facial recognition. Discover the transformative potential of Digital Travel Credentials and decentralized identity in revolutionizing international travel. Lastly, we’ll examine the urgent need for unified frameworks to align emerging technologies with civil liberties.

Here’s a closer look at what you’ll find in this month’s insights:

Protecting Academic Integrity with Digital Identity Technology

The scholarly publishing industry is grappling with an alarming rise in identity fraud and unethical practices like paper mills and author impersonation, undermining trust in academic research. To counteract these challenges, STM Solutions has unveiled a comprehensive report titled “Trusted Identity in Academic Publishing: The Central Role of Digital Identity in Research Integrity.” Developed in collaboration with a Researcher Identity Task and Finish Group, this initiative aims to provide practical guidelines for the effective use of digital identity technology.

The report calls for stronger identity verification mechanisms while respecting inclusivity and privacy. It emphasizes how digital identity solutions can authenticate researchers while maintaining their autonomy, thus preserving the credibility of academic contributions. A crucial aspect of this framework is its scalability, which accommodates the diverse range of research disciplines and global contexts without being intrusive.

This strategic document also advocates an industry-wide approach, urging publishers, institutions, and researchers to unite for seamless integration of identity verification systems. By doing so, the academic community can address fraud more effectively, sustain open collaboration, and enhance trust in published findings.

GAO Highlights Need for Civil Rights Protections Amid Federal Data Use

As federal agencies increasingly rely on advanced technologies like artificial intelligence (AI) and facial recognition, the U.S. Government Accountability Office (GAO) has raised concerns about their impact on civil rights. Despite the growing adoption of these tools, a recent GAO report reveals that existing federal guidelines fall short in protecting against biases, inequities, and potential abuses of personal data.

While some agencies, such as Homeland Security, have begun creating frameworks to address ethical concerns, the overall response remains fragmented. For instance, the Privacy Act of 1974 governs data handling but does not encompass safeguards for emerging technologies. This leaves significant gaps in accountability, allowing for inadvertent discrimination and systemic inequities.

GAO recommends that Congress establish robust, government-wide civil rights guidelines tailored to emerging technologies. These should include privacy safeguards, risk assessments, and ethical oversight to prevent misuse. Furthermore, the report stresses the importance of bridging workforce skills gaps by investing in specialized training, enabling public agencies to navigate the complexities of these evolving tools.

This call to action underscores a need for comprehensive policy reform, ensuring that technological advancements align with societal values and protect citizens’ fundamental rights.

Revolutionizing International Travel: Digital Identity Innovation

Imagine arriving at your tropical destination just 30 minutes after stepping off the plane. This seamless travel experience is now a reality, thanks to a groundbreaking trial conducted by SITA, Indicio, and Delta Air Lines, in collaboration with Aruba’s government. Using Digital Travel Credentials (DTC) and IATA’s OneID, the initiative has redefined how travelers journey from Atlanta to Aruba.

The process begins with the DTC, a cryptographically secure digital version of a passport, allowing travelers to preauthorize their journey. At Hartsfield-Jackson Airport in Atlanta, IATA’s OneID streamlines check-ins, baggage handling, and boarding processes. Upon landing in Aruba, passengers cross the border within seconds, holding the data required for verification securely on their mobile devices.

The initiative demonstrates the potential of decentralized digital identity technology, merging efficiency, security, and privacy. By combining the DTC and OneID workflows, travelers experienced reduced wait times and an overall enhanced travel experience. This innovation highlights a significant leap toward a unified, interoperable digital travel system.

The success of this trial is more than a technological milestone—it is a glimpse into the future of international travel. During the IATA World Passenger Symposium in Bangkok, SITA’s Michael Zureik will present the findings, signaling a major shift toward global adoption of decentralized identity solutions.

Emerging Technologies and the Call for Unified Civil Liberties Frameworks

The U.S. Government Accountability Office (GAO) has identified alarming gaps in the way federal agencies handle civil rights issues associated with emerging technologies. AI and facial recognition tools, while enabling efficiencies, have also amplified biases and raised concerns about discriminatory practices. Existing laws, such as the Privacy Act of 1974, focus on privacy but fail to address the civil liberties challenges posed by modern tools.

GAO’s analysis of 24 federal agencies revealed inconsistent approaches to mitigating these risks. While some, such as the Department of Homeland Security, have developed initial risk assessment tools, these efforts lack uniformity and coordination across agencies. Moreover, workforce shortages and outdated regulatory frameworks hinder the effective adoption of ethical practices.

To close these gaps, GAO urges Congress to create a government-wide framework addressing ethical data use, transparency, and accountability. The report also highlights the need for investments in workforce training and infrastructure, enabling agencies to better respond to technological advancements while protecting civil liberties.

This recommendation seeks to balance the promise of innovation with the need to uphold social justice, ensuring that government operations remain fair, inclusive, and trustworthy.

We look forward to bringing you more insightful updates as we continue to explore the latest trends and innovations in the field of digital identity. Together, we can contribute to a more secure and inclusive digital future.

This Month in Digital Identity — December Edition was originally published in Finema on Medium, where people are continuing the conversation by highlighting and responding to this story.

Welcome to the November edition of our monthly digital identity series! This month, we’re diving into essential advancements shaping digital identity and the future of secure verification. Discover key updates on the European Digital Identity Wallet, the latest approaches to mobile driver’s license verification, and how deepfake detection is evolving to tackle growing threats. Plus, we’ll explore Jumio’s innovative biometric liveness detection and its role in combating identity fraud.

Here’s a closer look at what you’ll find in this month’s insights:

The EUDI Wallet

The European Digital Identity (EUDI) Wallet is a transformative initiative designed to provide EU citizens with a secure, self-sovereign digital identity solution. This wallet enables individuals to manage their identity information independently, ensuring privacy and security in online interactions. By facilitating access to essential services such as banking, healthcare, and governmental applications, the EUDI Wallet promises to streamline daily life and foster a more inclusive digital economy.

However, its implementation faces several significant challenges. Firstly, robust cybersecurity measures are crucial to prevent identity theft and data breaches, which could undermine user trust. Secondly, achieving regulatory harmonization across diverse EU member states is essential, as different countries have unique legal frameworks and privacy regulations. Without a unified approach, the wallet’s effectiveness could be compromised, leading to confusion among users and service providers alike.

Collaboration among various stakeholders—including government agencies, technology providers, and civil society—will be pivotal in overcoming these hurdles. By establishing clear standards for security, interoperability, and user experience, the EUDI Wallet can become a reliable tool that empowers citizens while safeguarding their data. Ultimately, its success will hinge on building public trust and ensuring that the system is user-friendly, accessible, and compliant with the highest privacy standards.

mDL Verification

The emergence of mobile driver’s licenses (mDLs) signifies a significant shift in identity verification, presenting both opportunities and challenges for users and authorities. mDLs offer a modern alternative to traditional physical licenses, allowing users to carry their identification securely on their smartphones. This technological advancement aims to streamline the verification process for a wide range of services, from travel to online transactions.

However, the implementation of mDLs is fraught with challenges. One primary concern is the need for secure and intuitive verification processes that maintain user confidence while preventing identity fraud. Additionally, the lack of uniformity in regulations across different states poses a significant barrier to widespread adoption. Each state has its own legal standards and technical requirements, complicating interoperability and making it difficult for users to rely on their mDLs outside their home jurisdictions.

Privacy is another critical issue, as users must be assured that their personal information will remain secure and confidential. Striking a balance between robust security measures and a seamless user experience is essential for gaining public acceptance.

To facilitate the successful rollout of mDLs, continuous collaboration among stakeholders — including government agencies, technology developers, and consumers — is vital. By establishing best practices and regulatory frameworks, stakeholders can ensure that mDLs become a trusted and widely accepted form of identification, paving the way for a more secure and efficient digital identity landscape.

Deepfake Detection

The rise of deepfake technology presents significant challenges to the authenticity of digital content, raising concerns about misinformation and trust in media. Deepfakes utilize advanced artificial intelligence to create highly realistic but fabricated videos and audio, making it increasingly difficult for viewers to discern truth from deception. As this technology becomes more sophisticated, the need for effective detection methods becomes paramount.

Various techniques are being developed to identify deepfakes, focusing on detecting subtle inconsistencies that can indicate manipulation. These methods include analyzing facial movements, lighting discrepancies, and unnatural expressions, which may signal that a video has been altered. As detection technologies evolve, they must continuously adapt to keep pace with advances in deepfake creation.

A multi-pronged approach is essential to mitigate the risks associated with deepfakes. This involves not only developing robust technological solutions but also enhancing public awareness about the existence and implications of deepfakes. Educating consumers on how to recognize manipulated content is critical in fostering a more discerning audience that can critically evaluate the media they consume.

Regulatory measures also play a crucial role in addressing the challenges posed by deepfakes. Policymakers must consider ethical guidelines and legal frameworks that govern the creation and dissemination of synthetic media. By promoting transparency and accountability in digital content creation, society can better safeguard against the potential harms of deepfakes while preserving the integrity of visual communication.

Jumio’s Biometric Liveness Detection

Jumio’s development of in-house biometric liveness detection technology represents a significant leap forward in identity verification. As identity fraud becomes more prevalent, this innovative solution uses sophisticated artificial intelligence to accurately differentiate between genuine biometric data—such as facial recognition—and spoofing attempts, including photographs or masks. This capability is crucial for enhancing security in online transactions and customer onboarding processes.

The liveness detection technology analyzes various data points in real time, assessing factors such as facial movements and eye interactions to determine whether the biometric input is from a live person. By integrating this technology into their identity verification offerings, Jumio aims to provide organizations with a more reliable means of preventing identity theft and fraud.

Moreover, as the digital landscape evolves, the demand for effective biometric verification solutions is increasing. Organizations must navigate the dual challenge of enhancing security while ensuring a smooth user experience. Jumio’s biometric liveness detection addresses this need, positioning the company as a leader in the identity verification market.

In an environment where digital interactions are ubiquitous, establishing trust in online transactions is paramount. By offering advanced biometric solutions, Jumio is helping to build confidence among consumers and organizations alike, making it easier to engage in secure digital commerce. As identity verification technologies continue to evolve, Jumio’s innovations will play a vital role in shaping the future of secure online interactions.

We look forward to bringing you more insightful updates as we continue to explore the latest trends and innovations in the field of digital identity. Together, we can contribute to a more secure and inclusive digital future.

This Month in Digital Identity — November Edition was originally published in Finema on Medium, where people are continuing the conversation by highlighting and responding to this story.

Welcome to the October edition of our monthly digital identity series! This month, we’re exploring the critical developments and innovative strategies that are redefining the landscape of digital identity. We’ll delve into significant advancements in decentralized identity, the balance between regulation and privacy, the role of biometric technology in hiring compliance, and the establishment of security standards for digital ID wallets in the EU.

Here’s a closer look at the essential topics we’ll be covering:

Advancing Decentralized Identity with the SLAP Framework

Velocity Network has dedicated the past five years to developing the Internet of Careers, focusing on essential business needs through the SLAP framework. This innovative approach emphasizes four critical components:

• Survivable Credentials: These credentials are designed to remain valid and accessible over time, ensuring that users can reliably present their identities without facing barriers.
• Legal Risk Mitigation: By addressing potential legal challenges associated with identity verification, organizations can significantly reduce their exposure to regulatory pitfalls, fostering a more secure environment for both users and businesses.
• Accreditation for Issuers and Relying Parties: Establishing trusted standards for all participants in the identity ecosystem helps to enhance credibility and build trust among users.
• Practical Privacy: Prioritizing user privacy ensures that individuals maintain control over their personal information, which is essential in today’s digital landscape.

Velocity Network’s collaborative efforts invite stakeholders from various sectors to contribute to effective decentralized identity solutions. By working together, we can empower individuals with greater control over their identities and foster a more inclusive digital ecosystem.

Navigating the Tension Between Decentralized Identity and Regulation

In the ever-evolving digital landscape, the interplay between decentralized identity and regulatory frameworks has become increasingly critical. High-profile cases such as Silk Road and Tornado Cash highlight the challenges of balancing innovation with compliance.

To address these challenges, it is essential to adopt a balanced approach that fosters the development of decentralized reputation systems. Such systems can empower self-regulation while ensuring both privacy and accountability. By leveraging anonymous identities, we can create a framework where individuals have control over their digital presence while participating responsibly in digital platforms.

This approach not only enhances user empowerment but also helps build trust within communities. Learning from past experiences with regulatory challenges can inform the design of more resilient and adaptable decentralized identity systems. By understanding the nuances of this complex relationship, we can pave the way for innovative solutions that respect both freedom and the need for regulation.

Enhancing Hiring Compliance in the UK with Yoti Biometrics

Yoti is making significant strides in the UK hiring landscape by integrating biometric technology with Sterling’s background checks. This partnership aims to streamline compliance and enhance the security and accuracy of identity verification during the hiring process.

By utilizing Yoti’s biometric solutions, employers can simplify the compliance process, ensuring that they meet regulatory requirements efficiently. This integration not only reduces the risk of non-compliance but also enhances security, making it more difficult for fraudulent activities to occur.

Candidates benefit from this system as well, enjoying a smoother onboarding experience. The biometric verification process is designed to be quick and user-friendly, allowing job seekers to complete identity checks seamlessly. This innovative approach not only improves the overall efficiency of the hiring process but also instills greater confidence among employers and candidates alike.

As organizations increasingly recognize the value of biometric technology, Yoti’s integration with Sterling’s background checks stands as a promising development for the future of hiring compliance in the UK.

ENISA to Launch Cybersecurity Certification Scheme for EU Digital ID Wallets

In a significant move to bolster security in the digital identity landscape, the European Union Agency for Cybersecurity (ENISA) is set to establish a cybersecurity certification scheme for the EU’s digital ID wallets. This initiative aims to ensure that digital identity solutions meet high standards of security and trustworthiness, thereby promoting consumer confidence in these technologies.

The certification scheme will provide a robust framework for assessing and validating the security measures implemented in digital ID wallets. By aligning with EU regulations and standards, this initiative supports the broader strategy of creating a secure and interoperable digital identity ecosystem within the EU.

ENISA emphasizes the importance of collaboration with various stakeholders, including industry leaders and governmental bodies, to develop a comprehensive certification process. This collaborative approach is crucial for addressing the diverse needs and challenges in the digital identity landscape.

By fostering trust in digital identity solutions, this initiative paves the way for increased adoption and reliance on secure digital services across the EU.

We look forward to bringing you more insightful updates as we continue to explore the latest trends and innovations in the field of digital identity. Together, we can contribute to a more secure and inclusive digital future.

This Month in Digital Identity — October Edition was originally published in Finema on Medium, where people are continuing the conversation by highlighting and responding to this story.

Welcome to the September edition of our monthly digital identity series! This month, we’re exploring the critical developments and innovative strategies that are redefining the landscape of digital identity. Here’s a closer look at the essential topics we’ll be covering:

AI Enhancing Healthcare Fraud Prevention

Artificial Intelligence (AI) is becoming a crucial tool in combating healthcare fraud by analyzing vast datasets in real-time to detect fraudulent activities, particularly through voice biometrics that verify patient identities and prevent unauthorized access to healthcare services. Additionally, there is a growing focus on enhancing patient experiences through digital trust technologies, such as secure digital signatures and messaging platforms, which protect patient data and streamline healthcare processes. Innovations like chip-based ID cards are also being adopted, as seen in Vietnam, to secure patient information and simplify access to healthcare services, reducing the risk of identity theft and fraud. These technological advancements collectively aim to strengthen the integrity of healthcare systems, safeguard patient data, and improve operational efficiency, ultimately enhancing the overall patient experience.

Somalia’s Financial Inclusion Drive

Somalia is advancing its digital transformation with a new Memorandum of Understanding (MoU) between the National Identification and Registration Authority (NIRA) and the Somali Banks Association (SBA) to drive financial inclusion through the national ID program. Launched a year ago, this program aims to provide the 18 million residents with a unified identity, facilitating access to banking services and aligning with global standards. The partnership seeks to enhance financial security, reduce fraud, and streamline banking processes by using the National Identification Number (NIN) for customer verification. This initiative is part of a broader effort to bolster the country’s economy, ensure compliance with international regulations, and increase public trust in financial institutions. The collaboration has been praised by key government figures and international partners, who see it as crucial for Somalia’s development. Ongoing consultations with stakeholders aim to further strengthen the national ID system, making it more impactful in supporting economic growth and modernizing financial services.

Spain’s New Age Verification System

Spain has introduced technical specifications for a new online age verification system aimed at controlling minors’ access to adult content, using W3C Verifiable Credentials (VCs) as the core technology. This approach addresses growing concerns over the negative impact of unrestricted access to adult content on the mental health and social skills of children and teenagers. By implementing W3C VCs, Spain ensures that age verification is conducted securely and privately, without disclosing personal information, thus aligning with GDPR principles. W3C VCs offer unmatched security through advanced cryptographic methods, enhanced privacy by allowing users to share only necessary information, and portability by integrating seamlessly with digital wallets. The system also follows the OpenID For Verifiable Presentations (OpenID4VP) specification, ensuring secure and private verification, and includes a trust management framework to ensure only authorized entities can issue or verify credentials, making it an ideal solution for protecting minors online.

The Digital Travel Credential (DTC)

In the realm of digital identity, numerous digital credentials are vying to replace physical documents, with the European Union’s eIDAS 2.0 and digital driver’s licenses being notable examples. However, none match the Digital Travel Credential (DTC) standard for digital trust, developed by the International Civil Aviation Organization (ICAO), which sets the universal standards for passports. The DTC, designed as the digital equivalent of a passport, offers two types: one created by a user from their physical passport and another issued directly by passport authorities. Indicio and SITA pioneered the implementation of the Type 1 DTC, which is now being adopted by countries and airlines for seamless travel. The DTC’s strength lies in its use of cryptographic verification, ensuring that passport data is securely held on a user’s device without needing to be stored in centralized databases, mitigating risks of data breaches. By scanning their passport, users can verify the authenticity of their data, bind it to their device through biometric checks, and ensure that their digital credentials are trustworthy and tamper-proof. This system provides airlines, airports, and border control with the confidence to streamline travel processes, knowing that the data in the DTC is authenticated, portable, and instantly verifiable.

We look forward to bringing you more insightful updates as we continue to explore the latest trends and innovations in the field of digital identity. Stay tuned for future editions of our monthly segment!

This Month in Digital Identity — September Edition was originally published in Finema on Medium, where people are continuing the conversation by highlighting and responding to this story.

Welcome to the August edition of our monthly digital identity segment! This month, we’re diving deep into pivotal advancements and strategies that are shaping the future of digital identity. Here’s an in-depth look at the key topics we’re covering:

Enhancing Digital Identity Adoption

🌍 Our first article focuses on the EBSI-CAN project meeting, a landmark event in advancing digital identity adoption and cross-border interoperability between the EU and Canada. This meeting was crucial in addressing the complex challenges faced by international digital identity systems. It explored various technical barriers that currently impede seamless integration of digital identity systems across borders, such as differing standards and protocols. Regulatory alignment was another key focus, with discussions centered on harmonizing regulations to facilitate smoother interactions and exchanges of digital identity information between regions. Collaborative frameworks were also highlighted as essential for fostering international partnerships and creating a unified approach to digital identity. By tackling these issues, the EBSI-CAN project aims to build a more cohesive and efficient digital identity ecosystem that supports global digital transactions and interactions. This initiative represents a significant step toward overcoming the fragmentation in digital identity systems and achieving a more integrated global digital landscape.

Advancing Decentralized Identity

🔒 Our second feature delves into the exciting progress being made in the decentralized identity sphere, particularly the integration of OpenID’s verifiable credential protocols with DIDComm. This development marks a significant leap forward in enhancing digital identity management. OpenID’s verifiable credentials provide a robust framework for issuing and verifying digital identity information, while DIDComm enables secure, direct communication between trusted parties. The integration of these technologies facilitates a more secure and efficient exchange of identity information, supporting self-sovereign identity systems where users have greater control over their personal data. This advancement not only improves the reliability of digital identity exchanges but also enhances privacy by ensuring that personal information is only shared with trusted entities under secure conditions. The combination of OpenID and DIDComm represents a major stride toward a more user-centric and resilient digital identity infrastructure, paving the way for more secure and flexible identity management solutions.

Balancing Privacy, Security, and Convenience

🔐 In our third article, we explore the ongoing evolution of digital identity with a focus on balancing privacy, security, and convenience. As digital identity systems become more advanced, decentralized solutions are emerging as a promising way to enhance user control over personal data. These systems offer significant advantages over traditional centralized models by providing greater transparency and control to users. Our article examines how these decentralized systems address common concerns related to privacy and security while still delivering a high level of convenience. It discusses the technological innovations that are reshaping personal data management, including new methods for protecting user data and ensuring secure interactions with digital services. By exploring these advancements, the article provides insights into how future digital identity solutions might evolve to meet both user expectations and regulatory requirements, ultimately leading to a more balanced and user-friendly digital identity landscape.

The Strategic Advantage of Open Working Practices

💼 Our final feature in this edition discusses the strategic benefits of adopting open working practices. Open working practices, characterized by transparency, inclusivity, adaptability, collaboration, and community, offer organizations a powerful approach to enhancing their operations. The article explores how these principles can lead to greater organizational agility by breaking down traditional barriers and fostering a culture of open communication and collective problem-solving. It highlights how open working practices can drive innovation by encouraging diverse perspectives and ideas, leading to more creative and effective solutions. Additionally, the article examines how these practices can improve employee engagement and satisfaction by creating a more inclusive and supportive work environment. By embracing open working principles, organizations can achieve sustainable success and strengthen their performance in a rapidly changing business landscape.

We look forward to bringing you more insightful updates as we continue to explore the latest trends and innovations in the field of digital identity. Stay tuned for future editions of our monthly segment!

This Month in Digital Identity — August Edition was originally published in Finema on Medium, where people are continuing the conversation by highlighting and responding to this story.

As we enter the era of generative AI, the risk of identity theft for both individuals and organizations is escalating. A recent case in Hong Kong highlights this threat, where an office was deceived into transferring $25 million after a video call with a deepfake CFO and colleagues. As advances in AI erode trust, it becomes apparent that a robust digital identity solution for organizations is urgently needed.

In the past few years, the verifiable Legal Entity Identifier (vLEI) framework has emerged as one of the most promising solutions to this global crisis. The vLEI framework offers one of the most secure and trustworthy digital organization identity management to date and potentially revolutionizes digital business transactions worldwide.

Since vLEI is also still in its infancy, there is a significant challenge for the community to overcome its adoption hurdle. In this article, we propose 4 pragmatic criteria for identifying fair, good, and great use cases for vLEI from the adoptability perspective. These criteria are by no means rigid rules set in stone but serve as a useful mental model for pioneers and early adopters exploring vLEI use cases.

The 4 Criteria

We have identified 4 criteria for good and great vLEI use cases:

1. Use cases that involve organization-to-organization transactions
2. Use cases that involve cross-border transactions
3. Use cases that are highly regulated
4. Use cases that have open ecosystems

1. Org-to-Org

The first criterion for viable vLEI use cases is that they involve organization-to-organization (Org-to-Org) transactions. This includes business-to-business (B2B), business-to-government (B2G), and government-to-government (G2G) use cases. This is because org-to-org transactions often involve significant monetary value, which far outweighs the initial friction associated with adopting vLEI.

2. Cross-Border

Cross-border transactions often face challenges in identifying and verifying clients, suppliers, or partners across different countries, leading to significant perceived risks. The vLEI framework is ideal for addressing these challenges as it is specifically designed for international use. It can potentially streamline the cross-border identification and verification processes, mitigating risks and improving efficiency.

3. Highly Regulated

Highly regulated use cases are subject to strict requirements and standards, where non-compliance can result in severe penalties or legal consequences. As a result, these use cases often require extensive due diligence of business partners, including Know Your Customer (KYC), Anti-Money Laundering (AML), and Countering the Financing of Terrorism (CFT) checks.

The process of obtaining vLEI for organizations and their representatives involves robust identity verification that is more stringent than those often conducted in the financial sector. As a result, vLEI, which is built on the global LEI system, can help streamline the due diligence process, significantly reducing compliance costs.

4. Open Ecosystems

The final criterion for viable vLEI use cases is that they operate within open ecosystems, allowing the addition of organizations whose identities are not known in advance. Onboarding a new organization to the ecosystem often incurs significant cost, time, and effort. vLEI allows these onboarding costs to be offloaded to a third party, specifically a qualified vLEI issuer (QVI), which ensures that the organization and its representatives have undergone strict identity verification.

Fair, Good, and Great Use Cases

Great Use Cases

Great use cases are those that satisfy all 4 criteria, making them ideal candidates that could benefit from integrating vLEI into their workflows.

A prime example of a great use case is trade finance. It typically involves organizations (criterion 1) which are often located in different countries (criterion 2). Trade finance is also highly regulated, with financiers subject to AML and CFT requirements (criterion 3). The trade finance ecosystem is open, allowing any company worldwide to initiate trades and apply for, e.g., a letter of credit (criterion 4).

Good Use Cases

Good use cases are those that satisfy 3 out of the 4 criteria. We consider these use cases worth pursuing.

An example of a good use case is the financial reporting of banking institutions in Europe to the European Banking Authority (EBA). This exemplifies a B2G scenario (criterion 1), encompassing banks across multiple European countries (criterion 2) that operate within a highly regulated environment (criterion 3). What makes this use case simply good rather than great in our criteria is that European banks are already known entities within the closed ecosystem supervised by the EBA.

Fair Use Cases

Fair use cases are those that satisfy two or fewer criteria. While they may be a feasible use case for vLEI, we consider them a low-potential candidate. We argue that fair use cases will become viable once vLEI has achieved widespread adoption. For instance, organizations that already possess vLEI for stronger use cases might contemplate applying it to these fair use cases.

An example of a use case we consider “fair” for vLEI is an HR platform. Such a platform is used internally between employers and employees (not org-to-org) and is also not highly regulated. Typically, employees and employers have alternative means to verify each other, diminishing the necessity for vLEI in this context.

Conclusion

While vLEI holds significant potential to transform global business operations, it currently faces a challenge known as the “cold start problem,” where there are not enough holders and use cases to foster exponential growth in the ecosystem. Pioneers and early adopters are encouraged to prioritize exploring high-potential use cases.

Do you agree with our criteria? Are there additional criteria we should consider adding to the list? We welcome your feedback and invite you to contact us at contact@enauthn.id.

4 Criteria for Great vLEI Use Cases was originally published in Finema on Medium, where people are continuing the conversation by highlighting and responding to this story.

Note: This tutorial is heavily inspired by “KERI Tutorial Series — KLI: Sign and Verify with Heartnet” by Kent Bull

https://kentbull.com/2023/01/27/keri-tutorial-series-kli-sign-and-verify-with-heartnet/

This blog presents an introductory guide for implementing the Key Event Receipt Infrastructure (KERI) protocol using the Signify and KERIA agents. The guide starts with installation and running the agents using Docker containers. The guide then provides a script to showcase the use of Signify and KERIA agents, including procedures for creating autonomic identifiers (AIDs), signing messages, and verifying signatures.

Signify & KERIA

Signify & KERIA are open-source projects developed for building client-side identity-wallet applications using the KERI protocol. Signify-KERIA identity wallet utilizes the hybrid edge-cloud wallet architecture where Signify provides a lightweight edge wallet component whereas KERIA provides a heavier cloud wallet component. Signify and KERIA were designed based on the principle of “key at the edge (KATE)”. That is, essential cryptographic operations are performed at edge devices.

Some resources for Signify & KERIA can be found here

• The Signify-KERIA protocol by Philip Feairheller: https://github.com/WebOfTrust/keria/blob/main/docs/protocol.md
• KERI API (KAPI): https://github.com/WebOfTrust/kapi/blob/main/kapi.md

Signify Edge Agent

Signify provides an edge agent for a KERI identity wallet and is used primarily for essential cryptographic operations including key pair generation and digital signature creation. Signify utilizes the hierarchical deterministic (HD) key algorithm. For example, a Signify application could safeguard a single master seed which is used to generate and manage any number of AIDs. Signify is designed to be lightweight so as to support devices with limited capabilities.

Signify is currently available in Typescript and Python

• SignifyPy (Python) https://github.com/WebOfTrust/signifypy
• Signify-TS (Typescript) https://github.com/WebOfTrust/signify-ts

KERIA Cloud Agent

KERI Agent (KERIA) provides a cloud agent for a KERI identity wallet and is used for, e.g., data storage, agent-to-agent communications, and verification of KERI key event logs (KELs). KERIA is engineered to handle the heavy lifting for users, allowing their edge devices to stay lightweight while maintaining high security by performing all essential cryptographic operations at the edge.

A KERIA agent is cryptographically delegated by a Signify agent using the KERI delegation protocol. All instructions from a user are signed at the edge by a Signify agent and subsequently verified by a KERIA cloud agent. KERIA is currently available in Python: https://github.com/WebOfTrust/keria

Installation Guide for Node and NVM

In this guide, we will be using Node.js to run Signify-TS (Typescript) with a KERIA server running on a Docker container.

Install Node.js

Visit the Node.js website to download Node.js.

Install NVM on Linux or MacOS

To easily switch between different versions of Node.js, you could use Node Version Manager (NVM). NVM on Linux and macOS may be installed using curl

curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.34.0/install.sh | bash

Alternatively, we could use wget

wget -qO- https://raw.githubusercontent.com/creationix/nvm/v0.34.0/install.sh | bash

Install NVM on Windows

On Windows, NVM may be installed from the GitHub releases page.

Note: After installing NVM, do not forget to restart your terminal. Alternatively, you can refresh the available commands in your system path by executing source ~/.nvm/nvm.sh

Using NVM

To ensure that NVM is correctly installed, you can check its version with:

nvm ls

To install Node.js version 18.18.2, run:

nvm install v18.18.2

Here, we use v18.18.2 in this guide. This is not a requirement and other versions of Node.js should work with Signify-TS.

Install Dependencies and Run a KERIA Server

To install dependencies for the tutorial, you could clone this repository https://github.com/enauthn/tutorial-signify-keria and run the following script

git clone https://github.com/enauthn/tutorial-signify-keria
cd tutorial-signify-keria
npm install
docker-compose up -d

where docker-compose up -d runs a KERIA server in a Docker container. Alternatively, you could get a Docker image for running a KERIA server from Docker Hub https://hub.docker.com/r/weboftrust/keria.

Running Signify-TS Scripts

Here, we demonstrate Signify-TS Scripts for signing and verifying an arbitrary message. Here, a signer, called Allie, signs a message “Hello Brett” and sends it to a verifier, called Brett. Brett subsequently obtains Allie’s key event log (KEL) and uses it to verify the signature on the message.

Connecting Signify clients to the KERIA server

First, Allie and Brett must boot and then connect to a KERIA server with their Signify (edge) clients. Each boot command creates a separate agent and a database in the KERIA server. see https://github.com/WebOfTrust/keria for more details.

Typically, Allie’s and Brett’s Signify scripts should run on separate devices, but here we put them in the same Typescript file for simplicity. Allie’s and Brett’s Signify clients may also connect to different KERI servers at different service endpoints. In this tutorial, both clients connect to a KERIA server running on the local host for simplicity.

await signify.ready();

const url = 'http://127.0.0.1:3901';
const bootUrl = 'http://127.0.0.1:3903';
const bran1 = signify.randomPasscode();
const bran2 = signify.randomPasscode();

const allieClient = new signify.SignifyClient(
    url,
    bran1,
    signify.Tier.low,
    bootUrl
);
await allieClient.boot();
await allieClient.connect();

const brettClient = new signify.SignifyClient(
    url,
    bran2,
    signify.Tier.low,
    bootUrl
);
await brettClient.boot();
await brettClient.connect();

To explain the above script:

• signify.randomPasscode() generates a random string with 126-bit entropy using libsodium
• new signify.SignifyClient(…) creates a new Signify instance, initialized with the newly generated passcode
• allieClient.boot() creates a KERIA agent and a corresponding database at the KERIA server via port 3903
• allieClient.connect() connects a Signify agent to the corresponding KERIA agent that has been booted.

Signify uses a passcode to generate cryptographic keys using a key derivation function (KDF) where signify.Tier specifies how much the passcode is stretched.

Allie creates an AID

Before Allie can sign a message with the KERI protocol, she must first create an autonomic identifier (AID) with a key inception event in a Key Event Log (KEL).

const icpResult1 = await allieClient
    .identifiers()
    .create('aid1', {});
await waitOperation(allieClient, await icpResult1.op());

const rpyResult1 = await allieClient
    .identifiers()
    .addEndRole('aid1', 'agent', allieClient!.agent!.pre);
await waitOperation(allieClient, await rpyResult1.op());

To explain the above script:

• allieClient.identifiers().create('aid1', {}) creates an AID where the Signify agent signs the inception event and sends the event along with its signature to the KERIA agent. Here, the AID is given an alias 'aid1'.
• allieClient.identifiers().addEndRole(...) cryptographically authorizes the KERIA agent to operate on behalf of the AID’s controller.
• waitOperation(...) waits for the KERIA agent to complete its operation.

addEndRole stands for “adding endpoint role authorization”. This is a mechanism in the KERI protocol where the controller of an AID cryptographically authorizes—by signing with a private key associated with the AID—a service endpoint of a KERIA agent to operate on the AID’s behalf. Another agent that needs to communicate with the authorized KERIA agent can then verify the authorization signature.

Brett resolves Allie’s AID

Allie and Brett may exchange their KELs using the Out-Of-Band Introduction (OOBI) protocol. Allie may generate her OOBI URL that points to her KERIA agent’s service endpoint (which has been authorized in the previous step) as follows:

const oobi1 = await allieClient.oobis().get('aid1', 'agent');

The generated OOBI URL could be sent to Brett via an out-of-band channel such as email, messaging apps, or scanning QR code. Subsequently, Brett may ask his KERIA agent to resolve Allie’s OOBI to obtain the AID’s KEL from Allie’s KERIA agent:

const oobiOp = await brettClient.oobis().resolve(oobi1.oobis[0], 'aid1');
await waitOperation(brettClient, oobiOp);

Allie signs the Message

To sign a message, Allie may use the Signify KeyManager class as follows:

const aid1 = await allieClient.identifiers().get('aid1');
const keeper1 = await allieClient.manager!.get(aid1);
const message = "Test message";
const signature = await keeper1.sign(signify.b(message))[0];
console.log('signature', signature);

which generates the following CESR-encoded signature:

signature AAAnBe-VPfBU9-3eb7aM5GNwr_NBuoJzA8vm9AFPmgj3I4LIv1mup2bwPDlbIQ6gAgtaEZg5rwE1_fTVVTmPo0oI

To explain the above script:

• allieClient.identifiers().get('aid1') retrieves the information about the AID with alias 'aid1' from the KERIA agent
• allieClient.manager!.get(aid1) creates an instance from the KeyManager class called a keeper that signs an arbitrary byte string with keeper.sign()
• signify.b() turns a text string into a byte string.

When a Signify agent creates an AID, it uses a salt together with its passcode to generates cryptographic keys associated with the AID. The salt is then encrypted and sent to the KERIA agent. allieClient.identifiers().get('aid1') also retrieves and decrypts the salt where the KeyManager could use the salt to regenerate the key for signing the message.

Brett verifies Allie’s signature

After Allie sends the message to Brett, Brett wants to make sure the message is really from Allie by verifying the signature on the message. Brett may retrieve Allie’s KEL and the corresponding key state of her AID to verify the signature as follows:

const aid1StateBybrettClient = await brettClient.keyStates().get(aid1.prefix);
const siger = new signify.Siger({qb64: signature});
const verfer = new signify.Verfer({
    qb64: aid1StateBybrettClient[0].k[0]
});
const verificationResult = verfer.verify(siger.raw, signify.b(message));
console.log('verificationResult', verificationResult);

which gives the following output:

verificationResult true

To explain the above script:

• brettClient.keyStates().get(aid1.prefix) retrieves the key state of the Allie’s AID
• signify.Siger({qb64: signature}) is a signature-wrapper instance of the Siger class, initialized with the Allies’ signature on the message.
• signify.Verfer(...) is a verifier-wrapper instance of the Verfer class, initialized by the Allie’s public key
• verfer.verify(...) then verifies the message and its signature using Allie’s public key

The verification of the signature against the message indicates that the signature is valid. This ensures the authenticity and integrity of the message that Brett received from Allie.

Conclusion

This tutorial gives a brief introduction for using the KERI protocol with the Signify and KERIA agents, which provide a footing for building client-side KERI-based applications. Signify provides libraries for building KERI edge agents whereas KERIA provides libraries for building companion cloud agents. These agents follow the principle of “key at the edge (KATE)” where essential cryptographic operations are performed at edge devices.

Unfortunately, this is still the early days for these two projects, and there are not many educational materials around as of May 2024. To dive deeper into these two projects, I recommend studying their integration scripts at https://github.com/WebOfTrust/signify-ts/tree/main/examples/integration-scripts.

KERI Tutorial: Sign and Verify with Signify & Keria was originally published in Finema on Medium, where people are continuing the conversation by highlighting and responding to this story.

vLEI Demystified Series:

• Part1: Comprehensive Overview
• Part 2: Identity Verification
• Part 3: QVI Qualification Program

This blog is the third part of the vLEI Demystified series. The previous two, vLEI Demystified Part 1: Comprehensive Overview and vLEI Demystified Part 2: Identity Verification, have explained the foundation of the pioneering verifiable Legal Entity Identifier (vLEI) ecosystem as well as its robust Identity Verification procedures. In this part, we will share with you our journey through the Qualification of vLEI Issuers, called Qualified vLEI Issuers (QVIs), including the requirements and obligations that QVIs have to fulfill once they are authorized by GLEIF to perform their roles in the ecosystem.

The Qualification of vLEI Issuers is the evaluation process conducted by the Global Legal Entity Identifier Foundation (GLEIF) to assess the suitability of organizations aspiring to serve as Qualified vLEI Issuers within the vLEI ecosystem. GLEIF has established the Qualification Program for all interested organizations, which can either be the current LEI Issuers (Local Operating Units: LOUs) or new business partners who wish to explore the emerging vLEI ecosystem. The organizations that complete the Qualification Program under the GLEIF vLEI Ecosystem Framework (EGF) are authorized to perform verification, issuance, and revocation of vLEI credentials to legal entities seeking the credentials and also their representatives.

Step 1: Start the Qualification Program

To kick start the qualification process, the organizations interested in becoming QVIs must first review Appendix 2: vLEI Issuer Qualification Program Manual, which provides an overview of the required Qualification Program, and the vLEI Ecosystem Governance Framework (vLEI EGF) to make sure that they understand how to incorporate the requirements outlined in the framework to their operations. Once they have decided to proceed, the interested organizations may initiate the Qualification Program by sending an email to qualificationrequest@gleif.org along with a Non-Disclosure Agreement (NDA) signed by an authorized signatory of the interested organization.

Unless GLEIF has a mean to verify the signatory’s authority by themselves, the interested organization may be required to submit proof of the signatory’s authority. In the case where the NDA signer’s authority is delegated, the power of attorney may also be required.

After GLEIF reviews the qualification request, they will countersign the NDA and organize an introductory meeting with the interested organization, now called a candidate vLEI issuer, to discuss the next step of the Qualification Program.

Step 2: Implement the Qualification Program Requirements

To evaluate if a candidate vLEI issuer has both the financial and technical capabilities to perform the QVI role, the candidate vLEI issuer is required to implement the Qualification Program Requirements, which consist of business and technical qualifications. Throughout this process, the candidate vLEI issuer may schedule up to two meetings with GLEIF to clarify program issues and requirements.

Complete the Qualification Program Checklist

A candidate vLEI issuer is required to complete Appendix 3: vLEI Issuer Qualification Program Checklist to demonstrate that they are capable of actively participating in the vLEI ecosystem as well as being in good financial standing. The checklist and supporting documents can be submitted via online portals provided by GLEIF.

The Qualification Program Checklist is divided into 12 sections from Section A to Section L. The first five sections (Section A to Section E) focus mainly on the business aspects while the last seven sections (Section F to Section L) cover the technical specifications and relevant policies for operating the vLEI issuer Services.

Note: vLEI Issuer Services are all of the services related to the issuance, management, and revocation of vLEI credentials provided by the QVI.

Section A: Contact Details:

This section requires submission of the candidate vLEI issuer’s general information as well as contact details of the key persons involved in the vLEI operation project, namely: (1) Internal Project Manager, (2) Designated Authorized Representative (DAR), (3) Key Contact Operations, and (4) Key Contact Finance

Section B: Entity Structure

This section requires submission of the candidate vLEI issuer’s organization structure, regulatory internal and external audit reports, operational frameworks, and any third-party consultants that the candidate vLEI issuer has engaged with regarding their business and technological evaluation.

Section C: Organization Structure

This section requires submission of the current organization chart for all vLEI operations and a complete list of all relevant third-party service providers that support the vLEI operations.

Section D: Financial Data, Audits & General Governance

This section requires submission of financial and operational conditions of the candidate vLEI issuer’s business, including:

• Audited financial statements for the prior year
• Financial auditor reports
• Formal vLEI Issuer Operation Budget

Section E: Pricing Model

In this section, the candidate vLEI issuer outlines their strategy to generate revenue from the vLEI operations and ensure that they are committed to managing the funding and monetization of the services they plan to offer. This includes the pricing model and business plan regarding the vLEI issuer services

Section F: vLEI Issuer Services

In this section, the candidate vLEI issuer shall outline their detailed plans and processes related to the issuance and revocation of vLEI credentials, including:

• Processes for receiving payments from legal entity (LE) clients.
• Processes for identity verification in accordance with the vLEI EGF.
• Processes for validating the legal identity of official organization role (OOR) persons as well as using GLEIF API to choose the correct OOR code.
• Processes for calling the vLEI Reporting API for each issuance of LE and OOR vLEI credentials
• Processes for verifying the statuses of legal entity clients’ LEI. The clients must be notified 30 days before their LEI expires.
• Processes for revoking all vLEIs issued to the legal entity client whose LEI has lapsed
• Processes for monitoring compliance with the Service Level Agreement (Appendix 5)
• Processes for monitoring witnesses for erroneous or malicious activities

Section G: Records Management

In this section, the candidate vLEI issuer provides their internal Records Management Policy that defines the responsibilities of the personnel related to records retention to ensure that the records management processes are documented, communicated, and supervised.

Section H: Website Requirements

In this section, the candidate QVI’s websites are required to display the following items:

• QVI Trustmark
• Applications, contracts, and required documents for legal entities to apply for vLEI credentials.

Section I: Software

In this section, the candidate vLEI issuer provides their internal policy for the Service Management Process including:

• Processes for installing, testing, and approving new software
• Processes for identifying, tracking, and correcting software errors/bugs
• Processes for managing cryptographic keys
• Processes for recovering from compromise

The candidate vLEI issuer must also specify their policies and operations related to management for private keys and KERI witnesses as follows:

• Processes and policies for managing thresholded multi-signature scheme, where at least 2 out of 3 qualified vLEI issuer authorized representatives (QARs) are required to approve issuance or revocation of vLEI credentials
• Processes for operating KERI witnesses, where at least 5 witnesses are required for the vLEI issuer services

Section J: Networks and Key Event Receipt Infrastructure (KERI)

In this section, the candidate vLEI issuer describes their network architecture including KERI witnesses and the details of third-party cloud-based services as well as a process monitoring of the vLEI Issuer-related IT infrastructure. The candidate vLEI issuer must also provide the following internal policies:

• Disaster Recovery and/or Business Continuity Plan
• Backup Policies and Practices
• The vetting process for evaluating the reliability of third-party service providers

Section K: Information Security

In this section, the candidate vLEI issuer provides their internal Information Security Policy that includes, for example, formal governance, revision management, personnel training, physical access policies, incident reports, and remediation from security breaches.

Section L: Compliance

QVI candidates must declare that they will abide by the general and legal requirements as a vLEI Issuer by:

• Execute a vLEI Issuer Qualification Agreement with GLEIF
• Execute a formal contract, of which the template follows the Agreement requirements, with a Legal Entity before the issuance of a vLEI credential
• Comply with the requirements for Qualification, vLEI Ecosystem Governance Framework, and any other applicable legal requirements

Respond to Remediation (if any)

After the candidate vLEI issuer has submitted the qualification program checklist and supporting documents through online portals, GLEIF will review the submission and provide the review results and remediation requirements, if any. Subsequently, the candidate vLEI issuer must respond to the remediation requirements along with corresponding updates to their qualification program checklist and supporting documents.

Undergo Technical Qualification

After the qualification program checklist has been submitted, reviewed, and remediated, the candidate vLEI issuer then proceeds to the technical part of the qualification program. GLEIF and the candidate vLEI issuer then organize a dry run to test that the candidate vLEI issuer is capable of:

• Performing OOBI sessions and authentication
• Generating and managing a multi-signature group AID
• Issuing, verifying and revoking vLEI credentials

The purpose of the dry run is to make sure that the candidate vLEI issuer has the technical capability to operate as a QVI as well as identify and fix any technical issue that may arise. A dry run may take multiple meeting sessions if required.

After the candidate vLEI issuer completes the dry run, they may proceed to the official technical qualification, which repeats the process during the dry run. vLEI credentials issued during the official session are official and may be used in the vLEI ecosystem.

Step 3: Sign the Qualification Agreement

Once the vLEI candidates have completed all of the business and technical qualification processes, GLEIF will notify the organization regarding the result of the Qualification Program. The approval of the qualification application will result in the candidate vLEI Issuer signing the vLEI Issuer Qualification Agreement with GLEIF. The candidate vLEI Issuer will then officially become a QVI.

Beyond the Qualification Program

Once officially qualified, the QVI must ensure strict compliance with the vLEI EGF and the requirements that they completed in the Qualification Program Checklist. For example, their day-to-day operations must comply with Appendix 5: Qualified vLEI Issuer Service Level Agreement (SLA) as well as comply with their internal policies such as the Records Management Policy and Information Security Policy. They must also continuously monitor their services and IT infrastructure including the witnesses.

Annual vLEI Issuer Qualification

The QVI is also subject to the Annual vLEI Issuer Qualification by GLEIF to ensure that they continue to meet the requirements of the vLEI Ecosystem Governance Framework. If the QVI has made significant changes to their vLEI issuer services, IT infrastructure, or internal policies, the QVI must document the details of the changes and update corresponding supporting documentation. GLEIF will then review the changes and request for remediation actions, if any.

Conclusion

The processes of the QVI Qualification Program are designed to be extensively rigorous to ensure the trustworthiness of the vLEI ecosystems as QVIs play a vital role in maintaining trust and integrity among the downstream vLEI stakeholders. We at Finema are committed to promoting the vLEI ecosystem, and would be delighted to assist should you be interested in embarking on your journey to participate in the ecosystem.

vLEI Demystified Part 3: QVI Qualification Program was originally published in Finema on Medium, where people are continuing the conversation by highlighting and responding to this story.

• Part 1: Why should you adopt KERI?
• Part 2: What exactly is KERI?
• Part 3: How do you use KERI?

Now that you grasp the rationale underpinning the adoption of KERI and have acquired a foundational understanding of its principles, this part of the series is dedicated to elucidating the preliminary steps necessary for embarking upon a journey with KERI and the development of applications grounded in its framework.

The resources provided below, while presented in no particular order, serve to supplement your exploration of KERI. Moreover, this blog will serve as an implementer guide to further deepen your understanding and proficiency in utilizing KERI.

Read the Whitepaper

The Key Event Receipt Infrastructure (KEI) protocol was first introduced in the KERI whitepaper by Dr. Samuel M. Smith in 2019. The whitepaper kickstarts the development of the entire ecosystem.

While the KERI whitepaper undoubtedly offers invaluable insights into the intricate workings and underlying rationale of the protocol, I would caution against starting your KERI journey with it. Its length exceeding 140 pages, may pose a significant challenge for all but a few cybersecurity experts. It is advisable to revisit the whitepaper once you have firmly grasped the foundational concepts of KERI. Nevertheless, should you be inclined towards a more rigorous learning approach, you are certainly encouraged to undertake the endeavor.

I also recommend related whitepapers by Dr. Samuel M. Smith as follows:

• Universal Identifier Theory: a unifying framework for combining autonomic identifiers (AID) with human meaningful identifiers.
• Secure Privacy, Authenticity, and Confidentiality (SPAC): the whitepaper that laid the foundation for the ToIP trust-spanning protocol.
• Sustainable Privacy: a privacy-protection approach in the KERI ecosystem.

Read Introductory Contents

Before delving into the whitepaper and related specifications, I recommend the following introductory materials, which helped me personally:

• KERI Presentation at SSI Meetup Webinar, given by the originator of KERI, Dr. Samuel M. Smith, himself
• KERI for Muggles, by Samuel M. Smith and Drummond Reed. This was a presentation given at the Internet Identity Workshop #33.

Note: the author of this blog was first exposed to KERI by this presentation.

• Section 10.8 of “Self-Sovereign Identity” by Alex Preukschat & Drummond Reed, Manning Publication (2021). This section was also written by Dr. Samuel M. Smith.
• The Architecture of Identity Systems, by Phil Windley. Written by one of the most prominent writers in the SSI ecosystem, Phil compared administrative, algorithm, and autonomic identity systems.
• KERISSE, by Henk van Cann and Kor Dwarshuis, this an educational platform as well as a search engine for the KERI ecosystem.

More resources can also be found at https://keri.one/keri-resources/. Of course, this Hitchhiker’s Guide to KERI series has also been written as one such introductory content.

Read the KERI and Related Specifications

As of 2024, the specifications for KERI and related protocols are being developed by the ACDC (Authentic Chained Data Container) Task Force under the Trust over IP (ToIP) Foundation. Currently, there are four specifications:

• Key Event Receipt Infrastructure (KERI): the specification for the KERI protocol itself.
• Authentic Chained Data Containers (ACDC): the specification for the variant of Verifiable Credentials (VCs) used within the KERI ecosystem.
• Composable Event Streaming Representation (CESR): the specification for a dual text-binary encoding format used for messages exchanged within the KERI protocol.
• DID Webs Method Specification: the specification did:webs method that improves the security property of did:web with the KERI protocol.

There are also two related protocols, which do not have their own dedicated specifications:

• Self-Addressing Identifier (SAID): a protocol for generating identifiers used in the KERI protocol. Almost all identifiers in KERI are SAIDs, including AIDs, ACDCs’ identifiers, and schemas’ identifiers.
• Out-Of-Band-Introduction (OOBI): a discovery mechanism for AIDs and SAIDs using URLs.

To learn about these specifications, I also recommend my blog, the KERI jargon in a nutshell series.

Note: The KERI community intends to eventually publish the KERI specifications in ISO. However, this goal may take several years to achieve.

Check out the KERI Open-Source Projects

The open-source projects related to the KERI protocols and their implementations are hosted in WebOfTrust Github, all licensed under Apache Version 2.0.

Note: Apache License Version 2.0 is a permissive open-source software license that allows users to freely use, modify, and distribute software under certain conditions. It permits users to use the software for any purpose, including commercial purposes and grants patent rights to users. Additionally, it requires users to include a copy of the license and any necessary copyright notices when redistributing the software.

Here are some of the important projects being actively developed by the KERI community:

Reference Implementation: KERIpy

The core libraries and the reference implementation for the KERI protocol have been written in Python, called KERIpy. This is by far the most important project that all other KERI projects are based on.

• KERIpy (Python): https://github.com/WebOfTrust/keripy

KERIpy is also available in Dockerhub and PyPI:

• Dockerhub: https://hub.docker.com/r/weboftrust/keri
• PyPI: https://pypi.org/project/keri/

Edge Agent: Signify

The KERI ecosystem follows the principle of “key at the edge (KATE),” that is, all essential cryptographic operations are performed at edge devices. The Signify projects have been developed to provide lightweight KERI functionalities at edge devices. Currently, Signify is already in Python and Typescript.

• SignifyPy (Python) https://github.com/WebOfTrust/signifypy
• Signify-TS (Typescript) https://github.com/WebOfTrust/signify-ts

Signify is also available in PyPI and NPM:

• PyPI: https://pypi.org/project/signifypy/
• NPM: https://www.npmjs.com/package/signify-ts

Cloud Agent: KERIA

Signify is designed to be lightweight and is reliant on a KERI cloud agent, called KERIA. KERIA helps with data storage and facilitates communication with external parties. As mentioned above, all essential cryptographic operations are performed at the edge using KERIA. Private and sensitive data are also encrypted at the edge before being stored in a KERIA server.

• KERIA (Python): https://github.com/WebOfTrust/keria

KERIA is also available in Dockerhub:

• Dockerhub: https://hub.docker.com/r/weboftrust/keria

Browser Extension: Polaris

The browser extension project is based on Signify-TS for running in browser environments. There is also a companion repository called the Polaris Web for building frontend applications that are compatible with the Signify browser extension.

• Signify Browser Extension: https://github.com/WebOfTrust/signify-browser-extension
• Polaris web: https://github.com/WebOfTrust/polaris-web

Note: The Signify browser extension project was funded by Provanant Inc. and developed by RootsID. The project has been donated to the WebOfTrust Github project under Apache License Version 2.0.

Study KERI Command Line Interface (KLI)

Once you grasp the basic concept of KERI, one of the best ways to start learning about the KERI protocol is to work with the KERI command line interface (KLI), which uses simple bash scripts to provide an interactive experience.

I recommend the following tutorials on KLI:

• KERI & OOBI CLI Demo, by Phillip Feairheller & Henk van Cann.
• KERI KLI Tutorial Series, by Kent Bull. Currently, two tutorials are available: (1) Sign & Verify with KERI and (2) Issuing ACDC with KERI.

Many more examples of KLI scripts can be found in the KERIpy repository, at:

• KLI demo scripts: WebOfTrust/keripy/scripts/demo.

While KLI is a good introductory program for learning the KERI protocol, it is crucial to note that KLI is not suitable for developing end-user (client-side) applications in a production environment.

Note: KLI can be used in production for server-side applications.

Build an App with Signify and KERIA

For building a KERI-based application in production environments, it is recommended by the KERI community to utilize Signify for edge agents and KERIA for cloud agents. These projects were specifically designed to complement each other, enabling the implementation of “key at the edge (KATE)”. That is, essential cryptographic operations are performed at edge devices, including key pair generation and signing, while private and sensitive data are encrypted before being stored in an instance of KERIA cloud agent.

The Signify-KERIA protocol by Philip Feairheller can be found here:

• Signify/KERIA Request Authentication Protocol (SKRAP): https://github.com/WebOfTrust/keria/blob/main/docs/protocol.md

The API between a Signify client and KERIA server can be found here:

• KERI API (KAPI): https://github.com/WebOfTrust/kapi/blob/main/kapi.md

Example Signify scripts for interacting with a KERIA server can also be found here:

• Example scripts: https://github.com/WebOfTrust/signify-ts/tree/main/examples/integration-scripts

Join the KERI Community!

To embark on your KERI journey, I recommend joining the KERI community. As of April 2024, there are three primary ways to engage:

Join the WebOfTrust Discord Channel

The WebOfTrust Discord channel is used for casual discussions and reminders for community meetings. You can join with the link below:

• https://discord.gg/YEyTH5TfuB.

Join the ToIP ACDC Task Force

The ACDC Task Force under the ToIP foundation focuses on the development of the KERI and related specifications. It also includes reports on the news and activities of the community’s members as well as in-depth discussions of related technologies.

The ACDC Task Force’s homepage can be found here:

• https://wiki.trustoverip.org/display/HOME/ACDC+(Authentic+Chained+Data+Container)+Task+Force

Currently, they hold a meeting weekly on Tuesdays:

• NA/EU: 10:00–11:00 EST / 14:00–15:00 UTC
• Zoom Link: https://zoom.us/j/92692239100?pwd=UmtSQzd6bXg1RHRQYnk4UUEyZkFVUT09

For all authoritative meeting logistics and Zoom links, please see the ToIP Calendar.

Note: While anyone is welcome to join meetings of ToIP as an observer, only members are allowed to contribute. You can join ToIP for free here.

Join the KERI Implementer Call

Another weekly meeting is organized every Thursday:

• NA/EU: 10:00–11:00 EST / 14:00–15:00 UTC
• Zoom link: https://us06web.zoom.us/j/81679782107?pwd=cTFxbEtKQVVXSzNGTjNiUG9xVWdSdz09

In contrast to the ToIP ACDC Task Force’s meeting, the implementer call focuses on the development and maintenance of the open-source projects in WebOfTrust Github. As a result, the weekly Thursday meetings tend to delve deeper into technical details.

Note: There is also a weekly meeting on DID Webs Method every Friday. See the ToIP DID WebS Method Task Force’s homepage here: https://wiki.trustoverip.org/display/HOME/DID+WebS+Method+Task+Force.

The Hitchhiker’s Guide to KERI. Part 3: How do you use KERI? was originally published in Finema on Medium, where people are continuing the conversation by highlighting and responding to this story.

vLEI Demystified Series:

• Part1: Comprehensive Overview
• Part 2: Identity Verification
• Part 3: QVI Qualification Program

This blog is the second part of the vLEI Demystified series. Part 1 of the series outlines different stakeholders, their roles, and six types of credentials that are involved in the trust chain and the foundational structures of the vLEI ecosystem. This part delves deeper into the qualifications and verification procedures that persons representing these organizations have to go through prior to the issuance of vLEI credentials.

Overview of vLEI Identity Verification

Before participating in the vLEI ecosystem, including obtaining and issuing vLEI credentials, the representatives of all organization stakeholders must undergo rigorous identity verification processes to confirm their legal identity.

Note: Legal identity is defined as the basic characteristics of an individual’s identity. e.g. name, sex, place, and date of birth conferred through registration and the issuance of a certificate by an authorized civil registration authority following the occurrence of birth. [Ref: https://unstats.un.org/legal-identity-agenda/]

With some exceptions, authorized representatives of each organization stakeholder are responsible for performing identity verification on representatives of organizations downstream within the vLEI trust chain. That is, GLEIF verifies qualified vLEI issuers (QVIs), QVIs verify legal entities (LEs), and LEs verify role representatives, as shown below.

Note: The authorized representatives are the persons designated by an organization (either GLEIF, a QVI, or a legal entity) to officially represent the organization.

Note: There are two types of role representatives: official organization role (OOR) and engagement context role (ECR).

GLEIF Authorized Representative (GARs)

GARs are controllers of the GLEIF Root AID, GLEIF Internal Delegated AID (GIDA), and GLEIF External Delegated AID (GEDA).

As the root of trust of the vLEI ecosystem, GLEIF established an internal process to verify their GARs, as outlined in the GLEIF Identifier Governance Framework. This includes:

• The policies and processes for the genesis events of the GLEIF Root AID, GIDA, and GEDA
• Detailed identity verification process of all GARs where they mutually authenticate each other
• Contingency plans such as a designated survivor policy as well as restrictions on joint travel and in-person attendance of meetings.

Designated Authorized Representative (DAR)

DARs are representatives authorized to act on behalf of a Qualified vLEI Issuer (QVI) or an LE.

• Identity verification on a QVI’s DAR is performed by an external GAR.
• Identity verification on an LE’s DAR is performed by a QAR.

Qualified vLEI Issuer Authorized Representatives (QARs)

A QAR is a representative designated by a QVI’s DAR to carry out vLEI operations with GLEIF and LEs.

• Identity verification on a QAR is performed by an external GAR.

This process is detailed in Qualified vLEI Issuer Identifier Governance Framework and vLEI Credential Framework.

Legal Entity Authorized Representatives (LARs)

An LAR is a representative designated by an LE’s DAR to request the issuance and revocation of LE vLEI credentials and Role vLEI credentials.

• Identity verification on an LAR is performed by a QAR.

This process is detailed in Legal Entity vLEI Credential Framework.

Role Representatives (OOR and ECR Persons)

A role representative, either an OOR or ECR person, is designated by an LAR to represent an LE in a functional or official organization role, respectively. The identity verification process for a role representative depends on whether an authorization vLEI credential is used, see Part 1 of the series for more detail.

• In the case where an authorization vLEI credential is used, identity verification on a role representative is performed by both a QAR and an LAR.
• In a case where an LE issues a role vLEI credential directly without using an ECR authorization vLEI credential, identity verification of an ECR person needs to be performed by only a LAR.

This process is detailed in the following documents:

• Qualified vLEI Issuer Authorization vLEI Credential Framework
• Legal Entity Official Organizational Role vLEI Credential Framework
• Legal Entity Engagement Context Role vLEI Credential Framework

Identity Verification Processes

The identity verification process of all representatives in the vLEI ecosystem includes two subprocesses namely:

• Identity Assurance Process, which verifies the veracity and existence of a legal identity, as well as binding the legal identity to a representative
• Identity Authentication Process, which binds the representative to an autonomic identifier (AID)

Once the identity verification process is completed, a vLEI credential may be subsequently issued to the AID that has been bound to the representative.

Identity Assurance

The first stage of identity verification for the vLEI ecosystem is called identity assurance. This step involves an identity proofing process to verify the legal identities of all individuals prior to obtaining vLEI credentials. The vLEI Ecosystem Governance Framework (EGF) requires that Identity Assurance is performed according to Identity Assurance Level 2 (IAL2) as defined in NIST SP 800–63A.

The National Institute of Standards and Technology (NIST) standardized the identity proofing process in their Special Publication (SP) 800–63A. Although originating in the United States, SP 800–63A is one of the most influential standards for identity proofing and is widely referenced by various industries and governments worldwide.

Identity Assurance Level

NIST SP 800–63A has categorized the degrees of assurance in one’s identity into 3 levels:

• Identity Assurance Level 1 (IAL1): The service provider is not required to validate or link the applicant’s self-asserted attributes to their real-life identity.
• Identity Assurance Level 2 (IAL2): Either remote or physical identity proofing is required at this level. The applicant’s submitted evidence supports the real-world their real-world identity and verifies that the applicant is accurately linked to this identity.
• Identity Assurance Level 3 (IAL3): Physical presence is required for the identity proofing process at this level. Identifying attributes must be verified by an authorized and trained service provider representative.

Only IAL2 is relevant in the context of the vLEI EGF.

Identity Resolution, Validation, and Verification

Identity proofing in NIST SP 800–63A consists of three main components, namely:

• Identity Resolution: a process for uniquely distinguishing an individual within a given context.
• Identity Validation: a process for determining the authenticity, validity, and accuracy of the identity evidence
• Identity Verification: a process for establishing a linkage between the claimed identity and the person presenting the identity evidence.

For example, an applicant for a vLEI credential could present a verifier with a set of required identity evidence. The verifier must resolve the applicant’s legal identity and validate that the presented information on the collected evidence is legitimate. Validation may involve confirming the information with an authoritative source and determining that there is no alteration to the images and data of the presented evidence. Subsequently, the verifier may verify the applicant by comparing the applicant’s live image with the one displayed on the provided identity evidence.

Identity Evidence Collection

During identity resolution and validation, the collection of “identity evidence” is required to establish the uniqueness of the individual’s identity.

Note: Identity evidence is defined as information or documentation provided by the applicant to support the claimed identity. Identity evidence may be physical (e.g. a driver’s license) or digital.

To comply with IAL2, one of the following sets of identity evidence must be collected:

• a piece of STRONG or SUPERIOR evidence if the evidence’s issuing source confirmed the claimed identity by collecting at least two forms of SUPERIOR or STRONG evidence before and the service provider validates the evidence with the source directly; OR
• two pieces of STRONG evidence; OR
• one piece of STRONG evidence plus two pieces of FAIR evidence

NIST SP 800–63A defines five tiers of identity evidence’s strength: UNACCEPTABLE, WEAK, FAIR, STRONG, and SUPERIOR. While the strength of specific identity evidence, e.g., a driver’s license, may vary across jurisdictions, NIST provides examples of common evidence and their estimated strength, based on their general quality characteristics, for instance:

• SUPERIOR: passports and permanent resident cards
• STRONG: driver’s licenses and U.S. military ID cards
• FAIR: school ID cards and credit/debit cards

Further details on the ​​strengths of identity evidence can be found in Section 5.2.1 on the NIST SP 800–63A.

Identity Authentication

After completing identity assurance, an organization representative who applies for a vLEI credential may proceed to identity authentication, which establishes a connection between the representative — whose legal identity has been assured to meet IAL2 — to an autonomic identifier (AID).

Once such a connection has been established, a vLEI credential could be issued to the AID with confidence that the representative is the sole controller of the AID. Subsequently, the representative may cryptographically prove their control over the AID and the issued vLEI credential.

Note: An autonomic identifier (AID) is a persistent self-certifying identifier (SCID) that is derived and managed by cryptographic means without reliance on any centralized entity or distributed ledger technology.

Credential Wallet Setup

Before identity authentication can begin, a credential wallet must be set up for the organization representative. The primary role of a credential wallet includes:

• Creation, storage, and management of key pairs
• Creation, storage, and management of AIDs.
• Digital signature creation and verification

The specification for a credential wallet is detailed in Technical Requirements Part 1: KERI Infrastructure. The credential wallet must also be used during the live Out-of-band-Introduction (OOBI) session to complete the identity authentication process.

Note: A credential wallet for vLEI credentials is essentially a KERI-compatible identity wallet. It must be compliant with three specifications currently being developed under the Trust Over IP (ToIP) Foundation, namely, KERI, ACDC, and CESR specifications.

Out-of-band-Introduction (OOBI) Protocol

The identity authentication process is implemented using the Out-of-band-Introduction (OOBI) Protocol, which is a protocol defined in the ToIP Key Event Receipt Infrastructure (KERI) specification. The OOBI protocol provides a discovery mechanism for verifiable information related to an AID — including its key event log (KEL) and its service endpoint — by associating the AID with a URL.

For example, an AID EaU6JR2nmwyZ-i0d8JZAoTNZH3ULvYAfSVPzhzS6b5CM may provide a service endpoint at www.example.com with an OOBI URL of

http://www.example.com/oobi/EaU6JR2nmwyZ-i0d8JZAoTNZH3ULvYAfSVPzhzS6b5CM

The OOBI protocol is “out-of-band” as it enables any internet and web search infrastructure to act as an “out-of-band” infrastructure to discover information that is verified using the “in-band” KERI protocol. The OOBI protocol leverages the existing IP and DNS infrastructure for discovery so that a dedicated discovery network is not needed.

Note: The OOBI by itself is insecure, and the information discovered by the OOBI must be verified using the KERI protocol.

This OOBI URL may be used to discover the AID’s KEL as well as send messages to the AID, including sending a challenge message in a challenge-response protocol and sending a vLEI credential.

Challenge-Response Protocol

To establish a connection between a representative and an AID, the challenge-response protocol is implemented to ensure that the representative holds the private key that controls the AID.

With the OOBI protocol, the verifier uses the OOBI URL as a service endpoint to deliver the challenge message to the AID controller. The verifier of an AID then generates a random number as a challenge message and sends it to the AID controller. The AID controller then uses the private key associated with the AID to sign a digital signature on the challenge. The signature is the response to the challenge message and is returned to the verifier. Finally, the verifier verifies the response using the public key of the AID.

Man-In-the-Middle Attack

However, there is a risk that an attacker could intercept the communication between the representative and the verifier in a man-in-the-middle (MITM) attack. Here, the attacker obtains the authentic OOBI URL, which contains the representative’s AID, and sends a false OOBI URL, which instead contains the attacker’s AID, to the verifier.

Real-time OOBI Session

To mitigate the risk of an MITM attack, the vLEI EGF specifies an authentication process that is called a real-time OOBI session that a representative and their verifier must complete before issuance of a vLEI credential.

During a real-time OOBI session, the representative and the verifier must organize a real-time in-person or a virtual face-to-face meeting, e.g., using a Zoom call. For a virtual face-to-face meeting, there are extra requirements as follows:

• The meeting must be continuous and uninterrupted throughout the entire OOBI session.
• Both audio and video feeds of all participants must be active throughout the entire OOBI session.

The OOBI session consists of the following steps:

1) The identity verifier performs manual verification of the representative’s legal identity, which has been verified during the identity assurance process. For example, if the representative had provided a passport as their identity evidence during identity assurance, they may present the passport to the verifier once again during their live session.

2) After the verifier confirms that the evidence is accurately associated with the representative present in the meeting, they must exchange their AIDs through an out-of-band channel. For example, OOBI URLs can be shared in the live chat of a Zoom call or shared via QR codes via video feeds.

3) The verifier sends a unique challenge message to cryptographically authenticate the representative’s AID.

4) The representative uses their private key that is associated with the AID to sign and respond to the challenge.

5) The verifier verifies the response using the public key obtained from the AID’s key event log (KEL).

6) The challenge-response protocol is repeated where the representative is now the challenger and the verifier the responder.

Group Real-time OOBI Session for QARs and LARs

For issuance of QVI and LE vLEI credentials, all QARs and all LARs of the candidate QVI and LE, respectively, must be present in the real-time OOBI session.

• For the issuance of a QVI vLEI credential, 2 External GARs and at least 3 QARs must be present during the real-time OOBI session.
• For the issuance of a LE vLEI credential, 1 QAR and at least 3 LARs must be present during the real-time OOBI session.

Once the Authentication steps are completed, the identity verifier can now sign the vLEI credential to the representatives of the vLEI candidate organizations. However, the vLEI credential issuance process cannot be completed by a single representative. To meet the required weight threshold of the multi-signature scheme stated in the vLEI EGF, another representative in control of the issuer’s AID must combine the authority and approve the vLEI issuance. For instance, a QAR may perform the required verification processes on all LARs of an LE and initiate the issuance of an LE vLEI credential. At least one other QAR must review and approve the issuance.

Conclusion

While the verification processes that applicants seeking vLEI credentials have to complete before the issuance might appear rather involved, these thorough steps to verify the identity of individuals representing organizations are crucial to safeguarding against identity theft, impersonation, and other fraudulent activities across various industries. After the identity assurance process validates the legal identities of representatives, and the identity authentication process cryptographically associates the representatives to AIDs. After identity verification, vLEI credentials may be issued with confidence, maintaining the integrity and reliability of the vLEI ecosystem.

vLEI Demystified Part 2: Identity Verification was originally published in Finema on Medium, where people are continuing the conversation by highlighting and responding to this story.