Q & A

Updated 01-16-2026

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.

Q9. How are sovereign copies and public copies used?

The master copy of a digital identity, the sovereign copy, includes identifiers, attributes, images and 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 do not disclose private keys. Public copies are shared and used to identify, authenticate, and secure transactions. Public copies are exchanged using Diffie-Hellman, https, and OTPs; or in-the-clear at marginal risk.

Q10. Where are sovereign and public copies held?

Identity agents have a wallet object holding the owner’s sovereign copies and a contacts object for holding public copies provided by other owners. Sovereign and public copies conform with vCard 4.0.

Q11. 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 created it is “self-sealed”. When a notary public digitally seals a document it is “notarized“.

Q12. How are digital seals depicted?

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

Q13. How are digital identity templates used?

Custom “digital identity templates” can be used to brand customers and users. A template bearing “Ubank’s” digital seal issued to and populated by a customer yields a digital identity self-sealed by the customer and digitally sealed by the bank thereby strongly binding the customer to the bank’s brand. Similarly, digital identity templates can be used to bind and brand members of closed user groups.

Q14. 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):

Q15. 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.

Q16. 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.

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 depicts 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 ECDHE used to exchange public copies?

Identity agents can use ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) to exchange public copies of digital identities between users. Using ECDHE, each identity agent creates an ephemeral (short-term) public/private key-pair; public keys are exchanged; and they each use ECDHE to combine the public key received with the private key they hold to create matching symmetric keys. Finally, they use the matching symmetric keys to cryptographically exchange public copies of their owners’ digital identities.

Q21. When should MITM risk be mitigated?

There is a risk of a “man-in-the-middle” (MITM) monitoring or manipulating exchanged public keys. Such risk is small when using flash drives, password-protected WiFi routers, NFC and QR codes. However, methods capable of detecting and preventing MITM data corruption and tampering should be used when messaging and transacting between remotely located public spaces.

Q22. Can OTPs be used to detect a MITM attack?

One-time-passwords/PINs (OTPs) can be used to detect MITM attacks when alternate channels are available. Public keys generated by ECDHE can be exchanged over a primary channel (e.g. email) while a secondary channel (e.g. SMS) is used to exchange the OTPs which are hashed to create a fingerprint. The fingerprint is combined with the ECDHE generated symmetric key yielding an adjusted symmetric key. To avoid detection, a MITM must intercept both the exchanged OTPs and the public keys.

Q23. Can digital identities be exchanged peer-to-peer?

Digital certificates supporting https and a WebRTC signalling service enable identity agents to discover each other’s IP addresses and port numbers subsequently used to collaborate peer-to-peer. Session Description Protocol (SDP), STUN servers, and TURN relays enable mutual discovery. ECDHE is used to create a shared symmetric key for exchanging public copies of users’ digital identities.

Q24. How is remote password dependency reduced?

Consider a user having account/password access to an online service. The service supplies a branded (sealed) digital identity template. She uses her identity agent to populate the template creating her digital identity. She then submits a public copy of this digital identity to the provider’s identity agent. The service provider’s identity agent verifies that the identifying information specified by the public copy conforms with her online user profile. If so, the provider’s and user’s identity agents cross-seal and register public copies of their digital identities. Instead of using her account/password to log in, she can subsequently use the public copy of her digital identity to identify herself and be authenticated by 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