Q & A

Updated 12-27-2025

Q1. What are the principal goals of the architecture?

The overarching goal is to progressively decentralize control over digital identity from providers to users to disperse the attack surface and mitigate impersonation risk due to breaches and phishing. Shifting responsibility and control to individual users enables them to harmonize identifying information across the digital identities they create, maintain, and use. The architecture exploits authentication data, cryptography, and identity-proofing to elevate identity and authentication assurances.

Q2. What are the key architectural features?

Identity agents deploy digital identities controlled by the device owner (i.e. “self-sovereign”). Digital identities are intuitive and hold multiple private/public key-pairs enabling owners to mutually identity, authenticate, and collaborate. Identity agents deploy digital identities revealing only enough information to meet transactional needs. Identity agents use digital identities selected by the owner to collaborate securely; affix digital seals to digital identities, documents, and consent tokens; and identity-proof other identity agent owners

Q3. What types of digital identities can be created?

Digital business cards can be used to share contact information across professional networks. Members of social networks can create personal identity cards to share identifying information with friends and family. Digital bank cards and credit cards can be used to pay bills and transfer funds online. A driver can use her digital drivers license to access the DMV’s online system when renewing. A digital healthcard card can be used to securely access online medical records and communicate with healthcare providers.

Q4. How is self-sovereignty achieved?

Identity agents capture and encapsulate the owner’s authentication data (PINs, passwords, biometric minutia) and personal information. Owners are thereby strongly bound to their device(s) as well as their digital identities, consent tokens, identifying information, and private data.

Q5. How is remote identity agent existence checked?

When encountering a remote party over the Web, the owner’s identity agent conducts verification tests to detect whether the party has an identity agent and holds a valid digital identity. If the tests fail the encounter is abandoned.

Q6. How are digital identities structured?

Digital identities created by identity agents are based on a common data model specifying unique identifiers across a context including: creation/expiry dates; photos, icons, sealing images; legal, informal names, pseudonymous names; email address(es); telephone number(s); and cryptographic keys. Digital identities having non-identifying information are for incognito web activity.

Q7. Why do digital identities have mutiple key-pairs?

Motivated by Asokan to increase cryptographic strength, multiple private/public key-pairs are allocated to digital identities: signing/verifying keys; decrypting/encrypting keys; and embossing/inspecting keys.

Q8. How do digital identities and digital certs differ?

A signed digital certificate (cert) created by a certificate authority specifies a domain name and public key packaged with a paired private key in support of client/server protocols such as HTTPS. Digital identities have three private/public key-pairs generated by the owner’s identity agent for distinct cryptographic purposes. Digital certificates are not particulary user-friendly and do not hold personal information. In contrast, Digital identities mimic physical credentials in one’s wallet enabling owners to intuitively identify, authenticate, and collaborate with other identity agent owners.

Q9. What are “sovereign copies” and “public copies”?

The master copy of a digital identity, the “sovereign copy”, includes owner-specified identifiers, attributes, images and the generated private/public key-pairs. “Public copies” derived from a sovereign copy inherit the owner-specified properties but only the public keys (verifying, encrypting, and inspecting keys). The private keys of a sovereign copy are used to perform signing, decrypting, and embossing operations. Identity agents never disclose their owner’s private keys. However, public copies can be freely shared to identify and authenticate owners, and secure collaboration among them.

Q10. Where are sovereign and public copies held?

Identity agents have a wallet object for sovereign copies of the owner’s digital identities and a contacts object for public copies provided by other owners derived from their digital identities. vCard standard 4.0 structures both wallet and contacts objects. A wallet object specifies three (3) public/private key pairs per sovereign copy while a contacts object specifies three public keys (only) per public copy.

Q11. How are digital identity templates used?

Custom “digital identity templates” can be created to normalize and brand digital identities across distinct customer and user groups. For example, a custom digital identity template uniquely addressing “Ubank’s” requirements can be digitally sealed using Ubank’s logo thus branding templates distributed to Ubank customers. The identity agent of a customer verifies the digitally sealed template; populates the template with customer data; embeds unique private/public key-pairs; and self-seals the generated digital identity uniquely characterizing the owner while also digitally bound to Ubank. Similarly, custom digital identity templates can be used to create distinct digital identities across closed user groups.

Q12. How are digital seals used?

Mimicking a seal affixed to a document by a notary, an owner can use the sovereign copy of one of their digital identities to create and validate a digital seal affixed to a digital identity, a consent token or a document. A digital identity includes a “sealing image”, an embossing (private) key, and a paired inspecting (public) key. The embossing key is used to cryptographically affix the sealing image, an attestation, and a digital signature to an artifact. The inspecting key is used to verify the digital seal. When a digital identity is newly created it is “self-sealed”. When a notary digitally seals a document it is “notarized“.

Q13. How do owners mutually identify?

A sovereign copy and derived public copies hold the same identifying information. Exchanging public copies enable owners to identify each other. Identity assurances levels (AI#) associated with a given public copy can be derived from attached digital seals and attestations (if any):

Q14. How do owners mutually authenticate?

When a digital identity is created the embossing key is used to self-seal the sovereign copy. Public copies derived from a sovereign copy yield the same self-seals. Successfully verifying the self-seal affixed to a received public copy using the inspection key authenticates the public copy. Successful proof-of-possession (PoP) tests using random values and the public copy‘s public keys verify that the originating identity agent controls the embossing, signing, and decrypting keys of the sovereign copy. The receiving identity agent can also send a proof-of-custody (PoC) demand to the originating identity agent to verify the originating owner actively controls their device.

Q15. How are messages and transactions secured?

When sending, the private signing key of the sender’s sovereign copy is used to digitally sign payloads, and the public encrypting key of the receiver’s public copy is used to encrypt payloads. When receiving, the private decrypting key of the receiver’s sovereign copy is used to decrypt payloads, and the public verification key of the sender’s public copy is used to verify digital signatures attached to payloads.

Q16. How are digital seals depicted?

A digital seal is an object that combines the “sealing image” specified by an owner’s digital identity with an owner attestation, issue date, digital identity identifier, artifact identifier, and a digital [seal] signature.

Q17. How do digital seals elevate identity assurances?

A digital seal elevates non-repudiation strength over traditional digital signature. This is because digital seals created by identity agents tightly bind owners to their digital identities held within their strongly bound devices. When an owner creates a digital seal affixing their attestation to the digital identity of another owner, identity assurances associated with the other owner are elevated.

Q18. How are digital seals used to notarize documents?

The prototype illustrates a notary public collaborating with a customer to notarize an identifying document. The customer scans or photographs the identifying document and uses her identity agent to apply the embossing key of one of her digital identities to digitally seal the document. The notary public verifies the document and the digital seal affixed by the customer, and uses the embossing key of his sovereign copy to digitally seal the document thereby notarizing the customer’s identifying document.

Q19. How do identity agents protect private data?

The owner directs her identity agent to use the public encryption key of a selected digital identity to encrypt her private and identifying information. Stored locally or remotely, such private data can only be decrypted using the private decryption held of the owner’s the sovereign copy. To secure bulk data, the paired encryption and decryption keys are used to encrypt and decrypt symmetric keys used to encrypt and decrypt the data.

Q20. How is the Diffie-Hellman key method used?

The Diffie-Hellman key agreement method (ECDHE version) is used to securely exchange public copies of digital identities between identity agent owners. Each identity agent uses Diffie-Hellman to generate an ephemeral (short-term) public/private key-pair; exchange the public keys; and then combine the private key they each hold with the exchanged public key creating a shared symmetric key. The identity agents use the shared symmetric key to securely exchange their public copies.

Q21. When should MITM risk be mitigated?

The second Diffie-Hellman step where generated public keys are exchanged vulnerable to certain man-in-the-middle (MITM) exploits. MITM risk is small when using flash drives, private WiFi routers, NFC or QR codes to exchange public keys. MITM risk should be mitigated when using email, SMS or similar messaging apps to exchange public copies.

Q22. How are OTPs used to detect MITM attacks?

When alternate channels are available, public keys generated by Diffie-Hellman are exchanged between the collaborating identity agents over the primary channel (say email), while a second channel (say SMS) is used to exchange one-time-passwords (OTPs). Once the OTPs are exchanged, the identity agents combine and hash them to create a fingerprint used to derive an adjusted symmetric key from the symmetric key generated by Diffie-Hellman. Man-in-the-Middle exploits are thereby detected.

Q23. How is HTTPS used to prevent MITM attacks?

Identity agents with pre-installed digital certificates can leverage https providers to digitally sign, exchange and verify public keys generated by Diffie-Hellman. If successfully verified, the remaining Diffie-Hellman steps can be executed to yield the shared symmetric key subsequently used to securely exchange the public copies. Man-in-the-Middle exploits are thereby prevented.

Q24. How is password dependency reduced?

Verifiable owner control (self-sovereignty) reduces and potentially eliminates the need for remote access passwords and the burden of maintaining online user profiles. Providers and users having pre-installed identity agents can use their public copies to mutually authenticate instead of using account/passwords to sign-in. Providers can choose to make digital identity templates available for users to populate. Consider a user with account/password access to her provider’s online service. Having used her identity agent to create digital identity (sovereign copy), she offers the public copy to the provider’s identity agent. The provider’s identity agent verifies that the attributes of the public copy conform with her pre-existing online user profile. If they conform, the provider and user cross-seal and register each other’s digital identities. Instead of using her legacy password, the user can subsequently, employ her identity agent to present her public copy to identify herself and sign into the online service.

Q25. How does identity-proofing elevate assurances?

Users and providers can use their identity agents to proof, attest and digitally seal each other’s digital identities. An owner requesting elevated assurances submits a public copy of her digital identity plus identifying information to another owner. They meet in-person or online. If the identity-proofer confirms that the identifying information represents the requester, his identity agent uses the embossing key of his sovereign copy to create a digital seal affixing his attestation to her public copy. The digitally sealed public copy and the proofer’s public copy are returned to the requester’s identity agent which merges the affixed digital seal with her sovereign copy thereby elevating identity assurances associated with her digital identity. Identity agents verify a digital seal for their owners using the inspection key of the identity-proofer’s public copy. Digital identities sealed by multiple owners establishes mutual trust among them.

Q26. How are digital seals used to delegate consent?

The architecture decentralizes access to private owner data by circulating consent tokens digitally sealed by stakeholders attesting to their commitments. Resource owners use consent tokens to reliably grant and expire access to their private resources. Custodians hosting owner resources use consent tokens to clear and terminate access by requesters to suchresources. Requesters present tokens to custodians to gain access when needed. Consent tokens are archived for audit.

Q27. When can proof-of-existence be used?

A “proof-of-existence registry” can be leveraged to verify the integrity of public copies of digital identities sent in-the-clear (unencrypted). When an identity agent creates a digital identity, the sovereign copy is self-sealed (public copies inherit this self-seal). The hash of the public copy and the self-seal are combined into a record and written into the proof-of-existence registry. An identity agent receiving a public copy in-the-clear uses the inspection key of the public copy to verify the self-seal. If the self-seal verifies, the hash of the received public copy is computed and used to locate a record in the registry. The computed hash and self-seal matching the the contents of the located record verifies the integrity of received public copy. In the case of unsuccessful matching, the received public copy is discarded. The proof-of-existence registry does not reveal identifying information since only hashes of public copies are written into the registry.

Q28. How will owner data be backed up?

Authentication data and sovereign copies of digital identities (in wallet objects) are encrypted, backed up and recovered to/from local and tethered storage. Contacts can be synchronized with Google and SMS vCard files.

Q29. How will identities be copied across devices?

For owners having multiple devices (e.g. smart phones, tablet PCs, laptops) use export and import utilities to synchronize sovereign copies (in wallet objects) and public copies (in contacts objects) across devices.

Q30. How can identity agent software be hardened?

In certain domains the software may need to be hardened. Formal methods, trusted platform modules, secure enclaves, and trusted execution environments can be exploited. Quantum computing risk can be countered by using elliptic curve cryptography, ephemeral keys, key lengthening, and key rotation.

Top