In this step, we'll implement a modal that allows users to add new contacts by alias within the app. This process includes initializing the agent, connecting it to WebSocket (WS) sessions, and adding contacts to the app using the One37ID SDK.

The AddressActivity prompts the user to enter their address information, including street, city, province, country, and zip code.

The AmountActivity requests a numeric input, such as an amount to be paid, a quantity, or any numeric value required by the workflow.

This document explains the structure of the payload object used in credential issuance. It outlines its key components, role, and usage, providing a comprehensive understanding of how the payload object functions within the system.

The Browser Registration feature allows users to securely register browsers with the One37ID system. This functionality ensures that only authorized devices are recognized as trusted browsers, improving overall security. The registration process involves scanning a QR code, entering a registration code, and assigning a browser name, which are subsequently encrypted and stored as trusted identifiers.

Welcome to the world of One37ID SDK! Imagine you're tasked with creating a secure, user-friendly app that handles verifiable credentials (think: digital IDs, business cards, or secure contact sharing). Don’t worry—it sounds more complex than it is.

The Camera Activity allows the user to either capture a photo or scan a QR code, depending on the specific requirements of the workflow.

The Alias Manager in the One37ID SDK is responsible for managing aliases, which are identifiers that can be used to represent entities (such as users or organizations) within the system. This manager allows for a range of operations related to aliases, such as creating new aliases, enabling or disabling them, checking their availability, and syncing or moving them between wallets. The Alias Manager helps ensure that aliases are unique and can be managed effectively across different connections.

The ContactManager class is responsible for managing connections (contacts) within the One37ID platform. It provides a range of methods for tasks like adding, removing, and listing contacts, as well as verifying emails and retrieving connection flows.

The Credential Manager interacts with the agent to handle credentials, allowing operations such as fetching stored credentials, verifying their integrity (e.g., ensuring JWT-based credentials are valid), and deleting them when no longer needed. It also supports error handling during verification and storage processes.

The Notification Manager is responsible for handling all tasks related to notifications within the system. It provides methods to fetch, process, and delete notifications, ensuring that the user is always up to date with important events. It integrates with the agent to handle notifications effectively and can be used to process updates, clear notifications, and retrieve new ones.

The PeerToPeerManager is responsible for handling peer-to-peer data exchanges between users, specifically for initiating and managing proof requests. It allows one user (the initiator) to send a proof request to another user (the receiver), requesting specific information such as verified credentials or self-attested data. The manager facilitates various types of proof requests, including self-attested information, SD-JWT data, and verified email, ensuring that data exchanges occur securely and according to specified formats.

The BrowserRegistrationManager (or TrustBrowserManager as it's named in the code) is responsible for managing trusted browsers within an application. It allows the system to recognize, register, and manage browsers that are deemed secure and trusted for accessing the system. The manager supports operations such as retrieving a list of trusted browsers, adding a new trusted browser, enabling or disabling browser access, and removing browsers from the trusted list.

The first key action a user will take is creating a wallet. This wallet will contain the user's first name, last name, and email address, which are necessary for identification and email verification.

Workflows are a sequence of steps that define the logic and flow of a process. They are used to automate business processes, manage data, and coordinate tasks. The Workflow Engine provides a flexible and scalable platform for creating and executing workflows.

The CreditCardActivity collects credit card information from the user, such as cardholder name, card number, expiration date, and CVV.

Overview

This document provides a detailed explanation of the payload object model used in data requests, outlining its structure, components, and examples.

This document provides a detailed explanation of the restrictions model used within the ProofRequestCredential class. The restrictions model defines the constraints for credentials, ensuring that only the intended schemas, issuers, and attributes are used.

This activity requests the user to select a date, time, or both.

In development and testing environments, you can deploy the One37 Platform and support applications all on the same host using Docker Compose.

Introduction

This section of the developer guide focuses on handling proof requests and responses within the One37ID SDK, specifically focusing on acquiring and verifying verifiable credentials.

Now that you've initialized the One37ID agent and handled email verification, it’s time to display all the user’s connections (or contacts) in the app. A connection in this context is a secure relationship established between the user and another party, such as a business.

In this section, we'll walk through how to display and manage verifiable credentials associated with a business contact using the One37ID SDK. We’ll implement a screen where users can view, delete, and initiate new flows for exchanging credentials.

This document explains how the agentAlias field is encoded, the purpose of each part, and provides examples to clarify its structure and usage.

This documentation provides a detailed overview of all the routes and endpoints available in the Workflow Engine. Each endpoint is described with its HTTP method, URL, expected payload, and response format.

Purpose:

Overview

The Workflow Activity Callbacks are a set of pre-built utility functions available in the SDK that may be triggered by a user interaction (button etc) or initiated during the execution of a business workflow activity.

Aliases are a way to manage multiple user identities or profiles within your app. Each alias can be incognito or standard, and the app offers options to enable, disable, or delete these aliases. Aliases can be managed across multiple devices, providing users with a seamless experience.

This document provides detailed information about the ip and bfphash metadata fields, their purpose, and usage within your application workflows.

The multi-line activity is designed to capture a block of text or a detailed message.

Before we dive into the code, let’s make sure you have everything you need to get started. Here’s a quick checklist:

Introduction

This activity allows the user to select from multiple options.

Pending actions refer to actions within the application that have not yet received a response. For example, when a user initiates a workflow to validate a driver’s license and reaches the proof request/response screen, if the user doesn’t submit data back to the verifier, the action remains pending. These pending actions can be monitored and managed within the application.

The Wokflow Enging can only run workflows that are published.

In this section, we’ll focus on how to trigger and manage flows (activities) for a specific contact. The SDK allows users to run various credential exchange flows, and when a flow is initiated, specific activity callbacks are triggered based on the type of data being exchanged.

The Workflow Engine API provides two main endpoints for operation and are called with properly formatted POST requests.

This activity is used to capture a single line of text from the user, such as a first name, last name, or any simple textual input.

The Workflow Engine (WFE) is a collective referrence to the scalable process execution environment that consists of one or more co-ordinated engine instances or Nodes.

System attributes are essential metadata elements embedded within each credential in the Wallet. These attributes define key aspects of the credential, such as its classification, identity verification level, type, and specific metadata details unique to each credential type. Each credential carries its own set of system attributes. These attributes enable the wallet to interpret, categorize, and apply the credentials within the user's digital identity in a structured and secure manner.

The trust network object, referred to as trustInfo, provides information regarding the trust level of the browser, network, and business. This data allows for a secure verification of user interactions by assessing the reliability of these elements, enhancing overall trust. It can be used within proof request and response screens and can also display visual indicators (e.g., icons with color coding) to reflect the trust level of each attribute.

After the user creates the wallet and inputs their email, they will receive a verification email. The One37ID SDK simplifies this with the startEmailVerificationFlow() function, which sends a verification email to the user.