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

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

Иллюстрации

Показать все

Реферат

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

Колоссальные инновации в последнее время происходят в разработке систем для того, чтобы предоставлять людям больше контроля над тем, как их персональная идентификационная информация распределяется и используется, в частности, в цифровом контексте. Например, Корпорация 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 к хранилищ