предоставление цифровых удостоверений

Формула изобретения

1. Способ предоставления пользователю цифрового удостоверения, содержащий этапы

приема входных данных, определяющих дескриптор для цифрового удостоверения;

сохранение дескриптора;

в ответ на сохранение дескриптора автоматической отправки пользователю первого оповещения о том, что цифровое удостоверение доступно для пользователя;

приема запроса через первый канал на создание цифрового удостоверения для пользователя;

выдачи по второму каналу второго оповещения о том, что цифровое удостоверение было запрошено;

получения одобрения на создание цифрового удостоверения;

создания цифрового удостоверения.

2. Способ по п.1, в котором второе оповещение является электронным сообщением, посылаемым на известный адрес для пользователя.

3. Способ по п.1, в котором второе оповещение является электронным сообщением, посылаемым третьей стороне, отличной от пользователя.

4. Способ по п.1, в котором второе оповещение включает в себя электронную ссылку для облегчения процесса одобрения.

5. Способ по п.1, в котором первый канал является HTTP запросом, а второй канал является электронной почтой.

6. Способ по п.1, дополнительно содержащий этапы

приема второго запроса через первый канал для создания второго цифрового удостоверения для пользователя;

выдачи через второй канал третьего оповещения о том, что было запрошено второе цифровое удостоверение;

приема отклонения одобрения на создание цифрового удостоверения;

отправки третьей стороне электронного сообщения о том, что было принято отклонение одобрения.

7. Способ предоставления пользователю цифрового удостоверения, содержащий этапы

приема входных данных, определяющих дескриптор для цифрового удостоверения;

сохранения дескриптора;

в ответ на сохранение дескриптора автоматической выдачи пользователю оповещения о том, что цифровое удостоверение доступно для пользователя;

приема запроса на создание цифрового удостоверения;

создания цифрового удостоверения.

8. Способ по п.7, в котором оповещение включает в себя ссылку на электронный сайт для обеспечения возможности создания запроса.

9. Способ по п.7, дополнительно содержащий этап сбора данных, относящихся к пользователю;

при этом этап выдачи автоматически выполняется за этапом сбора.

10. Способ по п.7, в котором оповещение выдается третьей стороне.

11. Способ по п.7, в котором пользователь является членом группы пользователей, причем способ дополнительно содержит этап установления политики, согласно которой группе пользователей разрешается доступ к цифровому удостоверению;

причем этап выдачи оповещения содержит выдачу оповещения группе пользователей.

12. Способ по п.11, в котором этап выдачи оповещения содержит отправку сообщения к, по меньшей мере, одному приложению, исполняемому на пользовательской машине, которая ассоциирована с, по меньшей мере, одним из пользователей в группе пользователей.

13. Способ по п.12, в котором запрос создается, по меньшей мере, одним приложением автоматически без напоминания, по меньшей мере, одним пользователем.

14. Способ по п.7, дополнительно содержащий этапы криптографической защиты одного или более цифровых удостоверений и отправки одного или более криптографически защищенных цифровых удостоверений на пользовательскую машину.

15. Система для предоставления пользователю цифрового удостоверения, причем система содержит,

по меньшей мере, один блок обработки;

память, коммуникативно соединенную с, по меньшей мере, одним блоком обработки и хранящую инструкции, которые при исполнении, по меньшей мере, одним блоком обработки выполняют способ, содержащий этапы приема входных данных, определяющих дескриптор для цифрового удостоверения;

сохранения дескриптора;

в ответ на сохранение дескриптора автоматической выдачи пользователю оповещения о том, что цифровое удостоверение доступно для пользователя;

приема запроса на создание цифрового удостоверения и

создания цифрового удостоверения.

16. Система по п.15, в которой оповещение включает в себя ссылку на электронный сайт для обеспечения возможности создания запроса.

17. Система по п.15, причем упомянутый способ дополнительно содержит этап сбора данных, относящихся к пользователю;

при этом этап выдачи автоматически выполняется вслед за этапом сбора.

18. Система по п.15, в которой пользователь является членом группы пользователей, причем упомянутый способ дополнительно содержит этап установления политики, согласно которой группе пользователей разрешается доступ к цифровому удостоверению;

причем этап выдачи оповещения содержит выдачу оповещения группе пользователей.

19. Система по п.18, причем упомянутый этап выдачи оповещения содержит отправку сообщения к, по меньшей мере, одному приложению, исполняемому на пользовательской машине, которая ассоциирована с, по меньшей мере, одним из пользователей в группе пользователей.

Описание изобретения к патенту

ПРЕДПОСЫЛКИ К СОЗДАНИЮ ИЗОБРЕТЕНИЯ

В последнее время произошли значительные изменения в развитии систем, которые позволяют человеку лучше контролировать распространение и использование персональной информации, в частности в цифровом виде. Например, Корпорация Майкрософт в Редмонде, штат Вашингтон, среди других, распространяет систему, которую называют Windows CardSpace, являющуюся одной из реализаций корпорацией Майкрософт более общей системы, под названием "выбор информационной карты" (Information Card Selector). В системе Windows CardSpace пользователь получает один или несколько цифровых удостоверений, называемых информационными картами. Когда пользователь пытается получить доступ к ресурсу (у "проверяющей стороны"), который требует выполнения набора запросов о пользователе, пользователь использует цифровое удостоверение (в дальнейшем называемое "DIR", сокращение от "digital identity representation") для коммуникации с провайдером идентификации, который может подтвердить эти запросы. В некоторых случаях провайдер идентификации может контролироваться пользователем и запускаться на пользовательской машине. В других случаях этот процесс может контролироваться третьим лицом. Провайдер идентификации возвращает маркер идентификации, который включает затребованную запросом информацию.

Однако созданию и передаче DIR уделялось мало внимания. В настоящее время администраторы систем цифровой идентификации вынуждены изготавливать DIR вручную. Например, для изготовления вручную DIR и сохранения его в определенном месте, администратор может использовать некую утилиту, такую как генератор XML. После этого администратор может послать пользователю указатель на DIR, и пользователь с помощью этого указателя может извлечь данное DIR. Данная система создается для каждого отдельного случая, она подвержена ошибкам и уязвима с точки зрения безопасности, а также требует больших усилий от администратора.

РАСКРЫТИЕ ИЗОБРЕТЕНИЯ

Цель данного раскрытия изобретения - ввести выбор концепций в упрощенной форме, которая далее описана ниже в разделе "Осуществление изобретения". Данное краткое изложение не ставит задачу идентифицировать ключевые или неотъемлемые свойства заявленного объекта описания, также не ставится задача ограничения объема заявленного объекта описания.

Один аспект относится к способу передачи DIR пользователю. Запрос, такой как HTTP запрос на создание DIR для пользователя, принимается через первый канал. Через второй канал посылается извещение о запросе на DIR, например, по электронной почте. Затем принимается одобрение на создание DIR, причем еще до создания DIR.

Другой аспект относится к другому способу передачи DIR пользователю. Система генерации DIR опрашивается (например, приложением, работающим на машине пользователя) для определения наличия новых доступных для пользователя DIR. Затем определяется наличие доступного для пользователя нового DIR. Если таковой существует, то посылается запрос на создание нового DIR. В конце происходит прием нового DIR.

Еще один аспект относится к способу передачи DIR группе пользователей. Устанавливается политика, при которой доступ к DIR разрешен группе пользователей. Затем группа пользователей извещается о наличии доступного DIR. Затем принимается запрос от, по меньшей мере, первого пользователя группы пользователей на создание DIR. Наконец, DIR создается для, по меньшей мере, первого пользователя.

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

Далее дается ссылка на прилагаемые чертежи, в которых может не соблюдаться масштаб и в которых:

Фиг.1 иллюстрирует пример системы DIR, включающей самого пользователя, машину этого пользователя, проверяющую сторону, провайдера идентификации, систему генерации DIR, хранилище идентификационных данных, административную систему, а также систему сбора данных;

Фиг.2 иллюстрирует пример способа передачи и использования DIR;

Фиг.3 иллюстрирует другой пример способа передачи и использования DIR;

Фиг.4 иллюстрирует другой пример способа передачи DIR;

Фиг.5 иллюстрирует другой пример способа передачи DIR;

Фиг.6 иллюстрирует другой пример способа передачи DIR;

Фиг.7 иллюстрирует другой пример способа передачи DIR;

Фиг.8 иллюстрирует другой пример способа передачи DIR;

Фиг.9 иллюстрирует пример вычислительного устройства.

ДЕТАЛЬНОЕ ОПИСАНИЕ

Теперь мы опишем более полно пример реализации со ссылкой на прилагаемые чертежи. На всех чертежах одинаковые номера соответствуют одинаковым элементам.

Примеры описываемых здесь реализаций относятся в общем случае к системам идентификации, включающим DIR, используемые для инициирования коммуникации для создания маркеров идентификации, которыми могут обмениваться пользователи, провайдеры идентификации и проверяющая сторона для проверки подлинности идентификации и/или информации, относящейся к пользователю. В примерах реализаций, описываемых здесь, пользователь может быть лицом или несколькими лицами, компьютером, сетью или любой другой сущностью. У проверяющей стороны есть товары, услуги и другая информация, к которой пользователь хочет получить доступ и/или владеть. В примерах реализаций, проверяющая сторона может содержать один или несколько компьютеров, компьютерных сетей, массивов данных, баз данных, строений, сотрудников, услуг, компаний, организаций, мест физического нахождения, электронных устройств или любых других типов ресурсов.

Теперь обратимся к Фиг.1, на которой приведен пример системы 100 DIR, включая пользователя 110 и проверяющую сторону 120. Пользователь 110 владеет или контролирует пользовательскую машину 111. Пользовательская машина 111 включает компьютерную систему хотя бы временно контролируемую пользователем 110. Проверяющая сторона 120 может также включать компьютерную систему. Система 100 может также включать административную систему 160, систему 162 сбора данных, систему 164 генерации DIR, хранилище 168 данных идентификации и провайдера 115 идентификации, каждый из которых обсуждается далее ниже и может включать или быть частью компьютерной системы.

Пользователь 110 и проверяющая сторона 120 могут сообщаться друг с другом через одну или несколько сетей, таких как Интернет, или через телефонную сеть, или другие формы проводной или беспроводной связи. В примере реализации пользователь 110 может запросить товары, услуги, информацию, привилегии или другие формы доступа у проверяющей стороны 120. Проверяющая сторона 120 может потребовать проверки подлинности идентификации пользователя 110 или информацию о нем перед или в связи с передачей запрошенного доступа пользователю 110.

Также на Фиг.1 показан пример провайдера 115 идентификации. Провайдер 115 идентификации включает компьютерную систему, примеры реализаций, а также преобразователь 130 запросов и орган 140 обработки запросов. Преобразователь 130 запросов иногда называют "службой маркеров безопасности". В приведенном примере провайдер 115 идентификации может послать один или несколько запросов о пользователе 110. Запрос - это заявление или утверждение о пользователе, возможно включающий информацию о пользователе, такую, как, например, его имя, адрес, номер социальной защиты, возраст, кредитную историю, транзакционные требования и т.д. Как описано далее ниже, провайдер 115 идентификации может передавать запросы пользователю 119 и/или проверяющей стороне 120 в форме маркера идентификации с цифровой подписью. В примерах реализации провайдер 115 идентификации находится в доверительных отношениях с проверяющей стороной 120, и таким образом проверяющая сторона 120 доверяет запросам в подписанных маркерах идентификации, пришедших от провайдера 115 идентификации.

Хотя преобразователь запросов и орган 140 обработки запросов провайдера 115 идентификации показаны как отдельные сущности на Фиг.1, в альтернативных реализациях преобразователь 130 запросов и орган 140 обработки запросов может быть одной и той же сущностью или разными сущностями. Провайдер 115 идентификации в некоторых реализациях может принять форму сервиса маркера безопасности. Таким же образом провайдер идентификации 115 и система 164 генерации DIR может быть одной и той же сущностью или разными сущностями.

Компьютерные системы, описанные здесь, включают, без ограничений, персональный компьютер, сервер, портативное или стационарное устройство, микропроцессорную систему, систему на микропроцессорной основе, программируемую пользовательскую электронику, сетевые ПК, миникомпьютеры, мэйнфреймы, смарткарты, телефоны, средства мобильной или сотовой связи, карманный персональный компьютер, распределенную вычислительную среду, которая включает любое из перечисленных выше устройств. Переносимым компьютерным устройством может быть любая компьютерная система, разработанная для того, чтобы пользователь мог ее переносить. Каждая компьютерная система может также включать одно или несколько периферийных устройств, включая, но без ограничений: клавиатуру, мышь, камеру, веб-камеру, видеокамеру, сканер отпечатков пальцев, сканер радужной оболочки глаза, устройство вывода изображения (такое, как монитор), микрофон или колонки.

Каждая компьютерная система включает операционную систему, такую как (без ограничений) операционную систему WINDOWS (разработчик - корпорация Microsoft) и одну или несколько программ, хранящихся на машиночитаемых носителях. Каждая компьютерная система может также включать один или несколько коммуникационных устройств ввода или вывода, которые позволяют пользователю сообщаться с компьютерной системой, также как позволяют компьютерной системе сообщаться с другими устройствами. Коммуникации между компьютерными системами, используемыми пользователем 110 (например, пользовательской машиной 111), проверяющей стороной 120, системой 164 генерации DIR, административной системой 160, системой 162 сбора данных и провайдером 115 идентификации может быть реализована с использованием коммуникационных связей любого типа, включая, но без ограничений, Интернет, внутренние сети, сети Ethernet, связанные напрямую линии, спутники, инфракрасные сканеры, сотовую связь или любой другой тип проводных или беспроводных коммуникаций.

В некоторых примерах реализаций, описанных здесь, система 100 реализована хотя бы частично как система Information Card, предоставляемая средой.NET 3.0, разработанной корпорацией Microsoft (располагается в Редмонде, штат Вашингтон). Система Information Card позволяет пользователю управлять различными DIR от разных провайдеров идентификации.

Система Information Card использует одну платформу веб-сервисов, такую как Windows Communication Framework, входящую в состав среды.NET 3.0. Кроме того, система Information Card построена с использованием спецификаций безопасности веб-сервисов (Web Services Security Specification), распространяемой, хотя бы частично, корпорацией Microsoft из Редмонда, штат Вашингтон. Эти спецификации включают модель безопасности сообщений WS-Security, политику конечных точек WS-SecurityPolicy и метаданные для присоединения маркеров идентификации к сообщениям. Модель WS-SecurityPolicy описывает требования к политике конечных точек, такие, как требуемые маркеры идентификации и поддерживаемые алгоритмы шифрования. Такие требования к политике могут быть переданы и согласованы с использованием протокола метаданных, который определяется в WS-MetadataExchange. Модель WS-Trust описывает среду для моделей доверия, которая позволяет взаимодействовать различным веб-сервисам. Некоторые примеры реализаций, описанные здесь, ссылаются на описанные выше спецификации Web Services Security Specifications. В альтернативных реализациях одна или несколько других спецификаций могут быть использованы для облегчения процесса коммуникации между различными подсистемами в системе 100.

Обращаясь снова к Фиг.1, отметим, что пользователь 110 может послать запрос через пользовательскую машину 111 к проверяющей стороне 120 для доступа к товарам, услугам или другой информации. Например, в одной реализации пользовательская машина 111 посылает запрос к проверяющей стороне 120 на доступ к желаемой пользователем 110 информации от проверяющей стороны 120. Запрос, отправленный пользовательской машиной 111, может включать запрос на требования подлинности проверяющей стороны 120, использующей, например, механизмы, обеспечиваемые моделью WS-MetadataExchange.

В ответ на запрос проверяющая сторона 120 может отправить на пользовательскую машину 111 требования для проверяющей стороны 120 на проверку подлинности идентификации пользователя или другой информации о пользователе 110. Требования проверяющей стороны 120 к проверке подлинности мы будем называть здесь политикой безопасности. Политика безопасности как минимум определяет набор запросов от доверяемого провайдера 115 идентификации, который пользователь должен предоставить проверяющей стороне 120, чтобы проверяющая сторона 120 могла проверить подлинность пользователя 110. Политика безопасности может включать требование подтверждения персональных характеристик (таких как возраст), идентификации, финансового положения и т.д. Она также может включать правила, касающиеся уровня верификации и идентификации, которые требуются для проверки подлинности любых предлагаемых подтверждений (например, цифровой подписи от конкретного провайдера идентификации).

В одном примере проверяющая сторона 120 определяет свою политику безопасности, используя модель WS-SecurityPolicy, включая как требования к запросам, так и тип идентификационного маркера, требуемого проверяющей стороной 120. Примерами (но не ограничениями) типов запросов могут служить: имя, фамилия, адрес электронной почты, домашний адрес, город или другое место проживания, штат или провинция, почтовый код, страна, телефонный номер, номер социальной защиты, дата рождения, пол, персональный идентификационный номер, кредитный счет, финансовое положение, правовое положение и т.д.

Политика безопасности может также использоваться для задания типов маркеров идентификации, требуемых принимающей стороной 120 либо может использоваться тип по умолчанию, определяемый провайдером идентификации. Кроме того, для задания требуемых запросов и типов маркеров, политика безопасности может задавать конкретного провайдера идентификации, требуемого проверяющей стороной. Как вариант, политика может опустить этот элемент, оставляя определение подходящего провайдера идентификации самому пользователю 110. Также политика безопасности может задавать другие элементы, такие как, например, свежесть требуемого маркера безопасности.

В некоторых реализациях пользователь 110 может сделать запрос на то, чтобы проверяющая сторона 120 идентифицировала себя на пользовательской машине 111 таким образом, чтобы пользователь 110 мог решить, удовлетворяет ли он или нет политике безопасности принимающей стороны 120, как описано ниже. В одном примере проверяющая сторона 120 идентифицирует себя, используя сертификат X509. В других реализациях проверяющая сторона 120 может идентифицировать себя, используя другие механизмы, такие как, например, серверный сертификат протокола защищенных сокетов (Secure Sockets Layer, SSL).

Пользовательская машина 111 может включать один или несколько DIR для пользователя 110. Эти DIR (иногда их называют "информационными картами, Information Cards" в системе Windows Cardspace, предоставляемой средой.NET 3.0, разработанной корпорацией Майкрософт из Редмонда, штат Вашингтон) являются артефактами, которые представляют отношения, основанные на обмене маркерами между пользователем 110 и конкретным провайдером идентификации, таким как провайдер идентификации 115. Каждый DIR может соответствовать конкретному провайдеру идентификации, и пользователь 110 может иметь несколько DIR от одного или различных провайдеров идентификации. Использование DIR в системах идентификации описано в деталях в патентной заявке США серийный № 11/361281, который включен в данную работу посредством ссылки, как если бы он являлся частью данной работы.

DIR могут включать среди прочей информации политику выдачи маркеров идентификации провайдером идентификации, включая тип маркеров, которые могут быть выданы, типы запросов, для которых он имеет полномочия и/или мандат для использования с целью идентификации при запросе маркеров идентификации. DIR могут быть представлены в виде XML документов, которые выдаются провайдерами 115 идентификации или системами 164 генерации DIR и сохраняются пользователем 110 в устройстве хранения, таком, как пользовательская машина 111.

Пользовательская машина 111 может также включать селектор идентификации. В общем случае селектор идентификации представляет собой компьютерную программу с пользовательским интерфейсом, который позволяет пользователю 110 выбирать между одним или несколькими DIR пользователя 110 на пользовательской машине 111, запрашивать и получать маркеры идентификации от одного или нескольких провайдеров идентификации, таких как провайдер 115 идентификации. Например, когда политика безопасности проверяющей стороны 120 принята пользовательской машиной 111, селектор идентификации может быть запрограммирован на идентификацию одного или нескольких DIR, которые удовлетворяют одному или нескольким запросам, требуемым политикой безопасности, использующей информацию в DIR. Как только пользователь 110 принимает политику безопасности от принимающей стороны 120, пользователь 110 может сообщаться (используя, например, пользовательскую машину 111) с одним или несколькими провайдерами идентификации для сбора запросов, требуемых политикой.

В примерах реализаций пользователь 110 запрашивает один или несколько маркеров идентификации от провайдера 115 идентификации, используя механизм выдачи, описанный в модели WS-Trust. В примерах реализаций пользователь 110 направляет запрос с требованиями к политике проверяющей стороны 120 для провайдера 115 идентификации. Идентификация проверяющей стороны 120 может (но не обязательно должна) быть задана в запросе, посланном пользователем 110 провайдеру 115 идентификации. Запрос может включать также и другие требования, такие как запрос показать маркер.

В общем случае орган 140 обработки запросов провайдера 115 идентификации может обеспечивать один или несколько запросов, требуемых политикой безопасности проверяющей стороны 120. Преобразователь 130 запросов провайдера 150 идентификации программируется на преобразование запросов и генерацию одного или нескольких подписанных маркеров 150 идентификации, которые включают запрос (запросы), относящиеся к пользователю 110.

Как отмечалось выше, пользователь 110 может запрашивать маркер идентификации в определенном формате в своем запросе к провайдеру 115 идентификации, на основе требований проверяющей стороны 120. Преобразователь запросов 130 может быть запрограммирован на генерацию маркеров идентификации в одном или нескольких форматах, включая (но не ограничивая данным списком) X509, Kerberos, SAML (версии 1.0 и 2.0), простой расширяемый протокол идентификации (Simple eXtensible Identity Protocol, SXIP) и т.д.

Например, в одной реализации орган 140 обработки запросов программируется на генерацию запросов в первом формате A, а политика безопасности проверяющей стороны 120 требует маркер идентификации во втором формате B. Преобразователь 130 может преобразовывать запросы, поступающие от органа 140 обработки запросов из формата A в формат B перед отправкой провайдера идентификации пользователю 110. Кроме того, преобразователь запросов 130 может быть запрограммирован на улучшение семантики конкретного запроса. В примерах реализаций семантика конкретного запроса преобразована для минимизирования объема информации в конкретном запросе и/или маркере идентификации для уменьшения или минимизирования объема персональной информации, передаваемой в данном запросе.

В примерах реализации преобразователь 130 запросов посылает маркер 150 идентификации пользователю 110, используя механизмы ответа, описанные в модели WS-Trust. В одной реализации преобразователь 130 запросов включает сервис маркеров безопасности (иногда их называют "STS", сокращение от "security token service"). В примере реализации пользователь 110 посылает маркер 150 идентификации проверяющей стороне 120 путем привязывания маркера 150 идентификации к прикладному сообщению, используя механизмы безопасного связывания, описанные в модели WS-Security. В других реализациях маркер 150 идентификации может быть послан непосредственно от провайдера идентификации к проверяющей стороне 120.

Как только проверяющая сторона 120 принимает маркер идентификации 150, проверяющая сторона 120 может верифицировать (например, путем декодирования или дешифрования маркера 150 идентификации) происхождение подписанного маркера 150 идентификации. Проверяющая сторона 120 может также использовать запрос(ы) в маркерах 150 идентификации для удовлетворения политики безопасности принимающей стороны 120 для проверки подлинности пользователя 110.

Теперь обсудим более подробно передачу DIR. Пользователь может получить DIR различными способами. Например, в реализации, проиллюстрированной на Фиг.1, система генерации DIR 164 обычно используется для сообщения с пользователем 110, создания новых DIR и извещения пользователя 110 о доступности DIR. Система 164 генерации DIR может в некоторых реализациях включать в себя веб-сайт в интернете. В других реализациях система 164 генерации DIR может включать в себя веб-сервис. В некоторых реализациях система 164 генерации DIR может также включать в себя информационный интернет-сервер (Internet Information Server, IIS) (166).

Хранилище 168 данных идентификации представляет собой систему хранения цифровой информации, доступ к которой в некоторых реализациях могут иметь провайдер 115 идентификации, система 164 генерации DIR и система 160 администрирования. Хранилище 168 данных идентификации может включать в себя сервер базы данных, компьютерную память или любое другое устройство (устройства) хранения данных. Хранилище 168 данных идентификации может содержать несколько устройств или систем в распределенной модели данных. Хранилище 168 данных может также включать или содержать службу директорий, такую, как Active Directiry 169, распространяемую корпорацией Майкрософт из Редмонда, штат Вашингтон.

Система 160 администрирования может включать в себя компьютерную систему, включая пользовательский интерфейс, который позволит администратору сообщаться с хранилищем 168 данных идентификации и системой 164 генерации DIR. Она также позволяет администратору определить типы DIR, которые создает система 164 генерации DIR и позволяет администратору контролировать, имеет ли конкретный пользователь право получать конкретные DIR. Использование системы 160 администрирования обсуждается ниже.

Определенные реализации могут включать отдельные системы 162 сбора данных. Система 162 сбора данных может содержать компьютерную систему, адаптированную для сбора информации, относящуюся к пользователю. Например, система 162 сбора данных может содержать компьютерную систему отдела кадров, которая собирает персональную информацию о пользователе, такую как имя, номер телефона, номер социальной безопасности, адрес и т.д. Система 162 сбора информации может включать в себя отдельное хранилище или может использовать хранилище 168 идентификационных данных.

Фиг.2 иллюстрирует метод 200, который может быть реализован через систему 100. На этапе 210 администратор конфигурирует хранилище идентификационных данных. Например, администратор может, в некоторых реализациях, использовать систему 160 администрирования для установки таблиц в хранилище 168 идентификационных данных, которые будут использоваться для администрирования, генерирования и управления DIR. В примере реализации администратор может определить типы запросов, которые будут поддерживаться в DIR, созданных системой 164 генерации DIR и идентифицировать маркеры, сгенерированные провайдером 115 идентификации. Администратор может также использовать систему 160 администрирования для конфигурирования хранилища 168 данных идентификации для хранения информации о политике, такой, как типы маркеров, поддерживаемых провайдером 115 идентификации, информация об именах и общие метаданные. Другая информация в хранилище 168 идентификационных данных, которая может быть внедрена в DIR, включает фотографию пользователя 110 и информацию о соединениях, относящуюся к провайдерам идентификации, таким, как провайдер 115 идентификации.

Способ 200 далее переходит к этапу 220, когда пользователь 110 запрашивает DIR. DIR может быть запрошено различными способами. Например, пользователь 110 может использовать пользовательскую машину 111 для доступа к системе 164 генерации DIR через интернет браузер для запроса DIR. В некоторых реализациях пользователь 110 запрашивает конкретное DIR. В других реализациях, обсуждаемых ниже, пользователь запрашивает список DIR, имеющихся в наличии для пользователя 110 и выбирает из этого списка.

Затем способ 200 переходит к этапу 230, на котором система 164 генерации DIR проверяет хранилище 168 идентификационных данных, генерирует DIR и передает этот DIR пользователю 110. В одной реализации система 164 генерации DIR сначала проверяет хранилище 168 идентификационных данных для определения, имеет ли данный пользователь право запрашивать DIR. Это может быть выполнено различными способами, включая проверку DLL внутри хранилища 168 идентификационных данных, выполнение проверки доступа компонентом Active Directory, и т.д. Система 164 генерации DIR может также иметь доступ к идентификационным системным метаданным, хранимым в хранилище 168 идентификационных данных для определения, какие типы идентификационных запросов доступны для включения в новое DIR.

Когда система 164 генерации DIR создает новое DIR, DIR может принять форму XML документа и может включать, среди прочей информации: картинку для отображения на пользовательской машине; список запросов, включенный в DIR, список имеющихся в наличии типов маркеров для DIR; уникальное удостоверение DIR; подсказку ввода персональных данных (далее обсуждается ниже); идентификацию провайдера идентификации; и ссылку на конечную точку для провайдера 115 идентификации. Новое DIR может быть получено пользователем также различными способами, включая извещение по электронной почте о новом DIR, сообщение в формате HTTP или другими способами. При использовании здесь термин "электронная почта" включает текстовые сообщения, мгновенные сообщения или подобные формы электронной коммуникации.

При получении нового DIR пользователь 110 сохраняет 240 DIR, например в памяти, связанной с пользовательской машиной 111. Пользователь 250 затем запрашивает доступ к проверяющей стороне, такой как проверяющая сторона 120. Проверяющая сторона отказывает в доступе (например, путем перенаправления на страницу идентификации) и дает 260 свою политику безопасности обратно пользователю 110. Пользователь 110 затем выбирает 270 DIR, удовлетворяющее политике безопасности проверяющей стороны 120. Это может быть выполнено, например, через пользовательский интерфейс на пользовательской машине 111, которая показывает пользователю все имеющиеся в наличии DIR. В некоторых реализациях DIR, которые удовлетворяют требованиям политики безопасности проверяющей стороны, могут подсвечиваться для пользователя 110, в то время как другие карты будут без подсветки для облегчения процесса выбора для пользователя 110.

Пользователь 110 затем посылает 280 запрос для маркера идентификации к провайдеру идентификации, такой как провайдер 115 идентификации. Этот запрос на маркер идентификации может быть сгенерирован автоматически пользовательской машиной 111 при выборе пользователем 110 DIR, сохраненного на пользовательской машине 111. Провайдер идентификации 115 проверяет 285 хранилище 168 идентификационных данных для получения требуемой информации для наполнения запрошенного маркера идентификации. Эта информация могла бы включать, например, данные о запросах. Например, если выбранное DIR включает в себя запрос о возрасте, провайдер 115 идентификации может проверить хранилище 168 идентификационных данных для определения возраста пользователя. Провайдер 115 идентификации после этого становится способным создавать 285 запрошенный маркер идентификации и посылать 290 его пользователю. Затем пользователь посылает 295 маркер идентификации принимающей стороне и получает доступ, как это обсуждалось ранее.

При предоставлении доступа провайдером 115 идентификации тому же самому хранилищу 168 идентификационных данных, используемых системой 164 генерации DIR, администратор может гарантировать, что сгенерированные DIR останутся синхронизированными с актуальными данными, имеющимися для заполнения запросов в запрошенном маркере идентификации. Например, администратор конфигурирует хранилище 168 идентификационных данных таким образом, что данные по запросу о возрасте не сохраняются там, и тогда система 164 генерации DIR не будет создавать DIR, что включено в виде опции в запросе на возраст. Иначе могут появиться проблемы синхронизации. Например, предположим, что администратор создает новое DIR заново (без учета имеющихся идентификационных данных) и запрос на возраст включен и посылается как часть DIR назад пользователю. Когда пользователь пытается получить маркер идентификации через запрос о возрасте, этой информации нет в наличии и маркер будет отвергнут проверяющей стороной как неполный. Система 100, напротив, позволяет автоматическую синхронизацию сгенерированных DIR и имеющихся в наличии выделенных данных для заполнения соответствующих маркеров идентификации. Администратор через систему 160 администрации получает права для внесения изменений в хранилище идентификационных данных, которые автоматически отражаются как на передаваемых DIR, так и на соответствующих выдаваемых маркеров идентификации.

В некоторых реализациях, когда администратор вносит определенные изменения в хранилище 168 идентификационных данных, которые влияют на соответствие уже выпущенных DIR, любые пользователи, у которых имеются принятые измененные DIR, извещаются об этом и получают разрешения на получение новых DIR. Например, предположим, что правила хранения личных данных требуют, чтобы администратор удалил домашние адреса любых пользователей, сохраненные в хранилище 168 идентификационных данных. Любой пользователь 110, который получил DIR, в которое включен запрос на его/ее домашний адрес, теперь обладает неподходящим DIR (потому что в хранилище 168 идентификационных данных больше нет никаких данных, которые удовлетворяли бы этому запросу). В одной реализации, все такие пользователи извещаются, например, через электронную почту системой 164 генерации DIR, о том, что DIR (или несколько DIR) теперь не подходят, а также получают приглашение получить новый DIR, который не включает более не поддерживаемый запрос на домашний адрес. В этом случае единственное изменение, вносимое администратором в хранилище 168 данных (a) предотвращает новые DIR от выдачи с запросом на домашний адрес и (b) оповещает пользователей, что существующие DIR, которые включают данный запрос, недействительны и могут быть заменены.

Обращаясь теперь к Фиг.3, увидим теперь, что пример способа 300 описан в связи с системой 100, показанной на Фиг.1. В данном примере пользователь 110 идентифицируется на пользовательской машине 111. Пользовательская машина 111, например, может быть связана с интранетом, который включает службу директорий, такую как сервер 169 Active Directory. Идентификация пользователя 110 на пользовательской машине 111 может включать использование информации о подписи, получаемой любым известным способом, включая имя/пароль, смарткарту и т.д. Пользователь 110 затем инициирует 320 запрос на DIR, путем, например, указывания браузеру на пользовательской машине 111 веб-сайта, который содержит систему 164 генерации DIR. Пользователь 110 затем идентифицируется 330 в системе 164 генерации DIR. В некоторых реализациях пользовательская машина 111, система 164 генерации DIR, хранилище 168 идентификационных данных, провайдер 115 идентификации и система 160 администрирования могут быть частью одной и той же внутренней сети. В некоторых реализациях возможна лишь одна подпись. Например, если на пользовательской машине запускается операционная система WINDOWS, поставляемая корпорацией Майкрософт из Редмонда, штат Вашингтон, и в ней включена опция интегрированной идентификации (Windows Integrated Authentication), то идентификация в системе 164 генерации DIR может быть автоматической и беспроблемной для пользователя 110. Информация, используемая для входа в пользовательскую машину 111, передается на систему 164 генерации DIR вместе с запросом на доступ. В других реализациях администратор может сконфигурировать систему 164 генерации DIR, чтобы затребовать отдельную идентификацию пользователя 110. Администратор может сконфигурировать систему 164 генерации DIR, чтобы требовать любой из множества идентификационных механизмов, включая имя/пароль, смарткарту и т.д. В некоторых реализациях пользователь 110 может быть идентифицирован сервером IIS 166, который может легко быть сконфигурирован администратором для принятия любого из различных идентификационных методов.

Как только пользователь 110 идентифицирован, система 164 генерации DIR получает доступ 350 к хранилищу 168 идентификационных данных. В этом примере система 164 генерации DIR принимает форму веб-сервиса, чтобы позволить переговоры между системой генерации DIR и пользователем 110. В данном примере переговоры определяют тип DIR, который будет возвращен пользователю 110. В этом случае система 164 генерации DIR получает 350 имеющиеся в наличии дескрипторы DIR. В примерах реализаций администратор использует систему 160 администрирования для создания дескрипторов DIR. Например, корпоративный системный администратор может создавать дескрипторы, которые представляют различные DIR для сотрудников различных уровней. Частично занятый сотрудник, например, может иметь набор запросов, отличающийся от набора у полностью занятого сотрудника. Исполнительный директор может иметь набор запросов, отличающийся от набора остальных сотрудников. Даже картинки, которые ассоциируются с каждым дескриптором DIR, могут различаться - например, для отдела продаж картинка в DIR может быть оранжевой, в то время как для отдела бухгалтерии картинка может быть зеленой. Кроме того, возможно персонализировать картинку на карте, которая содержит картинку пользователя 110 (полученную из хранилища 168 данных идентификации). Это улучшает связь, которую пользователь 110 формирует между его/ее DIR и провайдером 115 идентификации. Это также обеспечивает лучшую способность "отпечатков пальцев".

В некоторых реализациях система 160 администрирования включает пользовательский интерфейс, который анализирует все имеющиеся в наличии типы информации, имеющиеся в хранилище 168 идентификационных, данных и представляет администратору легкую возможность создания дескрипторов. Например, администратору может быть дан список с: (a) классами пользователей (например, не полностью занятый сотрудник, полностью занятый сотрудник, сотрудник исполнительной команды, сотрудник отдела продаж и т.д.), (b) типами запросов (имя, адрес, телефонный номер, возраст и т.д.); (c) уровень доступа; (d) положение в компании (действующий сотрудник, уволенный сотрудник); и т.д. Администратор затем может решить создавать некоторые отличительные дескрипторы, доступные для некоторых или всех классов пользователей. Например, все пользователи могут иметь право получить базовый DIR, который включает имя пользователя, его телефонный номер и положение в компании. Однако, только исполнительная команда может иметь право получить DIR, которое также включает высокоуровневый уровень доступа. Эти дескрипторы могут быть созданы администратором и сохранены в хранилище идентификационных данных вместе с политикой, описывающей, каким пользователям разрешено получать DIR, соответствующие конкретным дескрипторам. Возможные команды, которые могут быть полезными для администратора при менеджменте дескрипторов, включают в себя: "ПОЛУЧИТЬ ДЕСКРИПТОР, ПОЛУЧИТЬ ВСЕ ДЕСКРИПТОРЫ, ДОБАВИТЬ ДЕСКРИПТОРЫ, ИЗМЕНИТЬ ДЕСКРИПТОРЫ, УДАЛИТЬ ДЕСКРИПТОРЫ, СКОПИРОВАТЬ ДЕСКРИПТОР B и т.д.".

Запрос пользователя 110 на доступные дескрипторы может быть выполнен на пользовательской машине 111 через веб-сервис, такой, как "ПОЛУЧИТЬ ДЕСКРИПТОРЫ". Это приведет к тому, что система генерации DIR проверит пользователя в соответствии с политикой, установленной администратором, чтобы определить какие из дескрипторов (если таковые вообще есть) имеются в наличии для пользователя 110. Это может быть выполнено, например, через проверку доступа к Active Directory. Дескрипторы могут сохраняться либо по одному, либо все вместе, например в: хранилище 168 идентификационных данных, памяти, связанной с системой 164 генерации DIR или в отдельном хранилище.

Система 164 генерации DIR затем посылает 360 имеющиеся в наличии дескрипторы на пользовательскую машину 111. Затем пользователь 110 выбирает 370 из имеющихся в наличии дескрипторов и запрашивает конкретный DIR (несколько DIR), соответствующий данному дескриптору (дескрипторам). Также это может быть выполнено, например, с помощью использования веб-сервиса, такого, как "ПОЛУЧИТЬ КАРТУ (КАРТЫ)" (в качестве примера приведем Information Cards доступные в системе Windows CardSpace, распространяемой, по меньшей мере, как часть корпорацией Майкрософт из Редмонда, штат Вашингтон.). Пользователь 110 может запросить один или несколько имеющихся в наличии DIR.

Система 164 генерации DIR затем создает 380 запрошенное DIR (несколько DIR). В примерах реализаций система генерации DIR снова включает в DIR подсказку ввода персональных данных. Например, DIR может включать подсказку имени/пароля, и у пользователя 110 может быть затребована идентификация с использованием данного имени/пароля с целью использовать DIR для обладания маркером идентификации. В некоторых реализациях тип идентификации может быть взят из идентификации, использованной пользователем для получения доступа к системе 164 генерации DIR. Например, если пользователь 110 использовал комбинацию имени/пароля для идентификации в ISS 166, то система 164 генерации DIR может использовать те же самые имя и пароль для DIR, когда оно отсылается обратно пользователю.

В других реализациях система цифровой генерации может иметь доступ к службам директорий, таким как Active Directory 169, которая может включать другие доступные способы идентификации для конкретного пользователя 110. Например, если пользователь 110 использует имя/пароль для идентификации в системе 164 генерации DIR, но Active Directory также включает сертификат, связанный со смарткартой, зарегистрированной на пользователя 110, то система 164 генерации DIR может включать либо один, либо оба типа идентификации как часть DIR, возвращаемой пользователю 110. Кроме того, если включена возможность одной подписи между пользовательской машиной 111 и системой 164 генерации DIR, тип идентификации, который включает DIR, может быть типом идентификации, использованным пользователем 110 для идентификации на пользовательской машине 111.

Как только DIR (несколько DIR) сгенерированы системой 164 генерации DIR, они оправляются 390 пользователю 110 любым из множества способов, включающих электронную почту, HTTP и т.д. В некоторых реализациях файл, который включает DIR (несколько DIR) может быть защищен. Это необходимо потому, что, в частности, в случае, когда несколько DIR высылаются пользователю, то файл, содержащий DIR, может включать в себя материал криптографического ключа, который должен быть защищен от несанкционированного доступа. Эта защита позволяет установить разделяемую секретную информацию между пользовательской машиной и системой 164 генерации DIR. Файл, содержащий DIR (несколько DIR) затем может быть дешифрован пользователем при инсталляции DIR на пользовательскую машину. Примеры способов инициирования, одобрения и отправки DIR обсуждаются ниже.

Теперь обратимся к Фиг.4, на котором проиллюстрирован способ 400. На этапе 410 через первый канал принимается запрос на создание DIR. Например, пользователь 110 может использовать интернет браузер на пользовательской машине 111 для запроса нового DIR у системы 164 генерации DIR. На этапе 420 через второй канал выдается 420 оповещение о запросе на DIR. Например, в ответ на запрос пользователя 110 о новом DIR система 164 генерации DIR или приложение, запущенное на пользовательской машине 111 может выслать оповещение по электронной почте, о том, что был сделан запрос. Это нужно для того, чтобы убедиться, что пользователь 110 - именно тот, кто запросил DIR, а не злоумышленник. В некоторых реализациях это сообщение по электронной почте может быть направлено на известный адрес электронной почты пользователя. В других реализациях оповещение может быть направлено третьему лицу, которое может в соответствии с политикой администрирования иметь обязанность одобрить выдачу нового DIR для конкретного пользователя 110. Например, некоторые DIR могут иметься в наличии для конкретных сотрудников в организации только, если их руководители одобрили эту выдачу. DIR этого типа может быть использовано, например, для предоставления доступа к конфиденциальной рабочей группе.

В данной работе термин "канал" ссылается на способ, которым информация передается при выдаче. Различия между разными каналами в способе 400 являются логическими. Два различных канала могут использовать некоторые или даже все те же самые физические или электрические коммуникационные связи или различные пути одновременно. Например, оповещение на этапе 420 может быть послано через ту же коммуникационную связь (например, Интернет), что и одобрение на этапе 430, но каналы могут быть логически разными (например, один из них может быть сообщением по электронной почте, а другой - сообщением в формате HTTP).

На этапе 430 принимается одобрение на создание DIR. Например, получатель оповещения на этапе 420 от системы 364 генерации DIR может ответить и одобрить выдачу запрошенного DIR. Это может быть выполнено разными способами. Например, оповещение на этапе 420 может содержать сообщение электронной почты со ссылкой на одобренный сайт, которым владеет система 364 генерации DIR.

На этапе 440 создается запрошенный DIR. Если одобрение было отклонено получателем оповещения на этапе 420, могут произойти другие события. Например, администратор может быть оповещен, что был сделан несанкционированный запрос на DIR.

Обратимся к Фиг.5, показывающей другой пример способа 500. На этапе 510 выдается оповещение о наличии DIR для пользователя. Например, система 364 генерации DIR может послать пользователю 110 сообщение по электронной почте, извещающее пользователя 110, что новое DIR имеется в наличии. Как вариант, оповещение может уйти к третьему лицу, такому, как руководитель пользователя. Этот тип оповещения может быть полезным в ситуации, когда администратор, например, поменял хранилище 168 идентификационных данных, включив туда дополнительный дескриптор. Система 364 генерации DIR может быть в этом случае использована для оповещения всех пользователей в классе, к которому принадлежит данный дескриптор, что новый DIR появился в наличии. Например, руководитель конкретного подразделения может запросить администратора создать новый дескриптор для DIR, для использования в конкретном проекте. Как только администратор создает этот дескриптор, пользователи, которым их руководитель хочет предоставить новые DIR, оповещаются автоматически.

Оповещение 510 может также быть включено как часть общего бизнес-процесса. Например, когда новый пользователь выходит на работу в организации, отдел кадров может собрать информацию об этом пользователе через систему 162 сбора данных. При сборе данных можно опустить серию автоматических этапов, включая сохранение релевантных идентификационных данных, относящихся в хранилище 168 данных к данному пользователю, и оповещение пользователя 110 о наличии DIR для него/нее. Оповещение может иметь различные формы, включая сообщение по электронной почте для пользователя, которое включает ссылку на веб-сайт, который содержит систему 164 генерации DIR. Как вариант на машине пользователя 111 может быть запущено приложение, адаптированное для приема сообщения от системы 164 генерации DIR о том, что новое DIR доступно для пользователя 110 (например, приложение может выдавать всплывающее сообщение, либо в панели с инструментами на пользовательской машине 111 может появиться иконка, и т.д.).

На этапе 520 принимается запрос на создание DIR. Этот этап может быть выполнен опять же различными способами. Например, пользователь 110 может ответить на электронное письмо с оповещением нажатием на ссылку, которая приводит его на веб-страницу, которая дает пользователю возможность запросить DIR. Как вариант, там, где на пользовательской машине 111 пользователя 110 извещает о наличии DIR извещает работающее на ней приложение, пользователь может запросить DIR через такое приложение, и это приложение может послать сообщение системе 364 генерации DIR для выполнение запроса.

На этапе 530 создается DIR в соответствии с запросом. Создание DIR может быть выполнено так, как это описано в других местах в данной работе. Затем DIR посылается 540 пользователю так же, как описано в других местах в этой работе.

Обратимся теперь к Фиг.6, на которой показан другой пример способа 600. На этапе 610 система генерации DIR опрашивается на наличие для пользователя нового DIR. Например, пользовательская машина 111 может быть запрограммирована на периодический опрос системы 164 генерации DIR на предопределенных интервалах. На этапе 620 определяется наличие для пользователя каких-либо новых DIR. Система 164 генерации DIR, например, может проверить хранилище 168 идентификационных данных на появление новых дескрипторов для пользователя с момента, когда она была последний раз опрошена на пользовательской машине 111. На этапе 639 выполняется запрос на создание нового DIR. Данный пример продолжается тем, что по получении извещения о появлении в наличии нового DIR пользователь 110 может послать запрос системе 164 генерации DIR на создание нового DIR. На этапе 640 происходит прием нового DIR (например, новое DIR, посланное системой 164 генерации DIR, может быть принято на пользовательской машине 111). Способ 600 является другим примером упрощения работы администратора. Если все пользовательские машины запрограммированы на опрос на наличие новых DIR, например, когда администратор создает новый дескриптор DIR в хранилище 168 идентификационных данных, выдача и доставка новых DIR является автоматической и не требуют от администратора каких-либо дальнейших усилий.

Также может быть выгодным иметь возможность создавать DIR динамически в ответ на политику безопасности проверяющей стороны. Обратимся теперь к Фиг.7, иллюстрирующей пример способа 700. На этапе 710 запрашивается доступ к проверяющей стороне. Например, если проверяющая сторона 120 является веб-сайтом с ограниченным доступом, пользовательская машина 111 пытается получить доступ к этому веб-сайту через браузер. На этапе 720 отклоняется доступ к проверяющей стороне и принимается политика безопасности проверяющей стороны. В продолжение данного примера проверяющая сторона 120 посылает на пользовательскую машину 111 свою политику безопасности и HTTP сообщение, которое перенаправляет браузер пользовательской машины 111 на страницу идентификации. Затем у системы генерации DIR запрашивается 730 DIR, которое удовлетворяет политике безопасности. В приведенном выше примере пользовательская машина 111 может сначала проверить, имеется ли в наличии подходящее DIR и, если его нет, пользовательская машина 111 может быть запрограммирована на запрос в локальный кэш для провайдеров идентификации, которые предлагают DIR, удовлетворяющие политике безопасности проверяющей стороны 120. Пользовательская машина может также запросить публичный список провайдеров DIR, принадлежащих третьему лицу. Пользователь 110 может затем выбрать подходящего провайдера DIR и систему генерации DIR, такую как система 164 генерации DIR. На этапе 740 происходит получение этого DIR. В приведенном выше примере пользовательская машина 111 получает новое DIR, которое она потом может послать провайдеру 115 идентификации, чтобы получить необходимый маркер идентификации для получения доступа к проверяющей стороне 120.

В некоторых реализациях пользовательская машина 111 может направить политику безопасности проверяющей стороны 120 системе 164 генерации DIR. Система 164 генерации DIR может затем проверить хранилище 168 идентификационных данных для определения, могут ли быть удовлетворены запросы или другие требования в политике безопасности. Если это так, то создаются DIR, удовлетворяющие политике безопасности. В этом случае пользователь может получить DIR по мере необходимости, независимо от того, сконфигурировал ли администратор заранее дескриптор идентификации, который соответствует требованиям политики безопасности данной конкретной проверяющей стороны.

Теперь обратимся к Фиг.8, показывающей другой пример способа 800. На этапе 810 устанавливается политика для группы пользователей и идентифицируется группа пользователей, для которой доступно DIR. Как показано в примере системы 100 на Фиг.1, при идентифицировании всех пользователей, являющихся частью определенной группы, которая должна получить определенное DIR, администратор может использовать систему администрирования для установки политики в хранилище 168 идентификационных данных. В некоторых реализациях это может быть выполнено администратором с использованием свойства "Групповая политика", имеющегося в Active Directory 169, либо другие средства для запуска резидентного клиентского приложения на пользовательской машине 111. На этапе 820 происходит оповещение группы пользователей, для которой доступно DIR. В приведенном выше примере активируется резидентное клиентское приложение на пользовательской машине 111. В результате этого пользователю может быть выдана подсказка о том, что доступно DIR (например, через всплывающее окно, иконку на панели инструментов и т.д.). Клиентское приложение может иметь свой собственный набор правил (например, возможность для пользователя 110 выбрать, чтобы напоминание происходило позднее; предоставление пользователю 110 определенного временного интервала для извлечения DIR; и т.д.). На этапе 830 принимается запрос на создание DIR от хотя бы одного пользователя в группе пользователей. В некоторых реализациях это может сопровождаться тем, что пользователь авторизирует создание DIR через резидентное клиентское приложение на пользовательской машине 111. В других реализациях клиентское приложение может запросить DIR без дальнейшего участия пользователя 110. На этапе 840 создается DIR для первого пользователя.

Фиг.9 иллюстрирует вычислительное устройство 900 общего назначения (называемое здесь также "компьютером" или "компьютерной системой"), которое может быть использовано для реализации описанных здесь вариантов. Компьютерное устройство 900 представляет только один пример вычислительной среды и не имеет целью задать какие-либо ограничения в объеме использования или функциональности компьютерной или сетевой архитектуры. Таким же образом и вычислительное устройство не задает какую-либо зависимость или требование, относящиеся к одному компоненту или комбинации компонентов, показанных в примере вычислительного устройства 900. На практике вычислительное устройство 900 может быть использовано, например, как пользовательская машина 111, система 164 генерации DIR, система 162 сбора данных, IIS 166, хранилище 168 идентификационных данных, Active Directory 169, система 160 администрирования, провайдер 115 идентификации или проверяющая сторона 120, как это описано выше и показано на Фиг.1.

В наиболее общей конфигурации вычислительное устройство 900 обычно включает хотя бы один модуль 902 обработки и память 904. В зависимости от точной конфигурации и типа вычислительного устройства память 904 может быть энергозависимой (такой, как оперативная память RAM), энергонезависимой (такой, как постоянная память ROM, флэш-память и т.д.) или комбинацией двух этих типов памяти. Наиболее общая конфигурация показана на Фиг.9 пунктирной линией 906. Системная память 904 хранит приложения, которые выполняются на вычислительном устройстве 900. Кроме того, память 904 может также хранить информацию, используемую в операциях, выполняемых вычислительным устройством 900, таких как запрос 910 на создание DIR и/или извещение 911 о доступности DIR, как описано ниже и показано на рисунках с Фиг.1 по Фиг.8.

Кроме того, компьютерное устройство 900 может также иметь дополнительные свойства и дополнительную функциональность. Например, вычислительное устройство 900 может также включать дополнительное хранилище 908 (съемное или несъемное), включая (но не ограничивая данный список) магнитные диски, оптические диски или пленку. Такое дополнительное хранилище показано на Фиг.9 в виде хранилища 908. Компьютерные носители данных включают энергозависимые и энергонезависимые, съемные и несъемные носители, реализованные любым способом или с использованием любой технологии хранения информации, такой как машиночитаемые инструкции, структуры данных, программные модули или другие данные. Память 904 и хранилище 908 являются примерами компьютерных носителей данных. Компьютерные носители данных включают (не ограничиваясь данным списком) память RAM, память ROM, память EEPROM, флэш-память или другие технологии памяти, CD-ROM, цифровые диски универсального назначения (DVD) или другие оптические накопители, магнитные кассеты, магнитную ленту, накопитель на магнитном диске или другие магнитные накопительные устройства либо любой другой носитель, который может быть использован для хранения желаемой информации и который может быть доступен через вычислительное устройство 900. Любые подобные компьютерные носители и накопители могут быть частью вычислительного устройства 900.

Специалистам в данной области должно быть понятно, что хранилище 908 может хранить различные виды информации. Среди других типов данных хранилище 908 может хранить цифровое удостоверение 930 (например, в случае пользовательской машины) или маркер 945 идентификации (например, в случае провайдера идентификации).

Вычислительное устройство 900 может также содержать коммуникационную связь (связи) 912, которые позволяют системе сообщаться с другими устройствами. Коммуникационная связь (связи) 912 являются примером средств коммуникации. Средства коммуникации обычно содержат машиночитаемые инструкции, структуры данных, программные модули или другие данные в виде модулированного сигнала данных, такого как несущая волна или другого транспортного механизма, и включают любые средства доставки информации. Термин "модулированный сигнал данных" означает, сигнал, одна или несколько характеристик которого задана или изменена таким образом, что с ее помощью кодируется информация в сигнале. В качестве примера (но не ограничения) могут служить средства коммуникации, которые могут включать проводные средства, такие как проводная сеть или прямое проводное соединение, и беспроводные средства, такие как акустические, радио, инфракрасные и другие средства беспроводной передачи. Термин "машиночитаемые носители данных" в данной работе включает как средства хранения, так и средства передачи.

Вычислительное устройство 900 может также иметь устройство(а) 914 ввода, такое как клавиатура, мышь, электронный карандаш, устройство голосового ввода, сенсорное устройство ввода и т.д. Устройство(а) 916 вывода, такие как дисплей, колонки, принтер и т.д. могут также быть включены. Все эти устройства хорошо известны в данной сфере деятельности, и нет смысла обсуждать их здесь дальше.

Различные реализации, описанные выше, даны только в качестве иллюстраций, и их не надо рассматривать, как ограничения. Специалисты в данной области уверенно распознают различные модификации и изменения, которые могут быть сделаны в описанных выше реализациях без ухода от сущности и объема данного описания изобретения или последующей формулы изобретения.