MXPA01008795A - Mutual authentication in a data network using automatic incremental credential disclosure - Google Patents

Abstract

In client/server computing, especially in the field of e-commerce, digitally signed credentials are passed between client and server to develop trust between the parties. However, this requires that one party discloses its credentials (which could be considered sensitive) to the other party before the disclosing party knows anything about the receiving party (someone has to go first). To solve this problem, the invention implements a negotiation of credential disclosure called automatic incremental credential disclosure. Each credential held at a local site is associated with an access policy which is based on opposing site credentials. Incoming requests for credentials are logically combined with the access policies to derive further negotiation responses.

Description

MUTUAL AUTHENTICATION IN A DATA NETWORK USING AUTOMATIC INCREMENTAL CREDENTIAL DESCRIPTION Field of the Invention The invention relates to the client / server computation field (also known as "distributed"), wherein a computing device ("the client") requests another computing device ("the server") to perform part of the client's work. Background of the Invention The client / server computation has been increasingly important in recent years in the world of information technology. This type of distributed computing allows a software process (for example, the customer) that runs on a machine to delegate some of its work to a software process (for example, the server), which runs on another machine, for example. be better suited to perform that task. The client and the server can also separate software processes running on the same machine. In these client / server systems, it is very important that the client and the server develop a sufficient level of trust with each other before they engage in significant interaction, because the information that can be exchanged during the client's request for processing server and / or the result of server processing that is returned to the client, can be highly sensitive information. Often, the client and the server have no prior relationship with each other and thus must enter into some kind of initial conversation in order to determine if they can trust each other before they describe some potentially sensitive information. A good example of when this is particularly useful is the case where the client is a World Wide Web viewer application that sends e-commerce requests on the Internet to a server application on the global network. In the initial interaction between these parties, the client of the network and the server of the network have no prior relationship and the network client for example can be very reluctant to provide a credit card number to the network server by Internet . It is known in the prior art to exchange credentials (ie, digitally signed estimates by the issuer or credential issuer with respect to the credential owner) between a client and a server, in order to build trust between them. A credential is signed when using the issuer's private key and can be verified by using the sender's public key. The credential adds one or more owner attributes, each attribute consists of a name / value pair and describes some property of the owner estimated by the shipper. Each credential also contains the public key of the owner of the credential. The owner can use the corresponding private key to answer challenges or otherwise demonstrate ownership of the credential. The owner can also use the private key to subscribe to another credential owned by a third entity. In this way, as is well known in the prior art, credentials can be combined into chains, where the owner of a credential is the issuer of the next credential in the chain. These chains can be presented to track a trusted network from a known entity (the issuer of the first credential in the 'chain) to the entity that submits or presents, in which trust must be established. The entity that presents is the owner of the last credential in the chain. The entity that presents can demonstrate the ownership of that credential by demonstrating the possession of the correspondence of the private key with the public key contained therein. The other support credentials are property of entities with whom the entity that presents or proposes have direct or indirect relationships, and although they are not owned by the entity that presents, the entity that presents maintains and presents copies of them. Each support credential contains the public key whose correspondence with the private key is used to subscribe the next credential in the chain. All credentials presented are relevant to demonstrate a (possible indirect) relationship between the presenting entity and the known entity issuing the first credential in the chain. The nature of that relationship can be inferred by inspecting the attributes of the credentials in the chain. Multiple chains may be presented to establish a higher degree of confidence or to demonstrate additional properties of the entity it presents and its relationships with known entities. The techniques in the previous specialty to use credentials in establishing mutual trust can be divided into two basic approaches. The first approach is described by A. Frier, P. Karlton, and P. Kocher, "The SSL 3.0 Protocol" (Netscape Communications Corporation), November 18, 1996; T. Dierks, C. Alien, "The TLS Protocol Version 1.0" (The TLS Protocol Version 1.0) draft-ietf-tls-protocol-06.txt, November 12, 1998; S. Farrell, "TLS Extensions for Attribute Certify Based Authorization" (TLS Extensions for Certificate of Attributes Based on Authorization), draft-ietf-tls-attr-cert-01.txt, August 20, 1998. This approach will be referred to as the SSL approach, as used by SSL, TLS and TLS with extensions for authorization based on attribute-certificate. In the SSL approach, the client and the server can exchange credentials as follows. The server starts the negotiation by unilaterally describing a pre-selected credential. You can include a request for client credentials, including the type of credential that the server can accept and, in the case of certificate-attribute, a template that indicates the required attributes. The second approach is described by N. Ching, V. Jones and M.Winslett, "Authorization in the Digital Library: Secure Access to Services across Enterprise Boundaries" (Authorization in the Digital Library: Secure Access to Services across Borders of Companies ), Minutes of the ADL '96 Forum on Advances in Research and Technology in Digital Libraries, Washington, DC, May 1996, available at http: // drl. cs. uiuc edu / security / pubs. html, - and also by M. Winslett, N. Ching, V. Jones, and I. Slepchin, "Using Digital Credentials on the World Wide Web" (Using digital credentials in the global network) Journal of Computer Security, 5, 1997, 255-267, available at http: // drl. cs. uiuc edu / security / pubs. html We will call this second approach the digital credential approach. In this approach, when a request is made for service by a client to a server without adequate aggregate credentials, the server sends the client a policy that regulates that service. A policy is a credential formula that is a logical combination of required credentials and restrictions expressed in the attributes they contain. Policies can be used to characterize required properties of the entity it presents and its relationships with known entities. Upon receiving this policy as a request for credentials, the client has the opportunity to select private credentials to submit to authorization service. When sending policies to clients, the servers download the credential selection. The practice also allows different servers to have very different policies, requiring different client attributes and accepting credentials issued by different authorities. These two approaches to the prior art support the server that sends a request for credentials to the client, including a characterization of credentials that would be acceptable to the server. However, the present inventors have noted deficiencies in this state of the art as follows. In the SSL approach, there is no opportunity for the server to authenticate information about the client before describing the server credential. The server can consider its credential as highly confidential, and in this way if the client and the server fail to establish mutual trust, then the server has passed on to the client a portion of highly sensitive (confidential) information. Also, if the credential described by the server does not satisfy the client, the client has no opportunity to request additional credentials from the server. This can be a serious problem when the client and the server have no prior relationship. In that case, it is unlikely that any simple credential shipper could be an acceptable authority on all server attributes of interest to all customers. The disadvantage of the previous systems based on the digital credentials approach arises with credentials that the client would like to describe only servers in whom a certain degree of trust has already been established. Previous systems developed using the digital credential approach have supported credential-client presentation policies that divide the services into equivalence classes and then, for each equivalence class, assign each customer credential to one of two categories. Credentials in the first category can be presented with any service request in the equivalence class. Those in the second category may only appear after the user's interactive consultation for authorization. These queries allow the user to move credentials from the second category to the first, allowing subsequent automatic submission. However, the mechanism is not fully automated since it requires a user to be available to make trusted decisions when new service classes are contacted. Within the context of the digital credential approach, an alternate technique is briefly described by Winslett et al. (Cited above), whereby the client may require server credentials to release the description of their own credentials. This technique can be used to implement a negotiation where there is a single application for credentials for each participant. Each service is associated with a policy that is sent to the client by the server when the client requests that service. When the scenario is reversedIt is not clear what purpose is intended to have servers that present credentials to clients. One possibility is to establish trust in the client for the general purpose of interacting with the server. Another is to establish trust specifically to stimulate clients to describe their credentials. In that last case, the approach could be used to allow a client to require server credentials before describing any of their own credentials to that server. However, it would be impossible for the server to request client credentials before describing its own credentials. Doing so would introduce a cyclical dependence, leading the negotiation to stagnation, because in this model all customer credentials are regulated by the same policy and therefore any subsequent server request would lead to an identical request from the client. SUMMARY OF THE INVENTION In accordance with a first aspect, the present invention provides a data processing apparatus for use in a client / server network, wherein a client data processing apparatus sends a request for data processing to the apparatus of server data processing and the server data processing apparatus performs data processing based on the request and returns a response to the client data processing apparatus, the data processing apparatus comprising: storage means, for store a plurality of local site credentials; means for receiving a first credential request from a data processing apparatus of the opposite side, the credentials requested by the first credential request, are local site credentials stored in the storage means that satisfy a first logical expression that is provided with the first credential request; and means for sending to the opposite site data processing apparatus a second credential request that depends on the contents of the first credential request, the credentials requested by the second credential request are opposite site credentials satisfying a second logical expression that is provided with the second credential request. According to a second aspect, the invention provides a method for operating the data processing apparatus of the first aspect. According to a third aspect, the invention provides a computer program product stored in a computer readable storage medium for, when a computer is run, carrying out the method steps of the second aspect. According to a fourth aspect, the invention provides a computer data signal incorporated in a carrier wave, the signal has program elements for instructing a computer to carry out the method steps of the second aspect.

In this manner, the present invention extends the digital credential approach of the prior art to support a sequence of interdependent requests for credential descriptions. In order to allow a sequence of interdependent requests by credential description, different credentials must be regulated by different policies. The request for credentials that the client receives from the server is not by individual credentials or even by a specific combination of credentials. On the contrary, it is for arbitrary credentials that satisfy a logical expression. In the present invention, the login request for credentials is logically combined with the credentials in current possession of the client, together with the access control policy associated with each of these credentials, to derive a new request for site credentials. opposite. In this manner, the present invention comprises any derivation of a responder request by credentials from a local credential access policy and a credential entry request, except in the case where the responder request is independent of the entry request . And in the latter case, excepted, a sequence of descriptions of incremental credentials is impossible due to the cyclical dependencies as discussed above. No previous solution explicitly recommends using credentials as a basis to regulate the description of credentials. There is no mention of the problem of interdependencies between credentials and the need to require different credential access policies for different policies to avoid some stagnation. There are automation aspects of establishing trust between strangers that keep their private credentials that have been overlooked in the past. There is also no prior mention of dynamically synthesizing credential requests during the establishment of trust. Previous solutions have selected the credential request content of pre-existing policies. The invention in this way provides fully automated trust negotiation between third-party data processing apparatuses that protect their credentials. Simple negotiation strategies can be applied immediately. More sophisticated techniques that balance or compensate for successful negotiation considerations and avoid description of accidental information regarding credentials can also be considered.

An important advantage that is provided by the present invention is that it allows to establish confidence automatically, even when the parties involved require some knowledge of their counterparts, before describing some of their credentials to them. In previous solutions, each participant only had one opportunity to present credentials in each negotiation, and one of the participants had to leave first. Unlike the previous solutions, the present invention does not require any participant in the negotiation to describe their credentials immediately, without any knowledge of the other participant. To obtain a highly sensitive service, a client may have to present a highly sensitive credential that describes only after having first obtained a moderately sensitive server credential. For this, the server in turn may require some less sensitive credential. The present invention makes it possible to negotiate a sequence of arbitrary length of pending credential exchanges. In some cases, this sequence may allow a higher degree of trust to be negotiated than a single exchange can. This makes the new solution potentially very important in the context of electronic business (ie e-business) among strangers, where automated business negotiations will require a, high degree of confidence that the participants negotiate in good faith and handle the information described properly. The present invention provides a basis for non-automatic negotiation of incremental credential description. It does this by associating with each credential in a local site, an access policy based on credentials of the opposite site, and by providing the logical combination of that policy with login requests by credentials to derive negotiation responses. BRIEF DESCRIPTION OF THE DRAWINGS The present invention will be better understood from the detailed description of the preferred embodiments thereof, w is given below in conjunction with the following drawing figures: Figure 1 is a block diagram showing the components of software according to a preferred embodiment of the present invention; Figure 2 is a flow chart showing the processing steps carried out by a local site according to a preferred embodiment of the present invention; and Figure 3 is an exemplary synchronization diagram showing a sequence of requests and responses according to a preferred embodiment of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS In the preferred embodiment of the present invention, a plurality of data processing units are in communication with each other through a data communication network. In Figure 1, a local site 10 is illustrated in communication over the network (not shown) with an opposite site 11, both of these sites are data processing units in the preferred embodiment (in another embodiment they may be separate processes running in the same data processing unit). Following the second approach of the prior art [Ching, et al., Winslett et al.] Discussed above, a data processing unit (ie negotiation participant) is represented in confidence negotiations by a security agent 101 as illustrated in Figure 1. Each negotiation participant can receive a request for credentials (application for credentials 21, Figure 1).

(Each application for credentials takes the form of a credential formula as in the second approach of the prior art discussed above). This request is for the description of local site credentials to the opposite site. The purpose of this description may already be to release service, or release the description of opposite site credentials required to advance in the negotiation of trust. The immediate problem in advance of the negotiation is to determine whether the local site 10 has enough confidence in the opposite site 11 to describe the credentials requested and if not, build a request for credentials from the opposite site (exit request for credentials 22) that can establish that confidence. As illustrated in Figure 1, each site associates a credential access policy 102 with each of its own credentials 103. That access policy identifies opposing site credentials that can release description of the local site credential. When a request for credentials 21 is received, the security agent 101 determines what action is appropriate. That determination is described in the following paragraphs, in conjunction with the architectural diagram of Figure 1, and with the stages (31-37) of the flow chart illustrated in Figure 2. The actions of the Security Agent begin at stage 31 where it receives from the opposite site an application for credentials 21 in the form of a logical expression. If the local site finds in step 32 that it does not have credentials that satisfy the request (and some type of response is required, as when the security agent belongs to a server), a rejection may be sent in step 33. Otherwise the security agent must determine in step 34 whether enough confidence has already been established in the opposite site to justify a combination of credentials that the request satisfies. Specifically, opposite site credential 23 accompanying application 21 or already in high-speed buffer or locally cache 104 may satisfy access policies 102 that regulate local credentials 103 which, in turn, satisfy application for admission 21 In that case, the combination of local credentials, released in this manner and satisfying the entry request 21, can be sent immediately to the opposite site 11, as illustrated in step 35. When the current entry request is received as In response to a prior request by the local site, that prior request may be repeated in step 35 in conjunction with the credentials sent, under the consideration that those credentials will now generate confidence to release compliance with the previous request. On the other hand, step 34 may determine that the locally available opposing site credentials (23 and / or 104) are not sufficient to release a combination of local property credentials 103 that satisfy the entry request 21. In that case, in step 36 security agent 101 derives an exit request 22 for additional credentials of the opposite side 11 by logically combining the login request for credentials 21 with the access policy to local site credential 102. These credentials of opposite site are requested for the purpose of releasing local site credentials that have been requested by the opposite site. In this way, to avoid unnecessarily requesting credentials, the referral process simplifies the request by taking into account which of the requested credentials the local site currently holds 103 and even more, by not requesting additional site credentials to free site credentials. local that are already released by accumulated credentials 104 and / or income 23 from the opposite site. In step 37, when the security agent 101 sends the request for additional credentials from the opposite site to release local site credentials, you can select at the same time to provide some local site credentials that are already released. For example, you can provide some local site credentials mentioned in the credential entry application 21. While you risk unnecessary credential description, this negotiation strategy decision may increase the probability and speed with which negotiation succeeds. . It does so by increasing the likelihood that the opposing site will immediately provide the requested credentials and by decreasing the possibility that the opposing site concludes that there is cyclical interdependence within the combined credential access policies of the two sites and therefore both abort the negotiation. As illustrated in Figure 1, when a local site is a server and the opposite site is a client, the content of the message that enters the client server can include a service request 24. This service request is a typical initial message in a negotiation of description of credentials between a client and a server. Upon receiving a request for service 24, the server security agent 101 applies a service regulation policy (not shown in Figure 1) to determine if the opposing site credentials 23 accompanying the request are sufficient to satisfy the policy. of service regulation (this is also true of the second approach of the prior art discussed above). Although some servers consider each page request independently ie stateless and therefore do not retain client credentials after each client request, others may, like clients, cache opposite site credentials 104. These servers may use credentials of opposite site in cache 104 as well as those 23 that accompany the request to try to satisfy its service regulation policies. Whether credentials from cached opposite site are used or not 104, when the service regulation policy is satisfied, the service is authorized 25. Otherwise security agent 101 returns to the service regulation policy in the form of an exit request by credentials 22. The description of credentials is then negotiated between the client and the server and if successful, the client can repeat the service request with sufficient credentials added to authorize the service. An example of this exchange is illustrated in Figure 3. In Figure 3, in step 1, the client sends a request for a particular service to the server site, requesting that the server perform a particular processing task (for example, read access to a database) on behalf of the client. No credentials are added to the request, supposedly because the client does not know the credentials policy that regulates that service. In stage 2, the server security agent sends the client's security agent the service regulation policy, which informs the client's security agent of his options regarding credentials to present in order to generate sufficient confidence in the party. of the server security agent to perform the requested service. This policy constitutes a request for credentials, and is treated as such when it is received by the client's security agent in stage 3. The client's security agent responds according to the stages discussed above in conjunction with the flow diagram of the client. Figure 2. That is, the client security agent receives the request by credentials (step 31) (to authorize the service requested in step 1). It determines that the client has at least one combination of credentials that satisfies the request (step 32). It determines that there are not enough locally available server credentials to satisfy the access control policies of the constituent credentials of any of those successful combinations (step 34). Therefore a new request is derived (step 36) designed to release this successful combination of its own credentials which in turn will release the desired service. Finally, send that request to the server without any added credentials. (In a variant of the example, the client can at this point add to the exit request some credentials requested by the server in stage 2, for example if their access control policies allow them to be described without prior knowledge of the server). Step 4 begins when the server security agent receives the request by credentials sent by the client at the end of step 3. This request is again processed as discussed above in conjunction with the flowchart of Figure 2. The The server security agent determines that it has credentials that will satisfy the request of the security agent to the client (step 32) and that they are not all released for description to the client security agent (step 34) (the server security agent has not yet has received no credentials from the client's security agent). It derives a request (step 36) for intended client credentials to release the credentials requested by the client's security agent, and sends them (step 37) to the client's security agent, along with some credentials that the client security agent request and whose access control policies allow them to be described without first seeing any customer credentials.

Step 5 begins when the client security agent receives the request and the credentials sent by the server security agent at the end of step 4. The client security agent determines that it has credentials that satisfy the request (step 32) , but no successful combination is composed of credentials whose access control policies are released by the server credentials received to date (step 34). In an effort to free up more of their own credentials, the client security agent then derives a new request for server credentials as follows (step 36). Modifies the entry request by credentials when replacing references to credentials that it does not have with the false constant. Then it replaces each remaining occurrence of a credential, which it owns, by the access policy for that credential. The resulting formula, like those access policies, is expressed in terms of opposite site credentials. Then it is combined with the request for credentials previously sent by the client to the server at the end in stage three, which may not yet be completely satisfied by the credentials received from the server. The security agent simplifies the resulting conjunction, to avoid unnecessarily requesting credentials. Simplification is done by removing from the formula each occurrence of a credential that the client's security agent has already received and that satisfies the constraints of attributes expressed in the formula. The resulting formula is simplified, treating eliminated credentials as constant truth and simplifying logical connectives of conformity. (An occurrence of truth in a conjunction is simply eliminated, an empty conjunction is replaced by truth, a truth that contains disjunction is replaced by truth). Finally, the client's security agent sends the formula that he has derived and simplifies in this way, sending equally any credentials requested in the login request, whose access control policies are released by server credentials received at the beginning of this stage . Stage 6 begins when the server security agent receives the. application and the credentials sent to it by the client's security agent at the end of step 5. The server security agent determines that it has credentials that satisfy the request (step 32), but not all of them are released (step 34) ). A new application is then derived by client credentials (step 36) by a procedure very similar to the one illustrated on the client side of stage 5. The main difference in the server-side derivation a on the client side is that, in In the negotiation strategy illustrated in this example, the server does not reuse its previous requests for client credentials. Stage 7 begins when the client security agent receives the request and the credentials sent by the server security agent at the end of the stage 6. The security agent of the client determines that he has at least one combination of credentials that satisfies the request (step 32). The client has now received sufficient credentials from the server to release this combination of credentials (step 34). So it sends such a combination to the server at the end of stage 7, along with the same request for credentials that it has sent to the server at the end of stage 5. Stage 8 starts when the server security agent receives the repeated request and the credentials sent by the client at the end of the stage 7. The server security agent determines that it has credentials that satisfy the request (step 32) and that are released (step 34) because its access control policies are satisfied by client credentials sent by the client at the end of the stage 7. Then send those credentials to the client. Step 9 starts when the client's security agent receives the credentials sent by the server at the end of stage 8. Those credentials, along with credentials received by the client's security agent at the beginning of stages 5 and 7, and cached by the client's security agent since that time, it satisfies the customer credentials access control policies that satisfy the policies that regulate the service received by the client's security agent in stage 7. The client's security agent then sends a combination of released credentials that together satisfy the policy that regulates the service. It also repeats the original service request. Stage 10 begins when the server security agent receives the service request and the credentials sent by the client at the end of stage 9. These credentials satisfy the service regulation policy, in such a way that the service is authorized, performed and its result is returned. It is received by the client in stage 11, which concludes the example. EXEMPLARY NEGOTIATION The example presented here illustrates the eleven stages of the hypothetical negotiation illustrated schematically in Figure 3. It is intended to illustrate the manipulation of formulas, as determined by the preferred embodiment of the present invention. The formulas are expressed informally. The example is to illustrate only and is not intended to accurately characterize any negotiation, credentials or actual policies. Hypothetical credentials Each credential entry begins with the abbreviation used for that credential in the rest of the example. Security Practices Credentials - Performed by both the Client and the Server We assume that security practices standards consultants issue credentials for security practices to entities whose security infrastructure qualifies. The rating can be used by third parties to estimate the probability that information provided to the entity will be accidentally described by that entity. To allow a qualifying entity to demonstrate that it meets the requirements of a certain degree while keeping private the grades it fails to meet, a separate credential is issued for each grade, with an attribute called "passed" that has the true value when the requirements for that degree are met, false otherwise.

In our example, there are four degrees of safety practices, low, medium, high and very high. The maximum degree satisfied by the server is "high" and the maximum degree satisfied by the client is "medium". Each entity protects the credentials it has by degrees in which it fails. If the credentials by degrees passed were not so well protected, the difference in protection would make it evident that degrees were failed. In such a way that credentials for all grades (except the lowest grades) are protected, whether the owner passes or fails. Degree of safety practices very high. High Sensitivity Degree of High Security Practices. Average sensitivity Degree of Safety Practices Medium. Sensitivity Low Degree of Low Safety Practices. Non-Sensitive Client Credentials Contract Destination Contracts. Issued by the party waiting for the shipment of articles. Extremely Sensitive You need to be sure that the information does not leak to a competitor.

Credit Letter of Credit. Issued by a creditor to the owner. Medium-high sensitivity. Loading and Discharge Installation Storage agreement in the loading and unloading facility of origin. Issued by the administration of the loading and unloading facility. Average sensitivity It is required to avoid dissemination to the competitors. Reception-S Reception of Previous Boarding. Issued by the charterer who has previously transported items. The customer in this example does not have any previous shipping receipt. Account Account established with the server / charterer. Issued by charterer In this example, the client does not have an account established with the server / charterer. Org-B Business Organization Membership Credential. Issued by a business organization, such as the International Chamber of Commerce. Not sensitive Server Credentials Reception Receipt of Previous Delivery. Issued pro owner of items transported in the past. Not Sensible Bail Bond Certification. Issued by Bonding Agency. Non-sensitive Ref Reference Manufacturers. Issued by manufacturers who wish to recommend the charterer based on previous business experience. Low sensitivity The server in this example has at least two of these from different manufacturers. B-Org Organization Membership Credential Business. Issued by a business organization such as the International Chamber of Commerce. Not sensitive Hypothetical Policies The policy that regulates a customer or server X credential, is designated by Xcnente ° ^ servi or respectively. The policies expressed here are not complete. In particular, they do not express requirements for support credentials, which are essential. Although they are not completely complete or realistic, the clauses introduced by "where" illustrate the use of credential attribute restrictions. For example, the client access control policy for your destination contract credential requires reference from two different credential shippers. Policies that Regulate Client Credentials Contract = High and Re ^ Y Ref2 Y (Bond O (Reception! And Reception2)) where High. passed = true Y Ref 1 shipper other than Ref2. shipper Y Reception! . shipper? Reception2. Issuer Credito = Med Y Refi Y Ref2 where Med. happened = true And Refx. shipper? Ref2. shipper Loading and unloading installation = Med Y (Bond 0 (Reception! And Reception.,)) where Med.pasó = c i e r t y Y Recepoiónj. shipper? Reception2. Very High shipper = High And B-Org where High. happened = true Altocl? = Med Y B-Orcf where Med.pasó = Medf? Close? Low = And B-Org where Low. passed = true Bajocl? ente = No Political Credentials Required to Regulate Server Credentials Receptionserv = No Credentials Required Fianzaserv? doI = No Credentials Required Refserv dor = Low where Low. happened = true Very Altoserv dor = High And B-Org where High. passed = true Altoserv? dor = Med Y B-Org where Med.passed = true Medserv? dor = Low And B-Org where Low. passed = true Bajoserv dor = No Required Credentials Policies that regulate the Server Service to Schedule a Board Account 0 (Installation of loading and unloading Y ((S-Reception! And S-Reception2) 0 Contract) And Credit) where S-Reception! . shipper? S-Reception2. Issuer Negotiation Stages The example is a successful negotiation. Applications for credentials are sent at the end of stages 2 to 7. Client credentials requested by the server at the end of stage 2 are required to authorize services. The rest of the negotiation serves to establish enough confidence for the client to describe those credentials to the server. The credentials requested in stages 3 through 7 are required to free access to credentials that in turn are required for successful negotiation.

At each stage where a site receives a request for credentials, the site has credentials that satisfy the request and stage 32 of Figure 2 is successful. At the end of each stage, the operational security agent sends to the opposite site all the credentials requested in the login request, whose access policies are released by opposing site credentials that are available locally. These are labeled below as "credentials requested, released." In the negotiation strategy illustrated by this example, the client security agent caches and repeats previous requests, while the server does not. Stage 1 - Client Sends Request for Service: Se Schedule Departure Dates Stage 2 - Server Receives Request, Returns the Service Regulation Policy. The server needs to establish confidence that the client is actually in the market for boarding services and can pay for it. Send the service regulation policy to schedule a shipment shown above. Stage 3 - The Client Receives Application for Credentials to Authorize the Service.

The server credentials available locally: None Credentials requested, not released: None (stage 34 failures) Application for entry, simplified by eliminating credentials that the client does not have: Installation of loading and unloading And Contract and Credit This formula with each credential replaced by his access policy (among claudators): [Med Y (Deposit O (Receipt and Reception2)) where Med. passed = true and Reception. shipper? Reception2 . sender] Y [High Y Ref: Y Ref2 Y (Bail O (Reception! Y Reception2)) where High. happened = true And Refx. shipper? Ref2. Shipper And Reception! . shipper? Reception2 .shipper] Y [Med Y efj Y Ref2 where Med. happened = true Y Refj. shipper? Ref2. sender] The formula, simplified as it is sent to the server as a credential request at the end of stage 3: High Y Refi Y Ref2 Y (Bail O (Reception! Y Reception2)) And Med where High. happened = true and Refi. shipper? Ref2. Shipper and Reception! . shipper? Reception2 .dispatcher And Med. Passed = true Stage 4 - Service Receives Application by Credentials Client Credentials available locally: None Credentials requested, released: Bond (stage 34 fails) The application for admission, with each credential replaced by its access policy (between claudatores): [Med Y B-Org where Med. happened = true] Y [Low where Low. passed = true] Y [Low where Low. passed = true] Y ([No credentials required] OR [No Credentials Required] AND [No Credentials Required])) AND [Low And B-Org where Low. passed = true] This simplified formula, as it is sent to the original client of stage 4: Med Y Low And B-Org where Med. passed = true and Low. happened = true. Stage 5 - Client Receives Application for Credentials and One Server Credential Server credentials available locally: Bail Credentials requested, released: Low, B-Org (stage 34 fails) The application for admission, with each credential replaced by its access policy (among claudatores): [Bajo Y B-Org en Bajo. passed = true] Y [No Credentials Required] AND [No Credentials Required] This formula in conjunction with the request to send to the server at the end of stage 3: [[Low AND B-Org where Low. passed = true] Y [No Credentials Required] Y [No Credentials Required]] Y [High Y Refi Y Ref2 Y (Bail O (Reception! Reception2)) And Med where High. passed = true Y Refx. shipper? Ref2. Shipper And Recetion! . shipper? Reception2. sender AND Med. passed = true] The request, simplified by removing locally available server credentials, as sent to the server at the end of step 5: Low And B-Org And High And Refx And Ref2 And Med Where Low. happened = true And High. happened = true And Ref? . shipper? Ref2. shipper Y Med. asó = true Stage 6 - Server Receives Application for Credentials and Two Client Credentials Client credentials available locally: Low, B-Org Credentials requested, released: Low, B-Org, Med (Stage 34 fails) The application for admission with each credential replaced by its access policy (between claudátores): [No Credentials Required] Y [No Credentials Required] Y [Med Y B-Org where Med. Happened = true] Y [Low where Low. passed = true] Y [Low And B-Org where Low. passed = true] The request, simplified by eliminating locally available customer credentials, as sent to the client at the end of stage 6: Med where Med. happened = true Stage 7 - Client Receives Application by Credentials and Three Server credentials Server credentials available locally: Bail (cached from stage 5), Low, B-Org, Med Credentials requested released: Med (Stage 34 is successful) Request sent to the server at the end of stage 5 (see stage 35): Low And B-Org And High And efi And Ref2 And Med Wherever Low. happened = true and High. happened = true and Ref? . shipper? Ref2. sender AND Med. happened = true The request, simplified by eliminating locally available server credentials as sent to the server at the end of stage 7: High Y Refi and Ref2 where High. passed = true Y Ref! • shipper? Ref2. Issuer Stage 8 - Server Receives Application for Credentials and One Client Credential Client credentials available locally: Low, B-Org (both cached from stage 6), Med Credentials requested released: High, Refx, Ref2 (Stage 34 succeeds, credentials sent in stage 35) Stage 9 - - Client Receives Three Server Credentials They end up releasing the Client Credentials that Authorize Service Since no more requests for credentials are received, the relevant request (Stage 31) becomes once again the policy that regulates the service received at the beginning of stage 3. Server credentials available locally: Deposit (Received at the stage 5) Low, B-Org, Med (received in stage 7) High, Refx, Ref2 (Received in stage 9) Credentials requested, released: Installation of loading and unloading, Contract, Credit (Stage 34 is successful) Application for service, Program of Dates of Shipment, first shipment in stage 1, now repeated with the requested credentials added. Stage 10 - Server Receives Service Request and Three Added Credentials, Authorizes Service The server confirms that the aggregated credentials satisfy the service regulation policy and authorizes the requested service. The result of that service is returned at the end of Stage 10. Stage 11 - Customer Receives Service Requested

Claims (17)

1. CLAIMS 1. A data processing apparatus for use in a client / server network, wherein a client data processing apparatus sends a data processing request to the server data processing apparatus and the data processing apparatus. server data performs data processing based on the request and returns a response to the client data processing apparatus, the data processing apparatus is characterized in that it comprises: storage means for a plurality of local site credentials; means for receiving a first credential request from an opposite site data processing apparatus, the credentials requested by the first credential request, are local site credentials stored in the storage means that satisfy a first logical expression that is provided with the first credential request; and means for sending to the opposite site data processing apparatus a second request for credentials, which depends on the contents of the first credential request, the credentials requested by the second credential request, are credentials of the opposite side that satisfy a second logical expression that is provided with the second credential request.
2. 2. The apparatus according to claim 1, characterized in that the storage means also store a plurality of credential access policies, each policy regulating access to a corresponding local site credential, based on opposing site credentials.
3. The apparatus according to claim 2, characterized in that it further comprises: means for determining whether the first logical expression that is provided with the first credential request is satisfied by a combination of local site credentials stored in the storage means, and when a determination is made that the first logical expression that is provided with the first credential request is satisfied by a combination of local site credentials stored in the storage means, they determine whether the credential access policies stored in the credentials means storage and that regulate the combination of local site credentials that satisfy the first logical expression that is provided with the first credential request, are satisfied by opposing site credentials that are available locally; sending means for the combination of local site credentials to the opposing site data processing apparatus when the determining means determine that the credential access policies are satisfied by locally available opposing site credentials; and logic combining means for, when the determining means determine that the credential access policies are not satisfied by locally available opposing site credentials, logically combining (a) the first request for received credentials, (b) the site credentials stored credentials and (c) stored credential access policies to derive the second logical expression in the second credential request for opposing site credentials which, together with the locally available credentials of the opposite site, satisfy the local credential access policies that regulate the combination of local site credentials that satisfy the first logical expression that is provided with the first request for local site credentials.
4. The data processing apparatus according to claim 1, characterized in that the opposite site data processing apparatus is a client data processing apparatus.
5. The data processing apparatus according to claim 1, characterized in that the opposite site data processing apparatus is a server data processing apparatus.
6. 6. The apparatus according to claim 1, characterized in that opposing site credentials are cached in local storage.
7. The apparatus according to claim 3, characterized in that the determination means, finding that this combination does not exist, sends a message that transports that finding to the opposite site data processing apparatus.
8. 8. The apparatus according to claim 1, characterized in that the client / server network is Internet.
9. 9. A method for operating a data processing apparatus, for use in a client / server network, wherein a client data processing apparatus sends a data processing request to the server data processing apparatus and the server data processing apparatus performs data processing based on the request and returns a response to the client data processing apparatus, the data processing apparatus comprises a storage means, for storing a plurality of local site credentials; the method is characterized in that it comprises the steps of: receiving a first credential request from an opposite site data processing apparatus, the credentials requested by the first credential request, are local site credentials stored in the storage means, which satisfy a first logical expression that is provided with the first credential request; and sending to the opposite site data processing apparatus a second credential request that is dependent on the contents of the first credential request, the credentials requested by the second credential request are opposite site credentials that satisfy a second logical expression that is provided with the second credential request.
10. The method according to claim 9, characterized in that the storage means also store a plurality of credential access policies, each policy regulating access to a corresponding local site credential, based on credentials of the opposite site.
11. The method according to claim 10, characterized in that it further comprises the steps of: determining whether the first logical expression that is provided with the first credential request is satisfied by a combination of local site credentials stored on the storage media , and when a determination is made that the first logical expression provided with the first credential request is satisfied by a combination of local site credentials stored on the storage media, determine whether the credential access policies stored on the storage media. and that regulate the combination of local site credentials that satisfy the first logical expression that is provided with the first credential request, are satisfied by opposing site credentials that are available locally; sending the combination of local site credentials to the opposing site data processing apparatus when the determination step determines that the credential access policies are satisfied by opposing site credentials that are locally available; and when the determination step determines that the credential access policies are not satisfied by locally available opposing site credentials, logically combining (a) the first received credential request, (b) the stored local site credentials, and (c) the stored credential access policies, to derive the second logical expression in the second credential request for opposing site credentials that together with locally available opposing site credentials, satisfy the local credential access policies that govern the credentials combination of local site that satisfy the first logical expression that is provided with the first request for local site credentials.
12. 12. The method according to claim 9, characterized in that the opposite site data processing apparatus is a client data processing apparatus.
13. The method according to claim 9, characterized in that the opposite site data processing apparatus is a server data processing apparatus.
14. The method according to claim 9, characterized in that opposing site credentials are cached in local storage.
15. 15. The method according to claim 9, characterized in that the client / server network is Internet.
16. 16. A computer program product stored in a computer readable storage medium for, when running in a data processing apparatus, instructing the data processing apparatus to perform the method steps according to claim 9.
17. 17. A computer program product data signal incorporated in a carrier wave, for, when running in a data processing apparatus, instructing the data processing apparatus to perform the method steps according to claim 9 .