Kaspar Etter

+41 79 851 66 46

kaspar.etter@digitalid.net

Digital IDThe Identity Layer

Motivation

2Protocol

In case of e-mail, you don’t care whether the

recipient uses the same provider as you do.

Why isn’t this the case for all web services?

Vision

3Protocol

The vision of Digital ID is to supersede

closed platforms with open standards.

⇒

Requirements

In order to take out the intermediary, we need:

● Identities for cross-provider authentication,

● Semantics for client-side data aggregation.

4Protocol

Supply DemandIntermediary

Abstract

Digital ID is a protocol that constitutes

● an open identity layer for the Internet,

● a lookup layer for personal information.

By making the identity part of the protocol,

accounts and logins are no longer needed,

which improves security and usability.

5Protocol

Identity Layer

Client

6Protocol

Application LayerEncodes the request and the response.

Handles the application logic and protocol.

Identity LayerAdds the identities of the sender and recipient.Enables compression, signature and encryption.

Transport LayerAdds the ports of the sending & receiving processes.Provides reliable, in-order byte-stream data transfer.

Internet LayerAdds IP addresses of sending & receiving devices.

Routes the packets across the network of networks.

Server

No passwords, no phishing!

Lookup Layer

7Protocol

         Service Layer

Identity Layer      

Alice Bob

Server

Client

Server

Server

1. Authorization 2. Lookup 3. Link

4. Request

“DNS for personal information”

Extensibility

Digital ID is intentionally kept as minimal and

generic as possible for modularity reasons.

The core protocol is extended by services that

use it as a lookup layer for host resolution and

as an identity layer for user authentication.

8Protocol

Digital ID (Identity and Lookup Layer including Contacts Management)

Messaging Files Calendar Updates Banking Health …

“Identity-based HTTP”

Independence

As Digital ID specifies how digital identities

are handled, every client is compatible with

every host, making them fully exchangeable.

9Protocol

Current Web Digital ID

⇒Proprietary Access Standardized Access

“Extensible SMTP & IMAP”

Data

Freedom: Separate Data and Logic

10Protocol

Logic

 Client

 Server

CompaniesCommunity

CompaniesCommunity

Providers orSelf-Hosting

Users

Software

Software

Hosting

User Control: We’ve been there before!

11Protocol

UserControl

CompanyControl

Logic

Data

PersonalComputer

PublicCloud

PersonalCloud

1995 2015

Logic

Data

Logic Data

Personal Cloud

decentralized

Digital ID combines

all benefits!

Value Propositions: Personal Cloud

12Protocol

Private Cloud

isolated

PrivacyCustomizationIndependence

Public Cloud

centralized

ConvenienceScalabilityGlobality

Comparison: Identity Standards

There are two major distinctions:

● Is the user or a client authenticated?

● Is the authentication towards your own

provider or the one of a friend/coworker?

Authorization of clients enables automation.

13Protocol

User Client

Internal HTTP Authent. OAuth (for APIs)

External SAML, OpenID Web ID, Digital ID

14Protocol

Comparison

«A Comparative Analysis of

Identity Standards for the

Internet» by Kaspar Etter.

An explanation for the selection of standards and

the criteria can be found on

https://www.digitalid.net/

documents/Report.pdf.

SAML: Security Assertion Markup Language (OASIS)

Name SAML OpenID WebID Digital ID

Suitability -- - + ++

– Scope of Identity - + + +

– Ext. Attribute Lookup - - + +

– Client Authorization - - + +

– User Accountability - - - +

Usability + - + +

– No Ad. Requirements + + + -

– Attribute-Based AC + - + +

– Support of Contacts - - + +

– Autom. Authentication + - - +

Security (-) (--) + ++

– Phishing Vulnerability (-) (-) + +

– Authentication Factor (-) (-) + +

– Limited Compromise - - - +

– Single Logout (+) - + +

Privacy - = = ++

– Calling Home - - + +

– No Wrong Consent (-) + - +

– Attribute Selection - + + +

– Pseudonymity + - - +

15Protocol

Current Web vs. Semantic Web (DID)

Many security issues come from

users running untrusted code:

Phishing, Cross-Site Scripting,

Cross-Site Request Forgery.

No possibility for phishing as the

secret never leaves the machine.

Another advantage is the ability to

communicate with several servers.

Web ServerAggregation of Information

Thin ClientOrdinary Web Browser

Data Code ⇒

DID ServerUser Access Control

Thick Client Aggregation of Information

Data

Code

DID ServerUser Access Control

Data

A bold step but trend from web to mobile anyway!

16Protocol

Screenshots: Desktop Prototype

17Protocol

Screenshots: Android Prototype

This app was developed by www.arnes.ch.

Licensing: AGPLv3 and Proprietary

18Protocol

The current implementation of the Digital ID protocol is available under:

Open Source: Copyleft

You are free to use our code (also

commercially) as long as you make

your code accessible to the general

public under the same conditions.

Closed Source: Copyright

In case you prefer to keep your code

that builds on our Digital ID library

proprietary, we can offer you a

customized but paid license.

.com

Questions

Concepts● Main Concepts● Digital Identity● Attributes and Certificates● Contacts and Contexts● Clients and Roles

19Protocol

Properties● Privacy● Security● Openness● Productivity● Accountability

Contact● kaspar.etter@digitalid.net● +41 79 851 66 46 (mobile)

Links● www.digitalid.net● www.synacts.com

Main Concepts

● Digital Identity: It represents the digital

equivalent of a natural or a legal person.

● Attributes and Certificates: Name-value pairs can be added to any digital identity.

● Contacts and Contexts: References to digital identities are stored hierarchically.

● Clients and Roles: You have to authorize apps or other users to act on your behalf.

20Protocol

Digital Identity

Every digital identity has a globally unique

identifier that consists of the username and

the host (after the “@”), at which it is hosted.

To ensure provider-independence, a digital

identity can be relocated to a new provider.

The old account has to link then to the new

account so that every client learns about it.

Several identities can be merged into one.

21Protocol

Attributes and Certificates

Each attribute has a unique identifier, which

determines both its syntax and its semantics.

Attributes can be cached for some duration before having to be reloaded from the host.

Each attribute has an access policy that de-termines its visibility towards other identities.

Authorities can confirm the correctness of attributes for attribute-based access control.

22Protocol

Contacts and Contexts

Contacts are references to other identities

and are handled with hierarchical contexts.

Contacts are asymmetric and private, which means the added person will not be notified.

Contexts are used to configure how requests to other identities are authenticated (if at all).

Contexts are also useful to address contacts or assign access permissions more efficiently.

23Protocol

Clients and Roles

Being just a protocol without a user interface,

Digital ID can only be accessed by clients.

Besides clients, you can also authorize other digital identities to act in a role on your behalf.

The authorization of agents (clients and roles) can be restricted regarding the contexts and

attributes that they can access and modify.

Agents can only authorize weaker agents.

24Protocol

Privacy

There is no centralized platform and full control can be achieved with self-hosting.

Requests are only signed when specified.

Users are not tracked by third parties and clients do not call home to an ID provider.

Anonymous credentials guarantee a minimal disclosure of personal information by allowing

users to submit certified attributes unlinkably.25Protocol

Security

A conceptual innovation, not a technological.

The encryption of traffic is mandatory andis based on 256-bit AES and 2048-bit RSA.

Instead of relying on passwords, authen-tication uses cryptographic credentials,

replacing knowledge with possession.

Clients are authorized according to the principle of least privilege (revocably).

26Protocol

Openness

The specification of the Digital ID protocolis publicly available at www.digitalid.net.

No license fees have to be paid for using it.

Apart from the strictly hierarchical public key

infrastructure, there is no centralized control.

The standard is maintained and enforced by

the non-commercial Digital ID Association.

27Protocol

Productivity

A unique identifier allows the identification of users across organizations for painless access.

Reduced spam due to authenticated senders.

Semantically stored data allows clients to

aggregate information in a meaningful way.

Smart services automate interactions that

previously required human involvement.

28Protocol

Accountability

Since all actions are digitally signed, everyone can be held liable for his or her (mis-)behavior.

All actions that affect the state of an identity

have to be logged and can thus be audited.

This ensures that hosts cannot frame users.

(If hosting providers misuse their power and

act as one of their users, this can be detected.)

29Protocol

Questions (continued)

Protocol● Protocol Flow● Packet Pipeline● Synchronization● Extensible Data Format

30Protocol

Architecture● Peer-to-Peer Architecture● Web of Trust Comparison● Public Key Infrastructure● Extensible Data Format

Comparisons● OpenID and SAML● OAuth and openPDS● X.509 Certificates (WebID)● Pretty Good Privacy (PGP)

Protocol● RSA Cryptosystem● Schnorr Signature● Anonymous Credentials● Verifiable Encryption

Protocol Flow

31Protocol

Client Server

1. Request

2. Response

Packet Pipeline

32Protocol

Sender

Compression

Signature

Encryption

Content

Decompression

Verification

Decryption

Content

Recipient

of a certain request-or response-type

ability to combine several contents

either none, host, client or credentials

RSA & AES with replay detection

TCP/IP

Synchronization

33Protocol

 Server

 Client

State

Action

SynchronizerReplyQuery

Extensible Data Format (XDF)

For the exchange of information, Digital ID introduces the extensible data format that is

based on types modeled as digital identities.

It has two kinds of types for blocks of bytes:

● Syntactic types specify a block’s encoding.

● Semantic types specify a block’s meaning.

Semantic types are based on syntactic types,

which can take semantic types as parameters.

34Protocol

Peer-to-Peer NetworkPeers share resources:

No single point of failure

Natural load balancing

Client-Server ModelServer provides service:

No freeloader problem

Reduced complexity

Peer-to-Peer Architecture

35Protocol

Digital ID uses a decentralized client-server model.

Web of Trust

36Protocol

Web of TrustDecentralized trust model:

No common trusted third party required for authent.

Better resilience against numerous cyber attacks

Public Key InfrastructureCentralized trust model:

Requires less knowledge and effort from users

Certificates are globally approved (for all users)

Digital ID: Security may not rely on ignorance!

Public Key InfrastructureDigital ID uses a strictly hierarchical public key

infrastructure so that failures don’t affect all:

By caching the public keys, corrupted certificate authorities pose no immediate threat (to most).

If digital signatures shall guarantee liability and

not just authenticity, then certificate revocation

lists do not work (new problem: timestamping).37Protocol

X.509: Digital ID:.ch

.de

ethz.ch inf.ethz.ch

uzh.ch mnf.uzh.ch

tum.de in.tum.de

DIDA

End-to-End Encryption

38Protocol

Arguments against E2EE:

With self-hosting, Digital ID is

indeed end-to-end encrypted.

When attribute-based access

control is used, the recipients are not known beforehand (which makes E2EE difficult).

E2EE prevents key recovery,

thin clients and data analytics.

E2EE makes the authorization

of clients way more difficult.

Arguments in favor of E2EE:

Less trust in provider needed

(who could still provide wrong public keys unless a web of trust instead of a PKI is used).

No bulk leaks of confidential

information in case of hacks.

No government surveillance

with Patriot Act or BÜPF/NDG (could also be against E2EE).

Sousveillance as alternative.

Comparison: OpenID and SAML

39Protocol

Single sign-on and federation standards are

not suited for the decentralization of services:

● They authenticate users instead of clients.

● They typically cannot be used for lookups.

● They often involve a lot of user interaction.

● They are a security nightmare (phishing,

complete compromise, often no logouts).

● They are also a privacy nightmare (calling

home, weak anonymity, wrong consent).

Comparison: OAuth and openPDS

OAuth allows to authorize clients for access

to resources with tokens instead of password.

OAuth is rather a framework than a protocol.

OAuth does not standardize the secured API.

OAuth does not introduce real user identities.

OAuth does not support asynchronous autho.

openPDS designed for analytics, not sharing.

40Protocol

Comparison: X.509 Certificates

WebID relies on client-side certificates for user authentication and works in any browser.

Users publish their public key on their profile.

WebID is the best alternative approach and gets a lot of things right regarding security.

It has issues regarding usability and privacy.

It lacks a lot of concepts like least privilege.

It complements DID for Web authentication.41Protocol

Comparison: Pretty Good Privacy

PGP was created by Phil Zimmermann in 1991.

Mainly used to sign and encrypt e-mails/files.

Similar signing and encryption mechanisms.

Uses a web of trust to verify the public key of

a person instead of a public key infrastructure.

It has never been used to authenticate users

at services and can not act as a lookup layer.

42Protocol

RSA Cryptosystem

Key Generation

Choose random primes p and q, compute n = p · q.

Compute φ(n) = (p - 1) (q - 1), choose e w. gcd(e, φ(n)) = 1.

Determine the multiplicative inverse of e: d ≡φ(n) e-1.

Publish modulus n & exponent e, retain d as private key.

Encryption/Verification

Compute ciphertext c ≡n me (m being a group element).

Decryption/Signing

Compute m ≡n cd ≡n (me)d ≡n m1 + k·φ(n) ≡n m (mφ(n))k ≡n m · 1k,

using Euler’s Theorem and that d · e – 1 = k · φ(n) for a k.

43Protocol

Schnorr Signature

Proof knowledge of x such that y ≡n gx:

● Compute t ≡n gr with random r ∈ Zφ(n).

● Compute c = hash(t) [ ⊕ hash(m)].

● Compute s = r – c · x, provide (t, c, s).

● Verify that t ≡n gs · yc ≡n gr – c · x · (gx)c.

This is a non-interactive version of a zero-

knowledge proof, with the challenge c being

determined after the value t has been fixed.44Protocol

Anonymous Credential System

Camenisch and Lysyanskaya Scheme:

● The public key of hosts consists of:RSA modulus n and bases f, g and h.

● Commit to x in RSA group: c ≡n gx hr.

● Host computes b ≡n (f–s c)–1/e with e.

● Prove fs ≡n b’e gx hr – e · r’ with b’ ≡n b · hr’.

Such credentials can be shown unlinkably.

45Protocol

Verifiable Encryption

In order to revoke the anonymity of a user,

its identity can be verifiably encrypted for

the issuing authority the following way:

● For any number z: (1 + z)m ≡z2 1 + m · z.

● Private key: Randomly chosen value x.

● Public key: Prime z, element g, y ≡z2 gx.

● Encrypt m as wm ≡z2 (yr · (1 + z)m, gr).

● Decrypt wm as m ≡z2 (w1 / w2x – 1) / z.

46Protocol