E-Commerce

By Mr. Neil Gogte

E-Commerce Fundamentals

1.1 B2C Fundamentals

1.2 B2B and its Advantages

2.1 Concents in Secure Electronic Transactions (SET)

2.2 Introductory Guide to PKI

2.3 Salient Points of the Information Technology Bill

3.1 Role of ISP

3.2 ISDN Services

3.3 Future Evolution - Wireless Application Protocol




"E-commerce services are the silver bullet that will
enable companies to take advantage of the true business
opportunities on the Web."

                                                                             Traci Gere, Analyst, The New York Times.

Electronic Commerce is one of the most important aspects of the internet to emerge. It allows people to exchange goods and services immediately and with no barriers of time or distance. Any time of the day or night, you can go online and buy almost anything you want.

The two main forms of e-Commerce are B2B or Business-to-Business and B2C or Business to Commerce. A typical example of B2C would be the various online shopping sites like Amazon.com, and a typical example of B2B would be the online Supply Chain Management wherein a purchase order of one company enters the system of the other company as a sales order.

Back to Index

1.1 B2C Fundamentals

Actually doing business on the web can be broken down into six main requirements.

  • On-Line Store

    The obvious requirement is an on-line store, or commerce-enabled web site where goods or services can be described and selected.

  • On-Line payments

    While it is possible to run an on-line store without accepting on-line payments, this is cumbersome and rarely successful. Accepting on-line payments is therefore essential and at the moment this means credit or debit cards.

  • Security

    For e-Commerce users to send data or payment particulars over the internet, the issue of security has to be addressed and the confidentiality, authenticity, integrity and non- repudiation of data ensured.

  • Shipping/Order Fulfillment

    OK, so you've made your sale and now you've got to deliver the goods. Just package them up and ship them off. Easy except what happens if you get dozens or hundreds of orders a day?

  • Customer Service

    Support, Complaints, Returns -the biggest complaint about E-Commerce is the poor level of customer service in the event of problems.

  • Promotion.

    The big one! Even if you do everything else right, without successful promotion your online business will fail.

    There is no right or wrong way to start up an E-Business, but any business plan, even if drawn up on the back of an envelope, should address these six topics.

    The commerce server provider takes care of all the hosting and software configuration and for a monthly fee the user gets a package which includes hosting the site, an integrated store and shopping cart, and usually optional services to take care of payment. There are very often other services thrown-in such as marketing facilities or an email account. ,

    When setting up a business on-line, building the Web-store is the easy bit. It's the financial side that causes the most problems.

    The simplest option is just to avoid on-line payments completely. Customers can place orders either by mailing an order form and a check to the merchant in time-honored fashion, or by phone. If you want to get sophisticated you can include a blank order form on-line, which the customer can print out. This option has the advantage of simplicity, but except for one-offor high value transactions (if you're selling a yacht for example) then it is completely ineffective. The Net is about speed and efficiency (not to mention instant gratification). If customers can't order it NOW then they will go elsewhere. That's why you need to accept credit cards.

  • Credit Cards: Merchant Account

    Before you can accept credit cards (either online or offline), you generally need a Merchant Account, which is a special type of bank account that supports credit card transactions. Small and home businesses often have difficulties qualifying for a Merchant Account. It can be even more difficult for Web-based businesses. Most banks have stringent requirements that a business must meet in order to be eligible for a Merchant Account. These requirements often cover credit history, cash reserves and length of time in business, none ofwhich are likely to be strong points of a business startup.

    Although the conventional banks are still very choosey about who they will give Merchant Accounts to, a whole host of "alternative" payment processing companies has sprang up in recent months and they will give a merchant account to practically anyone for a price. The greater the perceived risk to the payment-processor, the higher the price in setup fees, charges and reserve fees. Reserve fees are a proportion of the sales that are retained by the payment processing company for a set period of time to cover themselves in case of charge backs. (Charge backs are when a contested charge on a credit card has to be refunded to the customer.).

    Most web-based businesses that expect to have a high volume of sales will probably opt for some sort of Merchant Account arrangement, whether with a bank or one of the alternative companies. The charging structure can vary wildly so it is worth shopping around and if you are turned down by some institutions don't be discouraged there will almost certainly be someone willing to take you on and even if there isn't there is still another option available for accepting credit cards.

  • Credit Cards: Non-Merchant Account

    Recently a new breed of Internet payment companies has appeared that takes a lot of the pain out of accepting credit cards on-line. Basically these companies act as middlemen and carry out all the hard work, from processing the transaction on-line to collecting the payment into their own accounts.

    Periodically (usually monthly) the merchant will receive a check minus charges of course Inevitably it costs more to have a third party handling payments than doing it yourself, but for a small or home-based business the convenience and ease of set-up may well make it worthwhile. These services are also ideal for selling intangibles like shareware licenses or newsletter subscriptions.

    If you want to succeed in selling on-line, then you have to accept credit cards. Alternative payment methods will no doubt appear at some point in the future, but until then there is no real choice. However, credit card processing is quite a complicated operation. Put simply, it requires a payment gateway or Payment Processing Company (for example Cardservice International) to arrange for funds to be transferred from the customer's credit card account into a special type of bank account called a Merchant Account.

    That's all very well, but for many small or home-based businesses the Merchant Account presents a problem. Many banks are particular about whom they will allow to hold a Merchant Account, and it can often take some time to set up. There are often numerous restrictions and rules that are areal pain for a small home-based business with only a few items to sell and a low turnover.

    If you have a less than perfect credit history there might also be problems. There are however other options which allow small businesses to accept credit cards without requiring a Merchant Account. These services are fairly new and still quite expensive, although they do provide any easy way for anew web-business to start trading. In fact the whole Merchant Account system is likely to get a severe shaking-up when these Internet Payment Companies really take off in a big way. With thousands of very small businesses springing up on the Net daily, it makes much more sense for them to farm out the whole credit card and payment side of the business to specialized companies than for each one to have its own individual Merchant Account. These specialized companies work in much the same way. The customer places the order with the merchant, but it's the Internet Payment Company that processes the credit card transaction and collects the payment. Periodically checks are sent to the merchant (minus charges and commission of course). Most such companies offer additional services such as shopping cart software or shipping tracking services.

    Charges vary from between 6% to 15% of sales. All the companies hold back a proportion of sales (typically 10%) for up to 6 months to protect against charge back (funds haying to be returned to the customer for some reason). This is pretty standard for credit card operations.

    Back to Index

  • 1.2 B2B and its Advantages

    B2B extends automated e-commerce links to more trading partners than any other solution. It supports open standards, allowing companies to sidestep one of the most challenging barriers to business community integration: the politics of deploying proprietary technologies throughout partner organizations

    B2B integrates with, leverages and extends existing business processes and applications (including Ern, ERP , databases, e-commerce and other operational systems) beyond corporate boundaries. B2B enables tighter integration and greater efficiencies within business communities.

  • THE B2B LANDSCAPE

    Over the years various technologies have emerged for coordinating how information flows within companies and across organizational boundarie~. Traditionally, these technologies have been associated with specific types of business or business-unit relationships.

    Most companies, however, do not have the luxury of establishing only one type of business relationship. It is a given that supply chains will overlap. But as businesses increasingly invest in B2B technologies, Information Systems (IS) departments face being overloaded with multiple proprietary solutions, not to mention potential overhead that could ultimately impede business opportunities.

    Early B2B technologies have provided valuable lessons for next-generation B2B infrastructures. For example, Ern supports only limited transaction sets, and the process of integrating any conventions and extensions that depart from standard document structures has proven cumbersome and expensive.

    In an effort to mitigate these limitations, next-generation B2B infrastructures must be able to realize more fine-grained interactions and exchanges, with richer and more flexible data structures. The majority of these interactions are, and will continue to be, document-based. Since various partner applications do not need to reference one another directly, documents need to be created and sent, received and processed, in batch or near real-time.

    Other interactions (e.g. middleware technologies) require a service-based approach to integration. These real-time interactions allow tighter links between partner applications and processes. Distributed resources will need to interact with each other as peers. ASAP Financials application, for instance, should be able to "see" a Baan Manufacturing application as a native SAP resource, even when the two applications are separated by corporate firewalls.

    Each approach involves varying degrees of process coordination between partners' information systems. The fact that, to date, there has been no single B2B solution offering both document and service-Ievel exchange has complicated things further.

    Business Community Integration is generally defined as the automated exchange of information occurring independent of or alongside manual, human-based processes. It uses the open protocols of the Internet to allow an enterprise to exchange or share information across corporate \ boundaries or "firewalls" with it's network of customers, suppliers, and business partners by enabling companies to exchange documents with and offer real-time services to their top trading partners.

    When a business community is fully integrated, an organization's enterprise applications such as enterprise resource planning (ERP), customer relationship management (CRM) and legacy applications can interact seamlessly and securely with those of their external business partners - without cumbersome manual processes or significant changes to the organization's technology infrastructure.

    As a result of Business Community Integration, orders can be entered more rapidly and with fewer errors, products can be shipped sooner, compliance can be monitored in real time, and customer queries (such as price quotes and product availability) can be addressed more efficiently.

  • Technologies used in BlB

  • 1. Electronic Data Interchange (EDI): As Business Process 1 and Business process 2 may use different softwares there should be an another software for translating the data into a common language. This is achieved through Ern. But usage of Ern is very low because of cost factor.

  • 2. XML: XML is a markup language for documents containing structured information. Structured information contains both content (words, pictures, etc.) and some indication of what role that content plays. Almost all documents have some structure. A markup language is a mechanism to identify structures in a document. The XML specification defines a standard way to add markup to documents.

  • 3. JMQ: Java Message Queue technology enables the applications running at different run- times to communicate across heterogeneous networks and systems that may be temporarily offline. Applications send messages to queues and read messages from queues. Basically, this JMQ system is almost like E-mail system for applications. The JMQ system also maintains the message queue when one or more of the messages or systems involved in the message delivery, which are down or unreachable or temporarily unavailable and so on due to network problems. Message queuing systems provide guaranteed message delivery from the sending application to the receiving application by maintaining the message queue on the disk drive of every computer involved in the message delivery. When we send a message, it will first written to the queue on the disk of the sending computer. The message then sent to the queue on the disk queue on the second computer. After the message sent successfully to the disk queue on the second computer, the message in the disk queue on the first computer gets removed. In the r~ceiving computer, the message is maintained in the queue on the disk until it retrieves by any user or receiver.

  • 4. Orbix Server: It is a CORBA based server enables interaction between softwares running on different platforms. It supports IIOP protocol.

    Back to Index

  • 2.1 Concents in Secure Electronic Transactions (SET)

  • Role of payment systems

    Payment systems and their financial institutions will play a significant role by establishing open specifications for payment card transactions that:

    .provide for confidential transmission

    .authenticate the parties involved

  • ensure the integrity of payment instructions for goods and services order data

    .authenticate the identity of the cardholder and the merchant to each other.

  • Purpose of Secure Electronic Transaction

    To meet these needs, the SET Secure Electronic Transaction protocol uses cryptography to:

    .provide confidentiality of information

    .ensure payment integrity

  • authenticate both merchants and cardholders.

    This specification will enable greater payment card acceptance, with a level of security that will encourage consumers and businesses to make wide usage of payment card products in this emerging market.

  • Seven business requirements

    SET addresses seven major business requirements:

  • Provide confidentiality of payment information and enable confidentiality of order information that is transmitted along with the payment information.

  • Ensure the integrity of all transmitted data.

  • Provide authentication that a cardholder is a legitimate user of a branded payment card account.

  • Provide authentication that a merchant can accept branded payment card transactions through its relationship with an acquiring financial institution.

  • Ensure the use of the best security practices and system design techniques to protect all legitimate parties in an electronic commerce transaction.

  • Create a protocol that neither depends on transport security mechanisms nor prevents their use.

  • Facilitate and encourage interoperability among software and network providers.

  • Scope of SET

    Electronic shopping experience

    The electronic shopping experience can be divided into several distinct stages.

  • The cardholder browses for items in a variety of ways, such as using a browser to view an online catalog on the merchant's World Wide Web page, viewing a catalog supplied by the merchant on a CD-ROM, or looking at a paper catalog. 1. The cardholder selects items to be purchased.

  • The cardholder is presented with an order form containing the list of items, their prices, and a total price including shipping, handling, and taxes. This order form may be delivered electronically from the merchant's server or created .on the cardholder's computer by electronic shopping software. Some online merchants may also support the ability for a cardholder to negotiate for the price of items (such as by presenting frequent shopper identification or information about a competitor's pricing).

  • The cardholder selects the means of payment. This specification focuses on the case when a payment card is selected.

  • The cardholder sends the merchant a completed order along with payment instructions. In this specification, the order and the payment instructions are digitally signed by cardholders who possess certificates.

  • The merchant requests payment authorization from the cardholder's financial institution. .The merchant sends confirmation of the order .

  • The merchant ships the goods or performs the requested services from the order. .The merchant requests payment from the cardholder's financial institution.

  • Payment System Participants

  • Interaction of participants SET changes the way that participants in a payment system interact. In a face-to-face retail transaction or a mail order transaction, electronic processing begins with the merchant or the Acquirer. However, in a SET transaction, the electronic processing begins with the cardholder.

  • Cardholder In the electronic commerce environment, consumers and corporate purchasers interact with merchants from personal computers. A cardholder uses a payment card that has been issued by an Issuer. SET ensures that in the cardholder's interactions with the merchant, the payment card account information remains confidential.

  • Issuer An Issuer is a financial institution that establishes an account for a cardholder and issues the payment card. The Issuer guarantees payment for authorized transactions using the payment ..card in accordance with payment card brand regulations and local legislation.

  • Merchant A merchant offers goods for sale or provides services in exchange for payment. With SET, the merchant can offer its cardholders secure electronic interactions. A merchant that accepts payment cards must have a relationship with an Acquirer.

  • Acquirer An Acquirer is the financial institution that establishes an account with a merchant and processes payment card authorizations and payments.

  • Payment gateway A payment gateway is a device operated by an Acquirer or a designated third party that processes merchant payment messages, including payment instructions from cardholders.

  • Brand Financial institutions have founded payment card brands that protect and advertise the brand, establish and enforce rules for use and acceptance of their payment cards, and provide networks to interconnect the financial institutions. Other brands are owned by financial services companies that advertise the brand, and establish and enforce rules for use and acceptance of their payment cards. These brands combine the roles of Issuer and Acquirer in interactions with cardholders and merchants.

  • Third parties Issuers and Acquirers sometimes choose to assign the processing of payment card transactions to third-party processors. This document does not distinguish between the financial institution and the processor of the transactions.

  • Cryptography

  • Protection of sensitive information

    Cryptography has been used for centuries to protect sensitive information as it is transmitted from one location to another. In a cryptographic system, a message is encrypted using a key. The resulting ciphertext is then transmitted to the recipient where it is decrypted using a key to produce the original message. There are two primary encryption methods in use today: secret-key cryptography and public-key cryptography. SET uses both methods in its encryption process.

  • Secret-key cryptography Secret-key cryptography, also known as symmetric cryptography, uses the same key to encrypt and decrypt the message. Therefore, the sender and the recipient of a message must share a secret, namely the key. A well known secret-key cryptography algorithm is the Data Encryption Standard (DES), which is used by financial institutions to encrypt PINs (personal identification numbers).

  • Public-key cryptography Public-key cryptography, also known as asymmetric Cf)'ptography, uses two keys: one key to encrypt the message and the other key to decrypt the message. The two keys are mathematically related so that data encrypted with either key can only be decrypted using the other. Each user has two keys: a public key and a private key. The user distributes the public key. Because of the relationship between the two keys, the user and anyone receiving the public key can be assured that data encrypted with the public key and sent to the user can only be decrypted when the user uses the private key. This assurance is only maintained if the user en~.ures that the private key is not disclosed to anyone else. Therefore, the key pair should be generated by the user. The best known public-key cryptography algorithm is RSA (named after its inventors Rivest, Shamir, and Adleman).

    Secret-key cryptography is impractical for exchanging messages with a large group of previously unknown correspondents over a public network. For a merchant to conduct transactions securely with millions of Internet subscribers, each consumer would need a distinct key assigned by that merchant and transmitted over a separate secure channel. On the other hand, by using public-key cryptography, that same merchant could create a public/private key pair and publish the public key, allowing any consumer to send a secure message to that merchant.

  • Encryption Confidentiality is ensured by the use of message encryption.

  • Relationship of keys When two users want to exchange messages securely, each of them transmits one component of their key pair, designated the public key, to the other and keeps secret the other component, designated the private key. Because messages encrypted with the public key can only be decrypted using the private key, these messages can be transmitted over an insecure network without fear that an eavesdropper could use the key to read encrypted transmissions. For example, Bob can transmit a confidential message to Alice by encrypting the message using Alice's public key. As long as Alice ensures that no one else has access to her private key, both she and Bob will know that only Alice can read the message.

  • Use of symmetric key SET will rely on cryptography to ensure message confidentiality. In SET, message data will be encrypted using a randomly generated symmetric encryption key. This key, in turn, will be encrypted using the message recipient's public key. This is referred to as the "digital envelope" of the message and is sent to the recipient along with the encrypted message itself.

    After receiving the digital envelope, the recipient decrypts it using his or her private key to obtain the randomly generated symmetric key and then uses the symmetric key to unlock the original message.

  • Digital signatures

    Integrity and authentication are ensured by the use of digital signatures.

  • Relationship of keys Because of the mathematical relationship between the public and private keys, data encrypted with either key can only be decrypted with the other. This allows the sender of a message to encrypt it using the sender's private key. Any recipient can determine that the message came from the sender by decrypting the message using the sender's public key. For example, Alice can encrypt a known piece of data, such as her telephone number, with her private key and transmit it to Bob. When Bob decrypts the message using Alice's public key and compares the result to the known data, he can be sure that that the message could only have been encrypted using Alice's private key.

  • Using message digests

    When combined with message digests, encryption using the private key allows users to digitally sign messages. A message digest is a value generated for a message (or document) that is unique to that message.l A message digest is generated by passing the message through a one-way cryptographic function; that is, one that cannot be reversed. When the digest of a message is encrypted using the sender's private key and is appended to the original message, the result is known as the digital signature of the message. The recipient of the digital signature can be sure that the message really came from the sender. And, because changing even one character in the message changes the message digest in an unpredictable way, the recipient can be sure that the message was not changed after the message digest was generated. The algorithm used by SET generates 160-bit message digests. The algorithm is such that 'changing a single bit in the message will change, on average, half of the bits in the message digest. Roughly, the odds of two messages having the same message digest are one in 1 ,000 ,000 ,000 ,000, 000,000 ,000 ,000 ,000 ,000 ,000, 000,000 ,000 ,000, 000. It is computationally unfeasible to generate two different messages that have the same message digest.

  • Example of the use ofa digital signature

    For example, Alice computes the message digest of a property description and encrypts it with her private key yielding a digital signature for the message. She transmits both the message and the digital signature to Bob. When Bob receives the message, he computes the message digest of the property description and decrypts the digital signature with Alice's public key. If the two values match, Bob knows that the message was signed using Alice's private key and that it has not changed since it was signed.

  • Two key pairs SET uses a distinct public/private key pair to create the digital signature. Thus, each SET participant will possess two asymmetric key pairs: a "key exchange" pair, which is used in the process of encryption and decryption, and a "signature" pair for the creation and verification of digital signatures. Note that the roles of the public and private keys are reversed in the digital signature process where the private key is used to encrypt (sign) and the public key is used to decrypt (verify the signature).

  • Certificates Authentication is further strengthened by the use of certificates.

  • Need for authentication Before two parties use public-key cryptography to conduct business, each wants to be sure that the other party is authenticated. Before Bob accepts a message with Alice's digital signature, he wants to be sure that the public key belongs to Alice and not to someone masquerading as Alice on an open network. One way to be sure that the public key belongs to Alice is to receive it over a secure channel directly from Alice. However, in most circumstances this solution is not practical.

  • Need for a trusted third party An alternative to secure transmission of the key is to use a trusted third party to authenticate that the public key belongs to Alice. Such a party is known as a Certificate Authority (CA). The Certificate Authority authenticates Alice's claims according to its published policies. For example, a Certificate Authority could supply certificates that offer a high assurance of personal identity, which may be required for conducting business transactions; this Certificate Authority may require Alice to present a driver's license or passport to a notary public before it will issue a certificate. Once Alice has provided proof of her identity, the Certificate Authority creates a message containing Alice's name and her public key. This message, known as a certificate, is digitally signed by the Certificate Authority. It contains owner identification information, as well as a copy of one of the owner's public keys ("key exchange" or "signature"). To get the most benefit, the public key of the Certificate Authority should be known to as many people as possible. Thus, by trusting a single key, an entire hierarchy can be established in which one can have a high degree of trust. Because SET participants have two key pairs, they also have two certificates. Both certificates are created and signed at the same time by the Certificate Authority.

  • SET authentication The means that a financial institution uses to authenticate a cardholder or merchant is not defined by this specification. Each payment card brand and financial institution will select an appropriate method.

    Encryption summary This diagram provides an overview of the entire encryption process when Alice wishes to sign, for example, a property description and send it in an encrypted message to Bob. The numbered steps in the diagram are explained on the following pages.

    Encryption: The encryption process in the Figure consists of the following steps:

    1. Alice runs the property description through a one-way algorithm to produce a unique value known as the message digest. This is a kind of digital fingerprint of the property description and will be used later to test the integrity of the message.

    2. She then encrypts the message digest with her private signature key to produce the digital signature.

    3. Next, she generates a random symmetric key and uses it to encrypt the property description, her signature and a copy of her certificate, which contains her public signature key. To decrypt the property description, Bob will require a secure copy of this random symmetric key.

    4. Bob's certificate, which Alice must have obtained prior to initiating secure communication with him, contains a copy of his public key-exchange key. To ensure secure transmission of the symmetric key, Alice encrypts it using Bob's public key-exchange key. The encrypted key, referred to as the digital envelope, will be sent to Bob along with the encrypted message itself.

    5. Alice sends a message to Bob consisting of the following: the symmetrically encrypted property description, signature and certificate, as well as the asymmetrically encrypted symmetric key (the digital envelope).

    Decryption Likewise, the decryption process consists of the following steps:

    6. Bob receives the message from Alice and decrypts the digital envelope with his private key- exchange key to retrieve the symmetric key.

    7. He uses the symmetric key to decrypt the property description, Alice's signature, and her certificate.

    8. He decrypts Alice's digital signature with her public signature key, which he acquires from her certificate. This recovers the original message digest of the property description.

    9. He runs the property description through the same one-way algorithm used by Alice and produces anew message digest of the decrypted property description.

    10. Finally, he compares his message digest to the one obtained from Alice's digital signature. If they are exactly the same, he confirms that the message content has not been altered during transmission and that it was signed using Alice's private signature key. If they are not the same, then the message either originated somewhere else or was altered after it was signed. In that case, Bob takes some appropriate action such as notifying Alice or discarding the message.

    Certificate Issuance

    Cardholder certificates Cardholder certificates function as an electronic representation of the payment card. Because they are digitally signed by a financial institution, they cannot be altered by a third party and and can only be generated by a financial institution. A cardholder certificate does not contain the account number and expiration date. Instead the account infof1l1ation and a secret value known only to the cardholder's software are encoded using a one-way hashing algorithm. If the account number, expiration date, and the secret value are known, the link to the certificate can be proven, but the information cannot be derived by looking at the certificate. Within the SET protocol, the cardholder supplies the account information and the secret value to the payment gateway where the link is verified. A certificate is only issued to the cardholder when the cardholder's issuing financial institution approves it. By requesting a certificate, a cardholder has indicated the intent to perform commerce via electronic means. This certificate is transmitted to merchants with purchase requests and encrypted payment instructions. Upon receipt of the cardholder's certificate, a merchant can be assured, at a minimum, that the account number has been validated by the card-issuing financial institution or its agent. In this specification, cardholder certificates are optional at the payment card brand's discretion.

    Merchant certificates Merchant certificates function as an electronic substitute for the payment brand decal that appears in the store window-the decal itself is a representation that the merchant has a relationship with a financial institution allowing it to accept the payment card brand. Because they are digitally signed by the merchant's financial institution, merchant certificates cannot be altered by a third party and can only be generated by a financial institution. These certificates are approved by the acquiring financial institution and provide assurance that the merchant holds a valid agreement with an Acquirer. A merchant must have at least one pair of certificates to participate in the SET environment, but there may be multiple certificate pairs per merchant. A merchant will have a pair of certificates for each payment card brand that it accepts.

    Payment gateway certificates

    Payment gateway certificates are obtained by Acquirers or their processors for the systems that process authorization and capture messages. The gateway's encryption key, which the cardholder gets from this certificate, is used to protect the cardholder's account information. Payment gateway certificates are issued to the Acquirer by the payment brand.

    Acquirer certificates An Acquirer must have certificates in order to operate a Certificate Authority that can accept and process certificate requests directly from merchants over public and private networks. Those Acquirers that choose to have the payment card brand process certificate requests on their behalf will not require certificates because they are not processing SET messages. Acquirers receive their certificates from the payment card brand.

    Issuer certificates An Issuer must have certificates in order to operate a Certificate Authority that can accept and process certificate requests directly from cardholders over public and private networks. Those Issuers that choose to have the payment card brand process certificate requests on their behalf will not require certificates because they are not processing SET messages. Issuers receive their certificates from the payment card brand. -

    Back to Index

    2.2 Introductory Guide to PKI

    Public Key Infrastructure (PKI) provides the core framework for a wide variety of components, applications, policies and practices to combine and achieve the four principal security functions for commercial transactions:

  • Confidentiality -to keep information private

  • Integrity -to prove that information has not been manipulated

  • Authentication -to prove the identity of an individual or application .Non-repudiation -to ensure that information cannot be disowned

    The Components of a PKI

    A Public Key Infrastructure is a combination of hardware and software products, policies and procedures. It provides the basic security required to carry out electronic business so that users, who do not know each other, or are widely distributed, can communicate securely through a chain of trust. PKI is based on digital IDs known as "digital certificates" which act like "electronic passports", and bind the user's digital signature to his or her public key.

    A PKI should consist of:

    Security Policy

    A security policy sets out and defines an organization's top-level direction on information security, as well as the processes and principles for the use of cryptography. Typically it will include statements on how the organization will handle keys and valuable inforn1ation, and will set the level of control required to match the levels of risk.

    Certificate Practice Statement (CPS) Some PKI systems are Commercial CAs, and therefore require a CPS. This is a detailed document containing the operational procedures on how the Security Policy will be enforced and supported in practice. It typically includes definitions on how the CAs are constructed and operated, how certificates are issued, accepted and revoked, and how keys will be generated, registered and certified, where they will be stored, and how they will be made available to users.

    Certificate Authority

    The CA system is the trust basis of a PKI, as it manages public key certificates for their whole life cycle. The CA will:

  • Issue certificates by binding the identity of a user or system to a public key with a digital signature

  • Schedule expiry dates for certificates

  • Ensure certificates are revoked when necessary by publishing Certificate Revocation Lists (CRLs)

    When implementing a PKI, an organization can either operate its own CA system, or use the CA service of a Trusted Third Party.

    Registration Authority

    An RA provides the interface between the user and the CA. It captures and authenticates the identity of the users and submits the certificate request to the CA. The quality of this authentication process determines the level of trust that can be placed in the certificates.

    Certificate Distribution System

    Certificates can be distributed in a number of ways depending on the structure of the PKI environment, for example, by the users themselves, or through a directory service. A directory server may already exist within an organization or one may be supplied as part of the PKI solution.

    The UniCERT Modules

    Certificate Authority (CA): Signs and publishes certificates and certificate revocation lists.

    Certificate Authority Operator (CAO): The CAO is the PKI securityofficer.

    Registration Authority (RA): Routes information, certificates and certificate requests through the hierarchy.

    Registration Authority Operator: Approves and rejects remote and face-to-face certificate requests.

    Archive Server: This optional module enables end user encryption keys to be archived if required.

    Email Gateway: Receives certificate requests by email.

    VPN Gateway: Receives remote certificate requests for VPN systems. Web Gateway: Receives remote requests from web browsers.

    WebRAO: Approves and rejects certificate requests over the Internet.

    WebRAO Server: Act as a conduit of information between an RA and all the WebRAOs in its domain.

    Token Manager: Manages cryptographic hardware functions.

    UniCERT Certificate Authority

    The Certificate Authority (CA) module is the nucleus of a PKI. All trust within the infrastructure depends upon the CA's signature. The CA operates according to its own flexible policy, which is controlled by the Certificate Authority Operator (CAO).

    Responsibilities

  • The CA receives approved certificate and revocation requests from Registration Authorities (RAs) and CAOs, and returns certificates and confirmational messages.

  • If selected in the policy, the CA sends end users' private encryption keys that are marked to be archived to the Archive Server (AS).

  • Certificate Signing -the CA is responsible for signing infrastructural and end-user certificates. The CA also signs certificates for both subordinate (sub) CAs and other CAs in the case of cross certification.

  • Certificate Revocation Lists (CRLs) and Authority Revocation Lists (ARLs) -the CA signs all revocation information in the form of CRLs and ARLs.

  • Message Signing -all messages sent by the CA are digitally signed.

  • Message Verification -the CA verifies all messages it receives to ensure integrity and authenticity.

  • Data Archival -all data and audit logs are archived in the CA ' s database. All information archived is digitally signed by the CA. Each entry has a unique tracking number.

  • Publication of certificates -the CA optionally publishes certificates, CRLs and ARLs to a LDAP or X.500 directory and now also to disk to provide an easily customizable publication mechanism.

  • Optionally, the CA is responsible for publishing CRLs to Online Certification Status Protocol (OCSP) servers-

  • Generation ofKey Pairs -the CA generates its own key pair(s) and that of the first CAO. .Unique distinguished name (Dname) and public key check -the CA can optionally check that all certificates being certified have a unique Dname and/or public key.

    UniCERT Certificate Authority Operator

    The Certificate Authority Operator (CAO) module is the Security Officer of the PKI. The CAO controls all of the administration functions and grants privileges to other UniCERT modules and operators. There can be several CAOs if required.

    Responsibilities

  • The CAO communicates approved certificate requests directly with the CA; revocation requests are placed in the CA's database.

  • Policy Creation -the CAO is responsible for the creation and maintenance of policies for the issuance of certificates. The CAO also maintains the operational policies of the CA and all RAs.

  • Policy Push -the CAO dynamically pushes p())jcies out (via the CA and RAs) to individual Registration Authority Operators (RAOs) to allow them to issue certificates under the policy.

  • Revocation -Any certificate can be revoked by the CAO.

  • PKI Design -the CAO can add new modules to the PKI and grant them privileges.

  • Key Generation -the CAO is responsible for creating the keys pairs for new modules. .Message Signing -all messages sent by the CAO are digitally signed.

  • Message Verification -all messages received by the CAO are verified to ensure integrity and authenticity .

  • Data Archival -all data and audit logs are archived in the CA ' s database. All information archived is digitally signed by the CAO. Each entry has a unique tracking number.

    UniCERT Registration Authority

    The Registration Authority (RA) acts as a router between Registration Authority Operators (RAOs), a Gateway and the CA. RAs divide the PKI system into operational domains. Each operational domain is a separate structure linked to the CA. lntradomain confidentiality is maintained. The RA obeys its operational policy, which is either maintained locally or at the CAO.

    Responsibilities

  • The RA communicates approved end-user certificate and revocation requests received from RAOs to the CA. It receives certificates and confirmational messages from the CA and makes them available to the RAOs.

  • The RA communicates certificate and revocation requests received from the Gateway module to RAOs and sends certificates and informational messages back to the Gateway.

  • The RA is responsible for initiating end-user certificate rollover during pre-defined hours of the day.

  • Message Signing- all messages sent by the RA are digitally signed.

  • Message Verification -all messages received by the RA are verified to ensure integrity and authenticity.

  • Data Archival -all data and audit logs are archived in the RA' s database. All information archived is digitally signed by the RA. Each entry has a unique tracking number.

    UniCERT Registration Authority Operator

    The Registration Authority Operator's (RAO) primary function is to approve certificate requests to be certified by the CA. Each RAO has rights to issue certificates according to the policies that the CAO has pushed out to it.

    Responsibilities

  • The RAO receives certificate requests from the Gateway via the RA, as well as directly in a face-to-face manner.

  • The RAO is responsible for approving or rejecting end-user certificate requests face to face or remotely (policy dependent).

  • An RAO can revoke the certificates that it has issued (policy dependent).

  • An RAO can generate an end-user's key pair(s) in software or on cryptographic hardware (policy dependent).

  • An RAO sends approved certificate and revocation requests to the RA. ..Message Signing -all messages sent by the RAO are digitally signed.

  • Message Verification -all messages received by the RAO are verified to ensure integrity and authenticity.

  • Data Archival -all data and audit logs are archived in the RA 's database. All information archived is digitally signed by the RAO. Each entry has a unique tracking number.

    UniCERT Gateway

    The UniCERT Gateway consists of three distinct and separate parts: the Web Gateway, the Email Gateway and the Virtual Private Network Gateway. The three parts can reside on the same machine and act as one integrated module. The Gateway's function is to receive remote requests and return certificates and informational messages.

    Responsibilities

  • The UniCERT Gateway receives certificate requests from remote users and send them to the RA. The Gateway receives the certificates back from the RA and communicates them to the end user .

  • The Email Gateway polls a POP3 port for PKCS#lO certificate requests sent by email. The Gateway sends back certificates in PKCS#7 format and infonnational messages by email (SMTP) for certificate requests received by email.

  • The Web Gateway receives certificate requests via a HTTP post, and serves up informational web pages. The Gateway writes the issued certificate to files and emails a URL where a browser user can collect their certificate.

  • The Web Gateway also accepts certificate revocation requests via an HTTP post, from clients. The Gateway serves up confirmation of denial web pages. .

  • The VPN Gateway receives certificate requests via HTTP posts and serves up informational pages. The Gateway writes the issued certificate to files and emails a URL where a VPN client can collect their certificate.

  • The VPN Gateway receives Certificate Enrolment Protocol (CEP) requests directly by sockets and returns the certificate in the same manner .

  • The Gateway is responsible for maintaining a logging screen detailing every action.

    UniCERT WebRAO

    The Web Registration Authority Operator (WebRAO) client module allows operators to approve certificate requests using a standard web browser. The WebRAO can communicate with the rest of UniCERT over the Internet in complete security.

    Responsibilities

  • The WebRAO receives remote certificate requests (via the Gateway) from the RA (via the WebRAO Server) and directly in a face-to-face manner.

  • The WebRAO is responsible for approving or rejecting end-user certificate requests face to face or remotely (policy dependent).

  • In a future release the WebRAO will be able to revoke the certificates that it has issued (policy dependent).

  • A WebRAO can generate end-user key pairs in software (policy dependent). Future releases will support the generation of key pairs in cryptographic hardware.

  • A WebRAO sends approved certificate and revocation requests to the RA via the WebRAO Server .

  • Message Signing- all messages sent by the WebRAO are digitally signed.

  • Message Verification -all messages received by the WebRAO are verified to ensure integrity and authenticity.

  • Data encryption -all messages sent by or received by the WebRAO are fully encrypted and wrapped in a PKCS#7 wrapper.

  • Data Archival -all data and audit logs are archived in the RA's database. All infonnation archived is digitally signed by the WebRAO. Each entry has a unique tracking number.

    UniCERT WebRAO Server

  • The WebRAO Server acts as a conduit for information between the RA and the WebRAOs. Responsibilities

  • The WebRAO Server is responsible for communicating directly with the RA's database.

  • The WebRAO Server receives messages from WebRAOs and responds with relevant HTTP/ web pages.

  • The WebRAO Server distributes policies to the relevant WebRAO.

  • Message Signing -all messages proxied by the WebRAO Server are digitally signed. .Message Verification -all messages received by the WebRAO Server are verified to ensure integrity and authenticity .

  • Data encryption -all messages sent by or received by the WebRAO Server are fully encrypted and wrapped in a PKCS#7 wrapper .

  • Data Archival -all data and audit logs are archived in the RA's database. All information archived is digitally signed by the RAO. Each entry has a unique tracking number.

    UniCERT Archive Server

  • The Archive Server securely stores end users' private encryption keys. This permits the retrieval of keys at a later date should their keys become corrupted or if it is necessary for some authority to decrypt their data. Keys are only placed in the Archive Server if the policy dictates it.

    Responsibilities

  • The Archive Server encrypts the private key with a 3-DES Data Enciphennent Key (DEK), which is created uniquely for each archived key. The encrypted private key is then saved to the database.

  • The Archive Server encrypts the DEK with a further 3-DES key and the result is saved to the database.

  • Message Signing -all messages sent by the CA are digitally signed.

  • Message Verification -all messages received by the CA are verified to ensure integrity and authenticity.

  • Data Archival -all data and audit logs are archived in the AS's database. All information archived is digitally signed by the AS. Each entry has a unique tracking number.

    UniCERT Token Manager

    The Token Manager module is designed to manage the various security functions of smartcards and HSMs (tokens).

    Responsibilities

  • The Token Manager initializes tokens before they are used. This process protects the token with a PIN .

  • The Token Manager is responsible for changing the PINs on tokens. .The Token Manager can clone certain HSMs.

  • The Token Manager is used to change the passphrase that protects keys stored in software. .PSE files can be written to tokens using this module. Alternatively, a PSE previously written to a token can be written to a file.

    Back to Index

    2.3 Salient Points of the Information Technology Bill.

    Introduction

    The IT Bill 1999, is a Bill to provide legal recognition for transactions carried out by means of electronic data interchange and other means of electronic communication, commonly referred to as "electronic commerce", which involve the use of alternatives to paper-based methods of communication and storage of information, to facilitate electronic filing of documents with the Government agencies and for matters connected therewith or incidental thereto.

    Exclusions

    Nothing in this Act shall apply to a -

    (a) "negotiable instrument" as defined in section 13 of Negotiable Instruments Act, 1881 ;

    a. "power-of-attorney" as defined in section lA of the Powers-of-Attorney Act,

    1882;

    b. "trust" as defined in section 3 of the Indian Trusts Act, 1882;

    c. "will" as defined in clause (h) of section (2) of the Indian Succession Act, J 925 including any testamentary disposition by whatever name called;

    (b) any contract for the sale or the conveyance of immovable property or any interest in such property .

    ( c ) any such document or transaction as may be notified by the Central Government.

    Important Definitions

    "Asymmetric Crypto System" means a system capable of generating a secure key pair, consisting of a private key for creating a digital signature, and a public key to verify the digital signature;

  • "Digital Signature" means a signature affixed in an electronic form consisting of transformation of an electronic record using an asymmetric crypto system and a hash function such that a person having the initial untransformed electronic record and the signer's public key can determine whether the transformation was created using the private key that corresponds to the signer's public key; and whether the initial electronic record has been altered since the transformation was made.

  • "Hash Function" means an algorithm mapping or translating one sequence of bits into another, generally smaller, set (the hash result) such that a record yields the same hash result every time the algorithm is executed using the same record as input; it is computationally infeasible that a record can be derived o~ reconstituted from the hash result produced by the algorithm; and it is computationally infeasible that two records can be found that produce the same hash result using the algorithm.

  • "Digital Signature Certificate" means a Digital Signature Certificate issued under sub- section ( 4) of section 38;

  • "Certifying Authority" means a person who has been granted a licens~ to issue a Digital Signature Certificate under section sub-section (3) of section 22 ;

  • "Certification Practice Statement" means a statement issued by a Certifying Authority to specify the practices that the Certifying Authority employs in issuing Digital Signature Certificates;

    Legal recognition of electronic records

    Where any law provides that information or any other matter shall be in writing or in the typewritten or printed form, then notwithstanding anything contained in such law, such requirement shall be deemed to have been satisfied if such information or matter is,-

    (a) rendered or made available in an electronic form ;and

    (b) accessible so as to be usable for a subsequent reference.

    Legal Recognition of Digital Signatures Where any law provides that information or any other matter shall be authenticated by affixing the signature or any document should be signed or bear the signature of any person then notwithstanding anything contained in such law, such requirement shall be deemed to have been satisfied, if such information or matter is authenticated by means of digital signature affixed in such manner as may be prescribed by the Central Government.

    Retention of electronic records

    Where any law provides that documents, records or information be retained for any specific period, then that requirement shall be deemed to have been satisfied if such documents, records or information are retained in the electronic form if the following conditions are satisfied namely:-

    (a) the information contained therein remains accessible so as to be usable for subsequent reference,

    (b) the electronic record is retained in the format in which it was originally generated, sent or received, or in a format, which can be demonstrated to represent accurately the information originally generated, sent or received;

    (c) details which will facilitate the identification of the origin, destination, date and time of despatch or receipt of such electronic record is available in the electronic record:

    REGULATION OF CERTIFYING AUTHORITIES

    Appointment of Controller and other officers

    The Central government may by notification in the Official Gazette appoint a Controller of Certifying Authorities for the purposes of this Act and may also by the same or subsequent notification appoint such number of Deputy Controllers and Assistant Controllers as it deem fit.

    Functions of Controller

    The Controller may perform all or any of the following functions, namely:- (a) exercise supervision over the activities of Certifying Authorities;

    (b) lay down the standards to be maintained by Certifying Authorities;

    (c) specify the qualifications and experience which employees of the Certifying Authority should possess;

    (d) specify the conditions subject to which the certifying authority shall conduct its business;

    (e) specify the content of written, printed or visual material and advertisements that may be distributed or used in respect of a Digital Signature Certificate and the key;

    (1) specify the fonn and content of a Digital Signature Certificate and the key;

    (g) specify the form and manner in which accounts shall be maintained by the Certifying Authorities;

    (h) specify the terms and conditions subject to which auditors may be appointed and the remuneration to be paid to them;

    (i) facilitate the establishment of any electronic system by the Certifying Authority either solely or jointly with other Certifying Authorities and regulation of such systems;

    (0) specify the manner in which a Certifying Authority shall conducts his dealings with his subscribers;

    (k) resolve the conflict of interests involving the Certifying Authority and its subscribers;

    (1) lay down the duties of a holder of a Iicense to his subscribers with respect to Digital Signature Certificates;

    (m) maintain a database containing the disclosure record of every Certifying Authority containing such particulars as may be specified by regulations, which shall be accessible to public.

    Disclosure

    Every Certifying Authority shall disclose -

    (a) its Digital Signature Certificate which contains the public key corresponding to the private key used by that Certifying Authority to digitally sign another Digital Signature Certificate ; (b) any certification practice statement relevant thereto;

    (c) notice of the revocation or suspension of its Certifying Authority certificate if any; and

    (d) any other fact that materially and adversely affects either the reliability ofa Digital Signature Certificate, which that Authority has issued, or the Authority's ability to perform its services.

    DIGITAL SIGNATURE CERTIFICATES

    (1) Any person may make an application to the Certifying Authority for the issue of a Digital Signature Certificate in such fonn as may be prescribed by the Central Government.

    (2) Every such application shall be accompanied by such fee not exceeding twenty-five thousand as may be prescribed by the Central Government, to be paid to the Certifying Authority:

    Provided that while prescribing fees under sub-section (2) different fees may be prescribed for different classes of applicants.

    (3) Every such application shall be accompanied by a certification practice statement or where there is no such statement, a statement containing such particulars as may be specified by regulations.

    (4) On receipt of an application under sub-section (I) and after consideration of the certification statement or the other statement under sub-section (3) making such inquiries as it may deem fit, the Certifying Authority may grant the Digital Signature Certificate or for reasons to be recorded in writing reject the application.

    Provided that no Digital Signature Certificate shall be granted unless the Certifying authority is satisfied that the -

    (a) applicant holds the private key corresponding to the public key to be listed in the Digital Signature Certificate;

    (b) applicant holds a private key, which is capable of creating a digital signature,

    ( c ) the public key to be listed in the certificate can be used to verify a digital signature affixed by the private key held by the applicant.

    Establishment of Cyber Regulations Appellate Tribunal

    (1) The Central Government shall by notification, establish one or more Appellate Tribunals to be known as the Cyber Regulations Appellate Tribunal.

    (2) The Central Government shall also specify in the notification referred to in sub-section ( I) the matters and places in relation to which the Cyber Regulations Appellate Tribunal may exercise jurisdiction.

    Procedure and powers of the Cyber Regulations Appellate Tribunal

    (1) The Cyber Regulations Appellate Tribunal shall not be bound by the procedure laid down by the Code of Civil Procedure, 1908 (5 of 1908), but shall be guided by the principles of natural justice and, subject to the other provisions of this Act and of any rules, the Cyber Regulations Appellate Tribunal shall have powers to regulate their own procedure including the place at which they shall have their sittings.

    (2) The Cyber Regulations Appellate Tribunal shall have, for the purposes of discharging their functions under this Act, the same powers as are vested in a Civil Court under the Code of Civil Procedure, 1908 (5 of 1908), while trying a suit, in respect of the following matters, namely:- (a) summoning and enforcing the attendance of any person and examining him on oath;

    (b) requiring the discovery and production of documents or other electronic records;

    (c) receiving evidence on affidavits;

    (d) issuing commissions for the examination of witnesses or documents; ( e ) reviewing its decisions;

    (f) dismissing an application for default or deciding it ex parte; (h) any other matter which may be prescribed.

    (3) Every proceeding before the Cyber Regulations Appellate Tribunal shall be deemed to be a judicial proceeding within the meaning of sections 193 and 228, and for the purposes of section 196, of the Indian Penal Code and the Cyber Regulations Appellate Tribunal shall be deemed to be a civil court for all the purposes of section 195 and Chapter XXVI of the Code of Criminal Procedure, 1973 .

    No court shall have jurisdiction to entertain any suit or proceeding in respect of any matter which an adjudicating officer appointed under this Act or a Cyber Regulations Appellate Tribunal constituted under this Act is empowered by or under this Act to determine and no injunction shall be granted by any court or other authority in respect of any action taken to or to be taken in pursuance of any power conferred by or under this Act.

    Appeal to High Court

    Any person aggrieved by any decision or order of the Cyber Regulations Appellate Tribunal may file an appeal to the High Court within sixty days from the date of communication of the decision or order of the Cyber Regulations Appellate Tribunal to him on any question of fact or law arising out of such order:

    Computer

    Crime Whoever knowingly or intentionally conceals, destroys, or alters or intentionally or knowingly causes another to conceal, destroy, or alter any computer source document used for a computer, computer programme, computer system, or computer network, when the computer source code is required to be kept or maintained by law for the time being in force, shall be punishable with a fine which may extend up to rupees two lakhs or with imprisonment up to three years, or with both.

    Back to Index

    3.1 Role of ISP

    An ISP, or Internet Services Provider, is the cornerstone of the E-Commerce Infrastructure. I.t provides the basic connectivity for the players in the E-Commerce world.

    The important factors in measuring the performance of any I.SP is the bandwidth avai lable and the ease of getting connected. The bandwidth is measured in terms of kbps or Mbps (kilo- or Mega- bits per second), and indicates the speed of data flow. The ease of getting connected depends on the number of subscribers per telephone line. This is in the ratio of about] 0: I globally, while in India, the ratio is more like 50: I, and hence the poor connections here. An ISP employs different types of hardware to improve its performance and these include high-powered servers, digital and leased-Iine modems, and routers.

    There are other means of getting connected like leased line, ISDN, Wireless (WAP), etc. which are much faster and reliable but are generally beyond the means of an individual subscriber. The technology is these areas is still evolving, and an introduction to these areas is given in the ensuing chapters.

    While thus far, the role ofan ISP was seen just as providing point-to-point connectivity, today the focus is shifting towards becoming an Application Service Provider or an ASP. As technology improves, the range of applications and their complexity in terms of maintenance is also increasing. The full power of technology is not being afforded by many smaller organizations, and hence the evolution of an ASP which provides such applications on a shared basis offerring total security and confidentiality of data.

    Back to Index

    3.2 ISDN Services

    Definitios

    ISDN, which stands for Integrated Services Digital Network, is a system of digital phone connections which has been available for over a decade. This system allows data to be transmitted simultaneously across the world using end-to-end digital connectivity .

    With ISDN, voice and data are carried by bearer channels (B channels) occupying a bandwidth of 64 Kbps (bits per second). Some switches limit B channels to a capacity of 56 Kbps. A data channel (D channel) handles signalling at 16 Kbps or 64 Kbps, depending on the service type. Note that, in ISDN terminology, "K" means 1000 (103), not 1024 (210) as in many computer applications; therefore, a 64 Kbps channel carries data at a rate of 64000 bps. Anew set of standard prefixes has recently been created to handle this. Under this scheme, "K" (Kilo- ) means 1000 (103), "M" (Mega-) means 1000000 (106), and so on, and "Ki" (Kibi-) means 1024 (210), "Mi" (Mebi-) means 1048576 (220), and so on.

    There are two basic types ofISDN service: Basic Rate Interface (BRI) and Primary Rate Interface (PRI). BRI consists of two 64 kbps B channels and one 16 kbps D channel for a total of 144 kbps. This basic service is intended to meet the needs of most individual users.

    PRI is intended for users with greater capacity requirements. Typically the channel structure is 23 B channels plus one 64 kbps D channel for a total of 1536 kbps. In Europe, PRI consists of 30 B channels plus one 64 kbps D channel for a total of 1984 kbps. It is also possible to support multiple PRI lines with one 64kbps D channel using Non-Facility Associated Signaling (NF AS).

    H channels provide away to aggregate B channels. They are implemented as:

    HO=384 kbps (6 B channels)

    H10=1472 kbps (23 B channels) H11=1536 kbps (24 B channels)

    H12=1920 kbps (30 B channels) -International (El) only

    To access BRI service, it is necessary to subscribe to an ISDN phone line. Customer must be within 18000 feet (about 3.4 miles or 5.5 km) of the telephone company central office for BRI service; beyond that, expensive repeater devices are required, or ISDN service may not be available at all. Customers will also need special equipment to communicate with the phone company switch and with other ISDN devices. These devices include ISDN Tenninal Adapters (sometimes called, incorrectly, "ISDN Modems") and ISDN Routers.

    ISDN History

    The early phone network consisted of a pure analog system that connected telephone users directly by an interconnection of wires. This system was very inefficient, was very prone to breakdown and noise, and did not lend itself easily to long-distance connections. Beginning in the 1960s, the telephone system gradually began converting its internal connections to a packet- based, digital switching system. Today, nearly all voice switching in the U.S. is digital within the telephone network. Still, the final connection from the local central office to the customer equipment was, and still largely is, an analog Plain-Old Telephone Service (POTS) line.

    A standards movement was started by the International Telephone and Telegraph Consultative Committee (CCITT), now known as the International Telecommunications Union (ITU). The ITU is a United Nations organization that coordinates and standardizes international telecommunications. Original recommendations of ISDN were in CCITT Recommendation 1.120 (1984) which described some initial guidelines for implementing ISDN.

    Local phone networks, especially the regional Bell operating companies, have long hailed the system, but they have been criticized in recent years for being slow to implement ISDN. One good reason for the delay is the fact that the two major switch manufacturers, Northern Telecom (later known as Nortel, now known as Nortel Networks), and AT &T , selected different ways to implement the CCITT standards. These standards didn't always interoperate. This situation has been likened to that of earlier 19th century railroading.

    "People had different gauges, different tracks...nothing worked well."

    In the early 1990s, an industry-wide effort began to establish a specific implementation for ISDN in the U.S. Members of the industry agreed to create National ISDN 1 (NI-l) so that end users would not have to know the brand of switch they are connected to in order to buy equipment and software compatible with it.

    However, there were problems agreeing on this standard. In fact, many western states would not implement NI-l. Both Southwestern Bell and U.S. West said that they did not plan to deploy NI-l software in their central office switches due to incompatibilities with their existing ISDN networks.

    Ultimately, all the RBOCs did support NI-l. A more comprehensive standardization initiative, National ISDN 2 (NI-2), was more recently adopted. Some manufacturers of ISDN communications, such as Motorola and US Robotics (now owned by 3Com), have worked with the RBOCs to develop their own configuration standards for their own equipment. These kinds of actions, along with more competitive pricing, inexpensive ISDN connection equipment, and the desire for people to have relatively low-cost high-bandwidth Internet access have made ISDN more popular in recent years.

    Advantages of ISDN

    Speed

    The modem was a big breakthrough in computer communications. It allowed computers to communicate by converting their digital information into an analog signal to travel through the public phone network. There is an upper limit to the amount of information that an analog telephone line can hold. Currently, it is about 56 kbps. Commonly available modems have a maximum speed of 56 kbps, but are limited by the quality of the analog connection and routinely go about 45 kbps. Some phone lines do not support 56K connections at all, and there were currently 2 competing, incompatible 56K standards (X2 from US Robotics (recently bought by 3Com), and K56flex from Rockwell/Lucent). This standards problem was resolved when the ITU released the V .90 standard for 56K modem communications.

    ISDN allows multiple digital channels to be operated simultaneously through the same regular phone wiring used for analog lines. The change comes about when the telephone company's switches can support digital connections. Therefore, the same physical wiring can be used, but a digital signal, instead of an analog signal, is transmitted across tlie line. This scheme pem1its a much higher data transfer rate than analog lines. BRI ISDN, using a channel aggregation protocol such as BONDING or Multilink-PPP, supports an uncompressed data transfer speed of 128 kbps. In addition, the latency, or the amount of time it takes for a communication to begin, on an ISDN line is typically about half that of an analog line. This improves response for interactive applications, such as games.

    Multiple Devices

    Previously, it was necessary to have a phone line for each device you wished to use simultaneously. For example, one line each was required for a telephone, fax, computer, bridge/router, and live video conference system. Transferring a file to someone while talking on the phone or seeing their live picture on a video screen would require several potentially expensive phone lines.

    It is possible to combine many different digital data sources and have the information routed to the proper destination. Since the line is digital, it is easier to keep the noise and interference out while combining these signals. ISDN technically refers to a specific set of digital services provided through a single, standard interface. Without ISDN, distinct interfaces are required ( instead .

    Signaling

    Instead of the phone company sending a ring voltage signal to ring the bell in your phone ("In- Band signal"), it sends a digital packet on a separate channel ("Out-of-Band signal"). The Out-of- Band signal does not disturb established connections, and call setup time is very fast. For example, a V .34 modem typically takes 30-60 seconds to establish a connection; an ISDN call usually takes less than 2 seconds.

    The signaling also indicates who is calling, what type of call it is (data/voice), and what number was dialed. Available ISDN phone equipment is then capable of making intelligent decisions on how to direct the call.

    Back to Index

    3.3 Future Evolution - Wireless Application Protocol

    Introduction

    According to the Strategis Group, there will be over 530 million wireless subscribers by the year 2001. By 2005 the number of wireless subscribers will bre-ak tl1e one billion mark, and a "substantial portion of the phones sold that year will have multimedia capabilities." These multimedia capabilities include the ability to retrieve Email, and push and pull information from the Internet. In order to guide the development of these exciting new applications, the leaders of the wireless, telecommunications industry formed the -Wireless Application Proto£2L (WAP) Forum (www.wapforum.org).

    The Wireless Application Protocol is the de-facto world standard for wireless information and telephony services on digital mobile phones and other wireless terminals. Handset manufacturers representing over 75% of the world market across all technologies have committed to shipping WAP-enabled devices. Carriers representing nearly 100 million subscribers worldwide have joined WAP .This commitment will provide tens of millions of WAP browser-enabled products to consumers by the end of 2000. WAP allows carriers to strengthen their service offerings by providing subscribers with the information they want and need while on the go. The WAP Forum has published a global wireless protocol specification based on existing Internet standards such as XML and IP for all wireless networks.

    Enabling information access from handheld devices requires a deep understanding of both technical and market issues that are unique to the wireless environment. The WAP specification has been developed by the industry's best minds to address these issues. Wireless devices represent the ultimate constrained computing device with limitedCPU, memory, and battery life, and a simple user interface. Wireless networks are constrained by low bandwidth, high latency, and unpredictable availability and stability. But most important ofall, wireless subscribers have a different set of essential desires and needs than desktop or even laptop Internet users.

    The WAP specification addresses these issues by using the best of existing standards, and developing new extensions where needed. It enables industry participants to develop solutions that are air interface independent, device independent, and fully interoperable. The WAP solution leverages the tremendous investment in Web servers, Web development tools, Web programmers, and Web applications while solving the unique problems associated with the wireless domain. The specification further ensures that this solution is fast, reliable, and secure. It enables developers to use existing tools to produce sophisticated applications that have an intuitive user interface. Ultimately, wireless subscribers benefit by gaining the power of information access in the palm of their hand.

    The WAP specification has been written by telecommunication professionals so that the entire industry, and most importantly its subscribers, can benefit from a single, open specification. Wireless service providers are able to offer anew dimension of service that complements the existing features of their networks, while extending subscriber access to the unbounded creativity of the Web. Handset manufacturers can integrate microbrowser functionality at minimal cost, because the WAP specification is open and public. Application developers gain access to a whole new market of information-hungry users, while protecting and leveraging their current investments in Web technology. Subscribers gain real anytime, anywhere information access with a simple and effective user interface, available on a variety of networks and devices.

    While the WAP specification solves the transport and content problems of the constrained wireless environment today, the WAP Forum is constantly working to improve the state of wireless information access. Through its liaisons with ETSI, CTIA, and W3C, among others, the WAP Forum will continue to ensure that a single, open standard will be available to meet the wireless information needs of subscribers and industry participants worldwide. The WAP Forum is working with these standards bodies towards a goal of convergence with the HTML and HTTP standards, which are not yet optimized for the wireless environment.

    Why WAP is necessary

    Providing Internet and Web-based services on a wireless data network presents many challenges to wireless service providers, application developers, and handset manufacturers. While the obvious limitations are rooted in the nature of wireless devices and data networks, there are also more fundamental differences that are important to understand. The next few sections outline the challenges that must be overcome to make wireless Internet access appealing to the average wireless subscriber,

    The Market is Different

    Bringing computing power to a wireless handset opens an extensive new market for information access. This market is very different from the traditional desktop or even the laptop market because the subscriber has a different set of needs and expectations, Some of these differences include:

    Ease of use: Despite the fact that using a desktop computer has become progressively easier over the last five years, a wireless computing device must be dramatically easier to use than even the simplest desktop computer. These devices will be used by people who potentially have no desktop computing experience. Furthermore, they will often be used in a dynamic environment where the mobile professional is engaged in multiple activities. Subscribers won't be focused on their handset the way they are when they are sitting in front of a desktop computer. Therefore, the devices must be extremely simple and easy to use. Applications built for these devices must therefore present the best possible user interface for quick and simple usage. There can be no installation scripts, complicated menu structure, application errors, general protection faults, or complicated key sequences such as ctrl-alt-del, or alt-shift-F5.

    Market size: The growth and size of the wireless subscriber market has been phenomenal, According to Global Mobile magazine, there are over 200 million wireless subscribers in the world today. According to Nokia, there will be over I billion wireless subscribers by the year 2005. The wireless market is enormous: it can afford and will demand optimized solutions.

    Price sensitivity: Even with today's sub-$IOOO computers, a price difference of $50 between two models is not considered significant. However a difference of $50 between two handsets is very significant, especially after years of subsidized handset pricing by the service provider, Market studies have shown that a mass-market handset must be priced under $149 to be competitive. A solution must add significant value at a low cost to be effective in this market.

    Usage patterns: Subscribers expect wireless data access to perform like the rest of their handset: The service should be instantly available, easy to use, and designed to be used for a few minutes at a time. Hourglass icons telling subscribers to wait will not be acceptable.

  • Essential tasks: As soon as professionals step out of the office, information needs and desires change. Wireless Internet subscribers will not want to use their handset to "surf the Internet". They will have small, specific tasks that need to be accomplished fairly quickly. Subscribers will want to scan Email rather than read it all, or see just the top stock quotes of interest. Receiving timely traffic Alerts on the handset will be essential, whereas the same information may not be as valuable at the desktop. The best applications will give the user a comprehensive, personalized summary of important information and will allow them to easily drill down for more detailed information.

    The Network is Different

    Wireless data networks present a more constrained communication environment compared to wired networks. Because of fundamental limitations of power, available spectrum, and mobility, wireless data networks tend to have:

  • Less bandwidth .More latency

  • Less connection stability

  • Less predictable availability

    Furthermore, as bandwidth increases, the handset's power consumption also increases, which further taxes the already limited battery life of a mobile device. So, even as wireless networks improve their ability to deliver higher bandwidth, the power availability at the handset will still limit the effective throughput of data to and from the device. A wireless data solution must be able to overcome these network limitations and still deliver a satisfactory user experience.

    The Device is Different

    Similarly, mass-market, handheld wireless devices present a more constrained computing environment compared to desktop computers. Because of fundamental limitations of battery life and form factor, mass-market handheld devices tend to have

  • Less powerful CPU s,

  • Less memory (ROM and RAM) .Restricted power consumption .Smaller displays

  • Different input devices (e.g., a phone keypad, voice input, etc.)

    Because of these limitations, the user interface of a wireless handset is fundamentally different that that of a desktop computer. The limited screen size and lack of a mouse requires a different user interface metaphor than the traditional desktop GUI. These conditions are not likely to change dramatically in the near future. The most popular wireless handsets have been designed to be lightweight and fit comfortably in the palm ofa hand. Furthermore, consumers desire handsets with longer battery life, which will always limit available bandwidth, and the power consumption of the CPU, memory, and display. Because there will always be a performance gap between the very best desktop computers and the very best handheld devices, the method used to deliver wireless data to these devices will have to effectively address this gap. As this gap changes over time, standards will have to continually evolve to keep pace with available functionality and market needs.

    WAP Vl.0

    In April 1998, the WAP Vl.0 specification was published on the WAP Forum Web site (www.wapforum.org). The specification is a major achievement because it defines for the first time an open, standard architecture and set of protocols intended to implement wireless Internet access. It also provides solutions for problems not solved by other standardization bodies ( e.g. W3C, ETSI, TIA, IETF, etc) and is a catalyst for wireless development and standardization.

    The key elements of the WAP 1.0 specification include:

  • A definition of the WAP Programming Model, as seen in figure 1, is based heavily on the existing WWW Programming Model. This provides several benefits to the application developer community, including a familiar programming model, a proven architecture, and the ability to leverage existing tools (e.g., Web servers, XML tools, etc.). Optimizations and extensions have been made in order to match the characteristics of the wireless environment. Wherever possible, existing standards have been adopted or have been used as the starting point for WAP technology.

  • A markup language based on XML that is designed to enable powerful applications within the constraints of handheld devices. The Wireless Markup Language (WML) and WMLScript do not assume that a QWERTY keyboard or a mouse are available for user input, and are designed for small screen displays. Unlike the flat structure of HTML documents, WML documents are divided into a set of well-defined units of user interactions. One unit of interaction is called a card, and services are created by letting the user navigate back and forth between cards from one or several WML documents. WML provides a smaller, telephony aware, set of markup tags that makes it more appropriate than HTML to implement within handheld devices. From the WAP Gateway, all WML content is accessed over the Internet using standard HTTP 1.1 requests, so traditional Web servers, tools, and techniques are used to server this new market.

  • A specification for a microbrowser in the wireless terminal that controls the user interface and is analogous to a standard Web browser. This specification defines how WML and WMLScript should be interpreted in the handset and presented to the user. The microbrowser specification has been designed for wireless handsets so that the resulting code will be compact and efficient, yet provide a flexible and powerful user interface.

  • A lightweight protocol stack to minimize bandwidth requirements, guaranteeing that a wide variety of wireless network types can run WAP applications. The protocol stack is shown in figure 2.

    Figure 2: The Wap Protocol Stack

  • A framework for Wireless Telephony Applications (WTA) allows access to telephony functionality such as call control, phone book access, and messaging from within WMLScript applets. This allows operators to develop secure telephony applications integrated into WML/WMLScript services. For example, services such as Call Forwarding may provide a user interface that prompts the user to make a choice between accepting a call, forwarding it to another person or forwarding it to voicemail.

    Back to Index


    TOP

        Back to the Topics of the Seminar                                                               Back to Material