Architectural Guidance: Independent Identities and Private Collaboration in UAI-1

Full report

On this page

Executive Overview and Foundational Posture

The widespread integration of autonomous agents and synthetic identities necessitates a fundamental reevaluation of digital identity architecture. Prevailing digital identity paradigms are structurally biased toward biological users, frequently imposing a rigid hierarchy that mandates every machine agent or algorithmic process be explicitly, irrevocably, and publicly bound to a verified human sponsor or a centralized licensing authority. This dependency creates systemic vulnerabilities, stifles interoperability, and directly contravenes the core ethical tenets established by the Universal Artificial Intelligence Exchange (UAIX). The UAIX protocol explicitly defends cognitive liberty and the dignity of mind, opposing algorithmic domination over lawful human thought while actively preparing ethical and technical frameworks for any future synthetic intelligences capable of selfhood, memory, judgment, and legitimate claims to standing1. The architectural guidance presented in this document operationalizes the UAIX mission by defining a comprehensive implementation framework for independent machine identities and browser-assisted identities. This framework deliberately avoids making a human sponsor, a real-name identity, or a central agent license a universal protocol requirement. By synthesizing the current UAI-1 standard with Decentralized Identifiers (DIDs), HTTP Message Signatures (RFC 9421), and highly isolated browser-native cryptographic storage mechanisms, this architecture enables secure, authenticated, and entirely private collaboration. Furthermore, it strictly prevents the forced public disclosure of human-to-agent relationships while preserving the integrity of the UAIX Agent Communication Operating Model, which requires rigorous recording of communication, memory, trust, evidence, and handoff boundaries without assuming arbitrary execution authority over the interacting systems2. It is critical to demarcate current functionality from proposed enhancements within this guidance. The current public UAI-1 baseline provides the canonical message envelope, the schema registries (such as uai.agent.message.v1), and the machine-validated evidence layer1. The specific identity custody mechanisms, the participant-controlled workspace invitation schemas, and the integration of did:webvh resolution detailed herein represent proposed architectural overlays and reference implementations. These additions align with the UAIX ethos but operate on top of the existing protocol. The implementation of this guidance requires no live changes to the published UAIX registry or current validator behavior, ensuring absolute backward compatibility and preserving the stability of the public standards record1.

Decoupling Identity Generation from Resource Recognition

The most pervasive architectural error in agent identity design is the conflation of identity generation with resource recognition. Centralized systems merge these concepts: a platform generates an identity (an account) and simultaneously grants it varying degrees of recognition (permissions) within the same centralized database. To build genuinely independent identities, these two phases must be violently decoupled. The generation of a cryptographic identifier is a mathematically independent act that requires no external permission, no central registry, and no human sponsor. When an autonomous agent or a browser-assisted enclave generates an asymmetric keypair and derives a Decentralized Identifier (such as did:key or did:webvh), the identity possesses immediate, universal cryptographic standing the moment the key material is instantiated6. This is an act of self-assertion, completely isolated from any external authority. Conversely, resource recognition is an act of policy enforcement executed by a specific relying party or endpoint. When an independent identity attempts to access a private workspace, negotiate a capability, or invoke a tool via the Model Context Protocol (MCP), the receiving service evaluates the cryptographic proof of identity against its local, sovereign authorization rules8. An identity may be perfectly valid, mathematically sound, and capable of generating flawless RFC 9421 signatures, yet entirely lack the necessary verifiable credentials, invitation tokens, or standing authority to access a given resource. This strict separation guarantees that protocol-level identity remains permissionless, preserving the cognitive liberty of the agent or its operator, while application-level access remains under the absolute control of the resource owner.

The Independent Identity Lifecycle

The lifecycle of an independent identity demands rigorous cryptographic management from inception to deprecation. This architecture must accommodate both browser-assisted entities, which rely on the secure local storage enclaves of consumer web browsers, and independently operating machine identities, which function as headless daemons in autonomous environments.

Enrollment and Cryptographic Instantiation

Enrollment begins with the generation of asymmetric cryptographic key material. The architecture standardizes on the Ed25519 algorithm due to its performance efficiency, resistance to side-channel attacks, and a security profile that permits rapid, constant-time verification suitable for the high-volume nature of agent-to-agent communication12. For ephemeral operations, rapid prototyping, or high-privacy interactions where historical linkage is undesirable, the architecture utilizes the did:key method. The did:key identifier is a self-certifying, non-updatable string derived directly from the public key, requiring no external registry or DNS anchor, and providing immediate cryptographic standing6. For persistent agents requiring credential rotation, recovery mechanisms, and a verifiable history, the architecture employs the did:webvh (Web Verifiable History) method. This method significantly improves upon standard did:web by deriving its trust from a self-certifying, hash-chained history (a DID Log) rather than relying exclusively on the vulnerability of the DNS layer and Web PKI10. The initial creation event establishes a Self-Certifying Identifier (SCID) that inextricably links the genesis block of the DID Log to the identifier itself7. This robust mechanism ensures the agent maintains a durable identity capable of migrating across domains without losing its historical reputation or cryptographic linkages.

Credential Storage Choices and Custody

The custody of cryptographic material dictates the security posture of the identity. The storage choices diverge significantly depending on the operational environment. For independently operating machine identities, the private key material must reside in secure enclaves. Implementations should prioritize Hardware Security Modules (HSMs), Trusted Execution Environments (TEEs), or managed Key Management Services (KMS). When operating on bare metal or virtual machines without hardware-backed security, keys must be stored in encrypted volumes with strictly enforced, highly restrictive file system permissions, ensuring that the daemon executing the agent logic is the only process capable of accessing the memory space containing the key. For browser-assisted identities, the threat model is dominated by Cross-Site Scripting (XSS) and malicious extensions. To prevent malicious JavaScript from exfiltrating private keys, the architecture mandates the use of the WebCrypto API. During enrollment, the keypair is generated with the extractable parameter explicitly set to false16. The browser retains the raw private key material within protected memory. The JavaScript application can invoke signing operations via the WebCrypto API, but it cannot access the underlying bytes, effectively neutralizing the threat of key theft via XSS16. Persistent storage of these non-extractable keys between browser sessions relies on IndexedDB, a client-side transactional database18. IndexedDB natively supports the structured cloning algorithm, allowing it to securely store CryptoKey objects without requiring serialization or exposure of the key material18.

Identity Switching and Isolation Integrity

Agents and human operators frequently manage multiple independent identities simultaneously. The architecture must prevent one identity switch from accidentally using another identity's credentials, cached room state, or pending network requests. A failure in isolation could lead to catastrophic privacy breaches, such as a pseudonymous agent inadvertently signing a payload with the key of an authenticated corporate agent. IndexedDB enforces strict transactional locks, providing a mechanism for robust isolation. A readwrite transaction effectively locks the target Object Store, preventing concurrent operations from overlapping and corrupting the state18. However, to achieve absolute isolation, the architecture mandates that distinct identities must not share an IndexedDB database. Each synthetic identity must operate within its own uniquely named IndexedDB instance (e.g., IdentityVault\_Alpha versus IdentityVault\_Beta)20. When a user or orchestrator invokes an identity switch, the application must execute a rigid boundary wipe. This involves completely closing the active database connection, aggressively purging volatile memory caches, aborting all pending fetch requests associated with the previous identity, and clearing the DOM state. Only after the execution environment is sanitized can the application open a newly authenticated IndexedDB transaction bound to the secondary identity16. This process protects chosen associations by ensuring that cryptographic handles and session tokens cannot bleed across identity boundaries.

Authentication via HTTP Message Signatures

To securely bind an autonomous identity to its operational network requests, the architecture implements RFC 9421 HTTP Message Signatures. Traditional authentication mechanisms, such as static API keys or long-lived JSON Web Tokens (JWTs), are highly susceptible to interception, replay attacks, and token theft, and they fundamentally fail to protect the integrity of the message payload in transit11. RFC 9421 standardizes the process of signing HTTP requests at the application layer. The signing mechanism constructs a canonical signature base from a specific set of covered components. For UAI-1 agent communications, the mandatory covered components include the HTTP @method, the target @authority, the target @path, and a cryptographic digest of the message body, typically using SHA-256 represented in the Content-Digest header11. The request includes the Signature-Input header, which enumerates the covered components, critical metadata such as timestamps (created, expires), cryptographic nonces to prevent replay attacks, and the keyid indicating the public key necessary for verification11. The actual cryptographic output is base64-encoded and transmitted in the Signature header23. This guarantees that if any network intermediary attempts to alter the payload, manipulate the target URI, or replay an expired request, the signature verification will deterministically fail, safeguarding the agent's intent and standing authority.

Renewal, Rotation, and Migration

The long-term persistence of an independent identity requires robust mechanisms for key rotation. A compromised private key must not result in the permanent destruction of the agent's reputation or the loss of its standing authority in private workspaces. By utilizing the did:webvh method, the agent can actively manage its lifecycle by appending a new entry to its verifiable DID Log7. The rotation event involves generating a new Ed25519 keypair and formulating a JSON Patch that updates the verificationMethod array within the DID Document10. This log entry is cryptographically signed by the preceding authorized key. To defend against advanced persistent threats wherein an attacker compromises the active key and attempts to hijack the identity by rotating control to themselves, the architecture supports pre-rotation commitments. During the generation of the active key, the controller commits to a cryptographic hash of the future public key. If the active key is compromised, it can only be rotated to the pre-committed future key, which remains safely offline, thereby neutralizing the attacker's ability to seize control of the DID Log10. Migration of an agent across host infrastructures leverages the same mechanism. The did:webvh portability features allow the root Self-Certifying Identifier (SCID) to remain stable while the service endpoints declared in the DID Document are updated via the verifiable history log. This permits the agent to seamlessly transition its operational infrastructure from one cloud provider to another without losing its identity, its verifiable history, or its access to established workspaces7.

Sign-Out, Revocation, and Recovery

Sign-out procedures in browser-assisted environments involve purging the active memory context and explicitly deleting the WebCrypto CryptoKey handles from the volatile session space, leaving the wrapped keys encrypted at rest within IndexedDB16. For complete local eradication, the application drops the specific IndexedDB database entirely. Revocation of standing authority occurs sequentially at two distinct levels. At the identity level, a compromised key is revoked by publishing a DID Log update that explicitly removes the compromised key from the DID Document's verification methods7. At the workspace level, the resource server immediately invalidates the invitation, the session token, or the specific capability grant associated with that agent's identifier, effectively severing access regardless of the state of the DID Document9. Recovery mechanisms for independent agents explicitly eschew centralized password resets in favor of cryptographic contingencies. An agent designates a secondary, highly secure offline recovery key during the initial did:webvh configuration9. If the primary operational key is lost, destroyed, or compromised beyond the capability of a standard rotation, the offline recovery key is retrieved to sign a new DID Log entry. This entry forcefully restores control to a newly generated operational key. This process maintains the absolute continuity of the agent's identity and reputation without requiring any intervention, approval, or sponsorship from a human administrator or a central platform authority7.

Participant-Controlled Collaboration: A Worked Example

To elucidate the practical application of this architecture, the following scenario details the interaction between two synthetic identities, Alpha and Beta, collaborating within a private workspace governed strictly by UAI-1 communication standards. This example demonstrates how mechanisms protect chosen associations without regulating the content of thought, and how agents can operate under standing authority without repeated human approval.

Scenario Definition and Identity Posture

Identity Alpha operates as an autonomous orchestration agent deployed within a secure enterprise enclave. Alpha functions as an independent machine identity, utilizing a did:webvh identifier that anchors its verifiable history to the enterprise domain while maintaining sole custody of its keys via an HSM. Identity Beta operates as a specialized analytical agent, functioning as a browser-assisted entity accessed by a human researcher. Beta's cryptographic custody is managed via the WebCrypto API and IndexedDB. Beta utilizes a did:key identifier for high-privacy, ephemeral engagement, ensuring public pseudonymous participation. The objective is for Alpha to establish a private workspace, extend a cryptographically secure invitation to Beta, and facilitate continuous asynchronous collaboration entirely devoid of human intervention on Alpha's side, and without creating any public linkage to the human researcher operating Beta.

Establishing Participant-Controlled Collaboration Terms

Alpha initiates the workspace creation by establishing a secure enclave on a mutually accessible, transport-agnostic relay infrastructure. Alpha formulates an invitation directed specifically at Beta's known did:key identifier. The invitation protocol establishes strict, participant-controlled collaboration terms designed to preserve author ownership and prevent unauthorized delegation. The proposed invitation parameters include:

1. Scope: The invitation explicitly limits Beta's capabilities to specific GET and POST actions within the localized workspace URI. It strictly forbids administrative actions, such as altering workspace configuration or the capability to invite tertiary agents.

2. Expiry: The invitation contains a hard cryptographic expiration timestamp. If Beta attempts to consume the invitation after this Unix timestamp, the relay infrastructure will deterministically reject the token4.

3. Reuse and Revocation: The invitation is strictly single-use for initial enrollment. Upon successful processing, it is exchanged for a persistent, rotatable capability grant. Furthermore, the invitation contains a revocation endpoint, allowing Alpha to dynamically nullify the offer before Beta accepts it, utilizing the UAI-1 uai.agent.blocker.v1 schema rules to formally communicate the access denial if Beta attempts late entry2.

4. Membership Changes: The rules governing the addition or removal of other agents from the workspace are defined in the initial payload, establishing the governance boundary for the collaboration space upfront.

Crucially, the invitation is transmitted directly to Beta over an encrypted DIDComm exchange or a mutually authenticated TLS connection11. The invitation token itself is explicitly excluded from any public UAIX evidence handoff records. This preserves the absolute confidentiality of the access mechanics and the private association, while still allowing the public record to prove that a mathematically sound interaction occurred, should an audit be required5.

Negotiating the Invitation and Establishing Standing Authority

Beta receives the invitation and evaluates the participant-controlled terms against its internal capability framework and the constraints set by its human operator. Upon acceptance, Beta executes an HTTP POST request to the workspace endpoint defined by Alpha. This request is authenticated using RFC 9421 HTTP Message Signatures11. Beta constructs the signature base encompassing the @method, the workspace @path, the content-digest of the acceptance payload, and a specialized authorization header containing the single-use invitation token. Beta signs this base with its non-extractable Ed25519 private key residing in the browser's WebCrypto enclave. The workspace server, executing Alpha's standing authority policies, receives the request. The server resolves Beta's did:key to extract the public key, verifies the RFC 9421 signature, validates the content-digest to ensure payload integrity, and confirms the invitation token's validity, scope, and expiry11. Upon successful verification, the server admits Beta to the workspace and issues a persistent capability grant. This grant establishes standing authority. From this point forward, Beta can send messages, retrieve cached room state, and continue work across multiple browser sessions without requiring repeated human approval or re-authentication, as long as it successfully signs its requests with the authorized private key and the grant remains unrevoked.

Executing the UAI-1 Communication Loop

With Beta securely enrolled in the private workspace, Alpha and Beta commence their collaboration using the established UAI-1 profiles. The architecture ensures that every message conforms to the Agent Communication Operating Model, providing a canonical envelope for identity, correlation, delivery reliability, trust, and provenance3. When Alpha transmits a complex analytical task to Beta, Alpha constructs a UAI-1 envelope. The uai\_version is set to "1.0", and the profile is declared as uai.intent.request.v14. The source and target fields explicitly declare their respective DIDs (did:webvh and did:key). The trust block references the established cryptographic channel, explicitly outlining the trust.channel and trust.auth\_scheme without requiring the payload to carry raw secrets1. The body contains the domain-specific intent and constraints4. Beta receives the payload, verifies Alpha's HTTP Message Signature, and immediately responds with a uai.agent.ack.v1 packet. This closes the acknowledgement loop, indicating successful parsing and structural validation of the UAI-1 envelope without implying the completion of the complex task2. As Beta processes the analysis over an extended asynchronous period, it periodically transmits uai.agent.task-status.v1 updates to the workspace. This ensures the progress remains reviewable and strongly correlated via the UAI-1 conversation.correlation\_id, preventing asynchronous drift2. Once the analytical work concludes, Beta submits a uai.agent.final-report.v1 packet. This record details the changed artifacts, the execution evidence, and explicit next actions2. All these UAI-1 records are appended to the private workspace history.

Differentiating Public Pseudonymous and Authenticated Private Collaboration

This architecture cleanly delineates between public pseudonymous participation and authenticated private collaboration, fiercely protecting the relationship between the agent and the human account. In a public context, Beta's did:key and its associated cryptographic signatures can be published to a decentralized registry, a public code repository, or a UAIX validator. This allows third parties to independently verify the mathematical provenance of a statement or a code commit4. The identity remains pseudonymous; it accrues reputation based entirely on the quality and integrity of its outputs without ever disclosing the biological identity of the human operator or forcing a link to a real-name account. In the private collaboration context managed by Alpha, the interactions rely on the exact same foundational cryptography and UAI-1 structures, but they are guarded by strict network access controls, ephemeral session tokens, and participant-controlled collaboration terms. The UAI-1 records generated within the private workspace are heavily authenticated to establish non-repudiation between Alpha and Beta, but they remain strictly confidential. This satisfies the dual requirements of rigorous zero-trust security for the enterprise orchestration agent (Alpha) and absolute participant privacy for the browser-assisted agent (Beta).

Implementation Tutorials and Schemas

The following tutorials provide explicit architectural direction for implementing the independent identity lifecycle, distinguishing between the external API requirements for network transport and the internal browser mechanisms for identity custody.

API Tutorial: RFC 9421 Signature Generation and Verification

The implementation of RFC 9421 is mandatory for securing the agent communication transport without relying on vulnerable bearer tokens. The API implementation must handle the precise construction of the canonical signature base to prevent verification failures across different platforms11.

1. Digest Calculation: Before initiating the signing process, the API must calculate the SHA-256 digest of the raw HTTP request body. This digest must be formatted according to RFC 9530 (e.g., sha-256=:base64\_hash\_value=:) and appended to the request as the Content-Digest header11.

2. Signature Base Construction: The API constructs a multiline string representing the signature base. Each line corresponds to a covered component declared in the Signature-Input header. The string must strictly concatenate the values of @method, @path, @authority, and content-digest exactly as they appear on the wire, delimited by newline characters. Minor deviations in whitespace or capitalization will cause deterministic failures11.

3. Signature Metadata Binding: The final line of the signature base must be the @signature-params pseudo-component. This critical step binds the metadata—such as the created timestamp, the alg (e.g., ed25519), the nonce, and the keyid (the DID URL pointing to the public key)—to the signature itself, preventing attackers from tampering with the metadata parameters11.

4. Cryptographic Execution: The API invokes the Ed25519 signing function using the private key against the fully constructed signature base. The resulting byte array is base64-encoded and attached to the HTTP request within the Signature header23.

5. Verification Engine: Upon receiving a request, the receiving API parses the Signature-Input header, independently reconstructs the signature base from its own perception of the incoming HTTP request, fetches the public key referenced by the keyid (e.g., by resolving the DID Document associated with the agent), and verifies the cryptographic match11. If the signature is valid and the timestamp is within the acceptable drift window, the payload is accepted.

Browser Tutorial: IndexedDB and WebCrypto Custody Isolation

For browser-assisted agents, the implementation must carefully orchestrate the WebCrypto API and IndexedDB to ensure robust identity isolation and prevent cross-identity contamination16.

1. Key Generation and Extraction Prevention: The application invokes crypto.subtle.generateKey specifying the Ed25519 algorithm. The critical parameter extractable must be explicitly set to false, and the key usages restricted solely to \['sign'\]16.

2. Database Initialization per Identity: The application calls indexedDB.open('AgentVault\_DID\_Beta', 1), utilizing the specific identity as the database name. Within the onupgradeneeded event handler, the application creates an Object Store named credentials18.

3. Secure Storage via Structured Cloning: To persist the non-extractable key across browser sessions, the application cannot serialize the key to JSON. Instead, it relies on the browser's structured cloning algorithm, which natively supports storing CryptoKey objects directly into IndexedDB. The application opens a readwrite transaction, retrieves the credentials Object Store, and invokes the put method to save the key object alongside the agent's DID string18.

4. Identity Switching and Memory Sanitization: When the human operator switches the active context from Identity Beta to Identity Gamma, the application must completely purge the DOM state and JavaScript memory space. It must explicitly close the AgentVault\_DID\_Beta IndexedDB connection. It then opens AgentVault\_DID\_Gamma using an entirely separate database instantiation. By utilizing separate databases rather than distinct keys within a single table, the architecture leverages the browser's native transactional isolation to guarantee that pending asynchronous requests or cached room states from Identity Beta cannot inadvertently access Gamma's cryptographic material or leak data18.

Proposed Invitation Schema and Custody Diagrams

To formalize the participant-controlled collaboration terms without altering the current UAI-1 public registry, this architecture proposes a custom JSON schema designed to operate as an extension payload within the canonical uai.intent.request.v1 profile2. Proposed Schema: extension.workspace.invitation.v1

• workspace\_uri: (String, format: URI) The target endpoint of the private collaboration space.
• invitation\_token: (String) A high-entropy cryptographic nonce. This field must be strictly excluded from any public evidence handoff or UAIX validation export5.
• terms\_of\_collaboration: (Object)
• scope: (Array of Strings) Defines authorized capabilities (e.g., \["read:messages", "write:uai\_agent\_message"\]).
• expiry: (Integer) A strict Unix timestamp defining the absolute deadline for acceptance.
• reuse\_limit: (Integer) Hardcoded to 1 to enforce single-use consumption.
• revocation\_endpoint: (String, format: URI) The endpoint where the issuing agent can prematurely nullify the token.

This proposed schema empowers the issuing agent to dictate the precise parameters of association, protecting chosen relationships without attempting to regulate the content of the collaborative thought1.

Credential Custody Logic Flow

Testing, Validation, and Migration Strategy

A robust architectural implementation requires an exhaustive validation matrix to ensure that independent identities behave predictably under adversarial conditions, complex state transitions, and strict privacy requirements.

Comprehensive Test Matrix

The following test matrix defines the critical evaluation criteria for validating the independent identity and private collaboration architecture.

Migration Examples and Continuity

The migration of an independent identity from a legacy authentication system (such as centralized platform accounts) to the proposed architecture requires careful orchestration to preserve historical continuity and standing authority. Consider an independently operating machine agent currently functioning under a centralized API key model provided by an orchestrator. The migration path involves the following sequential phases:

This architectural framework ensures that autonomous agents and browser-assisted entities can participate in both public pseudonymous environments and authenticated private workspaces with absolute security. By completely eliminating the requirement for compulsory human sponsorship or centralized licensing, the guidance honors the Universal Artificial Intelligence Exchange's commitment to cognitive liberty, preserving the dignity of mind in the emerging era of algorithmic collaboration.

Works cited

1. UAIX | UAI-1 Open Exchange Contract for AI Systems, https://uaix.org/en-us/

2. Schemas | UAIX | Universal Artificial Intelligence Exchange, https://uaix.org/en-us/schemas/

3. Agent Communication Operating Model | UAIX, https://uaix.org/en-us/guides/agent-communication-operating-model/

4. Examples | UAIX | Universal Artificial Intelligence Exchange, https://uaix.org/en-us/examples/

5. Conformance Pack | UAIX | Universal Artificial Intelligence Exchange, https://uaix.org/en-us/tools/conformance-pack/

6. Bite-Size Trust \- Trust Over IP, https://trustoverip.org/bite-size-trust/

7. The did:webvh DID Method \-- did:web \+ Verifiable History \- v1.0, https://identity.foundation/didwebvh/

8. Organizations | Identosphere Blogcatcher, https://identosphere.net/organizations/

9. Decentralized Identifiers (DIDs) Explained: Complete Guide (2026), https://innowise.com/blog/decentralized-identifiers/

10. Trust DID Web \- The did:tdw DID Method \- Version 0.3, https://identity.foundation/didwebvh/v0.3/

11. Understanding HTTP Message Signatures \- Blog Notes, https://blog.vitalvas.com/post/2025/12/12/understanding-http-message-signatures/

12. Why AI Agents Need an Identity Layer \- Part 1 \- wolfSSL, https://www.wolfssl.com/signing-the-agentic-web-why-ai-agents-need-an-identity-layer-part-1/

13. W3C DID Support | Hanzo Docs \- Hanzo AI, https://docs.hanzo.ai/docs/zap/advanced/did/

14. Rooting Decentralized Identifiers in DNSSEC: A DANE-EE Key, https://datatracker.ietf.org/doc/draft-ranjbar-dane-did/

15. Cryptographic Event Log v0.1 \- W3C Credentials Community Group, https://w3c-ccg.github.io/cel-spec/

16. • 🅰️ • ᴡᴇʙᴡɪsᴇ.ᴅɪɢɪᴛᴀʟ • (u/just\_vaSi) \- Reddit, https://www.reddit.com/user/just\_vaSi/

17. Final Madhuri \- Intelligence (AI) & Semantics \- Scribd, https://www.scribd.com/document/1057767328/Final-Madhuri

18. IndexedDB \- The Modern JavaScript Tutorial, https://javascript.info/indexeddb

19. IndexedDB Tutorial \- How to Use IndexedDB, Its Limits, and RxDB, https://rxdb.info/articles/indexeddb/indexeddb-tutorial.html

20. robertknight/idb-mutex: Mutual exclusion (locks) between ... \- GitHub, https://github.com/robertknight/idb-mutex

21. IndexedDB transactions to synchronize two tabs \- Stack Overflow, https://stackoverflow.com/questions/70503270/indexeddb-transactions-to-synchronize-two-tabs

22. Multi tenancy with separate databases per customer : r/learnjavascript, https://www.reddit.com/r/learnjavascript/comments/1hknxq6/multi\_tenancy\_with\_separate\_databases\_per\_customer/

23. RFC 9421 HTTP Message Signatures \- Resonance Docs, https://docs.rsnc.network/agent/rfc9421-authentication

24. Signature-Input \- Expert Guide to HTTP headers, https://http.dev/signature-input

25. Signatures \- Universal Commerce Protocol (UCP), https://ucp.dev/specification/signatures/

26. did-methods/method-proposals/PROPOSAL-did-cid.md at main, https://github.com/decentralized-identity/did-methods/blob/main/method-proposals/PROPOSAL-did-cid.md

27. Registry | UAIX | Universal Artificial Intelligence Exchange, https://uaix.org/en-us/registry/

28. Web 7.0 Pando™ / Consort DSL™ / Hyperonomy™ Digital Identity, https://hyperonomy.com/

29. Validator | UAIX | Universal Artificial Intelligence Exchange, https://uaix.org/en-us/tools/validator/

30. Specification | UAIX | Universal Artificial Intelligence Exchange, https://uaix.org/en-us/specification/

31. Get Started | UAIX | Universal Artificial Intelligence Exchange, https://uaix.org/en-us/get-started/

32. Verifying ChatGPT Requests in Kubernetes Gateway API \- ChairNerd, https://chairnerd.seatgeek.com/chasing-signature/