Identity in the Virtual World:
Creating Virtual Certainty
David L. Wasley
Information Resources & Communications
UC Office of the President
Overview
What are we trying to accomplish?
“Network Identity”
Authentication is not Authorization
The Need for Anonymity
What’s missing?
The UC Common Authentication Project
4
The Problem
On the network, traditional “clues” to
identity
of an individual are not available
5
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
6
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”
7
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
4
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
10
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 11
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”
12
Who creates Identity?
Whoever assigns the attributes!
Dozens of different “authorities”
Inherently a distributed model
Acceptance is based on mutual trust
Broad access creates a new set of
challenges
8
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


The content provider is given a credential that



Based on the relationship of the individual to the
institution and the Ts & Cs of the contract
is issued by the contract holder
asserts eligibility
The content provider authorizes the user (or not)
9
Conflicts can arise because ...
Intellectual freedom demands privacy
The institution has occasional need to
circumvent privacy
Service providers need assurance that
access is granted appropriately
Who decides what is appropriate?



Application or service requirements
University policy
Faculty vs. “other”
8
Public Key Certificates
Electronic documents
Issued by a registered Certificate Authority
Issued to a known entity
Attributes can be associated with the entity

perhaps indirectly via “attribute databases”
Any receiver can validate the credential
The “private key” can be used for “signing”
Public keys are used for secure transactions
14
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
15
The Need for Anonymity
Intellectual freedom
Competitive advantage
Protect 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
16
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
17
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
13
What’s missing in PKI today?
Lots!

The CA is the easy part
User interface to the use of certificates
Portability
Management of certificates

E.g. revocation, escrow
Attribute definitions and services
Heirarchical 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
17
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
18
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, intuitive
Portability
Revocation
Public Workstations
20
UCCAP Initial Applications
MELWEB
Benefits enrollment
Other ESS functions
Access to licensed electronic publications
Electronic commerce
Etc.
21
UCCAP Status
Limited Production System initially
Prototype Root CA operational at OP

uses Netscape CA server
Prototype Campus CA’s under development
MELWEB certificate interface in test mode
University Directory in prototype stage



NetID’s defined
All UC employees are entered
Students will be entered during Spring term
22
More information
David L. Wasley
[email protected]
Vance Vaughan
[email protected]
See also
http://www.ucop.edu/irc/wp/wp_Reports/wpr001
http://www.ucop.edu/~authuser/cap
24