Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: A system and method for provisioning digital identity representations (“DIRs”) uses various techniques and structures to ease administration, increase accuracy, and decrease inconsistencies of a digital-identity provisioning system. Various methods are provided for creating new DIRs, requesting DIRs, notifying principals of available DIRs, and approving issuance of new DIRs.

Abstract: 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.

Abstract: A digital identity system includes a principal including an identity selector programmed to receive a security policy from a relying party, review a plurality of digital identities associated with the principal, and request one or more claims related to an identity of the principal from an identity provider. The principal is further programmed to receive one or more security tokens including the claims from the identity provider, and to forward the security tokens to the relying party.

Abstract: A digital identity system includes a principal including an identity selector programmed to receive a security policy from a relying party, review a plurality of digital identities associated with the principal, and request one or more claims related to an identity of the principal from an identity provider. The principal is further programmed to receive one or more security tokens including the claims from the identity provider, and to forward the security tokens to the relying party.

Abstract: A system and method for provisioning digital identity representations (“DIRs”) uses various techniques and structures to ease administration, increase accuracy, and decrease inconsistencies of a digital-identity provisioning system. A system is provided using a common identity data store for both DIR issuance and identity token issuance, decreasing synchronization issues. Various methods are provided for creating new DIRs, notifying principals of available DIRs, and approving issuance of new DIRs.

Abstract: A method for forming BiCMOS integrated circuits and structures formed according to the method. After forming doped wells and gate stacks for the CMOS devices and collector and base regions for the bipolar junction transistor, an emitter layer is formed within an emitter window. A dielectric material layer is formed over the emitter layer and remains in place during etching of the emitter layer and removal of the etch mask. The dielectric material layer further remains in place during source/drain implant doping and activation of the implanted source/drain dopants. The dielectric material layer functions as a thermal barrier, to limit out-diffusion of the emitter dopants during the activation step.

Abstract: 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.

Abstract: A user interacts with a client containing personal identity information operable to identify the user to a relying party when the relying party is presented with claims comprising a portion of the personal identity information. The personal identity information includes one or more claims, metadata associated with the one or more claims, and backing data associated with the one or more claims. The user may initiate use of another client and seek to be identified by the relying party while interacting with the other client by first porting the personal identity information to the other client. Porting the personal identity information includes binding the personal identity information and sending the bound personal identity information to a receiving client.

Abstract: 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.

Abstract: 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.