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

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

1. Система для предоставления цифрового представления идентификации для участника, содержащая:

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

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

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

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

2. Система по п.1, в которой система формирования цифрового представления идентификации дополнительно выполнена с возможностью:

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

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

принимать подтверждение на создание цифрового представления идентификации.

3. Система по п.1, в которой система формирования цифрового представления идентификации дополнительно выполнена с возможностью:

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

принимать запрос на создание одного или более цифровых представлений идентификации.

4. Система по п.1, дополнительно содержащая машину участника, при этом машина участника выполнена с возможностью:

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

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

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

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

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

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

9. Система по п.1, дополнительно содержащая:

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

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

10. Способ предоставления цифрового представления идентификации для участника, содержащий этапы, на которых:

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

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

посылают цифровое представление идентификации на машину участника.

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

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

13. Способ по п.10, дополнительно содержащий этап, перед этапом аутентификации, на котором выдают участнику уведомление о том, что цифровое представление идентификации доступно для участника.

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

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

- принимают подтверждение на формирование цифрового представления идентификации.

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

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

17. Способ предоставления цифрового представления идентификации для участника, содержащий этапы, на которых:

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

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

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

создают, по меньшей мере, первое цифровое представление идентификации.

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

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

принимают подтверждение на формирование первого цифрового представления идентификации.

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

Уровень техники

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

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

Сущность изобретения

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

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

Другой аспект относится к способу для предоставления DIR для участника. Способ включает в себя аутентификацию участника в системе формирования DIR с помощью информации регистрации в системе, такой как имя пользователя и пароль. Способ дополнительно включает в себя прием запроса на DIR и формирование запрошенного 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 идентификации включает в себя компьютерную систему. В примерных вариантах осуществления поставщик 115 идентификации включает в себя преобразователь 130 заявлений и центр 140 подтверждения заявлений. Преобразователь 130 заявлений иногда называют "служба маркера безопасности". В показанном примере поставщик 115 идентификации может предоставлять одно или более заявлений об участнике 110. Заявление - это высказывание или утверждение, сделанное об участнике, возможно, включающее информацию об участнике, такую как, например, имя, адрес, номер социального страхования, возраст, кредитная история, деловые качества и т.д. Как описано дополнительно ниже, поставщик 115 идентификации может предоставлять заявления участнику 110 и/или проверяющей стороне 120 в форме маркера идентификации с цифровой подписью. В примерных вариантах осуществления поставщик 115 идентификации имеет доверенные взаимоотношения с проверяющей стороной 120, так что проверяющая сторона 120 доверяет заявлениям в подписанном маркере защиты от поставщика 115 идентификации.

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

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

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

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

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

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

В ответ на запрос проверяющая сторона 120 может отправлять машине 111 участника требования проверяющей стороны 120 для того, чтобы аутентифицировать идентификацию или другую информацию об участнике 110. Требования проверяющей стороны 120 для аутентификации называются в данном документе политикой безопасности. Политика безопасности минимально задает набор заявлений от доверенного поставщика 115 идентификации, который участник 110 должен предоставлять проверяющей стороне 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 (иногда называемые "информационными картами" в системе Windows CardSpace, предоставляемой в инфраструктуре.NET 3.0, разработанной Корпорацией Microsoft из Редмонда, штат Вашингтон) являются средствами идентификации, которые представляют взаимосвязь выдачи маркеров между участником 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 заявлений поставщика 115 идентификации запрограммирован так, чтобы преобразовывать заявления и формировать один или более подписанных маркеров 150 идентификации, которые включают в себя заявление(я), касающиеся участника 110.

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

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

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

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

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

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

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

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

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

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

Способ 200 затем переходит к этапу 230, где система 164 формирования DIR сверяется с хранилищем 168 идентификационных данных, формирует DIR и предоставляет DIR участнику 110. В одном варианте осуществления система 164 формирования DIR сначала сверяется с хранилищем 168 идентификационных данных, чтобы определять, предоставлено ли участнику 110 право на запрошенное 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 для участника 110. В некоторых вариантах осуществления, DIR, которые удовлетворяют требованиям политики безопасности проверяющей стороны, могут быть выделены оформлением для участника 110, а другие карты могут быть недоступны для выбора, чтобы сделать процесс выбора проще для участника 110.

Участник 110 затем отправляет 280 запрос на маркер идентификации поставщику идентификации, такому как поставщик 115 идентификации. Этот запрос на маркер идентификации может быть сформирован автоматически посредством машины 111 участника после выбора участником 110 DIR, сохраненного на машине 111 участника. Поставщик 115 идентификации проверяет 285 хранилище 168 идентификационных данных, чтобы получать запрошенную информацию, чтобы заполнять запрошенный маркер идентификации. Эта информация может включать в себя, например, данные заявлений. Например, если выбранное DIR включает в себя заявление возраста, поставщик 115 идентификации может проверять хранилище 168 идентификационных данных, чтобы определять возраст участника 110. Поставщик 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, которое не включает в себя более неподдерживаемое заявление домашнего адреса. Таким образом, одно изменение администратором в хранилище 168 идентификационных данных (a) препятствует выдаче новых DIR с заявлением домашнего адреса и (b) оповещает участников о том, что существующие DIR, которые включают в себя это заявление, являются недопустимыми и могут быть заменены.

Ссылаясь теперь на фиг.3, примерный способ 300 описывается относительно системы 100, показанной на фиг.1. В этом примере участник 110 аутентифицируется на машине 111 участника. Машина 111 участника, например, может быть подключена к сети intranet, которая включает в себя службу каталогов, такую как сервер 169 Active Directory. Аутентификация участника 110 на машине 111 участника может включать в себя информацию регистрации в системе с помощью от любого известного способа, включая имя и пароль пользователя, смарт-карту и т.д. Участник 110 затем инициирует 320 запрос на DIR, например, посредством направления обозревателя на машине 111 участника на веб-узел, который содержит систему 164 формирования DIR. Участник 110 далее аутентифицируется 330 в системе 164 формирования DIR. В некоторых вариантах осуществления машина 111 участника, система 164 формирования DIR, хранилище 168 идентификационных данных, поставщик 115 идентификации и система 160 администратора могут быть частью одной сети intranet. В этом варианте осуществления существует возможность того, что поддержка одной регистрации в системе может быть доступна. Например, если машина участника работает под управлением операционной системы WINDOWS, предлагаемой Корпорацией Microsoft из Редмонда, штат Вашингтон, и Windows-средства аутентификации активированы, то аутентификация в системе 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 отдела продаж может быть оранжевым, тогда как изображение DIR отдела бухгалтерии является зеленым. Дополнительно, можно персонифицировать изображение карты так, чтобы содержать изображение участника 110 (полученное из хранилища 168 идентификационных данных). Это повышает ассоциативную связь, которую участник 110 создает между своим DIR и поставщиком 115 идентификации. Это также предоставляет оптимизацию возможностей "метода отпечатков пальцев".

В некоторых вариантах осуществления система 160 администратора включает в себя пользовательский интерфейс, который синтаксически анализирует все доступные типы информации, содержащейся в хранилище 168 идентификационных данных, и представляет администратору простой способ создавать дескрипторы. Например, администратору может быть представлен список из следующего: (a) классы участников (к примеру, сотрудник с неполным рабочим днем, штатный сотрудник, руководящий сотрудник, сотрудник отдела продаж и т.д.); (b) типы заявлений (имя, адрес, телефонный номер, возраст и т.д.); (c) уровни защиты; (d) статус занятости (работает, уволен); и т.д. Администратор затем может решать создавать различные дескрипторы, доступные для некоторых или всех классов участников. Например, все участники могут иметь право принимать основное DIR, которое включает в себя имя, телефонный номер и статус занятости участника. Тем не менее, только руководящие сотрудники могут иметь право принимать DIR, которое также включает в себя высокий уровень безопасности. Эти дескрипторы могут быть созданы администратором и сохранены в хранилище идентификационных данных наряду с политикой, разграничивающей то, каким участникам разрешено принимать DIR, соответствующие конкретным дескрипторам. Возможные команды, которые могут быть полезными для администратора при администрировании дескрипторов, включают в себя: GET DESCRIPTORS, GET ALL DESCRIPTORS, ADD DESCRIPTORS, CHANGE DESCRIPTORS, DELETE DESCRIPTORS, COPY DESCRIPTOR и т.д.

Запрос участником 110 на предмет доступных дескрипторов может быть выполнен посредством машины 111 участника через метод веб-службы, такой как GET DESCRIPTORS. Это должно инструктировать системе формирования DIR сверять участника 110 с политикой, заданной администратором, чтобы определять то, какие, если таковые имеются, дескрипторы доступны для этого участника 110. Это может быть выполнено, к примеру, через проверку прав доступа в Active Directory. Дескрипторы могут быть сохранены, к примеру, в любом или во всех из следующего: хранилище 168 идентификационных данных, запоминающее устройство, ассоциированное с системой 164 формирования DIR, или отдельное хранилище.

Система 164 формирования DIR затем отправляет 360 доступные дескрипторы на машину 111 участника. После этого участник 110 выбирает 370 из доступных дескрипторов и запрашивает конкретное DIR, соответствующее дескрипторам. С другой стороны, это может быть выполнено, например, посредством такого метода веб-службы, как GET CARD(s) (ссылаясь в данном примере на информационные карты, доступные в системе Windows CardSpace, распространяемой, по меньшей мере, частично Корпорацией Microsoft из Редмонда, штат Вашингтон). Участник 110 может запрашивать одно или несколько доступных DIR.

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

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

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

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

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

На этапе 430 подтверждение для DIR, которое должно быть создано, принимается. Например, получатель уведомления на этапе 420 от системы 364 формирования DIR может отвечать и подтверждать выдачу запрошенного DIR. Это может быть выполнено множеством способов. Например, уведомление на этапе может содержать почтовое сообщение со ссылкой на веб-узел подтверждения, назначенный посредством хоста системой 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 идентификационных данных то, стали ли какие-либо новые дескрипторы доступными для участника 110 со времени, когда он последний раз опрошен посредством машины 111 участника. На этапе 630 выполняется запрос на то, чтобы создавалось новое DIR. Продолжая пример, по получении уведомления о том, что новое DIR доступно, участник 110 может запрашивать, чтобы система 164 формирования DIR создавала новое DIR. На этапе 640 новое DIR принимается (к примеру, новое DIR может быть принято посредством машины 111 участника от системы 164 формирования DIR). Этот способ 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 администратор может использовать систему администратора для того, чтобы задавать политику в хранилище 168 идентификационных данных, авторизующую всех участников, которые являются частью конкретной группы, на то чтобы принимать конкретное DIR. В некоторых вариантах осуществления это может быть выполнено администратором с использованием функции групповой политики, доступной в Active Directory 169, или другого средства для того, чтобы запускать клиентское приложение, резидентно размещающееся на машине 111 участника. На этапе 820 группа участников, для которых DIR доступно, уведомляется. В примере выше клиентское приложение, резидентно размещающееся на машине 111 участника, активируется. Это может приводить к оповещению участника 110 о том, что DIR теперь доступно (к примеру, через всплывающее сообщение, значок панели инструментов и т.д.). Клиентское приложение может иметь собственный набор правил (к примеру, возможность для участника 110 выбирать то, чтобы напоминание выдавалось позже, предоставлять участнику 110 только определенное количество времени на то, чтобы извлекать новое DIR, и т.д.). На этапе 830 запрос, по меньшей мере, от первого участника в группе участников принимается, чтобы создавать DIR. В некоторых вариантах осуществления он может влечь за собой авторизацию пользователем создание DIR через клиентское приложение, резидентно размещающееся на машине 111 участника. В других вариантах осуществления клиентское приложение может запрашивать DIR без дополнительного участия участника 110. На этапе 840 DIR создается для первого участника.

Фиг.9 иллюстрирует общее вычислительное устройство 900 (также упоминаемое в данном документе как компьютер или компьютерная система), которое может использоваться для того, чтобы реализовать варианты осуществления, описанные в данном документе. Вычислительное устройство 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 связи являются примером среды связи. Среды связи типично содержат машиночитаемые инструкции, структуры данных, программные модули или другие данные в модулированном сигнале данных, таком как несущее колебание или другой механизм распространения, и включают в себя любой носитель для доставки информации. Термин "модулированный информационный сигнал" означает сигнал, который обладает одной или несколькими характеристиками, заданными или измененными таким образом, чтобы кодировать информацию в сигнале. В качестве примера, а не ограничения, среды связи включают в себя проводные среды, такие как проводная сеть или прямое проводное соединение, и беспроводные среды, такие как акустическая, РЧ (радиочастотная, RF), инфракрасная и другие беспроводные среды. Термин "машиночитаемые носители" при использовании в данном документе включает в себя как носители хранения, так и среды связи.

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

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