BRPI0806465A2 - provisão de represaentações de identidade digital - Google Patents

Abstract

PROVISãO DE REPRESENTAçõES DE IDENTIDADE DIGITAL. Um sistema e método para a provisão de representações de identidade digital ("DIR") utilizam várias técnicas e estruturas para facilitar a administração, aumentar a precisão, e diminuir as incoerências de um sistema de provisão de identidade digital. São providos diversos métodos para a criação de novas representações DIR, para a notificação de partes principais sobre representações DIR disponíveis, e aprovação de emissão de novas representações DIR.

Description

"PROVISÃO DE REPRESENTAÇÕES DE IDENTIDADE DIGITAL"

FUNDAMENTOS DA INVENÇÃO

Recentemente, tem-se observado uma formidável inovação no desenvolvimento de sistemas no sentido de oferecer às pessoas um controle cada vez maior sobre a maneira como suas informações de identidade pessoal são distribuídas e utilizadas, especialmente em um contexto digital. Por exemplo, a Microsoft Corporation, de Redmond, Washington, entre outras empresas, tem propagado um sistema por vezes referido como Seletor de Car- tão de Informação - uma instanciação da Microsoft referida como Windows CardSpace. Em um sistema Windows CardSpace, uma parte principal obtém uma ou mais representações de identidade digital, por vezes referidas como cartões de informação. Quando a parte prin- cipal tenta acessar um recurso (uma "parte confiante") que solicita um conjunto de declara- ções feitas sobre a parte principal, a parte principal emprega uma representação de identi- dade digital (doravante designada como "DIR") a fim de inicializar comunicação com um provedor de identidade que poderá assegurar essas declarações. Em alguns casos, o pro- vedor de identidade pode ser controlado por uma parte principal e executado na própria má- quina da parte principal. Outrossim, ele poderá ser controlado por uma terceira parte. O pro- vedor de identidade retorna uma "ficha de identidade", que inclui as informações de declara- ção solicitadas.

Pouca atenção tem sido dirigida, no entanto, à criação e provisão de representa- ções DIR. Atualmente, os administradores de sistemas de identidade digital são forçados a incorporar manualmente as representações DIR. Por exemplo, um administrador pode usar manualmente um software utilitário, tal como um gerador de linguagem XML1 para incorporar uma representação DIR e salvá-la em uma localização específica. O administrador poderá então enviar à parte principal um ponteiro para a representação DIR, e a parte principal, en- tão, irá recuperar a representação DIR. Este sistema fica ad hoc, sujeito a erros e vulnerabi- lidades de segurança, e se torna um trabalho intensivo para o administrador.

SUMÁRIO DA INVENÇÃO

Este sumário é provido de modo a introduzir uma seleção de conceitos, de uma forma simplificada, que serão descritos mais adiante, na seção Descrição Detalhada. Este sumário não se destina a identificar os aspectos principais ou as características essenciais da matéria reivindicada, nem se destina a ser utilizado como um auxílio na determinação do âmbito de aplicação da matéria reivindicada.

Um aspecto diz respeito a um método para a provisão de uma representação DIR para uma parte principal. Um primeiro canal envia uma solicitação, por exemplo, uma solici- tação de protocolo HTTP, no sentido de criar uma representação DIR para uma parte princi- pal. Um segundo canal, em seguida, envia uma notificação, por exemplo, um e-mail, de que uma representação DIR foi solicitada. Uma aprovação da representação DIR a ser criada é então recebida antes de a representação DIR ser criada.

Outro aspecto diz respeito a um outro método para a provisão de uma representa- ção DIR para uma parte principal. É emitida uma notificação para a parte principal de que a representação DIR se encontra disponível. Uma solicitação para criar uma representação DIR é então recebida antes de a representação DIR ser criada.

Outro aspecto se refere ainda a um outro método para a provisão de uma represen- tação DIR para uma parte principal. Um sistema de geração de representação DIR é consul- tado (por exemplo, por um aplicativo executável na máquina da parte principal) a fim de de- terminar se outras representações DIR diferentes se encontram disponíveis à parte principal.

Em seguida, é determinado se uma nova representação DIR se encontra disponível para a parte principal. Caso positivo, é enviada uma solicitação para a nova representação DIR a ser criada. Finalmente, a nova representação DIR é recebida.

Um outro aspecto se refere a um método para a provisão de uma representação DIR para um grupo de partes principais. É definida uma representação diretiva de que o grupo de partes principais pode ter acesso à representação DIR. O grupo de partes princi- pais é em seguida notificado de que a representação DIR se encontra disponível. Em segui- da, pelo menos uma primeira parte principal do grupo de partes principais envia uma solici- tação no sentido de criar a representação DIR. Por último, uma representação DIR é criada para pelo menos a primeira parte principal.

BREVE DESCRIÇÃO DOS DESENHOS

A seguir, será feita referência aos desenhos em anexo, que não necessariamente foram feitos em escala, e nos quais:

A Figura 1 ilustra um sistema de representação DIR exemplar incluindo uma parte principal, uma máquina principal, uma parte confiante, um provedor de identidade, um sis- tema de geração de representação DIR, um armazenador de dados de identidade, um sis- tema administrador, e um sistema de captura de dados;

A Figura 2 ilustra um método exemplar para a provisão e uso de uma representação DIR;

A Figura 3 mostra um outro método exemplar para a provisão e uso de uma repre- sentação DIR;

A Figura 4 ilustra um outro método exemplar para a provisão de uma representação DIR;

A Figura 5 ilustra um método exemplar para a provisão de uma representação DIR;

A Figura 6 ilustra um ilustra um método exemplar para a provisão de uma represen- tação DIR;

A Figura 7 ilustra um ilustra um outro método exemplar para a provisão de uma re- presentação DIR; A Figura 8 ilustra um outro método exemplar para a provisão de uma representação DIR; e

A Figura 9 ilustra um exemplo de um dispositivo computacional.

DESCRIÇÃO DETALHADA DA INVENÇÃO

A seguir, serão descritas modalidades exemplares em mais detalhes, com referên- cia aos desenhos em anexo.

As modalidades exemplares aqui apresentadas se referem, de modo geral, a siste- mas de identificação incluindo as representações DIR utilizadas no início da comunicação para a produção de fichas de identidade que podem ser trocadas entre uma parte principal, um provedor de identidade, e uma parte confiante para autenticar uma identidade e/ou in- formações relativas à parte principal. Nas modalidades exemplares do presente documento, a parte principal pode ser uma pessoa ou pessoas naturais, um computador, uma rede, ou qualquer outra entidade. A parte confiante possui bens, serviços ou outras informações que a parte principal deseja acessar e/ou obter. Nas modalidades exemplares, a partè confiante pode ser qualquer recurso, privilégio, ou serviço que requer uma diretiva de segurança para entrar, acessar ou utilizar. Por exemplo, uma parte confiante pode compreender um ou mais dentre: computadores, redes de computador, dados, bancos de dados, prédios, pessoal, serviços, empresas, organizações, locais físicos, dispositivos eletrônicos, ou qualquer outro tipo de recurso.

Com referência, a seguir, à Figura 1, um sistema de representação DIR exemplar 100 é mostrado, incluindo uma parte principal 110 e uma parte confiante 120. A parte princi- pal 110 fica de posse ou controle da máquina principal 111. A máquina principal 111 inclui um sistema computacional, pelo menos temporariamente controlado pela parte principal 110. A parte confiante 120 pode também incluir um sistema computacional 100. O sistema 100 pode incluir também um sistema administrador 160, um sistema de captura de dados 162, um sistema de geração de representação DIR 164, e um armazenador de dados de identidade 168, e um provedor de identidade 115, cada um dos quais sendo apresentados mais adiante e podem incluir, ou fazer parte de, um sistema de computador.

A parte principal 110 e a parte confiante 120 podem se comunicar entre si por meio de uma ou mais redes, como a Internet, ou através de comunicação telefônica ou outras formas de comunicação com ou sem fio. Nas modalidades exemplares, a parte principal 110 pode solicitar bens, serviços, informações, privilégios, ou outro acesso a partir de uma parte confiante 120. A parte confiante 120 pode solicitar a autenticação da identidade de, ou in- formações sobre, uma parte principal 110 antes ou em conjunto com a provisão do acesso solicitado à parte principal 110.

É também mostrado na Figura 1 um provedor de identidade 115 exemplar. O pro- vedor de identidade 115 inclui um sistema de computador. Nas modalidades exemplares, o provedor de identidade 115 inclui um transformador de declarações 130 e uma autoridade de declarações 140. O transformador de declarações 130 é por vezes referido como um "serviço de ficha de segurança". No exemplo apresentado, o provedor de identidade 115 pode prover uma ou mais declarações sobre a parte principal 110. Uma declaração é uma afirmação ou asserção feita sobre a parte principal, possivelmente incluindo informações sobre a parte principal, como, por exemplo, nome, endereço, número de segurança social, idade, histórico de declarações, solicitações transacionais, etc. Tal como descrito mais adi- ante, o provedor de identidade 115 pode prover declarações para a parte principal 110 e/ou para a parte confiante 120 sob a forma de uma ficha de identidade digitalmente assinada. Nas modalidades exemplares, o provedor de identidade 115 se encontra em uma relação de confiança com a parte confiante 120, e a parte confiante 120 confia nas declarações da ficha de identidade assinada do provedor de identidade 115.

Embora o transformador de declarações 130 e a autoridade de declarações 140 do provedor de identidade 115 sejam mostrados como entidades separadas na Figura 1, em modalidades alternativas, o transformador de declarações 130 e a autoridade de declara- ções 140 podem ser a mesma entidade ou entidades diferentes. O provedor de identidade 115 pode assumir a forma de um serviço de ficha de segurança em algumas modalidades exemplares. Do mesmo modo, o provedor de identidade 115 e o sistema de geração de re- presentação DIR 164 pode ser a mesma ou diferentes entidades.

Os sistemas de computador descritos neste documento incluem, sem limitação, um computador pessoal, um computador servidor, um dispositivo portátil ou laptop, um sistema microprocessador, um sistema baseado em microprocessador, um equipamento eletrônico programável pelo consumidor, PC de rede, minicomputadores, um computador de grande porte, um cartão inteligente, um telefone, um dispositivo de comunicação móvel ou celular, um assistente de dados pessoais, um ambiente computacional distribuído incluindo qualquer um dos referidos sistemas ou dispositivos, ou coisa do gênero. Alguns sistemas de compu- tador descritos neste documento podem incluir dispositivos computacionais portáteis. Um dispositivo computacional portátil é qualquer sistema de computador que se destine a ser fisicamente transportado por um usuário. Cada sistema de computador também pode incluir um ou mais periféricos, incluindo, sem limitação: um teclado, um mouse, uma câmera, uma web cam, uma câmera de vídeo, um scanner de impressão digital, um scanner de íris, um dispositivo de vídeo, tal como um monitor, um microfone, ou alto-falantes.

Cada sistema de computador inclui um sistema operacional, tal como (sem limita- ção) o sistema operacional Windows da Microsoft Corporation, e um ou mais programas armazenados no meio legível em computador. Cada sistema de computador pode incluir ainda um ou mais dispositivos de comunicação de entrada e saída que permite ao usuário se comunicar com o sistema de computador, bem como permite que o sistema de computa- dor se comunique com outros dispositivos. As comunicações entre os sistemas de computa- dor utilizados pela parte principal 110 (por exemplo, a principal máquina 111), parte confian- te 120, o sistema de geração de representação DIR 164, o sistema administrador 160, o sistema de captura de dados 162, e o provedor de identidade 115 podem ser implementa- das usando qualquer tipo de enlace de comunicação, incluindo, sem limitação, a Internet, as redes de área remota, as intranets, as Ethernets, as passagens diretas a fio, os satélites, as varreduras infravermelhas, as comunicações celulares, ou qualquer outro tipo de comunica- ção com ou sem fio.

Em algumas modalidades exemplares aqui apresentadas, o sistema 100 é imple- mentado, pelo menos em parte, como um sistema de Cartão de Informação provido na es- trutura .NET 3.0 desenvolvido pela Microsoft Corporation de Redmond, Washington. O sis- tema de Cartão de Informação permite às partes principais gerenciar várias representações DIR de vários provedores de identidade.

O sistema de Cartão de Informação utiliza uma plataforma de serviços da web, co- mo a Estrutura de Comunicação Windows da estrutura .NET 3.0. Além disso, o sistema de Cartão de Informação é construído utilizando as Especificações de Segurança dos Serviços da Web propagadas, pelo menos em parte, pela Microsoft Corporation de Redmond, Wa- shington. Estas especificações incluem um modelo de segurança de mensagem WS- Security, uma representação diretiva final WS-SecurityPolicy, uma troca de metadados WS- MetadataExchange, e um modelo de confiança WS-Trust. Geralmente, o modelo WS- Security descreve como anexar fichas de identidade a mensagens. O modelo WS- SecurityPoIicy descreve as exigências diretivas finais, tais como as fichas de identidade e os algoritmos de criptografia suportados necessários. Tais exigências diretivas podem ser en- caminhadas e negociadas usando um protocolo de metadados definido pelo modelo WS- MetadataExchange. O modelo WS-Trust descreve uma estrutura para modelos de confiança que permite que diferentes serviços da web se tornem operáveis entre si. Algumas modali- dades exemplares descritas no presente documento se referem às Especificações de Segu- rança dos Serviços da Web acima descritas. Em modalidades alternativas, uma ou mais outras especificações podem ser utilizadas para facilitar as comunicações entre os vários subsistemas do sistema 100.

Com referência novamente à Figura 1, a parte principal 110 pode enviar uma solici- tação através da máquina principal 111 para a parte confiante 120 para o acesso a bens, serviços ou outras informações. Por exemplo, em uma modalidade, a máquina principal 111 envia uma solicitação para a parte confiante 120 para o acesso a informações da parte con- fiante 120 que a parte principal 110 deseja. A solicitação enviada pela máquina principal 111 pode incluir um pedido para as exigências de autenticação do uso da parte confiante 120, por exemplo, dos mecanismos providos no modelo WS-MetadataExchange. Em resposta à solicitação, a parte confiante 120 pode enviar à parte principal 111 os requisitos para a parte confiante 120 no sentido de autenticar a identidade da parte prin- cipal ou outras informações sobre a parte principal 110. Os requisitos da parte confiante 120 para a autenticação são referidos no presente documento como uma diretiva de segurança.

Uma diretiva de segurança define minimamente o conjunto de declarações de um provedor de identidade confiável 115 que a parte principal 110 deve prover à parte confiante 120 para que a parte confiante 120 autentique a parte principal 110. Uma diretiva de segurança pode incluir a exigência de prova quanto a uma característica pessoal (como idade), identidade, situação financeira, etc. Ela pode incluir ainda regras sobre o nível de verificação e autenti- cação exigido para autenticar quaisquer ofertas de prova (por exemplo, a assinatura digital de um provedor de identidade em particular).

Em um exemplo, a parte confiante 120 especifica a sua diretiva de segurança u- sando o modelo WS-SecurityPolicy, incluindo tanto os requisitos de declaração, como o tipo de ficha de identidade exigidos pela parte confiante 120. Exemplos de tipos de declarações incluem, sem limitação: nome, sobrenome, endereço de e-mail, logradouro, nome da locali- dade ou cidade, estado ou província, código postal, país, número de telefone, número de seguro social, data de nascimento, sexo, número de carteira de identidade, pontuação de declaração, situação financeira, situação legal, etc.

A diretiva de segurança pode também ser usada para especificar o tipo de ficha de identidade exigida pela parte confiante 120, ou um tipo padrão pode ser utilizado, conforme determinado pelo provedor de identidade. Além de especificar as declarações necessárias e o tipo de ficha, a diretiva de segurança pode especificar um provedor de identidade específi- co requerido pela parte confiante. De maneira alternativa, a representação diretiva pode omitir este elemento, deixando a determinação do provedor de identidade específico para a parte principal 110. Outros elementos podem ser especificados na diretiva de segurança, bem como, por exemplo, a renovação da ficha de segurança exigida.

Em algumas modalidades, a parte principal 110 pode exigir que a parte confiante 120 se identifique para a máquina principal 111, de modo que a parte principal 110 possa decidir se deve ou não atender a diretiva de segurança da parte confiante 120, como descri- to abaixo. Em um exemplo, a parte confiante 120 se identifica usando um certificado X509. Em outras modalidades, a parte confiante 120 pode se identifica através de outros meca- nismos, tais como, por exemplo, um certificado servidor de Camada de Soquetes de Segu- rança ("SSL").

A máquina principal 111 pode incluir uma ou mais representações DIR 110. Estas representações DIR (por vezes referidas como "Cartões de Informação" no sistema Win- dows CardSpace provido na estrutura .NET 3.0 desenvolvida pela Microsoft Corporation, de Redmond, Washington) são artefatos que representam a relação de emissão de fichas entre a parte principal 110 e um provedor de identidade específico, tal como o provedor de identi- dade 115. Cada representação DIR pode corresponder a um provedor de identidade em particular, e a parte principal 110 pode ter múltiplas representações DIR do mesmo ou de diferentes provedores de identidade. O uso de representações DIR em um sistema de iden- tidade é descrito em detalhe no Pedido de Patente U.S. N. 11/361 281, incorporado ao pre- sente documento a título de referência, como se aqui integralmente apresentado.

As representações DIR podem incluir, entre outras informações, a representação di- retiva de emissão do provedor de identidade para fichas de identidade, incluindo o tipo de fichas que podem ser emitidas, os tipos de declaração para os quais tem autoridade, e/ou as credenciais a usar para autenticação ao solicitar fichas de identidade. As representações DIR podem ser representadas como documentos de linguagem XML emitidos pelos prove- dores de identidade 115 ou pelos sistemas de geração de representação DIR 164 e arma- zenados pelas partes principais 110 em um dispositivo de armazenamento, como a máquina principal 111.

A máquina principal 111 pode incluir ainda um seletor de identidade. Geralmente, um seletor de identidade é um programa de computador e uma interface de usuário que permite que a parte principal 110 escolha entre uma ou mais representações DIR da parte principal 110 na máquina principal 111 de modo a solicitar e obter fichas de identidade de um ou mais provedores de identidade, tal como do provedor de identidade 115. Por exem- pio, quando uma diretiva de segurança da parte confiante 120 é recebida pela máquina prin- cipal 111,o seletor de identidade poderá ser programado no sentido de identificar uma ou mais representações DIR que atendam a uma ou mais dentre as declarações exigidas pela diretiva de segurança, utilizando as informações das representações DIR. Quando a parte principal 110 recebe a diretiva de segurança da parte confiante 120, a parte principal 110 pode se comunicar com (utilizando, por exemplo, a máquina principal 111) um ou mais pro- vedores de identidade a fim de juntar as declarações exigidas pela representação diretiva.

Nas modalidades exemplares, a parte principal 110 solicita uma ou mais fichas de identidade do provedor de identidade 115 usando o mecanismo de emissão descrito no mo- delo WS-Trust. Nas modalidades exemplares, a parte principal 110 encaminha as exigên- cias de declaração da representação diretiva da parte confiante 120 para o provedor de i- dentidade 115. A identidade da parte confiante 120 pode, mas não precisa, ser especificada na solicitação enviada pela parte principal 110 a fim de identificar o provedor 115. A solicita- ção pode incluir outros requisitos, tais como um pedido de ficha de exibição.

Geralmente, a autoridade de declarações 140 do provedor de identidade 115 pode prover uma ou mais das declarações exigidas pela diretiva de segurança da parte confiante 120. O transformador de declarações 130 do provedor de identidade 115 é programado para transformar as declarações e gerar uma ou mais fichas de identidade assinadas 150 que incluem a declaração ou declarações relativas à parte principal 110.

Como acima referido, a parte principal 110 pode solicitar uma ficha de identidade em um determinado formato na sua solicitação ao provedor de identidade 115, com base nas exigências da parte confiante 120. O transformador de declarações 130 pode ser pro- gramado para gerar fichas de identidade de diversos formatos, incluindo, sem limitação, o X509, o Kerberos, o SAML (versões 1.0 e 2.0), o Simple eXtensible Identity Protocol ("SXIP"), etc.

Por exemplo, em uma modalidade, a autoridade de declaração 140 está programa- do para gerar declarações em um primeiro formato A, e a diretiva de segurança da parte confiante 120 exige uma ficha de identidade em um segundo formato Β. O transformador de declarações 130 pode transformar as declarações da autoridade de declarações 140 do formato A para o formato B antes de enviar uma ficha de identidade para a parte principal 110. Além disso, o transformador de declarações 130 pode ser programado para refinar a semântica de uma determinada declaração. Em modalidades exemplares, a semântica de uma determinada declaração é transformada de modo a minimizar a quantidade de informa- ções providas em uma determinada declaração e/ou ficha de identidade a fim de reduzir ou minimizar a quantidade de informação pessoal que é transmitida por uma determinada de- claração.

Nas modalidades exemplares, o transformador de declarações 130 encaminha a fi- cha de identidade 150 para a parte principal 110 utilizando os mecanismos de resposta des- critos no modelo WS-Trust. Em uma modalidade, o transformador de declarações 130 inclui um serviço de ficha de segurança (por vezes referido como "STS"). Em uma modalidade exemplar, a parte principal 110 encaminha a ficha de identidade 150 para a parte confiante 120 através da vinculação da ficha de identidade 150 a uma mensagem de aplicação utili- zando os mecanismos de vinculação de segurança descritos no modelo WS-Security. Em outras modalidades, a ficha de identidade 150 pode ser enviada representação diretamente do provedor de identidade 115 para a parte confiante 120.

Quando a parte confiante 120 recebe a ficha de identidade 150, a parte confiante 120 pode verificar (por exemplo, ao decodificar ou descriptografar a ficha de identidade 150), a origem da ficha de identidade assinada 150. A parte confiante 120 pode também utilizar a(s) declaração(ões) da ficha de identidade 150 a fim de atender à diretiva de segu- rança da parte confiante 120 no sentido de autenticar a parte principal 110.

A provisão de representações DIR será, agora, apresentada em mais detalhes. A parte principal 110 pode obter uma representação DIR de diversas maneiras. Na modalida- de exemplar ilustrada na Figura 1, o sistema de geração de representação DIR 164 é de modo geral utilizado para se comunicar com a parte principal 110, criar novas representa- ções DIR, e notificar a parte principal 110 sobre representações DIR disponíveis. O sistema de geração de representação DIR 164 pode, em algumas modalidades, incluir um web site da Internet. Em outras modalidades, o sistema de geração de representação DIR 164 pode incluir um serviço da web. O sistema de geração de representação DIR 164 pode ainda in- cluir ou trabalhar em conjunto com um servidor de informação da Internet (IIS) 166, em cer- tas modalidades.

O armazenador de dados de identidade 168 é um sistema de armazenamento de informações digitais que pode ser acessados em algumas modalidades pelo provedor de identidade 115, pelo sistema de geração de representação DIR 164, ou pelo sistema admi- nistrador 160. O armazenador de dados de identidade 168 pode incluir um banco de dados, uma memória computador, ou qualquer outro dispositivo de armazenamento de dados. O armazenador de dados de identidade 168 pode ser composto de uma pluralidade de disposi- tivos ou sistemas em um modelo de dados distribuídos. O armazenador de dados de identi- dade 168 também pode incluir ou compreender um serviço de diretório, como o Active Direc- tory 169 propagado pela Microsoft Corporation de Redmond, Washington.

O sistema administrador 160 pode incluir um sistema de computador, incluindo uma interface de usuário que permite que um administrador se comunique com o armazenador de dados de identidade 168 e com o sistema de geração de representação DIR 164. O sis- tema administrador 160 permite que o administrador organize e administre os dados dentro do armazenador de dados de identidade 168. Além disso, permite que o administrador de- termine os tipos de representações DIR que o sistema de geração de representação DIR 164 cria, e permite que o administrador controle quando uma determinada parte principal se torna elegível para receber representações DIR específicas. O uso do sistema administrador 160 será apresentado em mais detalhes abaixo.

Certas modalidades podem incluir um sistema de captura de dados separado 162. O sistema de captura de dados 162 pode compreender um sistema de computador adapta- do para capturar informações relativas às partes principais. Por exemplo, o sistema de cap- tura de dados 162 pode incluir um sistema de computador de recursos humanos que captu- ra informações pessoais sobre uma parte principal, tais como nome, número de telefone, número de seguro social, endereço, etc. O sistema de captura de dados 162 pode incluir um armazenamento separado ou pode utilizar o armazenador de dados de identidade 168.

A Figura 2 ilustra um método 200 que pode ser implementado através do sistema 100. Na etapa 210, o administrador configura um armazenador de dados de identidade. Por exemplo, o administrador poderá utilizar o sistema administrador 160 para configurar o ar- mazenador de dados de identidade 168. O administrador pode, em outras modalidades, uti- lizar o sistema administrador 160 no sentido de criar tabelas no armazenador de dados de identidade 168 que serão usadas para administrar, gerar e gerenciar representações DIR. Em uma modalidade exemplar, o administrador pode determinar os tipos de declarações que serão suportados nas representações DIR criadas pelo sistema de geração de repre- sentação DIR 164 e identificar as fichas geradas pelo provedor de identidade 115. O admi- nistrador pode ainda utilizar o sistema administrador 160 a fim de configurar o armazenador de dados de identidade 168 no sentido de armazenar informações de diretiva, tais como os tipos de fichas que o provedor de identidade 115 suporta, as informações de direito, e os metadados na federação. Outras informações de armazenador de dados de identidade 168 que podem ser incorporadas em uma representação DIR incluem uma fotografia da parte principal 110 e informações de conectividade relativas aos provedores de identidade, tais como o provedor de identidade 115.

O método 200, em seguida, prossegue para a etapa 220, quando a parte principal 110 solicita uma representação DIR. Uma solicitação de representação DIR pode ser feita de várias maneiras. Por exemplo, a parte principal 110 pode usar a máquina principal 111a fim de acessar o sistema de geração de representação DIR 164. Em algumas modalidades, a representação DIR 164 é um web site, e a máquina principal 111 acessa o sistema de ge- ração de representação DIR 164 através de um navegador da Internet para solicitar uma representação DIR. Em outras modalidades, a parte principal 110 solicita uma determinada representação DIR. E ainda em outras modalidades, apresentadas mais adiante, a parte principal 110 solicita uma lista de representações DIR 110 disponíveis e escolhe a partir dessa lista.

O método 200 em seguida continua na etapa 230, quando o sistema de geração de representação DIR 164 verifica o armazenador de dados de identidade 168, gera a repre- sentação DIR, e provê a representação DIR à parte principal 110. Em uma modalidade, o sistema de geração de representação DIR 164, primeiramente verifica o armazenador de dados de identidade a fim de determinar se a parte principal 110 tem direito à representação DIR solicitada. Isto pode ser obtido de diversas maneiras, inclusive ao verificar uma por um arquivo DLL de direitos dentro do armazenador de dados de identidade 168, ao realizar uma verificação de acesso ao Diretório Ativo, etc. O sistema de geração de representação DIR 164 pode também acessar os metadados de sistema de identidade armazenados dentro do armazenador de dados de identidade a fim de determinar quais tipos de declarações de i- dentidade se encontram disponíveis para serem incluídas na nova representação DIR.

Quando a representação DIR 164 cria uma nova representação DIR, a representa- ção DIR pode assumir a forma de um documento em linguagem XML e pode incluir, entre outras informações: uma imagem para exibição na máquina principal, uma lista de declara- ções incluídas na representação DIR; uma lista de tipos de fichas disponíveis para a repre- sentação DIR; um identificador único de representação DIR; uma dica de credencial (apre- sentada mais adiante); a identificação do provedor de identidade; ou uma referência final para o provedor de identidade 115. A nova representação DIR pode ser provida para a parte principal também de diversas maneiras, incluindo um e-mail da nova representação DIR, uma mensagem de protocolo HTTP, ou outros métodos. Conforme utilizado aqui, "e-mail" inclui uma troca de mensagens de texto, de mensagens instantâneas, e formas similares de comunicação eletrônica.

Após a recepção da nova representação DIR, a parte principal 110 armazena a re- presentação DIR 240, por exemplo, na memória associada à máquina principal 111. A parte principal 250, em seguida, solicita acesso a uma parte confiante, como à parte confiante 120. A parte confiante nega acesso (por exemplo, através de um redirecionamento a uma página de autenticação) 260 e provê 260 a sua diretiva de segurança de volta para a parte principal 110. A parte principal 110, em seguida, seleciona 270 uma representação DIR a fim de atender à diretiva de segurança da parte confiante 120. Isto pode ser obtido, por exem- plo, através de uma interface de usuário na máquina principal 111 que exibe todas as repre- sentações DIR disponíveis para a parte principal 110. Em algumas modalidades, a represen- tação DIR que atende às exigências da diretiva de segurança da parte confiante pode ser destacada para a parte principal 110, e outros cartões podem ser atenuados de modo a faci- litar o processo de seleção para a parte principal 110.

A parte principal 110, em seguida, envia 280 uma solicitação de ficha de identidade para um provedor de identidade, como ao provedor de identidade 115. A solicitação de uma ficha de identidade pode ser gerada automaticamente pela máquina principal 111 mediante seleção pela parte principal 110 de uma representação DIR armazenada na máquina princi- pal 111. O provedor de identidade 115 verifica 285 o armazenador de dados de identidade a fim de obter a informação necessária para preencher a ficha de identidade solicitada. Esta informação pode incluir, por exemplo, dados de declaração. Por exemplo, quando a repre- sentação DIR selecionada inclui uma declaração de idade, o provedor de identidade 115 poderá verificar o armazenador de dados de identidade 168 a fim de determinar a idade da parte principal 110. O provedor de identidade 115 é capaz, então, de criar 285 a ficha de identidade solicitada e enviá-la 290 para a parte principal. A parte principal, em seguida, envia 295 a ficha de identidade para a parte confiante e o acesso é concedido, conforme acima apresentado.

Ao prover acesso por um provedor de identidade 115 ao mesmo armazenador de dados de identidade 168 utilizado pelo sistema de geração de representação DIR 164, o administrador poderá se assegurar que a geração de representações DIR permanece em sincronia com os dados correntes disponíveis para atender as declarações de uma ficha de identidade solicitada. Por exemplo, quando um administrador configura o armazenador de dados de identidade 168 de tal maneira que dados para uma declaração de idade não fi- quem ali armazenados, o sistema de geração de representação DIR 164, neste caso, não criará uma representação DIR que inclua esta opção para declaração de idade. Caso con- trário, poderão surgir problemas de sincronização. Por exemplo, vamos supor que um admi- nistrador crie uma nova representação DIR ad hoc (sem referência a dados de identidade disponíveis), e uma declaração de idade é incluída e enviada como parte de uma represen- tação DIR de volta para uma parte principal. Quando a parte principal tenta obter uma ficha de identidade com uma declaração de idade, esta informação não estará disponível, e a ficha será rejeitada pela parte confiante como insuficiente. O sistema 100, em contrapartida, permitirá a sincronização automática das representações DIR geradas e a disponibilidade de dados subjacentes para o preenchimento das fichas de identidade correspondentes. Um administrador é provido com a capacidade, através do sistema administrador 160, para fazer alterações no armazenador de dados de identidade que automaticamente afetarão tanto a provisão de representações DIR como a emissão de fichas de identidade correspondentes.

Em algumas modalidades, quando o administrador faz mudanças particulares no armazenador de dados de identidade 168 que afetam a validade das representações DIR já emitidas, qualquer parte principal que tenha recebido as representações DIR afetadas é no- tificada e autorizada a obter novas representações DIR. Por exemplo, vamos supor normas de privacidade exijam que o administrador elimine os endereços residenciais de qualquer parte principal armazenados no armazenador de dados de identidade 168. Qualquer parte principal 110 que receba uma representação DIR que inclua uma declaração de endereço residencial agora terá uma representação DIR inválida (uma vez que não mais haverá ne- nhum dado no armazenador de dados de identidade 168 para atender a esta declaração). Em uma modalidade, todas as partes principais são notificadas, por exemplo, através do e- mail de um sistema de geração de representação DIR 164, que aquela representação DlR é agora inválida e convida as partes principais a obter uma nova representação DIR que não inclua a declaração de endereço residencial não mais suportada. Desta forma, a única alte- ração pelo administrador para o armazenados de dados de identidade 168 (a) impede que novas representações DIR sejam emitidas com uma declaração de endereço residencial, e (b) avisa à parte principal que as representações DIR existentes que incluam esta declara- ção são inválidas e podem ser substituídas.

Com referência, a seguir, à Figura 3, um método exemplar 300 é descrito em rela- ção ao sistema 100 mostrado na Figura 1. Neste exemplo, a parte principal 110 autentica a máquina principal 111. A máquina principal 111, por exemplo, pode ser conectada a uma intranet, que inclui um serviço diretório, como o servidor de Diretório Ativo 169. A autentica- ção da parte principal 110 para a máquina principal 111 pode incluir informações de assina- tura de qualquer método conhecido, incluindo nome de usuário / senha, cartão inteligente, etc. A parte principal 110, em seguida, inicia 320 uma representação DIR, por exemplo, a- pontando um navegador na máquina principal 111 para um web site que inclui o sistema de geração de representação DIR 164. A parte principal 110, em seguida, se autentica 330 no sistema de geração de representação DIR 164. Em algumas modalidades, a máquina prin- cipal 111,0 sistema de geração de representação DIR 164, o armazenador de dados de identidade 168, o provedor de identidade 115, e o sistema administrador 160 podem fazer parte da mesma intranet. Nessa modalidade, é possível que uma capacidade de única assi- natura esteja disponível. Por exemplo, quando a máquina principal é executada em um sis- tema operacional Windows disponível na Microsoft Corporation Redmond, Washington, e a autenticação Windows integrada é acionada, a autenticação no sistema de geração de re- presentação DIR 164 poderá ser automática e contínua para a parte principal 110 - a infor- mação utilizada para fazer Iogon (conexão) na máquina principal 111 é passada para o sis- tema de geração de representação DIR 164 juntamente com a solicitação de acesso. Em outras modalidades, o administrador pode configurar o sistema de geração de representa- ção DIR 164 de modo a requerer uma autenticação separada da parte principal 110. O ad- ministrador pode configurar o sistema de geração de representação DIR 164 de modo a re- querer qualquer dentre uma variedade de mecanismos de autenticação, incluindo nome do usuário / senha, cartão inteligente, etc. Em algumas modalidades, a parte principal 110 pode ser autenticada pelo servidor IIS 166, que pode ser facilmente configurado por um adminis- trador no sentido de aceitar qualquer dentre uma variedade de métodos de autenticação.

Quando a parte principal 110 é autenticada, o sistema de geração de representação DIR 164 acessa 350 o armazenador de dados de identidade 168. Neste exemplo, o sistema de geração de representação DIR 164 assume a forma de serviço da web de modo a permi- tir uma negociação entre o sistema de geração de representação DIR e a parte principal 110. Neste exemplo, a negociação determina o tipo de representação DIR que será retorna- do para a parte principal 110. Nesta instância, o sistema de geração de representação DIR 164 obtém 350 descritores de representação DIR disponíveis. Em modalidades exemplares, um administrador usa sistema administrador 160 para criar os descritores de representação DIR. Por exemplo, um administrador IT empresarial pode criar descritores que representam diferentes representações DIR para diferentes níveis de empregados. Um empregado em regime de meio expediente (part-time), por exemplo, poderá ter um conjunto diferente de declarações que um empregado em regime de expediente integral (full-time). Um presidente de empresa pode ter um conjunto de declarações diferente que o de um empregado assala- riado. Até mesmo as imagens associadas a cada descritor de representação DIR podem variar - por exemplo, a imagem de representação DIR do grupo de vendas pode ser laranja, enquanto a imagem de representação DIR do grupo da contabilidade pode ser verde. Além disso, é possível se personalizar a imagem de cartão de modo a conter a imagem de uma parte principal 110 (obtida no armazenador de dados de identidade 168). Isto aumenta a associação que a parte principal 110 faz entre as suas representações DIR e o provedor de identidade 115. Isto também proporciona melhores capacidades de "impressão digital". Em algumas modalidades, o sistema administrador 160 inclui uma interface de usu- ário que analisa todos os tipos disponíveis de informações disponíveis no armazenador de dados de identidade 168 e apresenta ao administrador uma maneira fácil de se criar descri- tores. Por exemplo, o administrador pode receber uma lista de: (a) classes de parte principal (por exemplo, empregados de meio expediente, empregados de expediente integral, mem- bro da equipe de executivos, membro do grupo de vendas, etc.); (b) tipos de declarações (nome, endereço, número de telefone, idade, etc.); (c) declarações de seguro; (d) condição empregatícia (corrente, demitido); etc. O administrador poderá, então, decidir criar descrito- res diferentes disponíveis para algumas ou todas as classes de partes principais. Por exem- plo, todas as partes principais podem estar aptas para receber uma representação DIR bá- sica, incluindo o nome da parte principal, o número de telefone, e situação empregatícia. No entanto, somente a equipe de executivos pode estar qualificada para receber uma represen- tação DIR que inclua ainda uma declaração de seguro de alto nível. Estes descritores po- dem ser criados pelo administrador e salvos no armazenador de dados de identidade junta- mente com uma diretiva que delineia quais partes principais poderão receber representa- ções DIR correspondentes a descritores específicos. Os possíveis comandos que podem se fazer úteis a um administrador no gerenciamento de descritores incluem: "OBTER DESCRITORES, OBTER TODOS OS DESCRITORES, ADICIONAR DESCRITORES, ALTERAR DESCRITORES, EXCLUIR DESCRITORES, COPIAR DESCRITOR, etc."

A solicitação por uma parte principal 110 para descritores disponíveis pode ser feita pela máquina principal 111 através de um método de serviço da web, como o "OBTER DESCRITORES." Isto faz com que o sistema de geração de representação DIR verifique a parte principal 110 contra a diretiva definida pelo administrador no sentido de determinar quais, caso algum, descritores estão disponíveis para a parte principal 110. Isto pode ser feito, por exemplo, através de uma verificação de acesso de Diretório Ativo. Os descritores podem ser armazenados em quaisquer dentre ou em todos os, por exemplo: um armazena- dor de dados de identidade 168, uma memória associada ao sistema de geração de repre- sentação DIR 164, ou um armazenador separado.

O sistema de geração de representação DIR 164 em seguida envia 360 os descrito- res disponíveis para a máquina principal 111. A parte principal 110 em seguida seleciona 370 dentre os descritores disponíveis e solicita representações DIR específicas correspon- dentes aos descritores. Mais uma vez, isto pode ser obtido, por exemplo, por um método de serviço da web, como o "OBTER CARTÃO" (referindo-se, neste exemplo, aos Cartões de Informação disponíveis no sistema Windows CardSpace propagado pelo menos em parte pela Microsoft Corporation de Redmond, Washington). Uma parte principal 110 pode solici- tar uma ou diversas representações DIR disponíveis.

O sistema de geração de representação DIR 164 em seguida cria 380 a represen- tação DIR solicitada. Nas modalidades exemplares, o sistema de geração de representação DIR inclui na representação DIR uma dica de credencial para "voltar" à representação DIR. Por exemplo, a representação DIR pode incluir uma dica de credencial de nome de usuário / senha, e a parte principal 110 pode ser solicitada a autenticar o uso daquele nome de usuá- rio / senha a fim de usar a representação DIR no sentido de obter uma ficha de identidade. Em algumas modalidades, o tipo de autenticação pode ser tirado da autenticação utilizada pela parte principal 110 a fim de obter acesso ao sistema de geração de representação DIR 164. Por exemplo, quando a parte principal 110 utiliza uma combinação de nome de usuário / senha para autenticar o servidor IIS 166, o sistema de geração de representação DIR 164 poderá usar o mesmo nome de usuário e senha para voltar à representação DIR quando a mesma é retornada para a parte principal 110.

Em outras modalidades, o sistema de geração digital pode ter acesso a um serviço de diretório, como o Diretório Ativo 169, que pode incluir outros métodos de autenticação disponíveis apropriada uma parte principal em particular 110. Por exemplo, quando a parte principal 110 usa um nome de usuário / senha para autenticar o sistema de geração de re- presentação DIR 164, mas o Diretório Ativo também inclui um certificado associado a um cartão inteligente registrado para a parte principal 110, o sistema de geração de representa- ção DIR 164 poderá incluir um tipo ou ambos os tipos de autenticação como parte da repre- sentação DIR retornada para a parte principal 110. Além disso, quando uma capacidade de assinatura única é habilitada entre a máquina principal 111 e o sistema de geração de re- presentação DIR 164, o tipo de autenticação incluído na representação DIR pode ser o tipo de autenticação utilizado pela parte principal 110 no sentido de se autenticar na máquina principal 111.

Quando a representação DIR é gerada pelo sistema de geração de representação DIR 164, a mésma é enviada 390 para uma parte principal 110 por meio de uma variedade de métodos, incluindo e-mail, protocolo HTTP, etc. Em algumas some modalidades, o arqui- vo que inclui a representação DIR poderá ser protegido por pinos. Isto acontece porque, especialmente quando múltiplas representações DIR são enviadas para a parte principal 110, o arquivo que contém as representações DIR poderá incluir um material de chave crip- tográfica que deveria ser protegido contra acesso não autorizado. O pino possibilita o esta- belecimento de um segredo compartilhado entre a máquina principal 111 e o sistema de geração de representação DIR 164. Um arquivo contendo representações DIR, neste caso, pode ser descriptografado pela parte principal ao instalar as representações DIR na máqui- na principal 111. Métodos exemplares para a inicialização, aprovação, e envio de represen- tações DIR serão apresentados em mais detalhes abaixo.

A seguir, com referência à Figura 4, é ilustrado um método 400. Na etapa 410, um primeiro canal envia uma solicitação no sentido de criar uma representação DIR. Por exem- pio, a parte principal 110 pode usar um navegador da internet na máquina principal 111a fim de solicitar uma nova representação DIR do sistema de geração de representação DIR 164. Na etapa 420, um segundo canal emite 420 uma notificação de que a representação DIR foi solicitada. Por exemplo, em resposta a uma solicitação para uma nova representa- ção DIR da parte principal 110, o sistema de geração de representação DIR 164 ou um apli- cativo executável na máquina principal 111 poderá enviar uma notificação de e-mail de que a solicitação foi feita. Isto pode funcionar como uma "verificação" de modo a garantir que é a parte principal 110 que está solicitando a representação DIR e não um impostor. Em algu- mas modalidades, o e-mail pode ser direcionado para um endereço de e-mail conhecido da parte principal. Em outras modalidades, a notificação pode ser direcionada a uma terceira parte cuja diretiva do administrador requer a aprovação da emissão de uma nova represen- tação DIR para a parte principal em particular 110. Por exemplo, algumas representações DIR poderão ficar disponíveis para certos empregados de uma empresa somente quando seus gerentes aprovam a emissão. Este tipo de representação DIR pode ser utilizado, por exemplo, a fim de obter acesso a um grupo de trabalho confidencial.

Conforme usado no presente documento, o termo "canal" se refere à maneira na qual a informação em emissão é comunicada. A distinção entre diferentes canais no método 400 é uma distinção lógica. Dois canais distintos podem empregar algum ou todos dentre os mesmos enlaces físicos ou eletrônicos de comunicação ou caminhos completamente dife- rentes. Por exemplo, uma notificação na etapa 420 pode ser enviada pelo mesmo enlace de comunicação (por exemplo, a Internet) que a aprovação na etapa 430, mas os canais po- dem ser logicamente diferentes (por exemplo, um pode ser um e-mail e o outro pode ser uma mensagem de protocolo HTTP).

Na etapa 430, é recebida uma aprovação para a representação DIR a ser criada. Por exemplo, o destinatário da notificação da etapa 420 do sistema de geração de represen- tação DIR 364 pode responder e aprovar a emissão da representação DIR solicitada. Isto pode ser feito de diversas maneiras. Por exemplo, a notificação da etapa 420 pode compre- ender um e-mail com um enlace para um site de aprovação agrupado pelo sistema de gera- ção de representação DIR 364.

Na etapa 440, a representação DIR solicitada é criada. Quando a aprovação é ne- gada pelo destinatário da notificação da etapa 420, outros eventos poderão ocorrer. Por e- xemplo, o administrador pode ser notificado de que uma solicitação não autorizada foi feita para uma representação DIR.

A seguir, com referência à Figura 5, é mostrado um outro método exemplar 500. Na etapa 510, é emitida uma notificação de que uma representação DIR se encontra disponível para uma parte principal. Por exemplo, o sistema de geração de representação DIR 364 pode enviar à parte principal 110 um e-mail avisando que uma nova representação DIR se encontra disponível. De maneira alternativa, a notificação pode ir para uma terceira parte, como o gerente da parte principal. Este tipo de notificação pode ser útil em uma situação na qual o administrador, por exemplo, alterou o armazenador de dados de identidade 168 de modo a incluir um descritor adicional. O sistema de geração de representação DIR 364 po- derá, então, ser usado no sentido de notificar de que uma nova representação DIR está dis- ponível para todas as partes principais de uma classe que se qualifica para o descritor. Por exemplo, o gerente de uma unidade empresarial em particular pode pedir a um administra- dor para criar um novo descritor para a representação DIR a ser usada em conjunto com um projeto em particular. Quando o administrador cria o descritor, a notificação de todas as par- tes principais de que o gerente deseja obter uma nova representação DIR poderá ser auto- mática. A notificação 510 pode também ser incluída como parte de um fluxo de trabalho em- presarial geral. Por exemplo, quando uma nova parte principal começa a trabalhar em uma organização, o departamento de recursos humanos pode capturar informações sobre a par- te principal através do sistema de captura de dados 162. Esta captura de dados pode dar origem a uma série de etapas automatizadas, incluindo o armazenamento dos dados de identidade relevantes com relação à parte principal no armazenador de dados de identidade 168 e a notificação à parte principal 110 de que uma representação DIR se lhe encontra disponível. A notificação pode assumir muitas formas, incluindo um e-mail para uma parte principal que inclui um enlace a um web site que compreende o sistema de geração de re- presentação DIR 164. De maneira alternativa, um aplicativo pode ser executado em uma máquina principal 111 adaptada para receber uma mensagem do sistema de geração de representação DIR 164 de que uma nova representação DIR está disponível para uma parte principal 110 (por exemplo, o aplicativo poderá reproduzir uma mensagem instantânea, um ícone poderá aparecer na barra de ferramentas de uma máquina principal 111, etc.).

Na etapa 520, é recebida uma solicitação para criar a representação DIR. Esta eta- pa pode também obtida de diversas maneiras. Por exemplo, a parte principal 110 pode res- ponder a um e-mail de notificação ao clicar em um enlace que a levará para uma página da web que oferece à parte principal a opção de solicitar a representação DIR. De maneira al- ternativa, quando um aplicativo de uma máquina principal 111 avisa à parte principal 110 de que a representação DIR está disponível, a parte principal poderá solicitar a representação DIR dentro de tal aplicativo e o aplicativo poderá retornar uma mensagem para o sistema de geração de representação DIR 364 a fim de fazer a solicitação.

Na etapa 530, a representação DIR é criada conforme solicitada. A criação da re- presentação DIR pode ser feita conforme descrito no presente documento. A representação DIR é em seguida enviada 540 para a parte principal, também conforme descrito no presen- te documento.

A seguir, com referência à Figura 6, é mostrado um outro método exemplar 600. Na etapa 610, um sistema de geração de representação DIR is consultado para novas repre- sentações DIR que se encontram disponíveis para uma parte principal. Por exemplo, a má- quina principal 111 pode ser programada de modo a periodicamente consultar o sistema de geração de representação DIR 164 a intervalos predeterminados. Na etapa 620, é determi- nado se todas as representações DIR novas estão disponíveis para a parte principal. O sis- tema de geração de representação DIR 164, por exemplo, poderá verificar no armazenador de dados de identidade 168 se todos os descritores novos se encontram disponíveis para a parte principal 110, desde a última vez que a consulta foi feita pela máquina principal 111. Na etapa 630, é feita uma solicitação para que uma nova representação DIR seja criada. Continuando o exemplo, após o recebimento da notificação de que uma nova representação DIR está disponível, a parte principal 110 poderá solicitar para que o sistema de geração de representação DIR 164 crie a nova representação DIR. Na etapa 640, a nova representação DIR é recebida (por exemplo, uma nova representação DIR poderá ser recebida por uma máquina principal 111 do sistema de geração de representação DIR 164). Este método 600 é um outro exemplo de como o trabalho do administrador pode ser simplificado. Caso todas as máquinas principais sejam programadas para consultar novas representações DIR, por exemplo, quando o administrador criar um novo descritor de representação DIR no armaze- nador de dados de identidade 168, a emissão e a liberação das novas representações DIR serão automáticas e não exigirão nenhum trabalho a mais da parte do administrador.

Pode ser também benéfico poder criar representações DIR dinamicamente em res- posta à diretiva de segurança de uma parte confiante. Com referência, a seguir, à Figura 7, um método exemplar 700 é ilustrado. Na etapa 710, o acesso é solicitado para uma parte confiante. Por exemplo, quando parte confiante 120 está limitada a um site da web, a má- quina principal 111 tenta acessar o site da web através de um navegador. Na etapa 720, o acesso à parte confiante é negado e uma diretiva de segurança da parte confiante é recebi- da. Continuando o exemplo, a parte confiante 120 envia para a máquina principal 111a sua diretiva de segurança e uma mensagem de protocolo HTTP que redireciona o navegador da máquina principal 111 para uma página de autenticação da web. Em seguida, é solicitada 730 uma representação DIR que atenda à diretiva de segurança do sistema de geração de representação DIR. No exemplo acima, a máquina principal 111 poderá, primeiramente, ve- rificar se ela tem uma representação DIR suficiente, e, caso negativo, a máquina principal 111 poderá ser programada para consultar um cache local por provedores de identidade que ofereçam representações DIR que atendam à diretiva de segurança da parte confiante 120. A máquina principal poderá também consultar uma lista pública de provedores de represen- tação DIR agrupados por uma terceira parte. A parte principal 110 poderá, em seguida, es- colher um provedor de representação DIR e um sistema de geração de representação DIR apropriados, tal como o sistema de geração de representação DIR 164. Na etapa 740, a representação DIR é recebida. No exemplo acima, a máquina principal 111 recebe a nova representação DIR, a qual poderá então ser encaminhada para o provedor de identidade 115 a fim de obter a necessária ficha de identidade de modo a obter acesso à parte confian- te 120.

Em algumas modalidades, a máquina principal 111 poderá encaminhar a diretiva de segurança da parte confiante 120 para o sistema de geração de representação DIR 164. O sistema de geração de representação DIR 164 poderá, em seguida, verificar o armazenador de dados de identidade 168 no sentido de determinar se as declarações e outras exigências apresentadas na diretiva de segurança podem ser atendidas. Caso positivo, a representa- ção DIR que atende à diretiva de segurança será criada. Desta maneira, a parte principal poderá obter a representação DIR de acordo com a sua necessidade, independentemente se o administrador pré-configurou um descritor de identidade que atenda às necessidades daquela diretiva de segurança da parte confiante em particular.

Com referência, a seguir, à Figura 8, um outro método exemplar 800 é mostrado. Na etapa 810, é definida uma diretiva para um grupo de partes principais, autorizando o grupo de partes principais quando a representação DIR se encontra disponível. Com refe- rência ao sistema exemplar 100 da Figura 1, um administrador poderá utilizar um sistema administrador no sentido de definir uma diretiva no armazenador de dados de identidade 168 autorizando todas as partes principais que fazem parte de um grupo em particular a receber uma determinada representação DIR. Em algumas modalidades, isto pode ser obti- do quando o administrador utiliza o recurso "Diretiva de Grupo" disponível no Diretório Ativo 169 ou outro meio para lançar um aplicativo de cliente residente em uma máquina principal 111. Na etapa 820, o grupo de partes principais para o qual a representação DIR está dis- ponível é notificado. No exemplo acima, o aplicativo de cliente residente na máquina princi- pai 111 é ativado. Isto poderá resultar no aviso à parte principal 110 de que uma represen- tação DIR se encontra neste momento disponível (por exemplo, através de uma mensagem instantânea, um ícone da barra de ferramentas, etc.). O aplicativo de cliente pode ter o seu próprio conjunto de regras (por exemplo, a capacidade de a parte principal 110 escolher ser lembrada mais tarde, prover à parte principal 110 apenas uma determinada duração de tempo para recuperar uma nova representação DIR, etc.). Na etapa 830, é recebida uma solicitação de pelo menos uma primeira parte principal do grupo de partes principais no sen- tido de criar a representação DIR. Em algumas modalidades, isto pode envolver a autoriza- ção da criação de uma representação DIR pelo usuário através do aplicativo de cliente resi- dente na máquina principal 111. Em outras modalidades, o aplicativo de circuito pode solici- tar uma representação DIR sem maior envolvimento da parte principal 110. Na etapa 840, a representação DIR é criada para a primeira parte principal.

A Figura 9 ilustra um dispositivo computacional geral 900 (também referido aqui como computador ou sistema de computador), que poderá ser usado para implementar as modalidades descritas no presente documento. O dispositivo computacional 900 vem a ser tão-somente um exemplo de um ambiente computacional e não pretende sugerir nenhuma limitação ao âmbito de aplicação ou à funcionalidade do computador ou arquiteturas de re- de. Sequer o dispositivo computacional 900 deve ser interpretado como tendo qualquer de- pendência ou exigência com relação a qualquer um ou combinação de componentes ilustra- dos no dispositivo computacional 900 exemplar. Nas modalidades, o dispositivo computa- cional 900 pode ser usado, por exemplo, como a máquina principal 111, o sistema de gera- ção de representação DIR 164, o sistema de captura de dados 162, o servidor IIS 166, o armazenador de dados de identidade 168, o diretório ativo 169, o sistema administrador 160, o provedor de identidade 115, ou a parte confiante 120, conforme descrito acima com relação à Figura 1.

Em sua configuração mais básica, o dispositivo computacional 900 tipicamente in- clui pelo menos uma unidade de processamento 902 e uma memória 904. Dependendo da configuração exata e do tipo do dispositivo computacional, a memória 904 pode ser volátil (como a memória RAM), não volátil (como a memória ROM, a memória flash, etc.) ou algu- ma combinação das duas. Esta configuração mais básica é ilustrada na Figura 9 nas linhas pontilhadas 906. A memória do sistema 904 armazena os aplicativos que são executáveis no dispositivo computacional 900. Além dos aplicativos, a memória 904 pode ainda armaze- nar informações que são utilizadas nas operações a serem realizadas pelo dispositivo com- putacional 900, tais como uma solicitação de criação de representação DIR 910 e/ou uma notificação de disponibilidade de representação DIR 911, conforme descrito abaixo com re- lação às Figuras 1 a 8.

Adicionalmente, o dispositivo computacional 900 pode ter ainda outros recursos / funcionalidade. Por exemplo, o dispositivo computacional 900 pode incluir ainda um outro armazenador 908 (removível e/ou não removível) incluindo, porém, não se limitando a, dis- cos ou fitas magnéticas ou ópticas. Este armazenador adicional é ilustrado na Figura 9 pelo armazenador 908. Os meios de armazenamento em computador incluem meios voláteis e não voláteis, removíveis e não removíveis implementados em qualquer método ou tecnolo- gia para o armazenamento de informações, tais como instruções legíveis em computador, estruturas de dados, módulos de programa, ou outros dados. A memória 904 e o armazena- dor 908 são exemplos de meios de armazenamento em computador. Os meios de armaze- namento em computador incluem, porém não se limitam a, memória RAM, memória ROM, memória EEPROM, memória flash ou outra tecnologia de memória, CD-ROM, discos versá- teis digitais (DVD) ou outro armazenador óptico, cassetes magnéticos, fita magnética, arma- zenador magnético de disco ou outros dispositivos de armazenamento magnéticos, ou qual- quer outro meio que possa ser utilizado para armazenar as informações desejadas e que possam ser acessadas pelo dispositivo computacional 900. Quaisquer destes meios de ar- mazenamento em computador podem fazer parte do dispositivo computacional 900.

Como os versados na técnica poderão apreciar, o armazenador 908 pode armaze- nar uma variedade de informações. Entre outros tipos de informação, o armazenador 908 poderá armazenar uma representação de identidade digital 930 (por exemplo, no caso de uma máquina principal) ou uma ficha de identidade 945 (por exemplo, no caso de um prove- dor de identidade).

O dispositivo computacional 900 pode também conter conexões de comunicação 912 que permitem que o sistema se comunique com outros dispositivos. As conexões de comunicação 912 são um exemplo de meios de comunicação. Os meios de comunicação tipicamente incorporam instruções legíveis em computador, estruturas de dados, módulos de programa ou outros dados em um sinal de dados modulado, tal como uma onda portado- ra ou outro mecanismo de transporte e inclui quaisquer meios de entrega de informação. O termo "sinal de dados modulado" significa um sinal que tem uma ou mais de suas caracterís- ticas definidas ou alteradas de tal maneira a codificar informações no sinal. À guisa de e- xemplo, e não de limitação, os meios de comunicação incluem meios com fio, tais como uma rede a fio ou uma conexão direta a fio, ou meios sem fio, tais como os meios acústicos, de RF, infravermelhos ou outros meios sem fio. O termo meio legível em computador con- forme usado no presente documento inclui tanto os meios de armazenamento como os mei- os de comunicação.

O dispositivo computacional 900 pode ter ainda dispositivos de entrada 914, tais como teclado, mouse, caneta, dispositivo de entrada de voz, dispositivo de entrada de to- que, etc. Os dispositivos de saída 916, tais como um vídeo, alto-falantes, impressora, etc., podem também ser incluídos. Todos estes dispositivos são bem conhecidos na técnica e não precisam ser apresentados aqui em mais delonga.

As várias modalidades acima descritas são providas à guisa de ilustração somente e não devem ser construídas com o sentido de limitação. Os versados na técnica pronta- mente reconhecerão que várias modificações e alterações podem ser feitas às modalidades acima descritas sem se afastar do verdadeiro espírito ou âmbito de aplicação da presente invenção ou das reivindicações a seguir.

Claims (20)

1. Método (400) para a provisão de uma representação de identidade digital (930) para parte principal (110), o método sendo CARACTERIZADO pelo fato de compreender as etapas de: - receber (410) uma solicitação através de um primeiro canal a fim de criar a repre- sentação de identidade digital (930) para a parte principal (110); - emitir (420) uma notificação através de um segundo canal de que a representação de identidade digital (930) foi solicitada; - receber (430) a aprovação para a representação de identidade digital (930) ser cri- ada; - criar (440) a representação de identidade digital (930).

2. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que a notificação é uma mensagem eletrônica enviada para um endereço conhecido da parte prin- cipal.

3. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que a notificação é uma mensagem eletrônica enviada para uma terceira parte.

4. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que a notificação inclui um enlace eletrônico a fim de facilitar a aprovação.

5. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que o primeiro canal é uma solicitação de protocolo HTTP e o segundo canal é um e-mail.

6. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de com- preender ainda as etapas de: - receber uma segunda solicitação através do primeiro canal a fim de criar uma se- gunda representação de identidade digital para a parte principal; - emitir uma segunda notificação através do segundo canal de que a segunda re- presentação de identidade digital foi solicitada; - receber uma negativa de aprovação para a representação de identidade digital a ser criada; - enviar uma mensagem eletrônica para uma terceira parte de que a recusa de a- provação foi recebida.

7. Método (500) para a provisão de uma ou mais representações de identidade digi- tal (930) para uma parte principal (110), o método sendo CARACTERIZADO pelo fato de compreender as etapas de: - emitir (530) uma notificação de que uma ou mais representações de identidade di- gital (930) estão disponíveis para a parte principal (110); - receber (520) uma solicitação para criar a uma ou mais representações de identi- dade digital (930); - criar (530) a uma ou mais representações de identidade digital (930).

8. Método, de acordo com a reivindicação 7, CARACTERIZADO pelo fato de que a notificação inclui um enlace para um site eletrônico a fim de permitir a criação da solicitação.

9. Método, de acordo com a reivindicação 7, CARACTERIZADO pelo fato de com- preender ainda a etapa de: - capturar dados relativos à parte principal; - sendo que a etapa de emitir é automaticamente realizada após a etapa de captu- rar.

10. Método, de acordo com a reivindicação 7, CARACTERIZADO pelo fato de que a notificação é emitida para uma terceira parte.

11. Método, de acordo com a reivindicação 7, CARACTERIZADO pelo fato de com- preender ainda a etapa de: - criar um descritor de representação de identidade digital; - sendo que a etapa de emitir uma notificação é automaticamente realizada após a etapa de criar.

12. Método, de acordo com a reivindicação 7, CARACTERIZADO pelo fato de que a parte principal é um membro de um grupo de partes principais, e pelo fato de compreender ainda a etapa de: - definir uma diretiva de que o grupo de partes principais obteve acesso à represen- tação de identidade digital; - sendo que a etapa de emitir a notificação compreende a emissão da notificação para o grupo de partes principais.

13. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que a etapa de emitir a notificação compreende o envio de uma mensagem para pelo menos um aplicativo executável em uma máquina principal associada a pelo menos uma das partes principais do grupo de partes principais.

14. Método, de acordo com a reivindicação 13, CARACTERIZADO pelo fato de que a solicitação é criada por pelo menos um aplicativo automaticamente, sem aviso por pelo menos uma parte principal.

15. Método, de acordo com a reivindicação 7, CARACTERIZADO pelo fato de com- preender ainda as etapas de: - proteger criptograficamente a uma ou mais representações de identidade digital; - enviar a uma ou mais representações de identidade digital criptograficamente pro- tegidas para uma máquina principal.

16. Método (600) para a provisão de uma representação de identidade digital (930) para uma parte principal (110), o método sendo CARACTERIZADO pelo fato de compreen- der as etapas de: - consultar (610) um sistema de geração de representação de identidade digital (164) a fim de determinar se alguma nova representação de identidade digital (930) está disponível para a parte principal (110); - receber (620) uma notificação de que uma nova primeira representação de identi- dade digital (930) está disponível para a parte principal (110); - solicitar (630) para que a nova primeira representação de identidade digital (930) seja criada; - receber (640) a nova primeira representação de identidade digital (930).

17. Método, de acordo com a reivindicação 16, CARACTERIZADO pelo fato de que a etapa de consultar é realizada automática e periodicamente por uma máquina principal.

18. Método, de acordo com a reivindicação 16, CARACTERIZADO pelo fato de compreender ainda a etapa de: - após receber a notificação, avisar à parte principal que a representação de identi- dade digital está disponível.

19. Método, de acordo com a reivindicação 18, CARACTERIZADO pelo fato de que a etapa de emitir uma notificação compreende fazer com que uma mensagem instantânea apareça em uma interface de usuário de uma máquina principal.

20. Método, de acordo com a reivindicação 18, CARACTERIZADO pelo fato de que a etapa de avisar inclui a provisão à parte principal de uma opção para ser lembrado mais tarde de modo a fazer com que a etapa de solicitar seja realizada.