|
Электронная
коммерция
|
|
Напоминание от
автора сайта Торговые
Web-серверы Приложения
для совершения покупок Затем появились формы заказа, которые покупатели могли пересылать по Интернет. Для этого требовались клиентские HTML-формы, взаимодействующие с заказчиками, а также серверные интерфейс CGI и специальные приложения, принимающие и обрабатывающие данные. От пользователей требовалось занести данные в одну или несколько HTML-форм. Часто внешний HTML-интерфейс генерировался динамически, в зависимости от базы данных товаров. Позднее были разработаны более сложные приложения: теперь пользователи могли просматривать интерактивные каталоги и заносить предметы с нескольких страниц в виртуальные списки покупок (virtual shopping cart). Система, установленная на сервере, запоминала все выбранные предметы и объединяла их в общий список по окончании посещение виртуального магазина. Такие приложения известны как приложения для совершения покупок (shopping cart application). Чтобы сохранить список выбранных предметов, приложения для совершения покупок используют специальные маркеры (cookies) и HTTP-заголовки. Помните, что HTTP - протокол без памяти (см. главу 12), то есть каждая HTTP-команда выполняется независимо от предшествующей. По этой причине обычно используется некоторый маркер, позволяющий логически объединить последовательности действий в HTTP-транзакции. Этот маркер должен быть доступен серверу, для чего его указывают как параметр в последующих URL динамических HTML-страниц или включают в другой HTTP-заголовок. Открытый HTTP S-HTTP HTTP и SSL При применении SSL с протоколом HTTP, Web-браузер использует URL-схемы вида <https://> вместо <http://> , как для открытого HTTP. Многие Web-браузеры сообщают пользователю (с помощью диалоговых окон, изображений ключиков скрепленных или порванных связей, и т. д.), что транзакции на основе HTTPS более безопасны, чем обычные HTTP-транзакции. Сейчас SSL используется повсеместно для обеспечения безопасности Web-транзакций общего назначения и практически заменил S-HTTP. Развитием SSL (и протоколов транспортного уровня) занимается рабочая группа Transport Level Security (TLS) в составе IETF. Системы торговых
серверов Более сложные системы выполнят проверку правильности платежа в реальном времени, что требует взаимодействия с банком, обслуживающим счета продавца. Менее сложные системы откладывают проверку правильности платежа до тех пор, пока запрошенная транзакция не будет перенесена в обычную расчетную систему продавца. Вот несколько примеров крупных коммерческих программ: Microsoft Site Server, Netscape Merchant System, Open Market Commerce Server, Net Commerce от IBM и Electronic Commerce Suite от iCat. Протокол SET Покупая товары с помощью обычных кредитных карт, покупатели взаимодействует с продавцами. Последние для проверки сделки обращаются к банкам, принимающим карточки к оплате, а банки-эммитенты взаимодействуют с держателями карт для получения денег за покупку. Применив эту, всем знакомую схему к электронным транзакциям, компании MasterCard, Visa и другие разработали протокол SET. Он использует тот же самый базовый процесс, но заменяет реальную кредитную карточку интерактивным протоколом. Протокол SET сохраняет иерархию доверительных отношений, что существует между продавцом и банком, принимающим платеж, а также владельцем карты и банком-эммитентом. В электронном варианте эта иерархия доверия формализована посредством цифровых сертификатов и иерархии сертификационных служб (аналог финансовой системы экономики). SET заменяет две отдельных технологии: STT (Secure Transaction Technology) от Visa и Microsoft и SEPP (Secure Electronic Payment Protocol) от MasterCard и IBM. К счастью, преимущества единой инфраструктуры были настолько очевидны, что два протокола объединили в один - SET. В некоторых случаях SET лучше, чем существующий механизм обычных кредитных карточек, особенно при обеспечении конфиденциальности потребителя. Транзакции зашифрованы так, чтобы торговцы видели только информацию о приобретаемых предметах, но не имели доступа к данным о лицевом счете клиента. Аналогично, банкам недоступна информация о покупаемых товарах, им видны лишь запросы кредитования продавца. Протокол SET не привязан ни к HTTP, ни к Web-коммерции. Его можно использовать с самыми разными протоколами. SET не простой протокол: его сообщения и структуры данных описаны в формате ASN.I (Abstract Syntax Notation One). В отличие от SSL, SET шифрует сами сообщения, а не канал связи. В результате возможны более сложные шифры, нежели многоцелевые (как в SSL). Структура SET-запроса разбивается на две части - информация о заказе (Order Information, 01) и информация о платеже (Payment Information, PI). Последняя нужна банку; но не продавцу. (Продавцу достаточно получить от банка подтверждение платежа.) Все данные, относящиеся к одной транзакции, скрепляются методом двойной подписи (dual signature). Этот метод использует два различных сообщения, одно из которых адресовано продавцу, а другое - банку. Эти сообщения взаимосвязаны, поэтому банк может сопоставить платеж с заказом, не зная всех деталей последнего. Продавец получает гарантии лишь относительно оплаты заказа и размера платежа, но не владеет никакой другой информацией (например, не знает номер счета - эквивалент шестнадцатизначного номера кредитной карточки - заказчика). Каждое сообщение обрабатывается алгоритмом дайджеста сообщений, который вырабатывает 160-битный дайджест. Затем два дайджеста соединяются, и результат обрабатывается этим же алгоритмом. Конечный вариант покупатель подписывает с помощью своего личного ключа. Это и есть двойная подпись. Затем покупатель отправляет два сообщения. Одно - продавцу, в нем описаны детали заказа и содержится дайджест сообщения, посланного банку. Другое сообщение - в банк; в нем указана стоимость транзакции и содержится дайджест сообщения, посланного продавцу. И банк, и продавец могут проверить подлинность полученного сообщения. Для этого необходимо вычислить дайджест принятого сообщения и объединить его с дайджестом другого сообщения. Вычисленный общий дайджест должен совпадать с расшифрованной (при помощи открытого ключа покупателя) двойной подписью. Обратите внимание на то, что этот метод позволяет покупателю торговаться при покупке. Продавец посылает банку сообщение только в том случае, если принимает предложение покупателя. Дайджест сообщения связывает транзакцию между продавцом и покупателем с сообщением межу банком и покупателем, подтверждающим платеж. SET явно использует два вида шифрования: симметричное и асимметричное, а также сертификаты для сопоставления открытого и личного ключей. Многие компании, производящие программное обеспечение, выпускают API для работы с протоколом SET. Большинство приложений, использующих SET, например системы торговых серверов и аналогичные им объекты клиентской стороны (своего рода виртуальные кошельки), применяют эти программные библиотеки. Электронные деньги Для большинства видов электронных денег разработаны специальные протоколы обмена финансовыми заявками между клиентом, продавцом и эммитентом денег (банком). Эти протоколы реализованы как для серверного ПО, так и для клиентского - электронного бумажника. Вот некоторые примеры существующих технологий электронных денег: • CyberCash и CyberCoin
от CyberCash Inc. •
eCash от DigiCash Inc. • Millicent от Digital
Equipment • iKP (Internet Keyed
Payment Protocols) от IBM • NetCheque, производитель
- University of Southern California's Information Sciences Institute • NetBill, производители
- Carnegie Mellon University's Information Networking Institute, • Mondex от Mondex
International • Interactive Messaging
Platform от First Virtual (на 07.07.2000 не работала -
прим. Тим) • Netscape LivePayment
от Netscape • MiniPay от IBM (на
07.07.2000 не работала - прим. Тим) Микроплатежи Электронные бумажники Другие компании применяют электронные бумажники для иных целей. Некоторые Web-узлы имеют гостевые книги, в которые пользователей просят сообщить информацию о себе и о своих предпочтениях для динамического формирования содержания узла. Часть этой информации хранят в <бумажниках>. Когда такие сведения помещены в одно место, где четко определены процедуры их запроса и обработки, удобнее использовать электронный бумажник (небольшую клиентскую базу данных, содержащую, например, номер кредитной карточки, информацию о цифровой подписи и сведения для идентификации и аутентификации) для нефинансовой информации. Кстати, в обычном бумажнике часто мы тоже храним массу нужных нам вещей, не имеющих отношения к деньгам: листочки с телефонами, записочки, фотографии и др. Смарт- карты Существует целый ряд стандартов для смарт-карт. Организация ISO разработала стандарты ISO 7816, определяющие совместимость на аппаратном уровне и на уровне канального протокола контактных смарт-карт на основе интегральных микросхем. Europay, MasterCard и Visa разработали спецификации смарт-карт, расширяющие стандарты ISO 7816. Эти спецификации содержат дополнительные типы данных и правила кодирования, позволяющие применять смарт-карты в финансовой сфере. Специалисты GSM (Global System for Mobile Communications) разработали спецификации, позволяющие с помощью смарт-карт идентифицировать и аутентифицировать пользователей мобильных телефонов. Рабочая группа PC/SC (Personal Computer / Smart Card) определила схему и API для взаимодействия смарт-карт с персональных компьютерами, а OpenCard Framework - для взаимодействия с OpenCard-совместимыми платформами (включая сетевые компьютеры). Java Commerce Взгляд в будущее Ссылки |