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) cryptographically affixed to a digital artifact proving the owner 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 sovereign copy of the digital identity. See Q&A.

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

Identity Assurance Levels (AI#): the confidence one has that a person is who they claim to be (NIST SP 800-63-3).

Identity Validation by Credit Card: Consider a user joining a professional association listing member names and qualifications. Membership dues are paid by credit card. Her identity agent creates a digital identity specifying her professional name and qualifications. A public copy of her digital identity and her credit card data are submitted to the association’s identity agent. If the credit card is successfully verified by the credit card processor, and her digital identity comports with her credit card data, the association’s identity agent creates a digital seal affixing an attestation (“credit card validated”) to her public copy. Identity assurances (AI2) associated with her digital identity are thereby elevated. Instead of logging on with a password, she can use her public copy to identify herself.

Identity-Proofing: Collaborating owners can identity-proof each other online (IA3) or in-person (IA4). The first owner submits a public copy of her digital identity plus identifying document(s) to the second owner, the “identity-proofer”. If the documents identify the first owner, the identity-proofer uses the embossing key of his sovereign copy to create a digital seal affixing his attestation (“proofed”) to her public copy. Her public copy is returned to her identity agent which applies the digital seal to her sovereign copy thereby elevating associated identity assurances. Other owners receiving her public copy can obtain the identity-proofer’s public copy and apply the inspection key to verify the digital seal and attestation. See Q&A.

Authentication Assurances

Authentication Assurance Levels (AA#): the confidence one has that a received public copy was originated by someone holding the sovereign copy. See Q&A.

AA0: Self-Seal Verification: To detect errors, identity agents authenticate received public copies by applying the public inspection key of the public copy to the self-seal.

AA1, AA2, AA3: Proof-of-Possession (PoP) Verification: Identity agents can use the inspecting, verifying, and encrypting keys of a public copy plus random values to prove the embossing, signing, and encrypting keys are possessed by the originating identity agent. This provides assurances the originating identity agent holds the sovereign copy from which the public copy was derived.

AA4: Proof-of-Custody (PoC) Verification: An identity agent receiving a public copy can demand the originating identity agent locally authenticate the device holder. This provides authentication assurances that the person with custody of the device holds the sovereign copy.

{identity assurances establish who the person actually is}

Exchange, Authentication, Identification

Public copies exchanged between owners enable them to mutually identify, authenticate, and collaborate. See Q&A.

Exchanging Public Copies: Owners meeting in-person can 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 exchanged public copies. When MITM and other risks are concerns, ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) or HTTPS is used.

Authentification Assurances (AA0 to AA4): Self-seal verification (AA0) is always conducted. AA1 may be sufficient to verify possession when risk is low or when ECDHE or HTTPS are used. AA2 and AA3 may be required to protect high value transactions. Proof-of-custody (AA4) is required to mitigate the risk of device loss.

Identity Assurances (IA0 to IA4): Requests to collaborate at level IA0 should be rejected. Requests at IA1 should not be used to exchange sensitive or private data. IA2 is likely sufficient when exchanging non-health and non-finiancial data. IA3 should be used when exchanging medical and health data. IA4 is likely acceptable when processing financial data supported by AA4 (proof-of-custody).

Registering: Public copies are cross-sealed and registered; the seals are applied to the sovereign copies.

Secure Collaboration: Identity agents use private/public keys to securely collaborate. When sending, the signing key of the sender’s sovereign copy digitally signs payloads and the encrypting key of the receiver’s public copy encrypts payloads. When receiving, the decrypting key of the receiver’s sovereign copy decrypts payloads and the verifying key of the sender’s public copy verifies 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 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.