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 Attestation

Mimicking seals embossed by notaries, a digital seal is a visual object (image + data) affixed to a digital artifact (digital identity, document, token) proving the owner of a given digital identity affixed the digital seal. The image property is a copy of the digital identity sealing image. The data property includes issue date/time, digital identity identifier, owner attestation, digital artifact identifier, and a digital signature computed over the properies using the embossing key of the digital identity (i.e. sovereign copy).

The public inspection key of an owner’s public copy can be used to verify the digital signature of a digital seal. When digital identities are created they are “self-sealed“ using the embossing key. When public copies are exchanged, they are “cross-sealed” using the embossing key of their sovereign copies. When a notary public digitally seals a document it is said to be “notarized“. Upon successfully “identity-proofing” an owner, the identity proofer affixes an attesting digital seal 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: Digital identities are characterized by identity assurance level (AI#) as follows:

Identity Inferred by Credit Card: Consider a user holding her physical credit card, and a self-asserted digital identity (identity assurance level IA1) held in her identity agent’s (digital) wallet.

Identity-Proofing: Collaborating owners can conduct identity-proofing online or in-person. Background checks may also be conducted. A first owner submits a public copy of her digital identity and identifying document(s) to a second owner, the “identity-proofer”. If the data is deemed to accurately identify the first owner, the identity-proofer uses the embossing key of his sovereign copy to create a digital seal affixing his attestation (e.g. “proofed”) to her public copy which is returned to her identity agent which affixes the digital seal to her sovereign copy. Thereafter, other owners can use the identity-proofer’s inspection key to verify the affixed digital seal to obtain elevated assurances as to the first owner’s identity (at AI3 or AI4).

Authentication Assurances

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.

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.

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

Proving the Concept

The proof-of-concept prototype depicts 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.