Journal of Information, Law and Technology

Identity Authentication and ‘E-Commerce’

Matthew D. Ford
BT Laboratories
Ipswich

m.d.ford@talk21.com, matthew.ford@bt.com 

This is a refereed article published on: 30 October 1998 

Citation: Ford M, 'Identity Authentication and 'E-Commerce'', 1998 (3) The Journal of Information, Law and Technology (JILT). <http://www.law.warwick.ac.uk/jilt/98-3/ford.html>

Abstract
Identity authentication is the process whereby some chosen attribute of a real-world entity (‘the distinguishing character or personality of an individual’) is demonstrated to belong to that entity. As ever larger numbers of organisations start to transact business over the Internet and other open networks, it becomes increasingly important to achieve secure identity authentication. A variety of identity authentication systems are available: including passwords, physical tokens, biometrics and digital signatures. Digital certificates attesting to a relationship between a documented attribute and a public key provide an extremely secure, affordable and flexible means of identity authentication. The procedures for establishing the veracity of a subscriber’s claims are varied and depend upon both the type of certificate being sought and the level of assurance required. A taxonomy of commercially available digital certificates in relation to their procedures for identity authentication reveals some interesting differences and ambiguities in the terminology adopted by the organisations providing them. Above all, the paucity of information currently made available by such organisations indicates the embryonic state of these systems and their associated procedures. Authority authentication is highlighted as an area in particular need of more research.

1. Introduction
Identity authentication systems and procedures are rapidly becoming one of the central issues in the practice and study of information systems development and security. The need to make electronic transactions secure is now a standard caveat attached to projections of e-commerce growth. While the global reach of the Internet and its potential for dramatically reducing transaction costs make it a very attractive medium for transacting business - to organisations and individuals alike - the inherent insecurities of an open network make this problematic.

Modern asymmetric cryptography techniques are gaining currency as a practical technical solution to the problems posed by open networks. However, these techniques cannot solve the real-world human issues of confidentiality, identity and authority. This paper will focus on currently documented procedures for identity authentication and how they relate to the real world. Specifically, what are the mechanisms for confirming or authenticating a real-world identity? What levels of assurance can we attach to these different mechanisms?

After refining the terms ‘e-commerce’ and ‘identity authentication’, the paper will provide an overview of the technical systems available for authenticating identity, before analysing the procedures available for identity authentication. An incomplete taxonomy of commercial solutions is presented and, finally, some comments on the increasingly important area of authority authentication are provided.

N.B. This paper does not discuss the legal validity of identity authentication techniques. Regional and national jurisdictions are beginning to issue legislation concerning digital signatures and there is, currently, no internationally accepted standard. Readers should be aware that, whatever the identity authentication techniques involved, local legal stipulations need to be understood in order that the techniques are productively implemented. Cross-border recognition of digital certificates and other identity authentication methods is an issue that has only recently begun to be addressed.

2. E-Commerce
Before discussing identity authentication, it is necessary to be clear about what is meant by e-commerce. Electronic commerce has been a feature of information systems in large organisations for many years now. The implementation of Electronic Data Interchange (EDI) systems, beginning in the early 1980s, facilitated electronic ordering, stock control, invoicing and all the features of a modern business transaction (excluding, until fairly recently, payment). Ensuring the security of these systems has been a relatively insignificant problem as they are constructed around closed networks between long-established business partners with prior, real-world, business relationships. Issues of trust, identity and confidentiality are, therefore, relatively unproblematic in this context.

More recently, the exponential growth of the Internet has created both the potential for, and a desire to conduct, these same business-to-business transactions, but also, critically, business-to-consumer transactions, across open networks. This development has given rise to some significant concerns. The openness of the network creates problems of confidentiality, and, in combination with the absence of a prior real-world relationship between the transacting parties, problems of identification and trust.

We should not focus exclusively on the commercial potential of modern computer communications networks however. Wherever two parties, be they individuals or organisations, public or private, wish to conduct a transaction across an open network such as the Internet, concerns as to confidentiality and identity will arise. Financial transactions across the Internet are usually cited as the best example of the need for confidentiality and identity authentication, for obvious reasons. However, governments and other public bodies also need to ensure rigorous identity authentication procedures are implemented before they can undertake electronic transactions with private individuals. The negative consequences of issuing a bogus passport are, surely, greater than those incurred from non-payment of an invoice. The following analysis of identity authentication issues, systems and procedures will, therefore, have relevance to any individual or organisation, whether public or private, wishing to transact across an open network for profit, or otherwise.

3. Identity Authentication
Identity n 2 the distinguishing character or personality of an individual
[The New Penguin English Dictionary]

Identity authentication is the process whereby some chosen attribute of a real-world entity (‘the distinguishing character or personality of an individual’) is demonstrated to belong to that entity. For example, if I am standing in front of you (provided that you are not visually impaired) the unique topography of my face is demonstrated to belong to me because you can see that it is attached to the rest of my body and that it displays all the subtleties of expression that you would expect in a human face. Thus, seeing my face permits identity authentication to take place. Note that I do not need to tell you my name.

This basic instance of identity authentication serves little purpose, except that it would permit a connection to be made between this instance of seeing my face and another instance of seeing my face in the future. In that case you could be reasonably certain that this was the same person you had seen before. This is an example of a very weak identity. A stronger identity is created, for example, when I tell you my name. Provided that you trust me not to lie about my name, this newly authenticated identity is more useful: you can find my phone number in a directory, or my office in a building. Note that trust is also implicit in the example of weak identity above: I could be a polymorphic extra-terrestrial.

In the field of information systems, identity authentication is increasingly important as more and more social and business transactions take place on-line. The complete absence of a physical presence coupled with the ever-present risks of communications interception demand that strong, easily verifiable and unique identity tokens are used during on-line transactions. These identity tokens come in various forms and are detailed in the next section.

It is important to be aware that the meaning of ‘identity’ is contingent upon the purpose for which its verification is being sought. In the definition of identity authentication given above, the phrase ‘chosen attribute’ reflects this. In the dictionary definition of identity, what makes a characteristic ‘distinguishing’? For some applications it may be a name, for others an age or a gender. In many e-commerce applications, the distinguishing characteristic is that of credit-worthiness, often coupled with a name and address for marketing purposes. This identity contingency gives rise to a need for flexibility in identity authentication systems if they are to be widely implemented.

These issues of attribute selection, trust, and contingency are central to the debate surrounding modern identity authentication systems, particularly in conjunction with issues of privacy and data protection, and would benefit from further research.

Having refined our terms, it is possible to examine the various identity authentication systems available and their respective merits and demerits.

4. Identity Authentication Systems
Authentication ‘is the most essential of all the security services because reliable authentication is needed to enforce access control, to determine who is authorised to receive or modify information, to enforce accountability, and to achieve non-repudiation.’ There are five methods of authenticating an identity principal:

1.	Something the claimant knows;
2.	Something the claimant owns;
3.	Something the claimant is;
4.	Claimant is at a particular place (at a particular time); and,
5.	Authentication is established by a trusted third party. 

Depending exclusively on any of methods 1-4 is generally inadequate and multi-token authentication systems are the norm. For example, bank ATM systems use a combination of methods 1 and 2 in the form of passwords (PINs) and bankcards.

In addition, there are two contexts in which authentication can take place: entity authentication; and data origin authentication. Entity authentication may be either unilateral or mutual. Mutual authentication is preferable in every instance to avoid the potential for ‘spoofing’ attacks. This paper is concerned exclusively with entity authentication techniques used to facilitate electronic transactions involving individuals and/or organisations and, as such, will not consider authentication protocols used in secure communications systems, or in secure computer operating systems. The different forms of identity tokens used to authenticate identity will now be examined.

4.1 Passwords, Physical Tokens and Biometrics
Passwords (in combination with user names) have been the mainstay of identity authentication systems since multi-user information systems came into being. Unfortunately, they are also one of the least secure techniques available and  ‘constitute one of the major vulnerabilities of electronic commerce systems.’ Threats to password-based authentication are:

•	External disclosure;
•	Guessing;
•	Communications eavesdropping;
•	Replay attacks; and,
•	Host compromise.

Password authentication systems are so notoriously insecure that they are nearly always combined with other methods of identity authentication.

Physical tokens are frequently used to enhance the security of identity authentication systems. Physical storage tokens are used by banks to corroborate an account number (held on a magnetic stripe card) with a password (PIN). More recently, tamper-proof integrated circuit cards (ICCs) allow the physical token to interact dynamically with the verification hardware. Examples of this interaction include:

•	Synchronous one-time passwords;
•	Challenge-response; and,
•	Digital signatures.

Using these ICC tokens affords greater protection against reverse-engineering, forgeries and replay attacks to which stripe cards are susceptible.

Biometric techniques include fingerprint recognition, retinal scanning, hand-geometry scanning, and handwriting or voice recognition. These techniques are all, currently, extremely expensive to implement effectively and are therefore only worth considering in big-budget, high-security applications. As the drawbacks (including high cost, poor ergonomics, reliability, speed, and data storage requirements) are mitigated by improvements in technology, biometric techniques could emerge as the most secure method of automated identity authentication.

4.2 Digital Signatures
Strong asymmetric cryptography combined with secure hash functions allows the creation of a digital signature. Digital signatures verify that the sender of a message is in possession of a unique ‘private’ key and also verify that the message has not been altered in transit. An examination of the technical details of this procedure is beyond the scope of this paper.

4.3 Certification Authorities and Digital Certificates
As stated above, digital signatures verify that the sender of a message is in possession of a unique private key. In order to verify a message signed with a digital signature, the recipient needs a copy of the sender’s public key. If the recipient knows the sender personally and can meet with them to exchange public keys, then a secure identity authentication system can be established. Electronic transactions between people or organisations in close physical proximity, with prior identity-trust relationships, are in the minority however, as has been discussed. It is therefore necessary to trust someone to provide recipients with public keys and to guarantee the association of the public key with some ‘chosen attribute’. This function is performed by a Certification Authority (CA) which issues digital certificates attesting to the connection between attribute and public key. Thus, ‘a public key is a surrogate presence in cyberspace for some entity in physical space. It acts directly in cyberspace, just as the associated entity can act in physical space.’

This is Bob’s public Key
Bob’s CA’s
Signature

               Certification Authority

•	
Public Key
Algorithm

Message
Digest
Algorithm

Digital
Signature

the owner of the key pair
•	the organisation of the owner
•	their public key
•	expiration information

Figure 1: Generating A Digital Certificate

Certification authorities eliminate the problems of scalability and physical separation associated with digital signatures, and introduce the problem of accepting a third party as suitably trustworthy. Several organisations have established themselves as CAs and are now beginning to issue digital certificates. Their procedures for establishing the ‘physical-space’ identity of an entity are examined below, after some comments on the importance of private key protection.

4.4 Private Key Protection
Assuming that the person wishing to authenticate a cyberspace identity trusts his CA and assuming that the CA is operating securely and correctly, the only problem with public key infrastructure (PKI) based systems arises when the private key of a certified private-public key-pair becomes compromised. Private keys must be generated randomly, and stored and transmitted securely in order for the trust placed in the associated digital certificate to be deserved. Once again, the general point is made to draw the reader’s attention to an area of interest, without going into lengthy technical detail about the merits of the various solutions available.

It is important to be aware that, currently, a password (or pass-phrase) is generally used to protect the private keys associated with web browser certificates (used for sending digitally signed e-mail and engaging in Internet-based electronic transactions). This is like buying the most secure door lock on the market and leaving the key under the doormat. The inherent weaknesses of password-based access control systems are not mitigated by utilising them to control access to more sophisticated identity authentication systems. On the contrary, the strength of the PKI fosters an entirely false sense of security when this method of private key protection is adopted.

Storing the private key on a physical token (an ICC card or a PCMCIA card) is an alternative protection method, and, when combined with a password, is a reasonably secure one. A secure biometric system would provide the maximum private key protection, at a price.

5. Identity Authentication Procedures
It is an unproven matter of faith among computer security specialists that private keys and digital certificates can be used to establish identity.

As has been previously stated, digital certificate verification does not prove that the certificate owner possesses the attribute attested to by the certificate. It only proves that they are in possession of a secret cryptographic key that has been signed by an appropriate CA. Michael Baum, who works for VeriSign, the largest and most experienced CA in business, describes digital certificates as providing ‘probative evidence’ useful in making a determination of identity in court. However, as previously stated, this facility depends upon:

•	the User being in control of a randomly-generated and un-compromised private key;
•	the CA following secure operating procedures; and,
•	the CA not being subsequently compromised.

Nobody is suggesting that CA-backed digital certificates are a final solution to the problems of identity authentication, simply that they are significantly more secure than earlier techniques. Despite their observations above, Garfinkel & Spafford (1997) accept that, ‘digital certificates are a substantially more secure way of having people identify themselves on the Internet than the alternative: usernames and passwords.’

With these comments in mind, let us turn to an examination of the procedures used by CAs when issuing digital certificates.

5.1 Types of Digital Certificate
There are basically 4 types of digital certificate:

•	Certification Authority Certificates: these certificates certify the CAs public key. They can be self-signed or signed by another CA. They are used to certify other certificates.
•	Server Certificates: these certificates certify a secure server’s public key. They must be signed by a recognised CA. They are used to identify the server to other servers, users, and CAs.
•	Personal Certificates: these certificates certify an individual’s public key. They must be signed by a recognised CA. They are used to identify the individual to other individuals, network servers, and CAs.
•	Software Publisher Certificates: these certificates certify a software publisher/developer. They must be signed by a recognised CA. They are used to identify developers and their software to other individuals, servers, and CAs.

The following analysis will focus on the authentication procedures adopted by CAs to verify the identity of an entity prior to issuing a personal certificate.

5.2 Certification Authority Procedures
As a component of the operating procedures of a CA, identification and authentication is divisible into four sections:

•	Initial registration;
•	Routine re-key (after certificate expiration);
•	Re-key after revocation; and,
•	Revocation request (due to key loss/compromise).

Sub-components of the initial registration section (which will include all the sub-components of any other section) are as follows:

•	Types of names assigned to the subject;
•	Whether names have to be meaningful or not;
•	Rules for interpreting various name forms;
•	Whether names have to be unique;
•	How name claim disputes are resolved;
•	Recognition, authentication, and role of trademarks;
•	If and how the subject must prove possession of the companion private key for the public key being registered;
•	Authentication requirements for organisational identity of subject; and,
•	Authentication requirements for a person acting on behalf of a subject, including:

•	Number of pieces of identification required;
•	How a CA validates the pieces of identification provided;
•	If the individual must present personally to the authenticating CA; and,
•	How an individual as an organisational person is authenticated.

Ideally, the taxonomy below would present an entry under each of these sub-component headings, for each CA. As is mentioned in the introduction to the taxonomy, the paucity of detailed information currently made available by commercial CAs makes this impossible.

We will now focus on the authentication requirements for establishing organisational and individual identity as mentioned above.

5.3 On-line Procedures
On-line procedures involve transmission of identity-related information across the same network for which a secure form of identity authentication is being sought. These procedures include:

•	Submission of WWW forms containing subscriber details;
•	Submission of public keys, and;
•	3rd party database referral.

Given that the CA needs assurance that both the public key value and the subscriber information originate from the named subscriber and have not been tampered with during transmission, the CA may verify submitted information with an on-line third party database (typically a consumer credit database, like Equifax in the USA).

There still remain severe ‘limitations to the assurances available using a purely online registration system’ however. Transferring some information through traditional off-line channels helps to mitigate these limitations.

5.4 Off-line Procedures
Off-line procedures allow real-world verification of subject identity attributes to take place. These include:

•	Physical presence: Indispensable to a strong confirmation of identity; permits verification of existence, distinguishing characteristics, capacity and intent; facilitates the measuring of biometrics; and,

•	Identification documents (e.g. passport, driver’s licence, employee badge, etc.): Properly analysed photographic ID documents provide an extremely trustworthy verification of the applicant’s identity. Nevertheless, reliance on documentary ID is ‘wrought with potential risks’.

Identity authentication procedures, which employ both on-line and off-line techniques, are relatively trustworthy and form the basis of current commercial CA high-assurance certificate registration practice. However, off-line procedures create problems for CAs desiring to support a large, geographically disperse subscriber population. Solutions to these problems involve establishing local registration authorities (LRAs) or converting existing organisations with the necessary office infrastructure already in place (e.g. banks or post offices) into CAs.

5.5 Local Registration Authorities
LRAs are organisations to which the CA delegates responsibility for authenticating the identity attributes of some real-world entity. LRAs provide local support to a set of CA subscribers. Examples of LRAs include:

•	Chambers of Commerce;
•	Notaries Public; and,
•	Organisational LRAs.

LRA functions might include:

•	Registering, de-registering, and changing the attributes of subscribers;
•	Identifying and authenticating subscribers;
•	Authorising requests for key pair generation;
•	Accepting and authorising requests for certificate suspension or revocation; and,
•	Physically distributing physical tokens (for storing private keys) to, and recovering obsolete tokens from, authorised subscribers.

Organisations wishing to issue digital certificates to their employees may establish themselves as LRAs related to an independent commercial CA. Large organisations may wish to establish themselves as fully functioning CAs with control over the technical and operational procedures, and several commercial organisations are now marketing business solutions to this end. Note that, regardless of who is issuing the certificates, unless subject authentication and private key protection procedures are rigorously defined and maintained, digital certificates will not be worth the silicon they are stored on.

5.6 Certificate Classes
‘The extent to which identity must be confirmed is dependent upon the level of assurances that a particular class or type of certificate purports to provide – this is typically expressed within the applicable certification practice statement or user agreement.’ As will become apparent from the taxonomy below, commercial CAs tend to issue different classes of certificate to cater for different entities and for different assurance requirements. Certificate classes differ with regard to:

•	Stated purpose
•	Identity authentication requirements
•	Validity period
•	Cost
•	CA liability ceiling
•	Minimum key length
•	Subscriber private key protection
•	CA private key protection

A simple example of how some of these factors might be defined is given below:

Type	Identification Requirements	Validity Period	Minimum Key Length	Key Protection	
Low Assurance	Driver’s License, passport, etc	Two Years	768 bits	Floppy Disk	
Medium Assurance	Driver’s License, Passport, etc. With signed authorisation from superior	Four Years	896 bits	Floppy Disk or FIPS 140-1 Level 2 cryptographic token card	
High Assurance	Government Identification card. With signed authorisation from superior	Four Years	1024 bits	FIPS 140-1 Level 3 cryptographic token card	
Source: Ford & Leech (1996)

Table 1: U.S. PKI Technical Working Group Certificate Assurance Levels

This paper is principally concerned with the identity authentication requirements of digital certificates. How do these requirements differ by the class of certificate involved? An attempt to create a specification for certificate-class identity authentication requirements is presented below. (IA stands for Issuing Authority meaning the organisation responsible for issuing the certificates, i.e. not an LRA.)

Class of Certificate	Required Certificate Application Information	
Class 1	Individuals:
Required Information
(a) Common name (or alias)
(b) Subject public key
(c) E-mail address
(d) Executed subscriber agreement
(e) Credit card information (if applicable)
(f) Challenge phrase (to later authenticate subscriber to the IA)
(g) Other information as prescribed by the IA
Optional
(h) Demographic data (Registration Field Information)

Method of Communicating Application: The IA communicates a certificate prototype (unsigned) and a subscriber agreement to the certificate applicant. By completing this on-line dialog via a secure Web channel, the certificate applicant then affirms that (i) the certificate applicant information is accurate and (ii) he or she has read, understands, and agrees to the term of the subscriber agreement. Upon completion of specified validation procedures, the IA sends E-mail to the E-mail address that was provided by the certificate applicant in the certificate application. This E-mail message contains a PIN (and optionally, a draft of information content to be included in the certificate) that authorises the certificate applicant to obtain a certificate from the IA.

Business Entities: Class 1 certificates are issued to individuals only.	
Class 2	Individuals:
Required Information
(a) Legal name (in the form of a common name)
(b) Proposed distinguished name
(c) Street, city, state, postal/zip code, country (of residence)
(d) Voice telephone numbers (of residence)
(e) E-mail address
(f) Subject public key
(g) Credit card information
(h) Spouse’s first name (if applicable)
(i) Social security number
(j) Date of birth
(k) Employer (if applicable)
(l) Challenge phrase (to later authenticate subscriber to the  IA)
(m) Executed subscriber agreement
(n) Previous address (if changed within last two years)
(o) Driver’s license information (if applicable)
(p) The “software publisher’s pledge” (for individual software publisher certificate applicants only)
(q) Other information as prescribed by the IA
Optional
(r) Demographic data (Registration Field Information)
Method of Communicating Application: Same as Class 1.

Business Entities: Class 2 certificates are issued to individuals only.	
Class 3	Individuals:
Required Information – Same as Class 2, plus:
(a) Subscriber agreement acknowledged by a notary or LRA (to fulfil the “personal presence” requirement) upon presentation of three (3) forms of identification by the certificate applicant.
Optional
(b) Previous employer
Agents/Authorised Representative: Class 3 permits businesses (but not individuals) to have an agent apply for a certificate, naming the principal (business) as a subscriber.
Method of Communicating Application: TBD

Business Entities:
Required Information
(a) Domain name
(b) Organisation
(c) Organisational unit (if applicable)
(d) Technical and billing contact persons
(e) City, state, country, postal/zip code
(f) Proof of right to use name (via third-party database checks and out-of-band verification)
(g) Proof of organisational status (such as proof of articles of incorporation, where applicable, or comparable proof)
(h) Proof of agent’s authority
(i) The “software publisher’s pledge” (for commercial software publisher certificate applicants only)
(j) Server serial number (for non-U.S. based Export Control Certificate applicants only)
Agents/Authorised Representative: See above
Method of Communicating Application: The completed application (and subscriber agreement) shall be submitted in electronic form.	
Source: VeriSign (1997) pp.36-37

Table 2: Required Certificate Application Information

To date, CAs have principally concerned themselves with issuing identity certificates. There is a need to develop procedures allowing CAs to issue certificates attesting to other attributes of a real-world entity (like age, sex, authority, privileges, etc.). The current paradigm for digital certificates is the X.509v3 standard (see appendix) which does not permit selective disclosure. This means that entities wishing to present digital credentials attesting to a particular attribute must reveal all other attributes contained in their digital certificate. Thus, digital certificates could provide unwelcome opportunities for data surveillance. Some solutions to the problem of attribute certification will be analysed in the final section, which follows the taxonomy of commercial CA certificates below.

6. Taxonomy
The following taxonomy of commercial CA certificates, with regard to their identity authentication procedures, is not comprehensive. Every effort has been taken to ensure the accuracy of the information presented. Many certification authorities have established web-sites advertising their products, but provide scant detail about their operating procedures. Where information was unavailable at the time of writing, the relevant entry has been marked ‘?’. Note that some CAs use extremely vague terms (e.g. ‘moderate ID authentication’) which are essentially meaningless. Ambiguity is also present in the use of the term ‘e-commerce’ which VeriSign seem to understand to mean high-risk inter-organisational transactions, while other CAs imply lower-risk individual transactions.

Company	Cert. Name	Ind./ Org.	Stated Purpose	Identity Authentication Procedures	
BelSign	Class 1	Ind.	Personal e-mail	Simple check of the non-ambiguity of the subject name within the BelSign repository, plus a limited verification of the e-mail address	
BelSign	Class 2	Ind.	E-Commerce	Identity information confirmed with 3rd party databases	
BelSign	Class 3	Org.	High Security	ID data is supplied on-line. 3 ID documents including the statutes of the organisation must be presented at a Chamber of Commerce for verification	
Thawte Consulting	FreeMail Cert.	Ind.	Personal e-mail	?	
Thawte Consulting	Basic Cert.	Ind.	E-Commerce	?	
Thawte Consulting	Premium Cert.	Ind.	Indisputable on-line identity equivalent to a passport	?	
SigNet	Personal Cert.	Ind.	Individual Authentication	Name, e-mail address	
SigNet	Server Cert.	Ind./ Org.	Server Authentication	Letter, server name, e-mail address	
SigNet	Developer Cert.	Ind./ Org.	Software Developer Authentication	Not yet available	
KeyWitness Canada	Class 1	Ind.	Personal e-mail	Low-level identity verification	
KeyWitness Canada	Class 2	Ind.	E-commerce	Moderate-level identity verification	
KeyWitness Canada	Class 3	Ind.	Application specific	Face-to-face or notarised verification	
KeyWitness Canada	Class 4	Org.	Application specific	High-level verification primarily for corporate servers	
Certificates Australia	Entry Level Cert.	Ind.	Personal e-mail	Applicant must provide name, address and telephone number. Details are not verified.	
Binary Surgeons	Personal Cert.	Ind.	Personal e-mail	?	
Binary Surgeons	Server Cert.	Org.	On-line server identification	Typed letter on company letterhead from company director verifying existence of company and applicant’s authority to act on behalf of the company. Letter detailing bank account details signed by whoever has authority to authorise direct debits	
IKS Germany	?	?	?	Require personal contact and presentation of passport	
ICE-TEL	?	Ind./ Org.	?	Evaluation of an authorised ID card	
Computer Security Technologies	Low-level assurance	Ind.	Personal e-mail	Specific procedures depend on org. acting as CA. Unverified check of standard documents (letterhead, business cards, etc.)	
Computer Security Technologies	Medium-level assurance	Ind.	Professional business documents generally not of a financial nature	Official registration documents: ID card; driving license; passport; etc.	
Computer Security Technologies	High-level assurance	Org.	Electronic commerce and financial transactions	Authorisation documents from a higher organisational authority. CAs verified using the official registration documents of the company.	
UNINETT	?	Ind.	?	Identity authentication is performed by Registration Authority based on one or more of the following paper credentials: driver’s license; passport; Norwegian bank card	
United States Postal Service	Self-authenticated Personal Cert.	Ind.	?	Check of uniqueness of name. No verification of applicant’s right to use name	
United States Postal Service	Basic Cert.	Ind.	?	Review of suitable paper credentials	
United States Postal Service	Biometrically authenticated personal Cert.	Ind.	?	Review of suitable paper credentials. Biometric measurements of applicant are used in the initialisation of trusted signing device	
United States Postal Service	Organisational Cert.	Org.	?	Fixed policy associated with creation and handling of all organisational certificates	
VeriSign, Inc.	Class 1 Digital ID	Ind.	Web browsing and personal e-mail; continuity of communications	Simple check of the non-ambiguity of the subject name within the VeriSign repository, plus a limited verification of the e-mail address	
VeriSign, Inc.	Class 2 Digital ID	Ind.	Intra/inter-organisational E-mail; small, “low-risk” transactions; personal/individual E-mail; password replacement; software validation; on-line subscription services	As Class 1 plus third party consumer database cross-reference; postal address confirmation	
VeriSign, Inc.	Class 3 Digital ID	Ind.	Provide important assurances of the identity of individual subscribers; LRA administrator authentication	As Class 2 plus personal presence before LRA or delegate (e.g. notary) with documentary identification	
VeriSign, Inc.	Class 4 Digital ID	Org.	Electronic commerce applications such as electronic banking, electronic data interchange (EDI), and membership-based on-line services; support software validation	As Class 2 plus review of authorisation records provided by the applicant or third-party business databases, and independent call-backs to the organisation	
KeyPOST	Personal Cert.	Ind.	On-line identification of individuals	Personal presence at KeyPOST nominated Australia Post outlet with photographic ID documents, application form, and fee	
KeyPOST	Organisational Cert.	Org.	On-line identification of organisations	Personal presence at KeyPOST nominated Australia Post outlet with photographic ID documents,  organisation ID documents,  letter of authorisation, application form, and fee	
UPTIME Commerce	Server Cert.	Org.	On-line server identification	Organisation details verified with 3rd party database (Dun & Bradstreet)	
South African CA	See VeriSign	
	See VeriSign	See VeriSign	

Table 3: A Taxonomy of Commercially-Available Digital Certificates with regard to their Identity Authentication Procedures

7. Authority Authentication
The notion of authority authentication is becoming increasingly important for practitioners and researchers in the field of digital certification. While the fundamental purpose of public-key certificates is to bind a public-key to some entity by means of unique identifiers included in the certificate, certificate verifiers may require other information before the signature can be trusted. For example, does the certificate holder have authority to:

•	Spend money;
•	Complete official documentation; or,
•	Accept an offer of contract?

Authority authentication ‘represents an important area of electronic commerce technology which is yet to be fully explored or developed,’ and as such will be briefly dwelt upon in this paper.

7.1 ‘Appropriate Authorities’
The X.509v3 standard for digital certificates certifying public-keys could be used to concurrently certify authorisation information. However, it is to be expected that the authority most suitable for issuing public-key digital certificates (namely, the commercial CAs currently in existence) will not be the authority most suitable for issuing certificates of authority. Therefore, identifying appropriate authorities is an important first step in this process. Another problem with tying authority information to public-key certificates is apparent when one considers that the time-period validity of public-key certificates may not match with the required time-period validity of an authority certificate.

7.2 Attribute Certificates
Attribute certificates have been developed by the US financial industry’s ANSI X9 committee in response to these problems with public-key certificates. Anyone can define and register attribute types and an attribute authority digitally signs certificates. This standard also permits attaching attributes to documents, which can then be transmitted along with the signature. If the attributes of the document require a level of authority not attested to by the attributes of the signature, the verifier can deduce a lack of proper authorisation.

7.3 Role Registers
Finally, another possible solution to the problems encountered when linking identity authentication with authority authentication is the concept of a role register. Role registers provide a means of mapping identities to authorities or privileges. Keeping the identity authentication process separate from the record of associated privileges enhances both flexibility and security.

8 Conclusion
Securely authenticating the identities and privileges of cyberspace entities is essential if the widely predicted explosion in the growth of e-commerce is to become a reality. Digital certificates issued and managed by certification authorities potentially provide a scaleable, flexible, and, above all, secure system by which to implement identity authentication procedures. It is critically important to realise that private-key protection and rigorous, real-world identity authentication procedures are the bedrock of this system. Therefore, information systems security practitioners need to be clear about what attributes of an entity they are concerned with authenticating. They need to be clear about what a particular digital certificate is actually attesting to, and, most importantly, they need to satisfy themselves that the certification authority procedures are adequate for the level of assurance they desire.

Information detailing the procedures employed by individual CAs to authenticate entity attributes (in the form of Certification Practice Statements) is notable by its absence from many CA web-sites. This indicates the embryonic state of the technology and, perhaps, the difficulties that have to be surmounted to define workable, secure solutions. Garfinkel & Spafford (1997) are right to burst the bubble by stating: 

‘The people who are actually setting up [public key infrastructure] systems ... don’t want a system that is perfect, just one that is better than today’s paper-based identification systems. Unfortunately, it’s not clear whether public-key technology even gives that kind of assurance about identity.’

Only if these techniques and procedures are implemented on a wide-scale will their practicability and reliability be tested. The same qualification holds true for more recently developed attribute certificates, which rely on the same technological principles.

Biometric identity authentication systems combined with rigorous operating procedures have the potential to provide maximally secure identity authentication for electronic transactions. They are unlikely to be widely implemented for reasons of cost, data storage, processing time, and ergonomics. There are also serious ethical issues associated with biometric identification systems.

Appendix

X.509 Version 3 Digital Certificate

Sources
BOOKS, JOURNAL ARTICLES & INTERNET WHITE PAPERS
Anderson R & Kuhn M (1996) Tamper Resistance – a Cautionary Note The Second USENIX Workshop on Electronic Commerce Proceedings, Oakland, California, November 18-21, 1996, pp 1-11 <www.cl.cam.ac.uk/~mgk25/tamper.html>

Chokhani S & Ford W (1996) Certificate Policy and Certification Practice Statement Framework (Draft) NIST, <http://csrc.ncsl.nist.gov/pki/docs/fmk03nov.doc>

Computer Security Technologies (1996) Certification Policies in the COST Certification Infrastructure Sweden <www.cost.se/cost_pol.htm> 

Electronic Commerce Promotion Council of Japan (ECOM) (1997) Certification Authority Guidelines (Alpha version) <www.ecom.or.jp/eng/output/ca/eng-guideline.htm>

Ellison C (1996) Establishing Identity Without Certification Policies <www.clark.net/pub/cme/usenix.html>
 
Ford W & Chokhani S (1997) Internet Public Key Infrastructure Part IV: Certificate Policy and Certification Practices Framework Internet Engineering Task Force, <ftp://ietf.org/internet-drafts/draft-ietf-pkix-ipki-part4-02.txt> [no longer available]

Ford W & Leech M (1996) Public Key Infrastructure Certificate Policy and Certification Practice Statement Framework Version 1.2b Policy Management Authority Committee of the Government of Canada Public Key Infrastructure

Ford W & Baum M S (1997) Secure Electronic Commerce: Building the infrastructure for digital signatures and encryption (Prentice Hall, Inc., New Jersey)

Garfinkel S & Spafford G (1996) Practical Unix and Internet Security, Second Edition (O’Reilly & Associates, Inc., Cambridge, USA)

Garfinkel S & Spafford G (1997) Web Security & Commerce (O’Reilly & Associates, Inc., Cambridge, USA)

Grant G L (1998) Understanding Digital Signatures: Establishing trust over the Internet and other networks (McGraw-Hill, Inc., New York)

Greenleaf G & Clarke R (1997) Privacy Implications of Digital Signatures Invited Address, IBC Conference on Digital Signatures, Sydney, 12 March 1997, <http://www.anu.edu.au/people/Roger.Clarke/DV/DigSig.html>

KeyPOST (1997) Certification Practice Statement v.1.1, Australian Postal Corporation, <www.auspost.com.au/keypost>

Kim H J (1995) Biometrics – Is it a viable proposition for identity authentication and access-control Computers & Security, Vol. 14, No. 3, pp.205-214

VeriSign (1997) VeriSign Certification Practice Statement version 1.2 VeriSign, Inc., California, <www.verisign.com/repository/CPS1.2/intro.html>

COMMERCIAL CERTIFICATION AUTHORITY WEB-SITES
Baltimore Technologies, Eire www.baltimore.ie
BelSign, Belgium www.belsign.com
Binary Surgeons, South Africa www.surgeons.co.za
Certificates Australia, Australia www.secdom.com.au
CompuSource, South Africa www.compusource.co.za
Computer Security Technologies, Sweden www.cost.se
Cybertrust GTE, USA www.cybertrust.com
EuroSign, UK www.eurosign.com
IKS, Germany www.iks-jena.de/produkte/ca/index.en.html
ICE-TEL, Denmark www.darmstadt.gmd.de/ice-tel/
KeyPOST, Australia www.auspost.com.au/keypost
KeyWitness, Canada www.keywitness.ca
SigNet, Australia www.signet.org.au
South African Certification Authority www.saca.net
Thawte, South Africa www.thawte.com
Trade Authority, USA www.tradewave.com/products/tradeauthority.html
UPTIME Commerce, USA www.uptimecommerce.com
VeriSign, USA www.verisign.com
World Wide Wedlin CA www.wedlin.pp.se