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

2. 4 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

3. 5 The Problem  On the network, traditional “clues” to identity of an individual are not available

4. 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 l possibly for cost allocation

5. 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 l possibly for cost allocation  We need digital credentials that l associate an individual with eligibilities l can assert ‘class’, perhaps anonymously  e.g. “dog”

6. 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

7. 10 What is “Identity” ?  The essence depends on context l Identity is based on attributes associated with an individual or thing l Not all attributes are important for all uses l “Given Name” is seldom useful  It is the individual’s relationship with the world that is (most) important

8. 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 l e.g. application for admission l User Profile

9. 11 Electronic Identity  Essential elements include: l A basic credential that is not easily forged l Attributes associated with that credential V e.g. name, campus position, campus role(s), etc. l Safe means to offer that credential to a service l A means for services to verify that credential  May be assigned to individuals, servers, etc. l “public workstations” can have an identity  An individual may hold several credentials

10. 12 How we use Identity  Eligibility to do something l Based on one or more attributes, etc.  “Signing” transactions or documents for validation and/or non-repudiation  Associating resource use with cost allocation l i.e. charging  As part of “trust”

11. 8 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

12. 9 Authentication is not Authorization  Authentic credentials merely help to relate an individual to attributes  The application or service determines “authorization” l based on attributes l possibly other heuristics  Credentials may assert eligibility

13. 9 Example - internal service  An application may be used by any faculty member l The user offers a basic ID credential l The appliction looks up the “faculty” attribute V should require authentication of the attribute service V may use a campus “attribute proxy” l The application authorizes the user (or not)  An application may be used by any graduate student in Physics after 5PM or on weekends

14. 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 l The license holder determines eligibility V Based on the relationship of the individual to the institution and the Ts & Cs of the contract l The content provider is given a credential that V is issued by the contract holder V asserts eligibility l The content provider authorizes the user (or not)

15. 8 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? l Application or service requirements l University policy l Faculty vs. “other”

16. 14 Public Key Certificates  Electronic documents  Issued by a registered Certificate Authority  Issued to a known entity  Attributes can be associated with the entity l 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

17. 15 Using Public Key Certificates  The basic personal certificate should have minimal content (NetID) l Minimal impact if it is compromised  Attributes should be retrieved from databases l With appropriate access control  Applications use the PKC and attributes l A common Attribute Server can help  Anonymity may require “on demand” secondary certificates

18. 16 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 l Libraries now go to some length to ensure this

19. 17 Multiple Certificates  It is inevitable that individuals will have more than one certificate l Perhaps many more than one l Perhaps issued by different authorities  We need to make this work l Automatic generation and selection l Certificate templates

20. 17 Multiple Certificate Types  Personal certificates are associated with known individuals l Owner must protect the “private key”  “Anonymous certificates” only assert certain attributes associated with the holder l E.g. registered student, UC employee, etc. l Eligible to access on-line information under the terms of publisher’s contract with UC

21. 13 Trust Models  Traditional (institutional) trust is hierarchical l Driver’s licenses, passports, SSNs, credit cards l Transitive Trust: V A & B trust; B & C trust; do A & C trust? V In “real life” A asks B about C; C asks B about A  We can do the same digitally l Credentialing services must be registered with one or more trust brokers l The trust broker must enforce standard practices

22. 17 What’s missing in PKI today?  Lots! l The CA is the easy part  User interface to the use of certificates  Portability  Management of certificates l E.g. revocation, escrow  Attribute definitions and services  Heirarchical trust

23. 17 A Common Solution?  Can we articulate a common framework and strategy for the use of PK certificates?  Can we define the missing pieces? l E.g. Attribute definitions and services  Can we develope hierarchical trust? l E.g. CREN’s CA  Can we work with vendors to “fix” browsers?  Can we demonstrate proof of concept

24. 18 UC Common Authentication Project  Uses Public Key Certificates l CA may be outsourced...  Will provide electronic credentials for all members of the UC community l a lifetime NetID  Flexible association of attributes l the University Directory l Campus attribute directories  Anonymous Certificates also will be issued

25. 20 Certificate Management Issues  Initial issuance l “Strength” of the ID required l Who is the “notary”? l What are the implications of being a notary?  User interface must be simple, intuitive  Portability  Revocation  Public Workstations

26. 21 UCCAP Initial Applications  MELWEB  Benefits enrollment  Other ESS functions  Access to licensed electronic publications  Electronic commerce  Etc.

27. 22 UCCAP Status  Limited Production System initially  Prototype Root CA operational at OP l uses Netscape CA server  Prototype Campus CA’s under development  MELWEB certificate interface in test mode  University Directory in prototype stage l NetID’s defined l All UC employees are entered l Students will be entered during Spring term

28. 24 More information David L. Wasley david.wasley@ucop.edu Vance Vaughan vance@uclink.berkeley.edu See also http://www.ucop.edu/irc/wp/wp_Reports/wpr001 http://www.ucop.edu/~authuser/cap