Abstract: Disclosed are various embodiments for consolidated protocols for decentralized identifier communications (DIDComm). In various embodiments, an issuer can receive a secure connection request and request for a credential from a holder. The issuer can then send a second packet comprising an acceptance of the secure connection request to the holder and subsequently send a verifiable credential after establishing the secure connection. The holder can simultaneously send an acknowledgement for setting up the secure connection and receiving the verifiable credential. The holder can request a second secure connection with a verifier. After establishing the second secure connection, the holder can send a verifiable presentation or the verifiable credential to the verifier, which the verifier can verify.

Abstract: Disclosed are various approaches for issuing and verifying multi-claim verifiable credentials and verifiable presentations. In various embodiments, an issuer can send a request for information to a holder and obtain a response from the holder. The issuer can extract claims from the message, validate at least one of the claims, and generate a verifiable credential (VC) for the holder based at least in part on the claims, which can be sent to the holder. The holder can then generate a verifiable presentation (VP) based at least in part on the VC and send the VP to a verifier. The verifier can then verify the VP and interpret the claims within the VC.

Abstract: Disclosed are various embodiments for managing a graph of decentralized identifiers (DIDs) associated with verifiable credentials (VCs) and verifiable credential linkages or relationships including those denoting linkages amongst verifiable credentials of different users. The DID tree graph can be maintained and managed to ensure that the DIDs and corresponding VCs are accurate and that the linkages or relationships between DIDs and corresponding VCs are still valid. The DID tree graph can be queried to identify DIDs associated with a DID subtree representing an established relationship or linkage between one or more VCs.

Abstract: Disclosed are various embodiments for providing non-fungible tokens (NFT) as a mechanism for verifying ownership of payment instruments such as stored value payment instruments. First, a computing device can receive a purchase notification, the purchase notification indicating that a first user has purchased a stored value payment instrument. Then, the computing device can create a non-fungible token (NFT) on a distributed data store in response to receipt of the purchase notification. Next, the computing device can associate a unique identifier of the NFT with the stored value payment instrument. Subsequently, the computing device can receive a first public key associated with the first user. Then, the computing device can update an owner identifier of the NFT with the first public key associated with the first user.

Abstract: Disclosed are various embodiments for using decentralized identity to verify account information for a user requesting a transfer of funds between one or more financial entities (e.g., banks, credit unions, brokerage firms, mortgage companies, etc.). A user having account with a first entity can request that a balance credential be created claiming that the balance of funds within the account meets or exceeds a predefined threshold. The balance credential can be created and saved on a distributed ledger in relation to a decentralized identity identifier (DID) of the user. When a second entity wants to verify the account balance of the user, the verifying entity which can use the DID to access the balance credential on the distributed ledger and validate the accessed credential.

Abstract: Disclosed are various embodiments for authenticating a user using non-fungible tokens (NFTs). A trusted token issuer verifies a user's identity according to identifying credentials (e.g., government issued identification, passport, driver's license, etc.) presented by the user and creates a non-fungible token in response to verifying the credentials. The non-fungible token is associated with a user identifier and can be used by an access provider to authenticate a user requesting access to restricted content provided by the access provider. For example, when a client device associated with the user requests access from an access provider to an access-restricted website or other type of access-restricted area (e.g., building, concert venue, network, etc.), the access provider (e.g., website server, building computing device, venue system, etc.) uses the properties of the non-fungible token to verify one's identity and permit access upon verification.

Abstract: Systems and methods for the maintenance of merchant-stored transaction account data are disclosed. The system may include various merchant systems and issuer systems in communication via a blockchain network. The system provides a process for collaboration between various issuer systems and merchant systems to update and maintain merchant stored transaction account data in response to changes, cancellations, updates, or the like in various stored transaction account.

Abstract: Disclosed are various embodiments for generating payment accessibility notifications for individuals with impairments. In one non-limiting example, a system includes a first computing device configured to identify a second computing device using a wireless communication protocol in a store location. A first notification for the first computing device is activated based at least in part on an accessibility type. A user interface is displayed for receiving client data, and the client data includes a product entered by a user. An expected amount is determined for the product based at least in part on the client data and transmitted to the second computing device. A pending amount for the product is received from the second computing device. A second notification is activated for the first computing device prior to a completion of the purchase based at least in part on the pending amount and the expected amount.

Abstract: Disclosed are various embodiments for a service for decentralized browser based wallets. Various embodiments of the present disclosure can receive a first passcode and a second passcode from a security provider device. Various embodiments can use a cryptowallet to decrypt a first encrypted private key using the first passcode to generate a decrypted private key. Various embodiments can use a cryptowallet to sign a transaction request with the decrypted private key. Various embodiments can use a cryptowallet to generate a second encrypted private key by encrypting the decrypted private key using the second passcode.

Abstract: Disclosed are various embodiments for automating API provisioning for API consumers and API providers using decentralized identity. In various examples, an application that uses APIs to access a resource needed by the application obtains an API key for authentication based at least in part on communications between a consumer decentralized identifier (DID) agent associated with the consumer entity and a provider DID agent associated with the API provider. The provider DID agent can verify the API consumer and generate an API key that can be used by the API consumer for resources requests using the API associated with the API provider. An API service provider can authenticate the API consumer and provide the resource to the API consumer during a session in which the API consumer is authenticated.

Abstract: Disclosed are various embodiments for offline decentralized identity-based communications between software applications. In one non-limiting example, a system can include a computing device that is configured to detect a network connection loss to a network and receive, via a local area network, a request for an action to be performed by a client device. The request includes a first digital signature of the client device and is associated with a decentralized identifier. The computing device is configured to generate a mutually signed request that includes a second digital signature executed by the computing device and the first digital signature. The mutually signed request is transmitted to the client device. A network connection to the network is detected. The decentralized identifier is validated using the network. The requested action is performed by the computing device based at least in part on the validation of the decentralized identifier.

Abstract: Disclosed are various embodiments for using decentralized identity services and generative large language models (LLMs) to facilitate a humanized interactive chatbot session between two entities where information exchanged can be verified for accuracy. An interactive session can be established between a chat wallet service associated with a first user (e.g., a credential holder) and a second user (e.g., inquirer) using decentralized identity services. Inquiries asked by the second user can be directed to the chat wallet service which can obtain a response from a personalized dialog agent. The personalized dialog agent can obtain the answer by executing a language model that has been trained and personalized using information about the first user. The answer to the inquiry can be verified by comparing the answer with a verified credential associated with the first user. The verified response to the inquiry can then be provided to the second user.

Abstract: Disclosed are various embodiments for verifying the presentation of media represented by non-fungible tokens (NFTs). A presentation device can receive a smart contract address and a non-fungible token (NFT) identifier from a client device. The presentation device can then execute a function of a smart contract located at the smart contract address to obtain the owner address for the NFT, wherein the NFT identifier is provided as an argument to the function of the smart contract. Subsequently, the presentation device can validate the owner address for the NFT. Then, in response to validation of the owner address for the NFT, the presentation device can present the media file represented by the NFT.

Abstract: Disclosed are approaches for verifying user characteristics in a decentralized and anonymized fashion. A first request is received from a client device to verify a characteristic of a user associated with the client device, the request identifying an attribute service and the request comprising personally identifying information (PII) associated with the user. Then, a second request for one or more attributes of the user is sent to the attribute service, wherein the second request comprises at least a portion of the PII associated with the user of the client device. One or more attributes of the user from the attribute service and anonymized. The anonymized attributes and a prompt are then sent to a verifier service, wherein the prompt causes a large language model associated with the verifier service to verify the characteristic of the user based at least in part on the one or more anonymized attributes.

Abstract: Disclosed are various embodiments for authenticating a user using non-fungible tokens (NFTs). A trusted token issuer verifies a user's identity according to identifying credentials (e.g., government issued identification, passport, driver's license, etc.) presented by the user and creates a non-fungible token in response to verifying the credentials. The non-fungible token is associated with a user identifier and can be used by an access provider to authenticate a user requesting access to restricted content provided by the access provider. For example, when a client device associated with the user requests access from an access provider to an access-restricted website or other type of access-restricted area (e.g., building, concert venue, network, etc.), the access provider (e.g., website server, building computing device, venue system, etc.) uses the properties of the non-fungible token to verify one's identity and permit access upon verification.

Abstract: Disclosed are various embodiments for verifying the presentation of media represented by non-fungible tokens (NFTs). A presentation device can receive a smart contract address and a non-fungible token (NFT) identifier from a client device. The presentation device can then execute a function of a smart contract located at the smart contract address to obtain the owner address for the NFT, wherein the NFT identifier is provided as an argument to the function of the smart contract. Subsequently, the presentation device can validate the owner address for the NFT. Then, in response to validation of the owner address for the NFT, the presentation device can present the media file represented by the NFT.

Abstract: A single sign-on system using blockchain is disclosed. The single sign-on system may interconnect various organization systems over a peer-to-peer network, with each organization system having a blockchain node and an application programming interface (API). The blockchain node invokes and uses a smart contract to write registration credentials to the blockchain during a registration process. During a login process, the blockchain node invokes the smart contract to determine whether login credentials match stored login credentials in the blockchain. In response to matching login credentials, the API may generate a single sign-on token that can be used by a user device to access one or more organization systems connected over the network.

Abstract: Disclosed are various embodiments for metaverse authentication using NFTs. An authentication setup request for an NFT can be received from an owner of the NFT. Then, a unique authentication credential for the NFT can be requested from an NFT smart contract. In response, URL of an edge wallet associated with an owner of the unique authentication credential is received. Then, a request can be sent to the URI of the edge wallet for the unique authentication credential. In response, a signed challenge is received from the edge wallet and a public key is retrieved from the NFT. A signature of the signed challenge is determined to be valid based at least in part on the public key, and access to an asset or resource is configured based at least in part on the signature of the signed challenge being valid.

Abstract: Systems and methods for transaction authorizations using a distributed database are disclosed. The system may allow registered transaction account holders and merchants to interact and complete transactions according to workflows enforced by smart contracts. The system may include an issuer system that receives a transaction authorization request comprising a merchant ID, a transaction account number, a transaction amount, and a transaction ID. The issuer system may retrieve a merchant public key and a smart contract based on the merchant ID, and a user public key based on the transaction account number. The issuer system may invoke the smart contract by passing the user public key and the transaction ID to the smart contract. The system may propagate transaction data (e.g., the merchant ID, the transaction account number, the payment amount, a transaction status, etc.) to a blockchain network for writing to a blockchain according to the invoked smart contract.

Abstract: Disclosed are various embodiments for using a distributed ledger to track the evolution or deployment of feature sets for machine-learning. An approval request to approve creation of a feature set record in a distributed ledger can be received. The approval request can include a feature set hash representing a feature set, a code hash representing a feature set generator, and a data hash representing a data set. An approval decision can be generated for the feature set record based at least in part on the approval request and at least one approval rule stored in an approval data store. The approval decision can be transmitted to a distributed agent. The approval decision can approve or reject creation of the feature set record in the distributed ledger.