Patent application number | Description | Published |
20080289020 | Identity Tokens Using Biometric Representations - An identity system and method uses biometric representation(s) in identity tokens. When a principal requests access to a relying party, the relying party may request an identity token containing a first claim about the principal and a biometric representation of the principal. An identity provider may then create the identity token, including a digital signature. The relying party may receive the identity token through a first channel and decode it. The relying party may also receive and use biometric information about the principal received through a second channel to verify the validity of the first claim at least in part through comparison of the biometric representation to the biometric information. | 11-20-2008 |
20090063466 | Resource selector, including for use in handheld devices - Described is a technology by which a resource selector traverses a hierarchical storage structure to enumerate its resources and provide a flat list of corresponding items. The user interacts with the flat list to select an item. The resource selector is particularly beneficial when incorporated into a handheld computing device. The resource selector may use a filtering criterion associated with an application program, e.g., the hierarchical storage may correspond to a file system, with the file extension (type) being the filtering criterion. A trigger coupled to the resource selector triggers the resource selector, in which the trigger may be incorporated into the application program, or may comprise an application-independent (e.g., operating system) component that knows which application program currently has focus and triggers the resource selector for that application. | 03-05-2009 |
20090113534 | GENERIC INTERACTIVE CHALLENGES IN A DISTRIBUTED SYSTEM - A challenge mechanism in which a challenge is issued from one message processor to another. In generating the challenge, the message processor may select any one or more of a number of available interactive challenge types, where each type of challenge type might use different user-originated information. Upon receiving the challenge, the challengee message processor may identify the challenge type based on information provided in the challenge, and perform different actions depending on the challenge type. The challengee message processor then generates an appropriate challenge response, and issues that challenge response to the challenger message processor. The challenger message processor may then validate the challenge response. | 04-30-2009 |
20090198761 | MESSAGE ENCODING/DECODING USING TEMPLATED PARAMETERS - Communication of a compressed message over a communication channel between message processors. The compressed message may be expressed in terms of an expressed or implicit template identification, and values of one or more parameters. Based on the template identification, the meaning of the one or more parameters may be understood, whereas the meaning of the parameter(s) may not be understood without a knowledge of the template. The template provides semantic context for the one or more parameters. The transmitting message processor may have compressed the message using the identified template. Alternatively or in addition, the receiving message processor may decompress the message using the identified template. The template itself need not be part of the compressed message as transmitted. | 08-06-2009 |
20090217362 | SELECTIVELY PROVISIONING CLIENTS WITH DIGITAL IDENTITY REPRESENTATIONS - A server provisions a client with digital identity representations such as information cards. A provisioning request to the server includes filtering parameters. The server assembles a provisioning response containing cards that satisfy the filtering parameters, and transmits the response to a client, possibly by way of a proxy. The provisioning response may include provisioning state information to help a server determine in subsequent exchanges which cards are already present on the client. A client may keep track the source of information cards and discard cards which a server has discarded. A proxy may make the provisioning request on behalf of a client, providing the server with the proxy's own authentication and with a copy of the request from the client to the proxy. | 08-27-2009 |
20090217383 | LOW-COST SECURITY USING WELL-DEFINED MESSAGES - Well-defined messages may be transmitted from a sending device to a recipient device in order to reduce the processing and resource requirements imposed by the security semantics of general message standards. The well-defined messages may include an expression of a collective intent of the security semantics included in the message. The expression of the security semantics within the message simplifies the discovery process for devices processing the message. The well-defined message may also require that any intermediary devices that process the well-defined message as it is transmitted from the sender device to the receiver device follow the expressed collective intent of the security semantics. If an intermediary device cannot understand or adhere to the expressed intent, the well-defined message must be rejected. | 08-27-2009 |
20090307744 | AUTOMATING TRUST ESTABLISHMENT AND TRUST MANAGEMENT FOR IDENTITY FEDERATION - A federated identity verification system includes an identity provider that provides security tokens ultimately to one or more relying parties for access by the client to services at a relying party. Specifically, the relying party can validate the security token from an identity provider (whether directly or via a client) when verifying that the received security token conforms to security configuration data previously exchanged with the identity provider. To establish the trust relationship, the identity provider and one or more relying parties exchange security configuration information through an agreed-to communication channel. The security configuration information indicates the settings that the other party needs to use for establishing, maintaining, and/or monitoring the trust relationship. The communication channel allows both parties to flexibly and continually synchronize changes to security configurations, and thus maintain, change, or end the trust relationship automatically, as desired. | 12-10-2009 |
20090319795 | DIGITALLY SIGNING DOCUMENTS USING IDENTITY CONTEXT INFORMATION - Creating a token for use by an entity when digitally signing documents. In a computing environment, a digital identity representation for an entity is accessed. The digital identity representation includes information identifying identity attributes about the entity and capabilities of an identity provider that provides tokens for use by the entity. Context information is accessed. The context information includes information about one or more of which, how or where the attributes for the entity identified in the digital identity representation will be used. A security token is created from the information in the digital identity representation and the context information. The security token makes assertions by the identity provider. The assertions are based on the information in the digital identity representation. The token further includes information related to at least a portion of the context information. | 12-24-2009 |
20090320095 | OBTAINING DIGITAL IDENTITIES OR TOKENS THROUGH INDEPENDENT ENDPOINT RESOLUTION - A federated identity provisioning system includes relying parties, identity providers, and clients that obtain tokens from identity providers for access to a relying party's services. When a client contacts a new relying party, the relying party provides information that the client can independently resolve and evaluate for trustworthiness. For example, the relying party provides a generic domain name address. The client can then resolve the domain name address over various, authenticated steps to identity an endpoint for a digital identity provisioning service. The client can further interact with and authenticate the provisioning service (e.g., requiring digital signatures) to establish a trust relationship. Once determining that the client/user trusts the provisioning service, the client/user can then provide information to obtain a digital identity representation. The client can then use the digital identity representation with the corresponding identity provider to obtain one or more tokens that the relying party can validate. | 12-24-2009 |
20100037303 | Form Filling with Digital Identities, and Automatic Password Generation - In one implementation, form field(s) of a form of a website or application are populated with data obtained using a digital identity, and the populated form field(s) are submitted to the website or application. A form field specification specifying information about the form fields of the form is obtained. A user selects or creates a digital identity. Data is obtained using the digital identity, and the data is used to provide values to the form. The data is submitted to the website or application. In another implementation, a username and password are automatically generated. The username and password that are generated meet parameters that may be specified by the website or application. The username and password are submitted to the website or application for a purpose such as registration or authentication, and stored away for future authentication. | 02-11-2010 |
20100240413 | Smart Card File System - An application programming interface (API) may receive high level file commands and implement those commands using the storage mechanism on a smart card. The smart card may have a processor and storage mechanism and may communicate to a host device using a packet based communication protocol, such as ADPU. The API may translate the high level file commands into one or more ADPU commands, communicate with the smart card, receive APDU responses, and translate the responses into high level file commands. A high level file command may allow access to a file using long file names, a hierarchical directory structure, and may allow creating, writing, reading, and deleting a file. Some embodiments may have more complex functions for navigating and manipulating a hierarchical directory structure, as well as defining metadata including access privileges and file types to individual files. | 09-23-2010 |
20100293385 | HTTP-BASED AUTHENTICATION - A system and method for authenticating an HTTP message. A relying party may respond to a request from a requester by sending an HTTP message with authentication specifications to the requester. The requester responds with a new request that adheres to a scheme specified by the relying party. A framework allows for a security token to be located in an HTTP header or a message body, with various options such as fragmenting the token available. An option allows for cryptographically binding the security token to the body of a message. An authentication framework provides for an implementation by an HTTP stack or by an application. | 11-18-2010 |
20100293604 | INTERACTIVE AUTHENTICATION CHALLENGE - A system and method for authenticating a request for a resource. A requester sends the request for a resource to a server in a first protocol. The server may send a challenge message to the requester. In response, the requester employs a challenge handler that performs an interactive challenge with a challenge server in a second protocol. Upon successful conclusion of the interactive challenge, the challenge handler synchronizes with a request handler, which sends a challenge response message to the server. The server may then enable access to the requested resource. | 11-18-2010 |
20110154465 | TECHNIQUES FOR ACCESSING DESKTOP APPLICATIONS USING FEDERATED IDENTITY - Techniques for extending federation services to access desktop applications are herein described. In addition to the foregoing, other aspects are described in the claims, drawings, and text forming a part of the present disclosure. | 06-23-2011 |
20110307938 | Integrating Account Selectors with Passive Authentication Protocols - Described is using a client-side account selector in a passive authentication protocol environment (such as OpenID) in which a relying party website trusts the authentication response from an identity provider website. The account selector may access and maintain historical information so as to provide user-specific identity provider selection options (rather than only general identity provider selection options). The account selector is invoked based upon an object tag in the page, e.g., as invoked by a browser extension associated with that particular object tag. The account selector may communicate with a reputation service to obtain reputation information corresponding to the identity providers, and vary its operation based upon the reputation information. | 12-15-2011 |
20120167158 | SCOPED RESOURCE AUTHORIZATION POLICIES - Resource authorization policies and resource scopes may be defined separately, thereby decoupling a set of authorization rules from the scope of resources to which those rules apply. In one example, a resource includes anything that can be used in a computing environment (e.g., a file, a device, etc.). A scope describes a set of resources (e.g., all files in folder X, all files labeled “Y”, etc.). Policies describe what can be done with a resource (e.g., “read-only,” “read/write,” “delete, if requestor is a member of the admin group,” etc.). When scopes and policies have been defined, they may be linked, thereby indicating that the policy applies to any resource within the scope. When a request for the resource is made, the request is evaluated against all policies associated with scopes that contain the resource. If the conditions specified in the policies apply, then the request may be granted. | 06-28-2012 |
20130125199 | TESTING ACCESS POLICIES - A policy that governs access to a resource may be tested against real-world access requests before being used to control access to the resource. In one example, access to a resource is governed by a policy, referred to as an effective policy. When the policy is to be modified or replaced, the modification or replacement may become a test policy. When a request is made to access the resource, the request may be evaluated under both the effective policy and the test policy. Whether access is granted is determined under the effective policy, but the decision that would be made under the test policy is noted, and may be logged. If the test policy is determined to behave acceptably when confronted with real-world access requests, then the current effective policy may be replaced with the test policy. | 05-16-2013 |
20130347063 | HANDLING CLAIMS TRAVERSING SECURITY BOUNDARIES - Sharing security claims across different security contexts. A method includes, for a first security context, identifying a first set of security claims. The method further includes for the first security context identifying a second set of security claims from the first set of security claims that is allowed to be sent from the first security context. The first set of security claims is modified to create the second set of security claims. For a second security context, security claim requirements are identified. The second set of security claims is modified to satisfy the security claim requirements for the second security context. | 12-26-2013 |