Abstract: The communication of a network message from a first network node in a particular location to a second network node in a manner that the second network node determines that the network message was processed the network message in the particular location. For instance, the particular location might be a geographic location or a network topographical location. The proof of location is accomplished by using a signed proof of location included by the first network node within the network message. The network message is then received by the second network entity. The second network entity then uses the signed proof of location data structure as input to a process that determines that the network message was processed at least based on the signed proof of location data structure.

Abstract: The communication of a network message from a first network node in a particular location to a second network node in a manner that the second network node determines that the network message was processed the network message in the particular location. For instance, the particular location might be a geographic location or a network topographical location. The proof of location is accomplished by using a signed proof of location included by the first network node within the network message. The network message is then received by the second network entity. The second network entity then uses the signed proof of location data structure as input to a process that determines that the network message was processed at least based on the signed proof of location data structure.

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 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: Techniques for implementing flexible identity issuance systems to allow users to specify one or more evaluation processes to be carried out by the issuance system based on input identity information. These evaluation processes may be specified in any suitable manner to allow an issuance system to carry out any process for generating output identity information for a content consumer. In some embodiments, an evaluation process may be specified to the issuance system as a series of tasks to be carried out, where each task corresponds to a conditions and an action to be taken when the condition is met. In this way, an evaluation process may be simply and easily specified by what operations are to be carried out, rather than how the operations are to be carried out. An issuer may interpret the specification to determine a functional process for carrying out the tasks.

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

Abstract: Managing peer-to-peer application components. A method may be performed, for example, at a computer system that includes application components including peer-to-peer application components. The peer-to-peer application components allow the computer system to communicate with other agents, such as host computers, operating systems, frameworks, application code and the like, in a peer-to-peer fashion. The computer system includes a launch pad module for coordinating the peer-to-peer application components. The method includes providing an extensible interface that allows peer-to-peer application components to be registered with the launch pad module. Peer-to-peer application components are registered with the launch pad module. Requests are accepted from agents directed to the peer-to-peer application components registered with the launch pad module. Launch functions are performed for the peer-to-peer application components registered with the launch pad module in response to the requests.

Abstract: A cryptographic session key is utilized to maintain security of a digital identity. The session key is valid only for a limited period of time. Additional security is provided via a bimodal credential allowing different levels of access to the digital identify. An identity token contains pertinent information associated with the digital identity. The identity token is encrypted utilizing public-key cryptography. An identifier utilized to verify the validity of the digital identity is encrypted with the cryptographic session key. The encrypted identity token and the encrypted identifier are provided to a service for example. The service decrypts the encrypted identity token utilizing public key cryptography, and decrypts, with the cryptographic session key obtained from the identity token, the encrypted identifier. If the identifier is determined to be valid, the transaction proceeds normally. If the identifier is determined to be invalid, the transaction is halted.

Abstract: Implementations of the present invention relate in part to optimizations to peer-to-peer communication systems. For example, one implementation relates to use of a smart transceiver that creates, caches, and manages communication channels dynamically between peers. Another implementation relates to use of a central tracking object that can be used to efficiently register and distribute peer messages among the various peers. In one implementation, the central tracking object is shared amongst peers in the group. Still another implementation relates to associating peer groups with namespaces, and for including peer groups of one namespace within still other peer groups of different namespaces. These and other aspects of the invention can also be used to ensure delivery intent of a given peer message is preserved, and to ensure that optimal numbers of messages are communicated to any given peer at any given time.

Abstract: Implementations of the present invention relate in part to optimizations to peer-to-peer communication systems. For example, one implementation relates to use of a smart transceiver that creates, caches, and manages communication channels dynamically between peers. Another implementation relates to use of a central tracking object that can be used to efficiently register and distribute peer messages among the various peers. In one implementation, the central tracking object is shared amongst peers in the group. Still another implementation relates to associating peer groups with namespaces, and for including peer groups of one namespace within still other peer groups of different namespaces. These and other aspects of the invention can also be used to ensure delivery intent of a given peer message is preserved, and to ensure that optimal numbers of messages are communicated to any given peer at any given time.

Abstract: Implementations of the present invention relate in part to optimizations to peer-to-peer communication systems. For example, one implementation relates to use of a smart transceiver that creates, caches, and manages communication channels dynamically between peers. Another implementation relates to use of a central tracking object that can be used to efficiently register and distribute peer messages among the various peers. In one implementation, the central tracking object is shared amongst peers in the group. Still another implementation relates to associating peer groups with namespaces, and for including peer groups of one namespace within still other peer groups of different namespaces. These and other aspects of the invention can also be used to ensure delivery intent of a given peer message is preserved, and to ensure that optimal numbers of messages are communicated to any given peer at any given time.

Abstract: Example embodiments provide for a rule-based wizard type tool for generating secure policy documents. Wizard pages present a user with general Web Service security options or questions at a user interface, which abstracts the user from any specific code, e.g., XML code, used for creating a Web Service policy document. Based on user input selecting general criteria, security rules are accessed and evaluated for automatically making choices on behalf of the user for creating a secure policy document. Other embodiments also provide for presenting the user with an easily understandable visual representation of selected criteria of a policy document in, e.g., a tree like structure that shows relationships between various elements of the criteria.

Abstract: Example embodiments provide for a rule-based wizard type tool for generating secure policy documents. Wizard pages present a user with general Web Service security options or questions at a user interface, which abstracts the user from any specific code, e.g., XML code, used for creating a Web Service policy document. Based on user input selecting general criteria, security rules are accessed and evaluated for automatically making choices on behalf of the user for creating a secure policy document. Other embodiments also provide for presenting the user with an easily understandable visual representation of selected criteria of a policy document in, e.g., a tree like structure that shows relationships between various elements of the criteria.

Abstract: Example embodiments provide for processing policies that include policy assertions associated with incoming or outgoing messages of an application in a distributed system, without having to have code within the application for executing the policy assertions. When a message is received by a Web service engine, a policy document associated with an application may be accessed for identifying objects corresponding to policy assertions within the policy document. The objects identified can then be used to generate assertion handlers, which are software entities that include executable code configured to determine if messages can satisfy requirements described by the policy assertions.

Abstract: Methods, systems, and computer program products for processing network messages in a manner that simplifies messaging application logic. Processing layers of a messaging system architecture that may include a transport layer, a channel layer, a send/receive layer, a service/client layer, and potentially others, are aware of an End Point Reference (“EPR”) within a network message The transport layer retrieves message data from a message transport. The channel layer de-serializing the network message consistent with an underlying type system. The send/receive layer filters and dispatches the network message to messaging logic (other layers or application logic) based on the EPRs. The service/client message layer dispatches the network message to messaging application logic based on the EPRs.

Abstract: A mechanism for performing role-based authorization of the one or more services using security tokens associated with received service request messages. This role-based authentication is performed regardless of the type of security token associated with the received service request messages. Upon receiving a service request message over the network for a particular service offered by the service providing computing system, the service providing computing system accesses a security token associated with the received service request message. Then, the computing system identifies one or more roles that include the identity associated with the security token, and correlates the roles with the security token. These correlated roles are then used to authorize the requested service. This mechanism is performed regardless of the type of the security token.

Abstract: Within a distributed system, e.g., Web service environment, the present invention provides a way for identifying policies mapped to messages associated with an application, without having to have code within the application for determining what policies should apply to the messages. A centralized Web service engine is provided that receives incoming and outgoing messages associated with an application. The messages have associated with them destination endpoint identifiers and request-reply properties, which the Web service engine can access. The Web service engine can then use at least the identifiers and properties for scanning policy message files corresponding to the applications in order to identify what policies, if any, should be applied to the messages.

Abstract: The present invention provides for maintaining security context during a communication session between applications, without having to have executable code in either application for obtaining or generating a security context token (SCT) used to secure the communication. On a service side, a configuration file is provided that can be configured to indicate that automatic issuance of a SCT is enabled, thereby allowing a Web service engine to generate the SCT upon request. On the client side, when a message is sent from the client application to the service application, a policy engine accesses a policy that includes assertions indicating that a SCT is required for messages destined for the Web service application. As such, the policy engine requests and receives the SCT, which it uses to secure the message.

Abstract: A message handling computing system that provides security across even transport-independent communication mechanisms, and which allows for convenient extension of security to different security token types, and may provide end-to-end security across different transport protocols. The message handling computing system includes a message handling component configured to send and receive network messages having security tokens. The message handling component interfaces with an expandable and contractible set of security token managers through a standardized application program interface. Each security manager is capable of providing security services for messages that correspond to security tokens of a particular type. A security token plug-in component registers new security token managers with the message handling component.

Abstract: A sending computer system relays a message or a processing request through one or more configurable routers prior to the message or request reaching an ultimate destination. A client at the sending computer system can indicate a routing preference for the message or request, and a module can supplement or override the routing preference by adding or deleting a router from a router list contained within the message or request. This change can be done based on router data, as well as based on content within the message. One or more intermediate routers along the routing path can perform a similar function as the module. The ultimate destination, or receiving computer system, verifies that it is the appropriate recipient of the message or request, and then accepts the data associated with the message or request. This has application to many types of messaging systems, including simple object access protocols.