BRPI0620078A2 - fichas de segurança que incluem alegações exibìveis - Google Patents
fichas de segurança que incluem alegações exibìveis Download PDFInfo
- Publication number
- BRPI0620078A2 BRPI0620078A2 BRPI0620078-8A BRPI0620078A BRPI0620078A2 BR PI0620078 A2 BRPI0620078 A2 BR PI0620078A2 BR PI0620078 A BRPI0620078 A BR PI0620078A BR PI0620078 A2 BRPI0620078 A2 BR PI0620078A2
- Authority
- BR
- Brazil
- Prior art keywords
- display
- sheet
- party
- data sheet
- safety data
- Prior art date
Links
- 231100000647 material safety data sheet Toxicity 0.000 title claims abstract description 98
- 238000000034 method Methods 0.000 claims description 19
- 230000015654 memory Effects 0.000 description 8
- 230000003287 optical effect Effects 0.000 description 8
- 238000004891 communication Methods 0.000 description 5
- 230000004044 response Effects 0.000 description 5
- 230000007246 mechanism Effects 0.000 description 4
- 230000006855 networking Effects 0.000 description 3
- 230000008520 organization Effects 0.000 description 3
- 230000003993 interaction Effects 0.000 description 2
- 230000002093 peripheral effect Effects 0.000 description 2
- 208000033748 Device issues Diseases 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 230000003203 everyday effect Effects 0.000 description 1
- 230000005055 memory storage Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000008569 process Effects 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 230000000644 propagated effect Effects 0.000 description 1
- 238000012552 review Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
- G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
- G06F21/6245—Protecting personal data, e.g. for financial or medical purposes
- G06F21/6263—Protecting personal data, e.g. for financial or medical purposes during internet communication, e.g. revealing personal data from cookies
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F15/00—Digital computers in general; Data processing equipment in general
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/31—User authentication
- G06F21/33—User authentication using certificates
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/06—Buying, selling or leasing transactions
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
Abstract
FICHAS DE SEGURANçA QUE INCLUEM ALEGAçõES EXIBìVEIS Um sistema para fornecer uma identidade digital inclui um transformador de alegações programado para gerar uma ficha de segurança que inclui uma ficha computacional e uma ficha de exibição, a ficha computacional incluindo uma ou mais alegações associadas à identidade de uma parte principal e a ficha de exibição incluindo informações de exibi- ção sobre as alegações contidas na ficha computacional. As informações de exibição são configuradas para permitir que a parte principal veja a ficha de exibição.
Description
"FICHAS DE SEGURANÇA QUE INCLUEM ALEGAÇÕES EXIBÍ- VEIS"
Nota sobre Copyright
Uma parte da revelação deste documento de patente contém material que está sujeito a proteção de copyright. O proprietário do copyright não tem objeção à reprodução por fac-símile, por parte de qualquer pessoa, do documento de patente ou da revelação de patente, tal como aparece no ar- quivo ou registros de patente do Escritório Norte-Americano de Marcas e Patentes, mas se reserva todos os direitos de copyright, quaisquer que sejam.
Antecedentes
A identidade é um componente importante que permi- te interações na vida cotidiana. Por exemplo, o cartão de crédito de um indivíduo permite que comerciantes identifi- quem o indivíduo e lhe permitam comparar produtos e serviços a crédito. O mesmo vale também para o mundo digital, onde a identidade digital permite interações digitais. Por exemplo, as identidades digitais podem ser utilizadas para autenticar partes umas com relação às outras no ambiente digital. Saber com quem se está interagindo é um elemento importante para se decidir se ou não confiar em, ou fornecer informações a, uma parte.
Uma entidade pode utilizar uma identidade digital para autenticar a identidade de uma parte ou outras informa- ções sobre a parte. Uma identidade digital pode ser emitida por outra entidade e incluir informações sobre a parte. E- xemplos de tais informações incluem o nome, o endereço, a inscrição na seguridade social, a idade, o número telefônico da parte, etc. Uma parte pode ter várias identidades digi- tais emitidas por uma ou mais outras entidades, semelhantes à de um indivíduo que tem uma carteira de motorista, um car- tão de crédito e um cartão de débito freqüentes.
A parte pode utilizar uma identidade digital para identificar-se para uma terceira parte. Por exemplo, uma terceira parte, como, por exemplo, um serviço on-line, pode exigir que a parte autentique sua identidade antes que a terceira parte permita que a parte acesse mercadorias ou serviços. Para autenticar sua identidade, a parte pode emi- tir para a terceira parte uma identidade digital sob a forma de uma ficha de segurança emitida por outra entidade confia- da pela terceira parte. Uma vez completa a autenticação, a terceira parte pode dar acesso às mercadorias ou serviços solicitados pela parte.
Em muitos casos, a parte tem pouca ou nenhuma ha- bilidade para controlar ou ver o conteúdo de uma ficha de segurança emitida por outra parte. Quando a parte comparti- lha a ficha de segurança com uma terceira parte durante a autenticação da identidade da parte, a privacidade da parte pode tornar-se uma preocupação. Por exemplo, sem o conheci- mento do conteúdo da ficha de segurança, a parte pode com- partilhar com a terceira parte, sem saber, informações pes- soais contidas na ficha de segurança que a parte não precisa compartilhar para autenticação. Além disto, a parte pode fornecer, sem saber, informações pessoais que a parte não quer compartilhar com a terceira parte (como, por exemplo, o número de inscrição na seguridade social, o número telefôni- co, etc.).
Sumário
Este Sumário é . apresentado para introduzir, sob uma forma simplificada, uma seleção de conceitos que são também descritos a seguir na Descrição Detalhada. Não se pretende com este Sumário identificar características chave ou caracter!sticas essenciais do objeto reivindicado, nem se pretende que ele seja utilizado como um auxílio na determi- nação do alcance do objeto reivindicado.
Outro aspecto refere-se a um sistema para fornecer uma identidade digital que inclui um transformador de alega- ções programado para gerar uma ficha de segurança que inclui uma ficha computacional e uma ficha de exibição, a ficha computacional incluindo uma ou mais alegações associadas à identidade de uma parte principal e a ficha de exibição in- cluindo informações de exibição sobre as alegações contidas na ficha computacional. As informações de exibição são con- figuradas para permitir que a parte principal veja a ficha de exibição.
Outro aspecto refere-se um método para fornecer uma identidade digital, o método incluindo: receber uma fi- cha de segurança que inclui uma ficha computacional e uma ficha de exibição, a ficha computacional incluindo uma ou mais alegações associadas à identidade de uma parte princi- pal e a ficha de exibição incluindo informações de exibição sobre as alegações na ficha computacional; e exibir as in- formações de exibição na ficha de exibição para a parte principal de modo que a parte principal possa considerar o conteúdo da ficha de exibição.
Ainda outro aspecto refere-se a um meio passível de leitura por computador que tem instruções executáveis por computador para executar etapas que incluem: gerar uma ficha de segurança que inclui receber uma ficha de segurança que inclui uma ficha computacional e uma ficha de exibição, a ficha computacional incluindo uma ou mais alegações associa- das à identidade de uma parte principal e a ficha de exibi- ção incluindo informações de exibição sobre as alegações contidas na ficha computacional; e exibir as informações contidas na ficha de exibição de modo que a parte principal possa considerar o conteúdo da ficha de exibição.
Descrição dos Desenhos
Será feita agora referência aos desenhos anexos, que não são necessariamente desenhados em escala, e nos quais:
A Figura 1 mostra um sistema de identidade digital exemplar;
A Figura 2 mostra um sistema de computador para fins gerais exemplar;
A Figura 3 mostra uma parte do sistema da Figura 1;
A Figura 4 mostra outra parte do sistema da Figura 1;
A Figura 5 mostra uma ficha de segurança exemplar;
A Figura 6 mostra um sistema de computador exem- plar programado para interpretar e exibir a ficha de exibi- ção de uma ficha de segurança;
A Figura 7 mostra outra parte do sistema da Figura 1;
A Figura 8 mostra um método exemplar para autenti- car uma parte principal;
A Figura 9 mostra um método exemplar para inter- pretar e exibir a ficha de exibição de uma ficha de segurança;
A Figura 10 mostra uma interface com usuário exem- plar para exibir a ficha de segurança de uma ficha de segu- rança; e
A Figura 11 mostra um método exemplar para gerar uma ficha de segurança que inclui uma ficha computacional e uma ficha de exibição.
Descrição Detalhada
Serão agora descritas mais completamente, com re- ferência aos desenhos anexos, modalidades exemplares. Estas modalidades são apresentadas de modo que esta revelação seja completa. Os mesmos números referem-se aos mesmos elementos em toda parte.
As modalidades exemplares aqui revelados referem- se de maneira geral a identidades digitais que podem ser trocadas entre uma primeira parte e uma segunda parte para autenticação de uma identidade e/ou informações relacionadas com a primeira parte. Nas presentes modalidades exemplares, a primeira parte pode ser um indivíduo, uma firma, uma orga- nização, um computador ou outro dispositivo, um serviço ou qualquer outro tipo de entidade. A primeira parte é aqui re- ferida como a parte principal. Nas modalidades exemplares, a segunda parte tem mercadorias, serviços ou outras informa- ções que a parte principal deseja acessar e/ou obter. A se- gunda parte é aqui referida como a parte que confia.
Com referência agora à Figura 1, é mostrado um sistema digital exemplar 100, que inclui uma parte principal 110 e uma parte que confia 120. A parte principal 110 e a parte que confia 120 podem comunicar-se uma com a outra a- través de uma ou mais redes, conforme também descrito a se- guir. Em modalidades exemplares, a parte principal 110 pode solicitar mercadorias, serviços ou outras informações da parte que confia 120, e a parte que confia 120 pode exigir a autenticação da identidade da ou das informações sobre a parte principal 110 antes ou juntamente com o fornecimento das mercadorias, serviços ou informações solicitados.
São também mostrados na Figura 1 um transformador de alegações 130 e uma autoridade de alegações 140 (às vezes referida como um serviço de ficha de segurança ou "STS") . No exemplo mostrado, o transformador de alegações 130 e a auto- ridade de alegações 140 são uma ou mais entidades que podem apresentar uma ou mais alegações ou asserções sobre uma par- te principal. Uma alegação é uma declaração feita sobre a parte principal relacionada com a identidade da parte prin- cipal ou com as informações sobre a parte principal, tais como, por exemplo, nome, endereço, No. de inscrição na segu- ridade social, idade, etc. Conforme também descrito a se- guir, o transformador de alegações 130 e a autoridade de a- legações 140 podem fornecer alegações à parte principal 110 e /ou à parte que confia 120 sob a forma de uma ficha de se- gurança assinada.
Nas modalidades exemplares, a autoridade de alega- ções 140 está em uma relação de confiança com a parte que confia 120, de modo que a parte que confia 120 confie as a- legações na ficha de segurança assinada da autoridade de a- legações 140.
Embora o transformador de alegações 130 e a auto- ridade de alegações 140 sejam mostrados como entidades sepa- radas na Figura 1, em modalidades alternativas o transforma- dor de alegações 130 e a autoridade de alegações 140 podem ser a mesma entidade ou entidades diferentes. Além disto, embora o transformador de alegações 130 seja mostrado como estando em comunicação com a parte principal 110, em modali- dades alternativas, a parte que confia 120 pode comunicar-se diretamente com o transformador de alegações 130, conforme também descrito a seguir.
Nas modalidades exemplares aqui reveladas, o sis- tema 100 é implementado como um sistema InfoCard apresentado na interface de programação com o aplicativo WINFX, desen- volvida pela Microsoft Corporation, de Redmond, Washington. O sistema InfoCard permite que as partes principais gerenci- em várias identidades digitais de diversas autoridades de alegações.
0 sistema InfoCard utilizada uma plataforma de serviços da Rede, tal como a Windows Communication Foundati- on, na interface de programação com o aplicativo WINFX. Além disto, o sistema InfoCard é construído utilizando-se as Es- pecificações de Segurança de Serviços da Rede propagadas, pelo menos em parte, pela Microsoft Corporation de Redmond, Washington. Estas especificações incluem um modelo de segu- rança para mensagens Segurança-WS, um política para pontos finais PolíticaDeSegurança-WS, um protocolo de metadados TrocaDeMetadados-WS e um modelo de confiança Confiança-WS. Geralmente, o modelo Segurança-WS descreve como anexar fi- chas de segurança a mensagens. O modelo PolíticaDeSegurança- WS descreve os requisitos de política para pontos finais, tais como fichas de segurança necessárias e algoritmos de criptografação suportados, implementados utilizando-se o protocolo de metadados TrocaDeMetadados-WS. O modelo Confi- ança-WS descreve uma estrutura para modelos de confiança que permite a inter-operação de diferentes serviços da Rede.
As modalidades exemplares aqui descritas referem- se às Especificações de Segurança para Serviços da Rede des- critas acima. Em modalidades alternativas, uma ou mais dife- rentes especificações podem ser utilizadas para facilitar as comunicações entre os diversos elementos no sistema 100.
Com referência agora à Figura 2, em uma modalidade exemplar a parte principal 110 é um indivíduo que utiliza um sistema de computador, como o sistema de computador exemplar 200, para comunicar-se com a parte que confia 120 e com o transformador de alegações 130. 0 sistema de computador 200 pode assumir diversas formas, tais como, por exemplo, um computador de mesa, um computador portátil e um computador de mão. Além disto, embora o sistema de computador 200 seja mostrado, os sistemas e métodos aqui revelados podem ser im- plementados também em diversos sistemas de computador alter- nativos .
O sistema 200 inclui uma unidade de processador 202, uma memória de sistema 204 e um barramento de sistema 206 que acopla diversos componentes de sistema, inclusive a memória de sistema 204, à unidade de processador 202. O bar- ramento de sistema 206 pode ser qualquer um de vários tipos de estrutura de barramento, inclusive um barramento de memó- ria, um barramento periférico e um barramento local que uti- lizam diversas arquiteturas de barramento. A memória de sis- tema inclui uma memória só de leitura (ROM) 208 e uma memó- ria de acesso aleatório (RAM) 210. Um sistema de entra- da/saída básico (BIOS) 212, que contém rotinas básicas que ajudam a transferir informações entre os elementos dentro do sistema de computador 200, é armazenado na ROM 208.
O sistema de computador 200 inclui também uma uni- dade de disco rígido 212 para ler de, e gravar em, um disco rígido, uma unidade de disco magnético 214 para ler de, ou gravar em, um disco magnético removível 216 e uma unidade de disco óptico 218 para ler de, ou gravar em, um disco óptico removível 219, como, por exemplo, CD-ROM, DVD ou outros mei- os ópticos. A unidade de disco rígido 212, a unidade de dis- co magnético 214 e a unidade de disco óptico 218 são conec- tadas ao barramento de sistema 206 por uma interface com a unidade de disco rígido 220, uma interface com a unidade de disco magnético 222 e uma interface com a unidade óptica 224, respectivamente. As unidades e seus meios passíveis de leitura por computador afins proporcionam armazenamento não volátil de instruções passíveis de leitura por computador, estruturas de dados, programas e outros dados para o sistema de computador 200.
Embora o ambiente exemplar aqui descrito possa u- tilizar um disco rígido 212, um disco magnético removível 216 e um disco óptico removível 219, outros tipos de meios passíveis de leitura por computador capazes de armazenar da- dos podem ser utilizados no sistema exemplar 200. Exemplos desses outros tipos de meios passíveis de leitura por compu- tador que podem ser utilizados no ambiente operacional exem- plar incluem cassetes magnéticos, cartões de memória flash, discos de vídeo digital, cartuchos Bernoulli, memórias de acesso aleatório (RAMs) e memórias só de leitura (ROMs).
Vários módulos de programa podem ser armazenados no disco rígido 212, no disco óptico 216, no disco óptico. 219, na ROM 208 ou na RAM 210, inclusive um sistema opera- cional 226, como, por exemplo, o sistema operacional WINDOWS da Microsoft Corporation, ou um mais programas de aplicativo 228, outros módulos de programa 230 e dados de programa 232.
O usuário pode introduzir comandos e informações no sistema de computador 200 através de dispositivos de en- trada, tais como, por exemplo, um teclado 234, um mouse 236 ou outro dispositivo indicador. Exemplos de outros disposi- tivos de entrada incluem uma barra de ferramentas, um menu, uma tela sensível ao toque, um microfone, um joystick, um mesa para jogos, uma caneta, um prato de satélite e um digi- talizador. Estes e outros dispositivos de entrada são fre- qüentemente conectados à unidade de processamento 202 atra- vés de uma interface com porta serial 240 que é acoplada ao barramento de sistema 206. No entanto, estes dispositivos de entrada podem ser também conectados por outras interfaces, tais como uma porta paralela, uma porta para jogos ou um barramento serial universal (USB). Um monitor LCD 242 ou ou- tro tipo de dispositivo de exibição é também conectado ao barramento de sistema 206 por meio de uma interface, como um adaptador de video 244, por exemplo. Além do monitor 242, os sistemas de computador podem incluir tipicamente outros dis- positivos de saida periféricos (não mostrados), tais como alto-falantes e impressoras.
O sistema de computador 200 pode funcionar em um ambiente de funcionamento em rede utilizando conexões lógi- cas com um ou mais computadores remotos, um servidor, um ro- teador, um PC de rede, um dispositivo par ou outro nó de re- de comum e inclui tipicamente muitos dos, ou todos os, ele- mentos descritos acima com relação ao sistema de computador 200. As conexões de rede incluem uma rede de área local (LAN) 248 e uma rede de área estendida (WAN) 250. Tais ambi- entes de funcionamento em rede são comuns em escritórios, redes de computadores empresariais, intranets e a Internet.
Quando utilizado em um ambiente de funcionamento em rede de LAN, o sistema de computador 200 é conectado à rede local 248 através de uma interface com rede ou adapta- dor 252. Quando utilizado em um ambiente de funcionamento em rede de WAN, o sistema de computador 200 inclui tipicamente um modem 254 ou outros dispositivo para estabelecer comuni- cações através da rede de área estendida 250, como a Inter- net. O modem 254, que pode ser interno ou externo, é conec- tado ao barramento de sistema 206 por meio da interface com porta serial 240. Em um ambiente de funcionamento em rede, os módulos de programa mostrados com relação ao sistema de computador 200, ou partes deles, podem ser armazenados no dispositivo de armazenamento em memória remoto. Deve ficar entendido que as conexões de rede mostradas são exemplos e que podem ser utilizados outros dispositivos para estabele- cer uma conexão de comunicação entre os computadores.
As modalidades aqui descritas podem ser implemen- tadas como operações lógicas em um sistema de computação. As operações lógicas podem ser implementadas (1) como uma se- qüência de tarefas ou módulos de programa implementados por computador que rodam em um sistema de computador e (2) como módulos lógicos ou de hardware interconectados que rodam dentro do sistema de computação. Esta implementação é uma questão de escolha que depende dos requisitos de desempenho do sistema de computador especifico. Por conseguinte, as o- perações lógicas que constituem as modalidades aqui descri- tas são referidas como operações, etapas ou módulos. Os ver- sados na técnica reconhecerão que estas operações, etapas e módulos podem ser implementados em software, em firmware, em uma lógica digital para fins especiais e qualquer combinação deles sem que se abandonem o espirito e o alcance da revela- ção. Este software, firmware ou seqüência semelhante de ins- truções de computador pode ser codificada e armazenada em um meio de armazenamento passível de leitura por computador e pode ser também codificada dentro de um sinal de onda porta- dora para transmissão entre dispositivos de computação.
Com referência agora à Figura 3, a parte principal 110 e a parte que confia 120 exemplares são mostradas nova- mente. A parte principal 110 pode comunicar-se com a parte que confia 120 utilizando, por exemplo, um sistema de compu- tador 300 (ver a Figura 6) que é semelhante ao sistema de computador 200 descrito acima. No exemplo mostrado, a parte principal 110 utiliza o computador 300 para enviar à parte que confia 120 uma solicitação de mercadorias, serviços ou outras informações. Em uma modalidade, por exemplo, a parte principal 110 envia à parte que confia 120 uma solicitação de acesso às informações que a parte principal 110 deseja.
A solicitação enviada pela parte principal 110 po- de incluir uma solicitação da política de segurança da parte que confia 120 utilizando, por exemplo, os mecanismos apre- sentados na TrocaDeDados-WS. Em resposta à solicitação, a parte que confia 120 envia à parte principal 110 requisitos para que a parte que confia 120 autentique a identidade ou outras informações sobre a parte principal 110. Os requisi- tos da parte que confia 120 para autenticação são referidos aqui como política de segurança. A política de segurança de- fine o conjunto de alegações que a parte principal 110 deve apresentar à parte que confia 120 para que a parte que con- fia 120 autentique a parte principal 110.
Em um exemplo, a parte que confia 120 especifica sua política de segurança utilizando a PolíticaDeSegurança- WS, que inclui tanto os requisitos de alegação quanto o tipo de ficha de segurança exigido pela parte que confia 120. Uma forma básica para uma política de segurança de acordo com a PoliticaDeSegurança-WS é mostrada no exemplo abaixo:
<sp:FichaEmitida...>
<sp:SolicitarGabaritoDeFichaDeSegurança>
<wst:TipoDeFicha>
urn:oásis:nomes:tc:SAML:1.0:asserção
</wst:TipoDeFicha>
<wst:Alegações
Wst: Dialeto=http: //schemas.microsoft. com/ws/2 00 5/05/identity >
<ic:Alegação
URI = "http' ://... / ws/2005/05/identidade/aIegações/nomedado"/ >
</wst:Alegações>
<sp:SolicitarGabaritoDeFichaDeSegurança>
</sp:FichaEmitida>
Neste exemplo, uma alegação referente ao nome dado da parte principal é exigida pela política de segurança para autenticação. Exemplos de outros tipos de alegações incluem, sem limitação, os seguintes:
• Primeiro Nome - Tipo: xs:cadeia - nome preferido ou primeiro nome do sujeito;
• Último Nome - Tipo: xs:cadeia - sobrenome ou nome de família do sujeito;
• Endereço de E-mail - Tipo: xs:cadeia - endereço preferido para o campo de e-mail "Para:" a ser enviado ao sujeito, usualmente
da forma <usuário>@<domínio>;
• Endereço de Rua - Tipo: xs:cadeia - componente de endereço de rua das informações de endereço do sujeito;
• Nome da Localidade ou Cidade - Tipo:
xs:cadeia - componente de localidade das informações de endereço do sujeito;
• Estado ou Província - Tipo: xs:cadeia - abreviatura do nome do estado ou província das informações de endereço do sujeito;
• Código Postal - Tipo: xs:cadeia - componente de código postal ou código zip das informações de endereço do sujeito;
• País - Tipo: xs:cadeia - país do sujeito;
• Número Telefônico Primário ou Residencial -
Tipo: xs:cadeia - número telefônico primário ou residencial do sujeito;
• Número Telefônico Secundário ou Comercial - Tipo: xs:cadeia - número telefônico secundário ou comercial do sujeito;
• Número Telefônico Móvel - Tipo: xs:cadeia - número telefônico móvel do sujeito;
• Data de Nascimento - Tipo: xs:data - a data de nascimento do sujeito sob a forma permitida pelo tipo de dados xs:data;
• Gênero - Tipo: xs:ficha - gênero do sujeito, que pode ter qualquer um destes valores de cadeia exatos - "Masculino", "Feminino" ou "Não Especificado"; e
• Identificador Pessoal Privado - Tipo:
xs:base64binário - indica o identificador privado que identifica o sujeito para a parte que confia.
A política pode ser também utilizada para especi- ficar o tipo de ficha de segurança exigido pela parte que confia 120, ou pode ser utilizado um tipo pré-definido espe- cifiçado pela Confiança-WS. Por exemplo, a política acima referida especifica um determinado tipo de ficha de seguran- ça que é exigido pela parte que confia 120 (isto é, "wst:TipoDeFicha").
Além de especificar as alegações e o tipo de ficha requeridos, a política de segurança pode especificar a auto- ridade de alegações específica exigida pela parte que confia ("sp:Emissor"), conforme mostrado abaixo:
<sp:sp de FichaEmitida:Uso="xs:qualquerURI" sp:IncluirFicha="xs:qualquerURI...>
<sp:Emissor>
<wsa:ReferênciaDePontoFinal>. . . </wsa : ReferênciaDePontoFinal> <sp:Emissor>
<sp:SolicitarGabaritoDeFichaDeSegurança>
<sp:SolicitarGabaritoDeFichaDeSegurança> <wsp:Política> <wsp:Política> ...
</sp:FichaEmitida>
A política pode omitir este elemento, deixando a determinação da autoridade de alegações apropriada para a parte principal.
Outros elementos podem ser especificados na polí- tica de segurança também, como, por exemplo, a recentidade da ficha de segurança exigida.
Com referência agora à Figura 4, uma vez que a parte principal 110 recebe a política de segurança da parte que confia 120, a parte principal 110 pode comunica-se com uma ou mais autoridades de alegações para reunir as alega- ções exigidas pela política. No exemplo mostrado, a parte principal 110 comunica os requisitos da política de seguran- ça ao transformador de alegações 130 e à autoridade de ale- gações 140.
Por exemplo, a parte principal 110 pode solicitar uma ou mais fichas de segurança da autoridade de alegações 140 utilizando o mecanismo de emissão descrito na Confiança- WS. Em um exemplo, a parte principal 110 encaminha para a autoridade de alegações 140 os requisitos de alegação conti- dos na política da parte que confia 120. A identidade da parte que confia 120 pode, mas não precisa, ser especificada na solicitação enviada pela parte principal 110 à autoridade de alegações 140. A solicitação pode incluir outros requisi- tos também, como, por exemplo, uma solicitação de ficha de segurança, conforme também descrito a seguir.
Um exemplo de solicitação de ficha de segurança é apresentado abaixo.
<wst:SolicitarFichaDeSegurança>
<wst:TipoDeFicha>
urn:oásis:nomes:tc:SAML:1.0:asserção </wst:TipoDeFicha>
<wst:Alegações
Ws :Dialeto=http://schemas.microsoft.com/ws/2005/05 /identity>
<ic:Alegação
URI="htpp://.../ws/2 005/05/identity/claims/givenname"/> </wst:Alegações>
</wst:SolicitarFichaDeSegurança>
Nas modalidades exemplares, a autoridade de alega- ções 140 pode ter sua própria política de segurança conforme especificada na PolíticaDeSegurança-WS e exigir autenticação da parte principal 110 antes que a autoridade de alegações 140 emita uma ficha de segurança à parte principal 110.
A autoridade de alegações 140 pode fornecer uma ou mais das alegações exigidas da parte que confia 120 pela po- lítica. Por exemplo, a autoridade de alegações 140 é progra- mada para gerar uma ou mais alegações exigidas pela políti- ca. O transformador de alegações 130 é programado para tra- duzir as alegações da autoridade de alegações 140 em uma ou mais alegações que possam ser entendidas pela parte que con- fia 120. Nas modalidades exemplares, o transformador de ale- gações 130 gera uma ou mais fichas de segurança 150 assina- das, que incluem a alegação ou alegações, conforme descrito a seguir.
A ficha de segurança 150 pode ser então emitida para a parte principal 110. Nas modalidades exemplares, o transformador de alegações 130 emite a ficha de segurança 150 para a parte principal 110 utilizando os mecanismos de resposta descritos na Confiança-WS.
Com referência agora à Figura 5, é mostrada uma ficha de segurança 150 exemplar. Na modalidade mostrada, a ficha de segurança 150 inclui uma ficha computacional 152 e uma ficha de exibição 154. A ficha computacional 152 inclui as alegações apresentadas pela autoridade de alegações 130 em um formato criptografado. Nas modalidades exemplares, o transformador de alegações 130 gera uma ficha computacional 152 em um formato criptografado que pode ser entendido (isto é, decodificado) pela parte que confia 120, conforme descri- to a seguir.
0 transformador de alegações 130 . gera também uma ficha de exibição 154. Geralmente, a ficha de exibição 154 inclui pelo menos um sumário das alegações que são incluídas na ficha computacional 152. A ficha de exibição 154 pode ser gerada em um formato que pode ser examinado pela parte prin- cipal 110 utilizando-se, por exemplo, o sistema de computa- dor 300, conforme descrito a seguir. Em alguns exemplos, a ficha de exibição 154 é gerada em um formato de texto sim- ples ou em um formato de Linguagem de Marcação de Hipertexto ("HTML"). Um exemplo de modalidade de ficha de exibição in- cluída como parte de uma resposta de ficha de segurança é mostrado abaixo.
<ic:FichaDeExibiçãoSolicitada>
<ic:FichaDeExibição xml:ling="en-us">
<ic:AlegaçãoDeExibição
URI="http://.../ws/2005/05/identity/claims/givenname"/>
<ic:IndicadorDeExibição>Nome Da- do</ic:IndicadorDeExibição>
<ic:ValorDeExibição>John</ic:VaIorDeExibição>
<ic:AlegaçãoDeExibição>
<ic:AlegaçãoDeExibição
URI="http://.../ws/2005/05/identity/claims/surname
"/>
<ic:IndicadorDeExibição>Último No- me</ic:IndicadorDeExibição>
<ic:ValorDeExibição>Doe</ic:VaIorDeExibição>
</ic:AlegaçãoDeExibição>
<ic:FichaDeExibição>
</ic:FichaDeExibiçãoSolicitada>
Segue-se uma descrição geral dos elementos mostra- dos acima na ficha de exibição:
• /ic:FichaDeExibiçãoSolicitada/ic:FichaDeExibição
- a ficha de exibição devolvida; • /ic: FichaDeExibiçãoSolicita- da/ic:FichaDeExibição/@xml:Iing - este atributo indica um identificador de linguagem, que utiliza os códigos de lin- guagem especificados no RFC 3066, no qual o conteúdo da fi- cha de exibição está localizado;
ic:FichaDeExibiçãoSolicitada/ic: FichaDeExibição/ic:AlegaçãoD eExibição - este elemento indica uma alegação individual de- volvida na ficha de segurança;
ic:FichaDeExibiçãoSolicitada/ic:FichaDeExibição/ic:AlegaçãoD eExibição/@URI - este atributo fornece o identificador único (URI) da alegação individual devolvida na ficha de seguran- ça;
ic:FichaDeExibiçãoSolicitada/ic: FichaDeExibição/ic:AlegaçãoD eExibição/ic:IndicadorDeExibição - este elemento opcional fornece um nome comum ou amigável para a alegação devolvida na ficha de segurança;
ic:FichaDeExibiçãoSolicitada/ic:FichaDeExibição/ic:AlegaçãoD eExibição/ic:Descrição - este elemento opcional fornece uma descrição da semântica para a alegação devolvida na ficha de segurança;
ic:FichaDeExibiçãoSolicitada/ic:FichaDeExibição/ic:AlegaçãoD eExibição/ic:ValorDeExibição - este elemento opcional forne- ce um ou mais valores exibiveis para a alegação devolvida na ficha de segurança; e
ic:FichaDeExibiçãoSolicitada/ic:FichaDeExibição/ic:TextoDeFi chaDeExibição (não mostrado) - este elemento opcional forne- ce uma representação textual alternativa da ficha inteira como um todo quando o conteúdo da ficha não é adequado para exibição como alegações individuais.
Em algumas modalidades, a ficha de segurança 150, que inclui a ficha computacional 152, é emitida de acordo com o padrão de Linguagem de Marcação de Asserção de Segu- rança ("SAML") promulgado pela Organização para o Avanço de Padrões de Informação Estruturados ("OÁSIS"). Por exemplo, a ficha de segurança 150 pode ser emitida de acordo com os pa- drões SAML 1.1 ou SAML 2.0. Podem ser também utilizados ou- tros padrões, tais como, por exemplo e sem limitação, um certificado X.509 e um bilhete Kerberos.
Além disso, a ficha de segurança 150 pode ser as- sinada ou endossada de maneira criptográfica pelo transfor- mador de alegações 130 por meio de um algoritmo conhecido. Em uma modalidade, por exemplo e sem limitação, é utilizada uma chave RSA assimétrica de 2048 bits. Em outras modalida- des, podem ser utilizados outros algoritmos de criptografa- ção, como, por exemplo, uma chave de criptografação assimé- trica codificada de base 64. Em uma modalidade, uma chave simétrica é utilizada como pré-definida. Desta maneira, no exemplo mostrado, uma parte como a parte que confia 120 pode verificar de maneira criptográfica que a ficha de segurança 150 se originou do transformador de alegações 140.
Nas modalidades exemplares, a ficha computacional 152 é vinculada à ficha de exibição 154 utilizando-se um ou mais algoritmos conhecidos, tais como, por exemplo e sem li- mitação, por meio de uma assinatura digital através de toda a mensagem de resposta da autoridade de alegações, que con- tém tanto a ficha computacional 152 quanto a ficha de exibi- ção 154.
Agora com referência à Figura β, o sistema de com- putador 300 exemplar da parte principal 110 pode incluir um intérprete 312 e um monitor 314. Na modalidade mostrada, por exemplo, o intérprete 312 pode ser um ou mais programas de aplicativo (ver os programas 228 descritos acima, por exem- plo) executáveis pelo sistema de computador 300. Além disto, o monitor 314 pode ser um dispositivo de saida, tal como uma impressora ou monitor (ver o monitor 242, por exemplo), que possa transmitir informações à parte principal 110.
Nas modalidades exemplares, o intérprete 312 é programado para interpretar a ficha de exibição 152 da ficha de segurança 150. Por exemplo, o intérprete 312 pode identi- ficar as alegações que são sumariadas na ficha de exibição 152, e o intérprete 312 pode exibir as alegações para a par- te principal 110 utilizando o monitor 314. Conforme também descrito a seguir, a parte principal 110 pode utilizar o su- mário das alegações incluídas na ficha de segurança 150 a- presentada no monitor 314 de modo a tomar uma decisão quanto a compartilhar ou não a ficha de segurança 150 com a parte que confia 120.
Agora com referência à Figura 7, a parte principal 110 pode emitir a ficha de segurança 150 para a parte que confia 120 de modo a satisfazer toda ou uma parte da políti- ca de segurança da parte que confia 120. Em um exemplo, a parte principal 110 pode emitir a ficha de segurança 150 pa- ra a parte que confia 120 vinculando a ficha de segurança 150 a uma mensagem de aplicativo utilizando os mecanismos de vinculação de segurança descritos na Segurança-WS.
Assim que a parte que confia 120 recebe a ficha de segurança 150, a parte que confia 120 pode verificar de ma- neira criptográfica a origem da ficha de segurança 150 assi- nada. A parte que confia 120 pode utilizar também as alega- ções na ficha computacional 152 da ficha de segurança 150 de modo a satisfazer a política de segurança da parte que con- fia 120 para autenticação da parte principal 110. Uma vez completa a autenticação, a parte que confia 120 pode dar a- cesso às mercadorias, serviços ou outras informações solici- tadas pela parte principal 110.
Agora com referência à Figura 8, é mostrado um mé- todo 400 exemplar para autenticar uma parte principal. O mé- todo 400 é descrito com referência a um exemplo não limita- dor, no qual a parte principal é o Empregado A. O Empregado A é empregado de uma empresa referida como "Empresa A", e a parte que confia é uma agência de viagens referida como "A- gência de Viagens A". A Empresa A tem parceria com a Agência de Viagens A para fazer planos de viagem para os empregados da Empresa A com desconto.
Na operação 410 do método 400, uma parte principal solicita informações de uma parte que confia. Na modalidade mostrada, por exemplo, a Empresa A utiliza um programa de aplicativo no computador do Empregado A para solicitar pla- nos de viagem do sítio da Rede da Agência de Viagens A. Em seguida, na operação 420, o computador do Empregado A recebe a política de segurança do sitio da Rede da Agência de Via- gens A. Esta política exige que o Empregado A submeta uma ficha de segurança com uma alegação estabelecendo que o Em- pregado A é um empregado da Empresa A antes que o Empregado A possa acessar os planos de viagem com desconto no sítio da Rede da Agência de Viagens A.
Na operação 430, o computador do Empregado A emite a política para uma autoridade de alegações, que é, no pre- sente exemplo, um serviço de ficha de segurança ou STS ope- rado pela Empresa A. O STS da Empresa A pode emitir uma fi- cha de segurança com uma alegação estabelecendo que o Empre- gado A é empregado da Empresa A. Por exemplo, a alegação po- de ser simplesmente "É Empregado da Empresa A = Verdadeiro". Em seguida, na operação 440, o computador do Empregado A re- cebe uma ficha de segurança assinada do STS da Empresa A. A ficha de segurança inclui uma ficha computacional e uma fi- cha de exibição, com a ficha computacional incluindo a ale- gação que estabelece que o Empregado A é um empregado da Em- presa A.
O controle passa então para a operação 450, e o computador do Empregado A apresenta ao Empregado A o sumário das alegações da ficha de segurança para exame. Em seguida, na operação 460, o Empregado A pode decidir se ou não emitir a ficha de segurança para o sítio da Rede da Agência de Via- gens A com base nas informações contidas na ficha de exibi- ção apresentada ao Empregado A.
Por exemplo, se a única alegação contida na ficha de segurança da Empresa A for a de que o Empregado A é um empregado da Empresa A (como, por exemplo, "É Empregado da Empresa A = Verdadeiro"), a ficha de exibição listará esta alegação para exame do Empregado A. Se o Empregado A se sen- tir confortável revelando esta informação para a Agência de Viagens A, o Empregado A pode emitir a ficha de segurança para o sitio da Rède da Agência de Viagens A na operação 465. O controle passa então para a operação 470, e o Empre- gado A ganha acesso aos planos de viagem com desconto soli- citados no sitio da Rede da Agência de Viagens A.
Se em vez disso o Empregado A decidir na operação 460 não emitir a ficha de segurança, o controle passa para a operação 480, e o Empregado A não emite a ficha de segurança para o sitio da Rede da Agência de Viagens A. Por exemplo, se a ficha de segurança da Empresa A incluir mais de uma ú- nica alegação sobre o Empregado Aeo Empregado A identifi- car uma alegação (examinando a ficha de exibição) de que o Empregado A se sente desconfortável compartilhando com a A- gência de Viagens A, o Empregado A pode decidir não emitir a ficha de segurança. Por exemplo, se a ficha de segurança da Empresa A incluir não só uma alegação estabelecendo que o Empregado A é um empregado da Empresa A, mas incluir também uma alegação com o número telefônico residencial do Emprega- do A, o Empregado A pode não se sentir confortável comparti- lhando o número telefônico residencial do Empregado A com a Agência de Viagens A. Nesta situação, o Empregado A pode e-, xaminar as informações de exibição da ficha de exibição da ficha de segurança, determinar que a ficha de segurança in- clui o número telefônico residencial do Empregado A e deci- dir não emitir a ficha de segurança para a Agência de Via- gens A.
Agora com referência à Figura 9, são mostrados de- talhes exemplares adicionais referentes à operação 450 do método 400 relacionada com o exame da ficha de exibição con- tida na ficha de segurança pela parte principal. Na operação 510, a ficha de exibição da ficha de segurança é interpreta- da pela parte principal. Em algumas modalidades, por exem- plo, um programa de aplicativo, tal como um plug-in de nave- gador da Rede ou um applet ou outro aplicativo, é programado para interpretar as informações contidas na ficha de exibi- ção. Em seguida, na operação 520, o aplicativo é programado para exibir as informações para a parte principal utilizando uma interface gráfica com o usuário, tal como uma interface com o navegador da Rede. Em modalidades alternativas, outras configurações são possíveis.
Com referência à Figura 10, por exemplo, é mostra- da uma interface com usuário 550 exemplar. A interface com usuário 550 exibe informações na ficha de exibição de uma ficha de segurança. A interface com usuário 550 inclui uma lista 555 das informações de exibição da ficha de exibição. No exemplo mostrado, as informações de exibição incluem in- formações sobre o empregador (a "Empresa A", por exemplo) e o número telefônico residencial ("999-999-9999", por exem- pio). A interface com usuário 550 inclui também um elemento de envio 557 e um elemento de cancelamento 559. A parte principal pode selecionar o elemento de envio 557 para envi- ar a ficha de segurança à parte que confia (a Agência de Vi- agens A, por exemplo) ou selecionar o elemento de cancela- mento 559 para abster-se de enviar a ficha de segurança.
Em modalidades alternativas, informações adicio- nais podem ser fornecidas na interface com usuário 550. Em algumas modalidades, por exemplo, podem ser listadas infor- mações sobre outras fichas de segurança que tenham sido en- viadas a uma parte que confia especifica e/ou informações sobre para onde a ficha de segurança especifica que está sendo exibida atualmente foi enviada anteriormente. Em ainda outras modalidades, as informações sobre a parte que confia para a qual a ficha de segurança vai ser enviada podem ser fornecidas na interface com usuário, e/ou podem ser apresen- tadas conexões para obter informações adicionais sobre a parte que confia. Outras configurações são possíveis.
Agora com referência à Figura 11, é mostrado um método 600 exemplar para uma autoridade de alegações e um transformador de alegações para gerar uma ficha de segurança que inclui uma ficha computacional e uma ficha de exibição. Mais uma vez, o método 600 é descrito com referência ao e- xemplo não limitador dado acima, no qual a parte principal é o Empregado A, a parte que confia é a Agência de Viagens A e a autoridade de alegações e o transformador de alegações são
a Empresa A.
Na operação 610, o STS da Empresa A recebe a polí- tica da Agência de Viagens A emitida pelo Empregado A. Em seguida, na operação 620, a Empresa A gera uma ficha compu- tacional que inclui uma ou mais alegações exigidas pela po- lítica de segurança. Na operação 630, é gerada uma ficha de exibição que inclui informações de exibição sobre as alega- ções contidas na ficha computacional. Em seguida, na opera- ção 640, a ficha de exibição é logicamente vinculada à ficha computacional de modo a se gerar a ficha de segurança. Fi- nalmente,. na operação 650, a ficha de segurança, que inclui a ficha computacional e a ficha de exibição, é emitida para o Empregado A, vinculadas de maneira criptográfica na mensa- gem de resposta.
Nas modalidades exemplares, uma ficha de exibição pode ser fornecida por pré-definição em cada ficha de segu- rança emitida por um transformador dé alegações. Em outras modalidades, uma ficha de exibição só é fornecida se a parte principal solicitar a ficha de exibição. Um exemplo de tal solicitação de ficha de exibição incluída em uma solicitação de ficha de segurança é apresentado a seguir.
<wst:SolicitarFichaDeSegurança>
<ic:SolicitarFichaDeExibição IdDeLing="en- us"/>
</wst:SolicitarFichaDeSegurança>
O atributo opcional "IdDeLing" indica o identifi- cador de linguagem para a ficha de exibição, que utiliza có- digos de linguagem especificados no RFC 3066.
Nas modalidades exemplares, se faltar a uma ficha de segurança a ficha de exibição, a parte principal é noti- ficada da falta da ficha de exibição e a parte principal po- de decidir se ou não emitir a ficha de segurança à parte que confia. Em outras modalidades, se nenhuma ficha de exibição for fornecida, nenhuma informação de exibição é apresentada à parte principal.
Nas modalidades exemplares, a parte principal pode examinar as informações de exibição da ficha de exibição e decidir se ou não emitir a ficha de segurança para a parte que confia. Em outras modalidades, a parte principal pode examinar as informações de exibição, mas não tem a opção de interromper a emissão da ficha de segurança para a parte que confia. Em outras palavras, uma vez "que a ficha de segurança é solicitada pela parte principal, a ficha de segurança é automaticamente emitida para a parte que confia assim que a ficha de segurança seja recebida pela parte principal.
Nas modalidades exemplares, apenas a parte de fi- cha computacional da ficha de segurança é emitida pela parte principal para a parte que confia. Em outras modalidades, a parte principal emite para a parte que confia toda a ficha de segurança, que inclui tanto a ficha computacional quanto a ficha de exibição.
Embora as modalidades exemplares aqui mostradas ilustrem uma ficha de segurança que é emitida por um trans- formador de alegações para uma parte principal e em seguida para uma parte que confia, em modalidades alternativas a fi- cha de segurança pode ser emitida diretamente do transforma- dor de alegações para a parte que confia. Em algumas modali- dades, por exemplo, uma ficha de segurança que inclui uma ficha computacional (e possivelmente uma ficha de exibição) pode ser emitida para a parte que confia, e uma outra ficha de segurança que inclui uma ficha de exibição (e possivel- mente a ficha computacional) pode ser emitida para a parte principal. Outras configurações são possíveis.
Embora as modalidades exemplares aqui mostradas ilustrem uma política de segurança que exige apenas uma úni- ca alegação e uma única ficha de segurança emitida por um transformador de alegações, em outras modalidades a política pode exigir várias alegações, e uma ou mais autoridades de alegações podem emitir uma ou mais fichas de segurança com uma ou mais alegações de modo a satisfazerem a política de segurança.
Embira em alguma das modalidades aqui reveladas a parte principal seja um indivíduo, em modalidades alternati- vas a parte principal pode ser uma empresa, uma organização, um computador ou outro dispositivo, um serviço ou qualquer outro tipo de entidade. Em uma modalidade alternativa, por exemplo, a parte principal é um dispositivo que é parte de uma rede. O sistema pode solicitar informações, tal como uma atualização de software, de outro dispositivo na rede que funciona como a parte que confia. A parte que confia pode exigir a autenticação da identidade do dispositivo antes que a parte que confia forneça a atualização solicitada. O dis- positivo pode solicitar de um ou mais transformadores de a- legações uma ou mais alegações exigidas pela política de se- gurança da parte que confia, e os transformadores de alega- ções podem fornecer ao dispositivo uma ou mais fichas de se- gurança que incluem fichas de exibição. O dispositivo pode ser programado para examinar o conteúdo das fichas de segu- rança e decidir se ou não emitir a ficha de segurança para a parte que confia com base em seu conteúdo. Se o dispositivo emitir a ficha de segurança para a parte que confia, a parte que confia pode então completar o processo de autenticação e fornecer a atualização solicitada ao dispositivo.
Pode haver diversas vantagens associadas a uma fi- cha de segurança que inclua tanto uma ficha computacional quanto uma ficha de exibição com informações de exibição que podem ser examinadas por uma parte principal. Por exemplo, uma parte principal pode efetivamente examinar o conteúdo de uma ficha de segurança que utiliza um programa de aplicativo no sistema de computador do cliente da parte principal pro- gramado para interpretar e exibir o conteúdo da ficha de e- xibição. Além disto, o exame pela parte principal do conteú- do da ficha de segurança permite que a parte principal tenha mais controle sobre as informações compartilhadas com as partes que confiam contidas na ficha de segurança. Além dis- to, o sistema que inclui uma ficha de segurança que inclui tanto uma ficha computacional quanto uma ficha de exibição vinculadas entre si pode fornecer uma pista audível caso o- corra a descoberta de informações não autorizadas sobre a parte principal.
As diversas modalidades descritas acima são apre- sentadas a título de ilustração apenas e não devem ser in- terpretadas como limitadoras. Os versados na técnica reco- nhecerão prontamente diversas modificações e alterações que podem ser feitas nas modalidades descritas acima sem que se abandonem o verdadeiro espírito e o alcance da revelação ou das reivindicações seguintes.
Claims (15)
1. Sistema para fornecer uma identidade digital, o sistema sendo CARACTERIZADO por compreender um transformador de alegações programado para gerar uma ficha de segurança que inclui uma ficha computacional e uma ficha de exibição, a ficha computacional incluindo uma ou mais alegações asso- ciadas à identidade de uma parte principal -β. a ficha de exi- bição incluindo informações de exibição sobre as alegações contidas na ficha computacional, onde as informações de exi- bição são configuradas para permitir que a parte principal veja a ficha de exibição.
2. Sistema, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que a ficha de segurança é assi- nada criptograficamente pelo transformador de alegações.
3. Sistema, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que a ficha computacional é vin- culada criptograficamente à ficha de exibição.
4. Sistema, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que a ficha de exibição é apre- sentada em um formato de texto simples.
5. Sistema, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que a ficha de exibição inclui um primeiro indicador de exibição programado para listar o nome de uma das alegações e um segundo indicador de exibição pro- gramado para listar o valor de uma das alegações.
6. Método para fornecer uma identidade digital, o método CARACTERIZADO por compreender: receber uma ficha de segurança que inclui uma fi- cha computacional e uma ficha de exibição, a ficha computa- cional incluindo uma ou mais alegações associadas à identi- dade de uma parte principal e a ficha de exibição incluindo informações de exibição sobre as alegações contidas na ficha computacional; e exibir as informações de exibição contidas na fi- cha de exibição para a parte principal de modo que a parte principal possa examinar o conteúdo da ficha de exibição.
7. Método, de acordo com a reivindicação .6, CARACTERIZADO por compreender também emitir a ficha de segu- rança para uma parte que confia.
8. Método, de acordo com a reivindicação 7, CARACTERIZADO por compreender também permitir que a parte principal decida se ou não emitir a ficha de segurança para a parte que confia.
9. Método, de acordo com a reivindicação 6, CARACTERIZADO pelo fato de que a ficha computacional é vin- culada à ficha de exibição de maneira criptográfica.
10. Método, de acordo com a reivindicação 6, CARACTERIZADO pelo fato de que a ficha de exibição inclui um primeiro indicador de exibição programado para listar o nome de uma das alegações e um segundo indicador de exibição pro- gramado para listar o valor de uma das alegações.
11. Meio passível de leitura por computador CARACTERIZADO por ter instruções passíveis de leitura por computador para executar etapas que compreendem: receber uma ficha de segurança que inclui uma fi- cha computacional e uma ficha de exibição, a ficha computa- cional incluindo uma ou mais alegações associadas à identi- dade de uma parte principal e a ficha de exibição incluindo informações de exibição sobre as alegações contidas na ficha computacional; e exibir as informações de exibição contidas na fi- cha de exibição para a parte principal de modo que a parte principal possa examinar o conteúdo da ficha de exibição.
12. Meio passível de leitura por computador, de acordo com a reivindicação 11, CARACTERIZADO por compreender também emitir a ficha de segurança para uma parte que confia.
13. Meio passível de leitura por computador, de acordo com a reivindicação 12, CARACTERIZADO por compreender também permitir que a parte principal decida se ou não emi- tir a ficha de segurança para a parte que confia.
14. Meio passível de leitura por computador, de acordo com a reivindicação 11, CARACTERIZADO pelo fato de que a ficha computacional é vinculada à ficha de exibição de maneira criptográfica.
15. Meio passível de leitura por computador, de acordo com a reivindicação 11, CARACTERIZADO pelo fato de que a ficha de exibição inclui um primeiro indicador de exi- bição programado para listar o nome de uma das alegações e um segundo indicador de exibição programado para listar o valor de uma das alegações.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US11/312,920 | 2005-12-19 | ||
| US11/312,920 US7788499B2 (en) | 2005-12-19 | 2005-12-19 | Security tokens including displayable claims |
| PCT/US2006/045386 WO2007075247A1 (en) | 2005-12-19 | 2006-11-22 | Security tokens including displayable claims |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| BRPI0620078A2 true BRPI0620078A2 (pt) | 2011-11-01 |
Family
ID=38175330
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| BRPI0620078-8A BRPI0620078A2 (pt) | 2005-12-19 | 2006-11-22 | fichas de segurança que incluem alegações exibìveis |
Country Status (8)
| Country | Link |
|---|---|
| US (1) | US7788499B2 (pt) |
| EP (1) | EP1964043A4 (pt) |
| JP (1) | JP5010615B2 (pt) |
| KR (1) | KR101319636B1 (pt) |
| CN (1) | CN101331509B (pt) |
| BR (1) | BRPI0620078A2 (pt) |
| RU (1) | RU2421789C2 (pt) |
| WO (1) | WO2007075247A1 (pt) |
Families Citing this family (65)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101048898B (zh) * | 2004-10-29 | 2012-02-01 | 麦德托尼克公司 | 锂离子电池及医疗装置 |
| US20070203852A1 (en) * | 2006-02-24 | 2007-08-30 | Microsoft Corporation | Identity information including reputation information |
| US8117459B2 (en) * | 2006-02-24 | 2012-02-14 | Microsoft Corporation | Personal identification information schemas |
| US8104074B2 (en) * | 2006-02-24 | 2012-01-24 | Microsoft Corporation | Identity providers in digital identity system |
| US8078880B2 (en) * | 2006-07-28 | 2011-12-13 | Microsoft Corporation | Portable personal identity information |
| US8060931B2 (en) | 2006-09-08 | 2011-11-15 | Microsoft Corporation | Security authorization queries |
| US20080066158A1 (en) * | 2006-09-08 | 2008-03-13 | Microsoft Corporation | Authorization Decisions with Principal Attributes |
| US20080065899A1 (en) * | 2006-09-08 | 2008-03-13 | Microsoft Corporation | Variable Expressions in Security Assertions |
| US20080066169A1 (en) * | 2006-09-08 | 2008-03-13 | Microsoft Corporation | Fact Qualifiers in Security Scenarios |
| US8095969B2 (en) | 2006-09-08 | 2012-01-10 | Microsoft Corporation | Security assertion revocation |
| US7814534B2 (en) | 2006-09-08 | 2010-10-12 | Microsoft Corporation | Auditing authorization decisions |
| US8201215B2 (en) | 2006-09-08 | 2012-06-12 | Microsoft Corporation | Controlling the delegation of rights |
| US8938783B2 (en) * | 2006-09-11 | 2015-01-20 | Microsoft Corporation | Security language expressions for logic resolution |
| US20080066147A1 (en) * | 2006-09-11 | 2008-03-13 | Microsoft Corporation | Composable Security Policies |
| US8656503B2 (en) | 2006-09-11 | 2014-02-18 | Microsoft Corporation | Security language translations with logic resolution |
| US8387108B1 (en) * | 2006-10-31 | 2013-02-26 | Symantec Corporation | Controlling identity disclosures |
| US8407767B2 (en) * | 2007-01-18 | 2013-03-26 | Microsoft Corporation | Provisioning of digital identity representations |
| US8087072B2 (en) * | 2007-01-18 | 2011-12-27 | Microsoft Corporation | Provisioning of digital identity representations |
| US8689296B2 (en) | 2007-01-26 | 2014-04-01 | Microsoft Corporation | Remote access of digital identities |
| US20080201338A1 (en) * | 2007-02-16 | 2008-08-21 | Microsoft Corporation | Rest for entities |
| US8301901B2 (en) * | 2007-03-06 | 2012-10-30 | Emc Corporation | System and method for expressing and evaluating signed reputation assertions |
| US8151324B2 (en) | 2007-03-16 | 2012-04-03 | Lloyd Leon Burch | Remotable information cards |
| US20090178112A1 (en) * | 2007-03-16 | 2009-07-09 | Novell, Inc. | Level of service descriptors |
| US20090228885A1 (en) * | 2008-03-07 | 2009-09-10 | Novell, Inc. | System and method for using workflows with information cards |
| US20090077627A1 (en) * | 2007-03-16 | 2009-03-19 | Novell, Inc. | Information card federation point tracking and management |
| US20090077118A1 (en) * | 2007-03-16 | 2009-03-19 | Novell, Inc. | Information card federation point tracking and management |
| US20090249430A1 (en) * | 2008-03-25 | 2009-10-01 | Novell, Inc. | Claim category handling |
| US20090204622A1 (en) * | 2008-02-11 | 2009-08-13 | Novell, Inc. | Visual and non-visual cues for conveying state of information cards, electronic wallets, and keyrings |
| US8370913B2 (en) * | 2007-03-16 | 2013-02-05 | Apple Inc. | Policy-based auditing of identity credential disclosure by a secure token service |
| US20090077655A1 (en) * | 2007-09-19 | 2009-03-19 | Novell, Inc. | Processing html extensions to enable support of information cards by a relying party |
| US7870597B2 (en) | 2007-04-10 | 2011-01-11 | Symantec Corporation | Method and apparatus for managing digital identities through a single interface |
| US20090063312A1 (en) * | 2007-08-28 | 2009-03-05 | Hurst Douglas J | Method and System for Processing Secure Wireless Payment Transactions and for Providing a Virtual Terminal for Merchant Processing of Such Transactions |
| KR20090051966A (ko) * | 2007-11-20 | 2009-05-25 | 한국전자통신연구원 | 웹사이트 로그인 처리 방법 및 장치 |
| US20090199284A1 (en) * | 2008-02-06 | 2009-08-06 | Novell, Inc. | Methods for setting and changing the user credential in information cards |
| US20090205035A1 (en) * | 2008-02-11 | 2009-08-13 | Novell, Inc. | Info card selector reception of identity provider based data pertaining to info cards |
| US20090204542A1 (en) * | 2008-02-11 | 2009-08-13 | Novell, Inc. | Privately sharing relying party reputation with information card selectors |
| US20090210400A1 (en) * | 2008-02-15 | 2009-08-20 | Microsoft Corporation | Translating Identifier in Request into Data Structure |
| US20090217368A1 (en) * | 2008-02-27 | 2009-08-27 | Novell, Inc. | System and method for secure account reset utilizing information cards |
| US8079069B2 (en) | 2008-03-24 | 2011-12-13 | Oracle International Corporation | Cardspace history validator |
| US20090272797A1 (en) * | 2008-04-30 | 2009-11-05 | Novell, Inc. A Delaware Corporation | Dynamic information card rendering |
| US8910257B2 (en) * | 2008-07-07 | 2014-12-09 | Microsoft Corporation | Representing security identities using claims |
| US20100011409A1 (en) * | 2008-07-09 | 2010-01-14 | Novell, Inc. | Non-interactive information card token generation |
| US20100031328A1 (en) * | 2008-07-31 | 2010-02-04 | Novell, Inc. | Site-specific credential generation using information cards |
| US8561172B2 (en) | 2008-08-29 | 2013-10-15 | Novell Intellectual Property Holdings, Inc. | System and method for virtual information cards |
| US20100095372A1 (en) * | 2008-10-09 | 2010-04-15 | Novell, Inc. | Trusted relying party proxy for information card tokens |
| EP2340503A4 (en) * | 2008-10-13 | 2013-01-09 | Hewlett Packard Development Co | SYSTEMS AND METHODS FOR SECURING SENSITIVE INFORMATION |
| US8083135B2 (en) * | 2009-01-12 | 2011-12-27 | Novell, Inc. | Information card overlay |
| US8632003B2 (en) | 2009-01-27 | 2014-01-21 | Novell, Inc. | Multiple persona information cards |
| US20100251353A1 (en) * | 2009-03-25 | 2010-09-30 | Novell, Inc. | User-authorized information card delegation |
| US8078870B2 (en) * | 2009-05-14 | 2011-12-13 | Microsoft Corporation | HTTP-based authentication |
| US20100299738A1 (en) * | 2009-05-19 | 2010-11-25 | Microsoft Corporation | Claims-based authorization at an identity provider |
| US8825745B2 (en) | 2010-07-11 | 2014-09-02 | Microsoft Corporation | URL-facilitated access to spreadsheet elements |
| US9582673B2 (en) | 2010-09-27 | 2017-02-28 | Microsoft Technology Licensing, Llc | Separation of duties checks from entitlement sets |
| EP2453377A1 (en) * | 2010-11-15 | 2012-05-16 | Gemalto SA | Method of loading data into a portable secure token |
| US9038155B2 (en) * | 2011-12-02 | 2015-05-19 | University Of Tulsa | Auditable multiclaim security token |
| US8725650B2 (en) * | 2012-01-26 | 2014-05-13 | Microsoft Corporation | Document template licensing |
| US9055314B2 (en) * | 2012-10-04 | 2015-06-09 | Verizon Patent And Licensing Inc. | Secure transfer of credit card information |
| EP2822216A1 (en) * | 2013-07-05 | 2015-01-07 | Gemalto SA | Method of privacy preserving during an access to a restricted service |
| US11349675B2 (en) * | 2013-10-18 | 2022-05-31 | Alcatel-Lucent Usa Inc. | Tamper-resistant and scalable mutual authentication for machine-to-machine devices |
| US10929858B1 (en) * | 2014-03-14 | 2021-02-23 | Walmart Apollo, Llc | Systems and methods for managing customer data |
| US10509898B2 (en) * | 2015-01-21 | 2019-12-17 | Jim Barney et al. | Enhanced security authentication methods, systems and media |
| US9934543B2 (en) | 2015-07-17 | 2018-04-03 | Bank Of America Corporation | Secure traveler framework |
| WO2018175980A1 (en) * | 2017-03-24 | 2018-09-27 | Comet Enterprises, Inc. | A credential management system for distributed authentication, and related systems and methods |
| JP6731887B2 (ja) * | 2017-06-27 | 2020-07-29 | Kddi株式会社 | 保守システム及び保守方法 |
| JP6696942B2 (ja) * | 2017-08-14 | 2020-05-20 | Kddi株式会社 | 車両保安システム及び車両保安方法 |
Family Cites Families (55)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPS63242751A (ja) | 1987-03-30 | 1988-10-07 | Matsushita Electric Ind Co Ltd | 乗物用テレビジヨン装置 |
| US5442704A (en) | 1994-01-14 | 1995-08-15 | Bull Nh Information Systems Inc. | Secure memory card with programmed controlled security access control |
| US5678015A (en) | 1995-09-01 | 1997-10-14 | Silicon Graphics, Inc. | Four-dimensional graphical user interface |
| US5898435A (en) | 1995-10-02 | 1999-04-27 | Sony Corporation | Image controlling device and image controlling method |
| US6005939A (en) * | 1996-12-06 | 1999-12-21 | International Business Machines Corporation | Method and apparatus for storing an internet user's identity and access rights to world wide web resources |
| FR2776415A1 (fr) | 1998-03-20 | 1999-09-24 | Philips Consumer Communication | Appareil electronique comportant un ecran et procede pour afficher des graphismes |
| US6161125A (en) | 1998-05-14 | 2000-12-12 | Sun Microsystems, Inc. | Generic schema for storing configuration information on a client computer |
| US20020056043A1 (en) | 1999-01-18 | 2002-05-09 | Sensar, Inc. | Method and apparatus for securely transmitting and authenticating biometric data over a network |
| JP2000259278A (ja) | 1999-03-12 | 2000-09-22 | Fujitsu Ltd | 生体情報を用いて個人認証を行う認証装置および方法 |
| US6553494B1 (en) | 1999-07-21 | 2003-04-22 | Sensar, Inc. | Method and apparatus for applying and verifying a biometric-based digital signature to an electronic document |
| US6785810B1 (en) | 1999-08-31 | 2004-08-31 | Espoc, Inc. | System and method for providing secure transmission, search, and storage of data |
| JP5265830B2 (ja) | 1999-10-20 | 2013-08-14 | コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ | 情報処理装置 |
| JP3580200B2 (ja) | 1999-10-28 | 2004-10-20 | ブラザー工業株式会社 | 記録情報処理装置および記録情報処理プログラムを記録したコンピュータ読み取り可能な記録媒体 |
| US6738901B1 (en) | 1999-12-15 | 2004-05-18 | 3M Innovative Properties Company | Smart card controlled internet access |
| AU2001238519A1 (en) | 2000-02-18 | 2001-08-27 | Vasco Data Security, Inc. | Field programmable smart card terminal and token device |
| US7409543B1 (en) * | 2000-03-30 | 2008-08-05 | Digitalpersona, Inc. | Method and apparatus for using a third party authentication server |
| JP4586237B2 (ja) | 2000-05-23 | 2010-11-24 | 沖電気工業株式会社 | 生体照合システム |
| JP2001344205A (ja) * | 2000-05-31 | 2001-12-14 | Nippon Telegr & Teleph Corp <Ntt> | サービス提供システムおよびサービス提供方法ならびに記録媒体 |
| GB0027685D0 (en) | 2000-11-13 | 2000-12-27 | Canon Kk | Filter based authoring tool |
| US7047418B1 (en) | 2000-11-29 | 2006-05-16 | Applied Minds, Inc. | Imaging method and device using biometric information for operator authentication |
| US6934913B2 (en) | 2000-12-07 | 2005-08-23 | International Business Machines Corp. | Graphical data entry screen |
| US20020175916A1 (en) | 2001-04-16 | 2002-11-28 | Nichols Michael R. | Method for presenting circular dialog windows |
| US7069447B1 (en) | 2001-05-11 | 2006-06-27 | Rodney Joe Corder | Apparatus and method for secure data storage |
| US7103773B2 (en) | 2001-10-26 | 2006-09-05 | Hewlett-Packard Development Company, L.P. | Message exchange in an information technology network |
| WO2003048892A2 (en) | 2001-11-14 | 2003-06-12 | Mari Myra Shaw | Access, identity, and ticketing system for providing multiple access methods for smart devices |
| US7610390B2 (en) | 2001-12-04 | 2009-10-27 | Sun Microsystems, Inc. | Distributed network identity |
| US7996888B2 (en) | 2002-01-11 | 2011-08-09 | Nokia Corporation | Virtual identity apparatus and method for using same |
| FR2836251B1 (fr) * | 2002-02-18 | 2004-06-25 | Gemplus Card Int | Dispositif et procede de securisation de donnees sensibles, notamment entre deux parties via un organisme tiers |
| US7308579B2 (en) | 2002-03-15 | 2007-12-11 | Noel Abela | Method and system for internationally providing trusted universal identification over a global communications network |
| US7162475B2 (en) | 2002-04-17 | 2007-01-09 | Ackerman David M | Method for user verification and authentication and multimedia processing for interactive database management and method for viewing the multimedia |
| US7096200B2 (en) | 2002-04-23 | 2006-08-22 | Microsoft Corporation | System and method for evaluating and enhancing source anonymity for encrypted web traffic |
| US6993659B2 (en) | 2002-04-23 | 2006-01-31 | Info Data, Inc. | Independent biometric identification system |
| AU2003249211A1 (en) | 2002-07-12 | 2004-02-02 | Checkspert, Inc. | System and method for remote supervision and authentication of user activities at communication network workstations |
| US6810480B1 (en) | 2002-10-21 | 2004-10-26 | Sprint Communications Company L.P. | Verification of identity and continued presence of computer users |
| US7284062B2 (en) | 2002-12-06 | 2007-10-16 | Microsoft Corporation | Increasing the level of automation when provisioning a computer system to access a network |
| GB0229894D0 (en) | 2002-12-21 | 2003-01-29 | Ibm | Methods, apparatus and computer programs for generating and/or using conditional electronic signatures and/or for reporting status changes |
| US8255978B2 (en) * | 2003-03-11 | 2012-08-28 | Innovatrend, Inc. | Verified personal information database |
| US8014570B2 (en) | 2004-11-16 | 2011-09-06 | Activcard, Inc. | Method for improving false acceptance rate discriminating for biometric authentication systems |
| US8108920B2 (en) | 2003-05-12 | 2012-01-31 | Microsoft Corporation | Passive client single sign-on for web applications |
| US7406601B2 (en) | 2003-05-23 | 2008-07-29 | Activecard Ireland, Ltd. | Secure messaging for security token |
| WO2005038555A2 (en) | 2003-09-12 | 2005-04-28 | Aristocrat Technologies Australia Pty Ltd | Communications interface for a gaming machine |
| US8190893B2 (en) | 2003-10-27 | 2012-05-29 | Jp Morgan Chase Bank | Portable security transaction protocol |
| US20050108575A1 (en) | 2003-11-18 | 2005-05-19 | Yung Chong M. | Apparatus, system, and method for faciliating authenticated communication between authentication realms |
| US20050124320A1 (en) | 2003-12-09 | 2005-06-09 | Johannes Ernst | System and method for the light-weight management of identity and related information |
| US20050125677A1 (en) * | 2003-12-09 | 2005-06-09 | Michaelides Phyllis J. | Generic token-based authentication system |
| US7634801B2 (en) | 2004-01-09 | 2009-12-15 | Panasonic Corporation | Multifunction machine and personal authentication method of multifunction machine |
| US7953759B2 (en) | 2004-02-17 | 2011-05-31 | Microsoft Corporation | Simplifying application access to schematized contact data |
| US7355110B2 (en) | 2004-02-25 | 2008-04-08 | Michael Tepoe Nash | Stringed musical instrument having a built in hand-held type computer |
| US20060010007A1 (en) | 2004-07-09 | 2006-01-12 | Denman John F | Process for using smart card technology in patient prescriptions, medical/dental/DME services processing and healthcare management |
| US20060206723A1 (en) | 2004-12-07 | 2006-09-14 | Gil Youn H | Method and system for integrated authentication using biometrics |
| US20060129509A1 (en) | 2004-12-09 | 2006-06-15 | Calpine Corporation, A Delaware Corporation | Database schema |
| EP1693801A3 (en) | 2005-02-16 | 2006-11-29 | David Schaufele | Biometric-based systems and methods for identity verification |
| US8117459B2 (en) | 2006-02-24 | 2012-02-14 | Microsoft Corporation | Personal identification information schemas |
| US8104074B2 (en) | 2006-02-24 | 2012-01-24 | Microsoft Corporation | Identity providers in digital identity system |
| US20080289020A1 (en) | 2007-05-15 | 2008-11-20 | Microsoft Corporation | Identity Tokens Using Biometric Representations |
-
2005
- 2005-12-19 US US11/312,920 patent/US7788499B2/en active Active
-
2006
- 2006-11-22 BR BRPI0620078-8A patent/BRPI0620078A2/pt not_active IP Right Cessation
- 2006-11-22 RU RU2008124907/08A patent/RU2421789C2/ru not_active IP Right Cessation
- 2006-11-22 KR KR1020087014863A patent/KR101319636B1/ko active IP Right Grant
- 2006-11-22 JP JP2008545618A patent/JP5010615B2/ja not_active Expired - Fee Related
- 2006-11-22 EP EP06838382A patent/EP1964043A4/en not_active Ceased
- 2006-11-22 WO PCT/US2006/045386 patent/WO2007075247A1/en active Application Filing
- 2006-11-22 CN CN2006800475254A patent/CN101331509B/zh not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| RU2008124907A (ru) | 2009-12-27 |
| CN101331509A (zh) | 2008-12-24 |
| JP5010615B2 (ja) | 2012-08-29 |
| JP2009520272A (ja) | 2009-05-21 |
| KR101319636B1 (ko) | 2013-10-17 |
| EP1964043A4 (en) | 2009-10-21 |
| WO2007075247A1 (en) | 2007-07-05 |
| KR20080078841A (ko) | 2008-08-28 |
| US7788499B2 (en) | 2010-08-31 |
| CN101331509B (zh) | 2012-06-27 |
| RU2421789C2 (ru) | 2011-06-20 |
| US20070143835A1 (en) | 2007-06-21 |
| EP1964043A1 (en) | 2008-09-03 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| BRPI0620078A2 (pt) | fichas de segurança que incluem alegações exibìveis | |
| US10530760B2 (en) | Relationship-based authorization | |
| US8156537B2 (en) | Method and system for access control using resource filters | |
| US8725536B2 (en) | Establishing a patient-provider consent relationship for data sharing | |
| US7016877B1 (en) | Consumer-controlled limited and constrained access to a centrally stored information account | |
| BRPI0806465A2 (pt) | provisão de represaentações de identidade digital | |
| US8024273B2 (en) | Establishing patient consent on behalf of a third party | |
| US20200134750A1 (en) | Field configuration of an instance of a client application based on a transactional role of a user of that client application to prevent unintended disclosure of confidential information when closing a real estate transaction | |
| US20090307755A1 (en) | System and method for facilitating cross enterprises data sharing in a healthcare setting | |
| US20010021928A1 (en) | Method for inter-enterprise role-based authorization | |
| TWI273811B (en) | Method and system of application server object-level security for distributed computing domains | |
| GB2448396A (en) | Managing user digital identities through a single interface | |
| US8479006B2 (en) | Digitally signing documents using identity context information | |
| CN102016872A (zh) | 使用文件锁来控制对文档的访问 | |
| BRPI0706703A2 (pt) | informações sobre identidade que incluem informações sobre reputação | |
| TW200811685A (en) | System and method for tracking the security enforcement in a grid system | |
| BR112020016003A2 (pt) | Sistemas e métodos para uso no gerenciamento de identidades digitais | |
| US20230024594A1 (en) | Systems and methods for safe social gatherings during a contagious pandemic | |
| TWI287740B (en) | Method of activating a device and computing system | |
| Chadwick et al. | Using the Internet to access confidential patient records: a case study | |
| US20140278542A1 (en) | Method and system for medical record collection and distribution | |
| Satybaldy et al. | Decentralized identity management for e-Health applications: state-of-the-art and guidance for future work | |
| CN101601022B (zh) | 数字身份表示的供应 | |
| Van Dyke | Establishing federated trust networks among web services | |
| TW201007590A (en) | Method and system for managing multi-antivirus-software |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| B08F | Application dismissed because of non-payment of annual fees [chapter 8.6 patent gazette] |
Free format text: REFERENTE A 4A ANUIDADE. |
|
| B08K | Patent lapsed as no evidence of payment of the annual fee has been furnished to inpi [chapter 8.11 patent gazette] |
Free format text: REFERENTE AO DESPACHO 8.6 PUBLICADO NA RPI 2161 DE 05/06/2012. |