Identity in the Virtual World: Creating Virtual Certainty David L. Wasley Information Resources & Communications UC Office of the President.

Identity in the Virtual World:

Creating Virtual CertaintyCreating Virtual Certainty

David L. WasleyInformation Resources & Communications

UC Office of the President

4

Overview

What are we trying to accomplish?“Network Identity”Authentication is not AuthorizationThe Need for AnonymityWhat’s missing?The UC Common Authentication Project

5

The Problem

On the network, traditional “clues” to identityof an individual are not available

6

The Problem

On the network, traditional “clues” to identityof an individual are not available

Appropriate control of access to information resources and services is necessary possibly for cost allocation

7

The Problem

On the network, traditional “clues” to identity of an individual are not available

Appropriate control of access to information resources and services is necessary possibly for cost allocation

We need digital credentials that associate an individual with eligibilities can assert ‘class’, perhaps anonymously

e.g. “dog”

4

What are we trying to accomplish?

We must create a set of credentials and supporting infrastructure so that we can recreate in the digital world an analog of the control and management procedures with which we are familiar.

This includes a basis for “trust”To accomplish this requires fundamental

understanding of the problems

10

What is “Identity” ?

The essence depends on context Identity is based on attributes associated with

an individual or thing Not all attributes are important for all uses “Given Name” is seldom useful

It is the individual’s relationship with the world that is (most) important

10

Different types of Identity

Specific association with an individual is required for many purposes

Association with a class of individuals may be adequate for some things

Correlation of sequential activities may be the important function e.g. application for admission User Profile

11

Electronic Identity

Essential elements include: A basic credential that is not easily forged Attributes associated with that credential

e.g. name, campus position, campus role(s), etc. Safe means to offer that credential to a service A means for services to verify that credential

May be assigned to individuals, servers, etc. “public workstations” can have an identity

An individual may hold several credentials

12

How we use Identity

Eligibility to do something Based on one or more attributes, etc.

“Signing” transactions or documents for validation and/or non-repudiation

Associating resource use with cost allocation i.e. charging

As part of “trust”

8

Who creates Identity?

Whoever assigns the attributes!Dozens of different “authorities”Inherently a distributed modelAcceptance is based on mutual trustBroad access creates a new set of

challenges

9

Authentication is not Authorization

Authentic credentials merely help to relate an individual to attributes

The application or service determines “authorization” based on attributes possibly other heuristics

Credentials may assert eligibility

9

Example - internal service

An application may be used by any faculty member The user offers a basic ID credential The appliction looks up the “faculty” attribute

should require authentication of the attribute service may use a campus “attribute proxy”

The application authorizes the user (or not)An application may be used by any graduate student

in Physics after 5PM or on weekends

9

Example - external service

A provider of site licensed content needs to know that a potential user belongs to the class of individuals eligible to gain access The license holder determines eligibility

Based on the relationship of the individual to the institution and the Ts & Cs of the contract

The content provider is given a credential that is issued by the contract holder asserts eligibility

The content provider authorizes the user (or not)

8

Conflicts can arise because ...

Intellectual freedom demands privacyThe institution has occasional need to circumvent

privacyService providers need assurance that access is

granted appropriatelyWho decides what is appropriate?

Application or service requirements University policy Faculty vs. “other”

14

Public Key Certificates

Electronic documentsIssued by a registered Certificate AuthorityIssued to a known entityAttributes can be associated with the entity

perhaps indirectly via “attribute databases”

Any receiver can validate the credentialThe “private key” can be used for “signing”Public keys are used for secure transactions

15

Using Public Key Certificates

The basic personal certificate should have minimal content (NetID) Minimal impact if it is compromised

Attributes should be retrieved from databases With appropriate access control

Applications use the PKC and attributes A common Attribute Server can help

Anonymity may require “on demand” secondary certificates

16

The Need for Anonymity

Intellectual freedomCompetitive advantageProtect appropriate privacy (e.g. marketing)Electronic voting (very hard)True anonymity means it isn’t possible to

trace the credential to any association with a particular individual Libraries now go to some length to ensure this

17

Multiple Certificates

It is inevitable that individuals will have more than one certificate Perhaps many more than one Perhaps issued by different authorities

We need to make this work Automatic generation and selection Certificate templates

17

Multiple Certificate Types

Personal certificates are associated with known individuals Owner must protect the “private key”

“Anonymous certificates” only assert certain attributes associated with the holder E.g. registered student, UC employee, etc. Eligible to access on-line information under the

terms of publisher’s contract with UC

13

Trust Models

Traditional (institutional) trust is hierarchical Driver’s licenses, passports, SSNs, credit cards Transitive Trust:

A & B trust; B & C trust; do A & C trust? In “real life” A asks B about C; C asks B about A

We can do the same digitally Credentialing services must be registered with one or

more trust brokers The trust broker must enforce standard practices

17

What’s missing in PKI today?

Lots! The CA is the easy part

User interface to the use of certificatesPortabilityManagement of certificates

E.g. revocation, escrow

Attribute definitions and servicesHeirarchical trust

17

A Common Solution?

Can we articulate a common framework and strategy for the use of PK certificates?

Can we define the missing pieces? E.g. Attribute definitions and services

Can we develope hierarchical trust? E.g. CREN’s CA

Can we work with vendors to “fix” browsers?Can we demonstrate proof of concept

18

UC Common Authentication Project

Uses Public Key Certificates CA may be outsourced . . .

Will provide electronic credentials for all members of the UC community a lifetime NetID

Flexible association of attributes the University Directory Campus attribute directories

Anonymous Certificates also will be issued

20

Certificate Management Issues

Initial issuance “Strength” of the ID required Who is the “notary”? What are the implications of being a notary?

User interface must be simple, intuitivePortabilityRevocationPublic Workstations

21

UCCAP Initial Applications

MELWEBBenefits enrollmentOther ESS functionsAccess to licensed electronic publicationsElectronic commerceEtc.

22

UCCAP Status

Limited Production System initiallyPrototype Root CA operational at OP

uses Netscape CA server

Prototype Campus CA’s under developmentMELWEB certificate interface in test modeUniversity Directory in prototype stage

NetID’s defined All UC employees are entered Students will be entered during Spring term

24

More information

David L. Wasley

[email protected]

Vance Vaughan

[email protected]

See alsohttp://www.ucop.edu/irc/wp/wp_Reports/wpr001

http://www.ucop.edu/~authuser/cap