Architecture

Agents — Identities — Seals — Collaboration

Notarizing–Proofing–Delegating–Prototype

Identity Agents

The architecture is comprised of identity agents installed on user and provider devices to create and deploy digital identities for device owners. An identity agent captures authentication data (passwords, PINs, biometrics) binding the owner to digital identities and other data. Digital identities are owner-controlled (i.e. “self-sovereign”). Identity agents use digital identities to securely collaborate, deploy digital seals, conduct identity-proofing, and delegate consent. See Q&A.

Digital Identities

Digital identities are used to identify and authenticate owners, secure transactions, and protect private data. Mimicking physical credentials “in one’s wallet”, digital identities enable intuitive ease-of-use for owners. Identity agent owners can create a range of digital identities: digital personal IDs, digital business IDs; digital medical IDs; digital drivers licenses; digital passports; digital bank IDs; etc. Owner-specified properties typically include an identifier, image (photo), owner attributes, sealing image, expiry, and (3) generated private/public key-pairs: signing/verifying, decrypting/encrypting, and embossing/inspecting. The “sovereign copy” of a digital identity is tightly controlled by the owner. “Public copies” of a sovereign copy inherit the owner-specified properties and the 3 public keys but not the 3 private keys. The public keys of a public copy can be used to verify that the private keys of the sovereign copy are owner-controlled. Digital identity templates can be created to brand digital identities across customer and user groups. “Anonymous” digital identities can be created for incognito browsing and posting. See Q&A.

Digital Seals and Attestations

Mimicking seals affixed by notaries to documents, a digital seal is a visual object (image+data) affixed to a digital artifact (document, consent token, digitial identity) proving a given owner created a digital seal affixing an attestation to the digital artifact (see figure). The image property is the “sealing image” of the digital identity used by the owner to create the digital seal. The data properties specify issue date/time, digital identity identifier, owner attestation, digital artifact identifier, and digital signature computed over the digital identity, attestation and digital artifact using embossing key of the sovereign copy.

The public inspection key of the owner’s public copy can be used to verify the digital signature. When digital identities are created they are “self-sealed“ using the embossing key. When public copies are exchanged between owners they are “cross-sealed” using the embossing key of each owner’s sovereign copy. When a notary public digitally seals a document it is said to be “notarized“. Upon successfully “identity-proofing” an owner, an attesting digital seal is affixed to the owner’s digital identity. When delegating consent, digital seals are used to affix stakeholder “commitments” to consent tokens.

Identity Assurances and Proofing

Identity assurances for accessing and sharing online resources and private data varies with risk (corruption, loss, misuse, fraud). Identity assurances are thought to be unneccessary or undesirable when browsing or posting messages. Social, professional and messaging providers do not require users to prove who they are. For many online services, customer-provided credit card data satisfies identity assurance needs. In contrast, financial, government, defense, and corporate providers implement custom practices and considerable effort to prove the identity of customers, employees, and contractors.

Identity-proofing is a process whereby identifying data is examined to prove a person’s identity. Consider an owner requiring elevated identity assurances. She submits a public copy of her digital identity and identifying data to an identity-proofer. Given he concludes the data identifies the requester, the embossing key of his sovereign copy is used to affix an attesting digital seal to her public copy merged by her identity agent with her sovereign copy. Identity agents of other owners receiving her public copy can use the inspection key of the identity-proofer’s public copy to validate the attesting digital seal affixed to her public copy. In-person identity-proofing by qualified personnel using certified documents elevates identity assurances. Cross-sealed digital identities among owners builds mutual trust.

Collaborating Securely

Exchanging — Identifying — Authenticating

Instead of using identifiers and passwords to sign in, identity agents exchange and register public copies of digital identities used together with sovereign copies to securely collaborate. See Q&A for more.

Exchanging Public Copies: Typically, owners meeting in-person can use their identity agents to safely exchange public copies over private WiFi networks and NFC (Near Field Communications). When man-in-the-middle (MITM) risk is low, proof-of-existence (PoE) can be used to verify public copies exchanged via email and SMS. When MITM risk is significant, Diffie-Hellman (D-H) or HTTPS are used to exchange public copies securely.

Identity Assurance Levels: Used to assess whether received public copies address perceived risks.

Authentication Assurance Levels: Used to determine which verification methods to use.

AA0: Seal-Seal Verification: The inspecting key of received public copies are used by identity agents to verify self-seals. A verified self-seal confirms the public copy was not corrupted in transit from the corresponenting identity agent. However, this does not prove owner identity.

AA1, AA2, AA3: Proof-of-possession (PoP) Verification: To verify the authentication assurance level, each identity agent can respectively use the public inspecting, verifying, encrypting keys of the received public copy and a random value to verify that the private embossing, signing, encrypting keys are held by the corresponding identity agent.

AA4: Proof-of-custody (PoC) Verification: To further verify authentication assurance, the receiving identity agent can demand the sending identity agent authenticate the owner to confirm he/she controls the device from which the public copy was received.

Registering: The received public copies are cross-sealed and transferred to the corresponding identity agents which attach the cross-sealed digital seals to the sovereign copies and register the public copies.

Collaborating: Having exchanged public copies, identity agents use signing/verifying and decrypting/encrypting keys to securely collaborate. When sending, the signing key of the sender’s sovereign copy is used to digitally sign payloads and the encrypting key of the receiver’s public copy is used to encrypt payloads. When receiving, the decrypting key of the receiver’s sovereign copy is used to decrypt payloads and the verifying key of the sender’s public copy is used to verify payloads.

Notarizing Documents

Consider a notary certifying a customer’s identifying document. The customer uses the embossing key of a selected digital identity to digitally seal her document. The notary then uses the inspecting key of the customer’s public copy to verify the digital seal. Finally, the notary public uses the embossing key of his digital identity to digitally seal (“notarize”) the document. Other owners can verify the notarizing seal by obtaining the notary’s public copy, using the inspecting key to verify the seal (see Q&A).

Delegating Consent

In contrast to server-centric consent models, the architecture decentralizes access to private data of owners 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 a given owner’s resources use consent tokens to clear and terminate access to the resources. Requesters present the tokens to custodians for access (see Q&A).

Proof-of-Concept Prototype

The proof-of-concept prototype illustrates identity agents creating, exchanging and using digital identities; creating and verifying digital seals; mutually identifying and authenticating owners; securing messages, transactions, and private information; notarizing documents; identity-proofing owners; and delegating consent to access private information. HTML, CSS, JavaScript, JSON, and node.js have been used to develop the prototype software.