Privacy by Design Identity Architecture Using Agents and Digital Identities

Abstract

Today’s web is comprised of a patchwork of identity solutions because neither identity nor privacy were designed-in when it was created. This paper proposes an integrative identity architecture that satisfies the principles of privacy by design from inception. Comprised of identity agents and digital identities that are tightly held by their owners, the architecture decentralizes control over identity from providers to users. Owners can manage their digital identities and private data such that liability risks are reduced for service providers without compromising ease-of-use. Identity agents and digital identities enable owners to prove who they are when required, protect their private and identifying data, and securely collaborate. Digital identities are virtualized to look and behave like credentials found in one’s wallet thereby facilitating technology adoption and reducing dependency on remote access passwords. A gestalt privacy by design process has been used to discover and validate the architecture’s privacy requirements and design elements, systematically reasoning about how the design satisfies the requirements. The process can be applied to organically improve the architecture and create a reference model for open source development. This paper also relates the architecture to W3C’s models for verifiable credentials and decentralized identifiers, summarizes the architecture’s features, capabilities and benefits, and suggests areas for further study.

Annex: Identity Architecture Validation

A gestalt privacy by design process has been used to iteratively identify and validate the privacy requirements and design elements of the identity architecture. This annex explains how each design element satisfies the privacy requirements thereby mutually validating the design elements and the privacy requirements. The paragraphs below reference Fig. 4, Fig. 5, Fig. 6, Fig. 7 and Fig. 8 in the body of this paper.

• A. User Interface Design View

The User Interface Design View shown in Fig. 4 encompasses design elements D1, D2 and D3 implementing privacy requirements R1, R2 and R3. The proposed privacy by design default settings for the User Interface Design View are also identified.

• R1: Tightly Control Private and Identifying Information.

• D1: Encapsulate Authentication Data and Private Information.

Design element D1 combined with physical custody of the owner’s Internet device satisfies R1 by providing strong assurances that the owner, whether an end-user or a system administrator, controls her Internet device, installed identity agent, and encapsulated digital identities.

Although physical custody of her device enables the owner to maintain control over her identity agent, this is not enough to guarantee that her device has not been stolen or lost. Relying parties need objective proof that the owner of a remotely held device has control over it. This design element satisfies this need by exploiting native mechanisms built into Internet devices (smart phones, tablet PCs, laptops) including password, PIN, biometric, and geo-location authentication mechanisms.

Design element D1 significantly reduces the risk of theft and loss of the owner’s device by encapsulating the owner’s authentication data while providing the device’s authenticator(s) access to this data by way of an application programming interface (API). When the owner’s device is first used, her native authenticator enrolls her authentication data by writing this data via the API to the identity agent. Subsequently, the authentication data can be accessed via the API to support the authenticator’s mechanisms for verifying the device owner. Once a positive authentication indication is detected, the identity agent’s digital identities, interfaces and other data are made available for use. The authentication data is not revealed by the identity agent.

Design element D1 thereby provides strong assurances that the owner tightly controls his/her digital identities including private and identifying information, secrets and crypto keys. When digital identities are created, the identity agent of an owner allocates public/private encryption key-pairs to each and vaults its so-called sovereign image. The private keys of the digital identity are not disclosed by the identity agent. However, the identity agent can distribute public copies⁹ to other parties.

• R2: Selectively Disclose Identifying Information.

• D2: Identities Virtualized and Selectively Disclosed.

Identity agents use an identity data model (e.g. [8]) to support the specification of digital identities that characterize the owner (e.g. claims, attributes and images). Design element D2 satisfies R2 by addressing usability and ease-of-use thereby enabling owners to create and select digital identities that have the appearance and behavior (“look and feel”) of identity credentials used in the real world.

Figure 4 depicts the owner holding multiple digital identities in her wallet such as a digital business card, digital driver’s license, e-health card, digital credit card, and/or electronic membership card. Instead of using remote access passwords, owners intuitively select digital identities that disclose only the private and identifying information necessary to satisfy the needs and purposes of the collaborating service provider or consumer. To facilitate disclosure, design element D2 enables owners to specify “anonymous identities” where the attributes are known only to the owner; “pseudo-anonymous identities” where the attributes are disclosed only to trusted collaborators; and “civil identities” where identifiers and attributes partially or fully elaborate identifying information.

• R3: Protect Private and Identifying Information.

• D3: Private Data, Keys and Secrets Encrypted.

Digital identities have multiple public/private encryption key-pairs that can be used to protect private data and secrets of the identity agent owner. Design element D3 satisfies R3 by applying these encryption keys to prevent hackers and malware from maliciously accessing such data including authentication data, digital identities, encryption keys, passwords, and PINs encapsulated by the identity agent. A designated public key of a digital identity of the owner can be used to encrypt her private data and secrets. Only the owner can decrypt the data using the paired private key.

Privacy by Design Default Settings of User Interface Design View

When the identity of an originating party is unknown or uncertain, the identity agent should not use digital identities that include identifying, private or secret information. Anonymous and pseudo-anonymous identities could be used as defaults when first establishing an online session or when exchanging digital identities with newly introduced or unvetted parties at meetings or public gatherings. Wireless mechanisms like QR codes, NFC, WiFi and Bluetooth could be used to securely transfer digital identities and private data when collaborators meet in-person.

• B. Interoperability Design View

The Interoperability Design View shown in Fig. 5 encompasses design elements D4, D5 and D6 implementing privacy requirements R4, R5 and R6. Figure 6 supports the reasoning behind how design element D4 satisfies privacy requirement R4. The proposed privacy by design default settings for this design view are also identified.

• R4: Exchange Digital Identities Securely.

• D4: Secure Digital Identity Exchange.

Design element D4 satisfies R4 by enabling digital identities to be reliably and securely exchanged, the aim being to prevent man-in-the-middle attacks akin to robocalls and wiretaps on telephone networks. Options for exchanging digital identities include exchanging them in the clear; exchanging one-time passwords (OTPs) out-of-band; transferring them over HTTPS once logged in using an online password; and meeting in-person to transfer digital identities wirelessly.

Although the above methods carry various risks, they are safe enough to use in many contexts. One risk is that of digital identities being highjacked. Such risks can be mitigated by using an online service and combining hashing with Diffie-Hellman’s key agreement method (DH) [14]. Our adapted Diffie-Hellman protocol¹⁰ is depicted in Fig. 6 as well as in Fig. 7 (1) where it is shown in the context of verification.

Figure 6 illustrates how two owners can securely exchange public copies of their digital identities. Owners 1 and 2 have digital identities they wish to exchange respectively using identifiers id1 and id2. They first use their identity agents to store the public keys of their digital identities in the exchange service’s repository at locations computed by respectively hashing id1 and id2 (e.g. using SHA256). Subsequently exchanging id1 and id2 by alternate means (e.g. physical transfer or out-of-band), they use their identity agents to hash the opposite owner’s identifier to locate and retrieve the public keys of the other owner. The DH key agreement method is then applied by both owner’s identity agents to combine the private keys of the owner with the retrieved public keys of the other owner thereby generating the same symmetric encryption key (or keys) for both owners. Finally, the symmetric keys are applied to encrypt and thereby securely exchange public copies of their digital identities.

To overtake the owners’ digital identities, a malicious high-jacker would be obliged to successfully intercept id1 and id2, breach the digital identity exchange service, and discover the private keys from the captured public keys. Alternatively, the high-jacker could attempt to breach both owners’ devices and identity agents.

• R5: Secure Agent Transactions End-to-End.

• D5: Secure Identity Agent Collaboration.

Design element D5 satisfies R5 by enabling collaborating identity agents to secure transactions end-to-end in order to thwart surveillance and tampering. Once identity agents have reliably transferred digital identities, they can use them to securely collaborate bilaterally by selecting designated keys bound to their digital identities. When sending a payload, the sender’s private signing key and the recipient’s public encrypting key are applied. When receiving, the recipient’s private decrypting key and the sender’s public verifying key are applied.

• R6: Secure Private Data and Message Transfers.

• D6: Secure Application Service Collaboration.

Design element D6 enables collaborative services (e.g. web messaging apps) to implement R6 by leveraging already exchanged digital identities held in owners’ wallets and contact lists to secure messages end-to-end. The owners’ identity agents expose an API to the service at each endpoint. By means of these APIs, the sending owner directs the service to select a digital identity from her wallet and a digital identity of the recipient from her contacts list. The sender’s identity agent uses the private signing key of her digital identity and the public encrypting key of the recipient’s digital identity to respectively sign and encrypt the message and send this message together with digital fingerprints¹¹ of the sender’s and recipient’s digital identities to the recipient. The service at the recipient’s endpoint uses the identity agent’s API to select the digital identities from the recipient’s wallet and contacts list, verify the received digital fingerprints, decrypt the message, and verify the digital signature.

Privacy by Design Default Settings of Interoperability Design View

By default the interoperability design view could be configured to invoke the adapted Diffie-Hellman exchange protocol to reliably transfer collaborators’ digital identities. Identity agents and applications could default to using digital identities to secure all transactions end-to-end. Owners should be warned of the risks of choosing to exchange digital identities and transactions when using less reliable transfer methods.

• C. Verification Design View

The Verification Design View shown in Fig. 7 encompasses design elements D7, D8 and D9 implementing privacy requirements R7, R8 and R9. The proposed privacy by design default settings for the Verification Design View are also identified.

• R7: Detect Counterfeits and Prevent Impersonation.

• D7: Proof-of-Possession and Proof-of-Custody Verification.

Design element D7 combines prior art proof-of-possession [10] with proof-of-custody (remote authentication-on-demand) to satisfy R7 by verifying that a remotely located owner controls her digital identities and device. This adaptation relies on the identity agent encapsulating the owner’s authentication data and digital identities.

Figure 7 (2, 3, 4) shows two parties synchronously collaborating online. The identity agent of the depicted owner presents a public copy of her digital identity to the identity agent of the relying party (2). The identity agent of the relying party verifies the presented identity and obtains proof that the originator controls the associated digital identity. To accomplish this, the relying party’s identity agent uses a public key of the presented digital identity to launch a proof-of-possession challenge (3) to verify the presented digital identity. Such challenges can only be satisfied by using the paired private key of the digital identity controlled by the originator’s identity agent. Executed bilaterally, both parties can determine whether the identity agent of the collaborator controls the presented digital identity thereby detecting counterfeits.

Once possession of the private key has been verified, the identity agent of a relying party can send a proof-of-custody demand (4) to the originating identity agent to verify custody by the enrolled holder using design element D1. An affirmative proof-of-custody indication is returned if the originator is successfully authenticated. This element of the protocol can also be conducted bilaterally.

Used together, collaborating identity agents can execute proof-of-possession and proof-of-custody challenges to prove that the corresponding party controls the presented digital identity thereby detecting impersonation and ensuring that subsequent transactions can be secured end-to-end (9).

• R8: Verify Acquired Identifying Information.

• D8: Proof-of-Existence Registration and Verification.

To satisfy R8, design element D8 has adapted¹² a “proof-of-existence” hashing method popularized by blockchain [15] with our digital sealing method. This method enables owners to verify each other’s digital identities when collaborating asynchronously (e.g. email and messaging). Figure 7 illustrates the owner registering a digital identity (5) in a proof-of-existence identity registry and a relying party verifying it (6).

When registering a digital identity in the proof-of-existence identity registry (5), the registry’s identity agent first uses design element D7 to execute proof-of-possession and proof-of-custody challenges to verify the identity of the registrant. If successfully verified, the owner’s identity agent hashes the digital identity, digitally seals the hashed digital identity, and uses the registry’s identity agent to store the hash and digital seal in the registry. A relying party, having acquired a registered digital identity from the owner, verifies the acquired digital (6) by having her identity agent hash the digital identity, use the hash to verify that the record exists in the identity registry, retrieve the digital seal, and use a designated public key of the acquired digital identity to verify the affixed digital seal. These steps enable a relying party to determine whether an acquired digital identity exists and was registered by the originating owner. A breach of the registry will not reveal private data of registered digital identities (attributes, images, keys, etc.) because they are hashed.

• R9: Proof, Attest and Verify Attestations.

• D9: Proofing, Attesting, Sealing and Verifying Seals.

Design element D9 satisfies R9 by implementing procedures and methods for proofing, attesting, creating and verifying digital seals and attestations affixed to digital identities. NIST provides identity proofing guidance [16].

Figure 7 depicts two issuers having proofed, attested and affixed digital seals to the owner’s digital identity. The process begins with an issuing owner meeting the requesting owner to validate her identity by inspecting presented identifying information. If successfully identity-proofed, the issuer uses his identity agent to affix an attestation (e.g. “proofed”) to her digital identity using a digital seal (7). A digital seal is created by using a pre-determined sealing image and the private embossing key of a selected digital identity of the issuer (see 7.1). A relying party can verify such digital seals and attestations (8) by using the public inspection key of the public copy of issuer’s digital identity.

As illustrated, multiple parties (users and providers) can proof, attest and digitally seal a given digital identity. Digital identities affixed with multiple digital seals arguably elevate identity assurances over digital identities having a single digital seal or no seals at all. Digital seals can be used to affix attestations to other electronic documents including consent tokens as discussed below.

Privacy by Design Default Settings of Verification Design View

Default settings could include routinely registering digital identities whenever they are created and updated. Proof-of-existence, proof-of-possession and proof-of-custody methods should be employed by default whenever executing high risk or high value transactions (e.g. for banking and critical infrastructures).

• D. Delegated Consent Design View

The Delegated Consent Design View shown in Fig. 8 encompasses design elements D10, D11 and D12 implementing privacy requirements R10, R11 and R12. The privacy by design default settings for this design view are identified below.

Today’s consent models are managed by service providers. For example, OpenID Connect (openid.net) is a server-centric consent model where user authentication and access tokens are wholly controlled by service providers. In contrast, the model described herein decentralizes consent by using digital seals to cryptographically bind stakeholder commitments and identities to consent tokens which can be expired, revoked, registered and tracked. Since commitments are affixed using digital seals, they cannot be repudiated (see Sect.7.1). Figure 8 depicts the consent delegation process. Each consent token identifies the resource owner, resource custodian, requester, the owner’s private resources, access permissions including purposes, and expiry date/time. Given digital seals have sealing images, consent tokens rendered by identity agents visualize commitments for users. The event logger enables accountability.

• R10: Delegate Consent to Access Private Data.

• D10: Acquiring Stakeholder Commitments.

Design element D10 satisfies R10 by enabling resource owners to use their identity agents to delegate consent to other parties requesting access to their private resources. Stakeholders use their identity agents to digitally seal a circulated consent token.

Figure 8 shows a consent token collaboration sequence (1–6) among stakeholders. They use their identity agents and selected digital identities to create digital seals affixing their commitments to the consent token. The resource owner first requires the requesting owner to affix requested permissions and intended purpose to the consent token with a digital seal, and then the resource custodian’s approval to provide access by affixing a digital seal. Once satisfied, the resource owner grants access by digitally sealing the access token and issuing it to the requester who can present the token to the resource custodian whenever requesting access.

• R11: Enable Authorized Access to Private Data.

• D11: Controlling Access to Private Data.

Design element D11 satisfies R11 by using finalized consent tokens to provide authorized access to owner resources controlled by resource custodians according to commitments and approvals affixed to the consent token by stakeholders.

• R12: Hold Stakeholders Accountable.

• D12: Event Logging and Monitoring.

Design element D12 implements R12 by tracking and reporting digitally sealed stakeholder commitments as well as access, expiry and revocation events.

Privacy by Design Default Settings of Delegated Consent Design View

Identity agents should register consent tokens when digitally sealed into a proof-of-existence registry to enable expiry and revocation checking by stakeholders.

• E. Summary

Our privacy by design validation process has confirmed that the proposed identity architecture is capable of reliably and securely supporting the following:

• Identity agents will be able to control owners’ authentication data and deploy digital identities thereby enabling them to control what they disclose;

• Digital identities managed by identity agents will enable owners to secure their transactions end-to-end and protect their private data stored locally or remotely;

• Owners will be able to use their identity agents to proof and attest the digital identities of other parties thereby elevating identity assurances and privacy protection;

• Owners will be able to use their identity agents and digital identities to create digital seals enabling express delegated consent among stakeholders;

• The identified privacy default settings will minimize how much private and identifying information is disclosed by owners, and how much is collected by service providers and collaborating peers.

• Visibility and transparency into the design by way of the privacy by design process will enable third-party validation and improvement benefiting users and providers.