Managing exchanges of sensitive data

A method, system or computer usable program product for managing exchanges of sensitive data including utilizing a processor to request a service across a network from an application, the service requiring a disclosure of a first set of sensitive data by the application; providing a set of certified policy commitments regarding the first set of sensitive data to the application for a determination of acceptability; and upon a positive determination, receiving the service including the disclosure of the first set of sensitive data.

This application is copending with concurrently filed application Ser. No. 13/841,777 of Daniel Guinan, filed on Mar. 15, 2013, entitled “MANAGING DATA HANDLING POLICIES”; with concurrently filed application Ser. No. 13/842,580 of Daniel Guinan, filed on Mar. 15, 2013, entitled “MANAGING DATA HANDLING POLICIES”; and with concurrently filed application Ser. No. 13/842,756 of Daniel Guinan, filed on Mar. 15, 2013, entitled “MANAGING DATA HANDLING POLICIES”; the disclosure of each of the foregoing which is incorporated in its entirety herein by reference.

BACKGROUND

1. Technical Field

The present invention relates generally to managing exchanges of sensitive data, and in particular, to a computer implemented method for managing exchanges of sensitive data between applications of multiple nodes.

2. Description of Related Art

The secure exchange of information in the age of the internet is an ongoing issue. Internet security can include browser security and network security as that applies to operating systems and applications. Many technologies have been utilized including passwords, biometrics, encryption, and authentication such as with the use of public and private keys. Various communication protocols have been utilized including transmission control protocol and internet protocol (TCP/IP) and a secure socket layer (SSL). Various languages have also been utilized that can take advantage of the foregoing including hypertext markup language (HTML), extensible markup language (XML) and more recently LXML which binds certain XML with certain libraries through an application program interface.

SUMMARY

The illustrative embodiments provide a method, system, and computer usable program product for managing exchanges of sensitive data including utilizing a processor to request a service across a network from an application, the service requiring a disclosure of a first set of sensitive data by the application; providing a set of certified policy commitments regarding the first set of sensitive data to the application for a determination of acceptability; and upon a positive determination, receiving the service including the disclosure of the first set of sensitive data.

DETAILED DESCRIPTION

Processes and devices may be implemented and utilized to manage exchanges of sensitive data. These processes and apparatuses may be implemented and utilized as will be explained with reference to the various embodiments below.

FIG. 1is a block diagram of a data processing system in which various embodiments may be implemented. Data processing system100is one example of a suitable data processing system and is not intended to suggest any limitation as to the scope of use or functionality of the embodiments described herein. Regardless, data processing system100is capable of being implemented and/or performing any of the functionality set forth herein.

As shown inFIG. 1, computer system/server112in data processing system100is shown in the form of a general-purpose computing device. The components of computer system/server112may include, but are not limited to, one or more processors or processing units116, a system memory128, and a bus118that couples various system components including system memory128to processor116.

Computer system/server112typically includes a variety of computer system readable media. Such media may be any available media that is accessible by computer system/server112, and it includes both volatile and non-volatile media, removable and non-removable media.

Program/utility140, having a set (at least one) of program modules142, may be stored in memory128by way of example, and not limitation, as well as an operating system, one or more application programs, other program modules, and program data. Each of the operating system, one or more application programs, other program modules, and program data or some combination thereof, may include an implementation of a networking environment. Program modules142generally carry out the functions and/or methodologies of the embodiments. For example, a program module may be software for managing exchanges of sensitive data.

Computer system/server112may also communicate with one or more external devices114such as a keyboard, a pointing device, a display124, etc.; one or more devices that enable a user to interact with computer system/server112; and/or any devices (e.g., network card, modem, etc.) that enable computer system/server112to communicate with one or more other computing devices. Such communication can occur via I/O interfaces122through wired connections or wireless connections. Still yet, computer system/server112can communicate with one or more networks such as a local area network (LAN), a general wide area network (WAN), and/or a public network (e.g., the Internet) via network adapter120. As depicted, network adapter120communicates with the other components of computer system/server112via bus118. It should be understood that although not shown, other hardware and/or software components could be used in conjunction with computer system/server112. Examples, include, but are not limited to: microcode, device drivers, tape drives, RAID systems, redundant processing units, data archival storage systems, external disk drive arrays, etc.

FIG. 2is a block diagram of a network of data processing systems in which various embodiments may be implemented. Data processing environment200is a network of data processing systems such as described above with reference toFIG. 1. Software applications may execute on any computer or other type of data processing system in data processing environment200. Data processing environment200includes network210. Network210is the medium used to provide simplex, half duplex and/or full duplex communications links between various devices and computers connected together within data processing environment200. Network210may include connections such as wire, wireless communication links, or fiber optic cables.

Server220and client240are coupled to network210along with storage unit230. In addition, laptop250and facility280(such as a home or business) are coupled to network210including wirelessly such as through a network router253. A mobile phone260may be coupled to network210through a mobile phone tower262. Data processing systems, such as server220, client240, laptop250, mobile phone260and facility280contain data and have software applications including software tools executing thereon. Other types of data processing systems such as personal digital assistants (PDAs), smartphones, tablets and netbooks may be coupled to network210.

Server220may include software application224and data226for managing exchanges of sensitive data or other software applications and data in accordance with embodiments described herein. Storage230may contain software application234and a content source such as data236for managing exchanges of sensitive data. Other software and content may be stored on storage230for sharing among various computer or other data processing devices. Client240may include software application244and data246. Laptop250and mobile phone260may also include software applications254and264and data256and266. Facility280may include software applications284and data286. Other types of data processing systems coupled to network210may also include software applications. Software applications could include a web browser, email, or other software application for managing exchanges of sensitive data.

Server220, storage unit230, client240, laptop250, mobile phone260, and facility280and other data processing devices may couple to network210using wired connections, wireless communication protocols, or other suitable data connectivity. Client240may be, for example, a personal computer or a network computer.

In the depicted example, server220may provide data, such as boot files, operating system images, and applications to client240and laptop250. Server220may be a single computer system or a set of multiple computer systems working together to provide services in a client server environment. Client240and laptop250may be clients to server220in this example. Client240, laptop250, mobile phone260and facility280or some combination thereof, may include their own data, boot files, operating system images, and applications. Data processing environment200may include additional servers, clients, and other devices that are not shown.

Among other uses, data processing environment200may be used for implementing a client server environment in which the embodiments may be implemented. A client server environment enables software applications and data to be distributed across a network such that an application functions by using the interactivity between a client data processing system and a server data processing system. Data processing environment200may also employ a service oriented architecture where interoperable software components distributed across a network may be packaged together as coherent business applications.

FIG. 3is a block diagram of applications managing exchanges of sensitive data in which various embodiments may be implemented. In this example, two nodes are shown with applications exchanging sensitive data under certain conditions, referred to herein as policies, with the assistance of a certifying authority node. A node may be a data processing system, a group of data processing systems working together, or a portion of a data processing system such as a virtual machine. Each node may include sensitive data which may be handled in accordance with certain policies.

A set of nodes300includes a node 1 (N1)310, a node 2 (N2)350and a certifying authority node390. These nodes are in communication with each other such as across a network or the internet305. Node 1 may be a mobile device such as a mobile phone or tablet, or it may be a fixed location device such as a personal computer or server. Node 2 may be a service or other device that can provide services or provide information for node 1. Certifying authority node390may be utilized for enabling the trusted communications of sensitive information between node 1 and node 2. For illustrative purposes, node 1 will be described as a mobile device and node 2 will be described as a service provider in this example, although many other types of nodes may utilize the elements described herein and alternatives thereto.

Node 1 includes a key manager320and an application A330. Node 1 may include multiple applications such as described below. Key manager320includes a private key322and a public key324. Private key322is maintained within node 1 and is not shared with other nodes. Public key324is maintained within node 1 and may be shared with other nodes. Public key324may also be a mutable identifier for node 1. Private key322and public key324may be obtained during a registration process as described below and may be shared among multiple applications on node 1.

Node 1 also includes Application A330. Application A includes a set of software332for performing tasks and a set of SDK (software development kit) software334which is utilized for communicating with other nodes. SDK334may be obtained from a third party developer such as certifying authority node390and may be embedded in application330during the development of that application. Alternatively, SDK may be open source software or other commonly known or utilized software for enabling common communications between applications and a certifying authority node. SDK334includes configuration data336(also referred to as metadata) and API (application program interface)338. Configuration data336includes a variety of configuration information such as an application identifier that identifies the type of application, a company name of the developer or distributor of the application, a version number that identifies the version of the application, etc. API338is a common interface that may be utilized for communicating with other applications either within node 1 or with other nodes such as node 2 and with the certifying authority node. SDK334may also include a certificate339that is loaded into the SDK when the application is first used or when it registers with the certifying authority node or other registration authority. Certificate339may also be referred to herein as a certified policy.

Node 2 includes a key manager360and an application B370. Node 2 may include multiple applications such as described below. Key manager360includes a private key362and a public key364. Private key362is maintained within node 2 and is not shared with other nodes. Public key364is maintained within node 2 and may be shared with other nodes. Public key364may also be a mutable identifier for node 2. Private key362and public key364may be obtained during a registration process as described below and may be shared among multiple applications on node 1.

Node 2 also includes Application B370. Application B includes a set of software372for performing tasks and a set of SDK (software development kit) software374which is utilized for communicating with other nodes. SDK374may be obtained from a third party developer such as certifying authority node390and may be embedded in application370during the development of that application. Alternatively, SDK may be open source software or other commonly known or utilized software for enabling common communications between applications and a certifying authority node. SDK374includes configuration data376(also referred to as metadata) and API (application program interface)378. Configuration data376includes a variety of configuration information such as an application identifier that identifies the type of application, a company name of the developer or distributor of the application, a version number that identifies the version of the application, etc. API378is a common interface that may be utilized for communicating with other applications either within node 2 or with other nodes such as node 1 and with the certifying authority node. SDK374may also include a certificate379that is loaded into the SDK when the application is first used or when it registers with the certifying authority node or other registration authority. Certificate379may also be referred to herein as a certified policy.

Certifying authority node390includes a certificate database manager392with an API393that accesses a certificate database395. The certificate database includes certificates generated during a registration process as described below and allows other nodes to access those certificates as needed for enabling trusted exchanges of information. Certifying authority node390may also include a policy library396for access by developers when generating certified policies for their applications or for use during the registration process as described below. Those policies generated by developers may be stored in a policy database utilized during an application registration process discussed below with reference toFIG. 6.

FIGS. 4A and 4Bare a flow diagram400of the operation of a node application exchanging certificates and data with another node in which various embodiments may be implemented. For illustrative purposes, node 1 will be described as a mobile device such as a cell phone with application A and node 2 will be described as a service provider such as a server with application B in this example, although many other types of nodes and applications may utilize the elements described herein and alternatives thereto.

In a first step400, application A of node 1 requests a service of application B of node 2. For example, application A may be a mapping application on a mobile phone that requests information from a central server about a certain location or businesses at a certain location. In subsequent step405, application B determines whether the requested information is sensitive and requires certain security or privacy protections. That is, the information may be confidential or private and require certain security and or privacy commitments before being disclosed to another node. For example, if the information included certain medical information of a patient, that information needs to be carefully protected. If yes, then processing continues to step408, otherwise processing continues to step450ofFIG. 4B.

In step408, application A and application B establish a secure connection (e.g. SSL). Then in step410, application B requests trust information from A. In step415, application A then transmits a copy of the trust information including the application A certificate, the node 1 public key, and the application A configuration data including the application A identifier. Alternatively, application B can obtain the application A certificate from certifying authority node using the application A identifier. Upon receiving the trust information from A, application B then authenticates the application A certificate in step420. As described below with reference toFIGS. 6A and 6B, a hash of the application A certificate (certified policy) has been encrypted with the private key of the certifying authority node thereby generating a certifying authority signature. Application B can then authenticate the certified policy by verifying that the certified policy is genuine and has not been modified. This authentication can be accomplished by hashing the certified policy, decrypting the signature using the certifying authority node public key, and comparing the results. In addition, application B can compare the name of the application in the certified policy to the name acquired above when establishing the secure communications, thereby verifying application A is providing the correct certified policy and not the policy of a third party. In an alternative embodiment, certificate chaining analysis can be performed to authenticate the certified policy. That is, application B looks at the certified policy of application A and authenticates that node 1 owns the key associated with that policy, and then looks at a list of trusted keys (certificates) stored in the node 2 SDK to ensure that the chain of signers between what it trusts and the signer of that policy is transitively trusted. If the certified policy is authenticated, then processing continues to step425, otherwise processing continues to step445where the service request is denied.

In step425, the application A policy commitments are compared to the application B policy requirements. This is to determine whether the application A policy commitments meet or exceed the application B policy requirements. If there are contradictions where the application A policy commitments do not meet or exceed the application B policy requirements, then application B may not share data with application A as the appropriate data handling protections are not in place at application A. This comparison may be accomplished mathematically, which may be simplified by using a common hierarchically based policy library as described with relation toFIG. 5B. That is, the policy requirements and policy commitments may each include a set of references to the policy library. Each of the references in the application B policy requirements must correspond to a reference in the application A policy commitments. As a result, in step425, it is determined whether the application A policy is acceptable (non-contradictory) to application B. If yes, then processing continues to step430. If not, then processing continues to step445where the service request is denied.

In step430, application B challenges the identity of application A and node 1. This can involve application B challenging application a to solve a problem with the private key stored in node 1 that is associated with a public key contained in the certified policy. If the application A and node 1 identity is authenticated, then processing continues to step448, otherwise processing continues to step445where the service request is denied. Alternative embodiments may utilize alternative means for one application to verify the identity of the other application. In step448, a trust connection has now been established where application B can trust sensitive information with application A on node 1. Processing then continues to step450ofFIG. 4B.

In step450, application B determines whether it needs information from application A in order to perform the requested service. If not, then processing continues to step499where the requested service is performed. If such information is needed, then in step450, application B of node 2 requests that needed information from application A of node 1. For example, application B may be a mapping service requesting the current location of node 1. In subsequent step455, application A determines whether the requested information is sensitive and requires certain security or privacy protections. If yes, then processing continues to step458, otherwise the requested information is provided and processing continues to step499where the requested service is performed.

In step458, application A and application B establish a secure connection (e.g. SSL) if such a connection was not previously established in step408above. Then in step460, application A requests trust information from B. In step415, application B then transmits a copy of the trust information including the application B certificate, the node 2 public key, and the application B configuration data including the application B identifier. Alternatively, application A can obtain the application B certificate from certifying authority node using the application B identifier. Upon receiving the trust information from B, application A then authenticates the application B certificate in step470. A hash of the application A certificate (certified policy) has been encrypted with the private key of the certifying authority node thereby generating a certifying authority signature. Application B can then authenticate the certified policy by verifying that the certified policy is genuine and has not been modified. This authentication can be accomplished by hashing the certified policy, decrypting the signature using the certifying authority node public key, and comparing the results. In addition, application A can compare the name of the application in the certified policy to the name acquired above when establishing the secure communications, thereby verifying application B is providing the correct certified policy and not the policy of a third party. In an alternative embodiment, certificate chaining analysis can be performed to authenticate the certified policy. That is, application A looks at the certified policy of application B and authenticates that node 2 owns the key associated with that policy, and then looks at a list of trusted keys (certificates) stored in the node 1 SDK to ensure that the chain of signers between what it trusts and the signer of that policy is transitively trusted. If the certified policy is authenticated, then processing continues to step475, otherwise processing continues to step496.

In step475, the application B policy commitments are compared to the application A policy requirements. This is to determine whether the application B policy commitments meet or exceed the application A policy requirements. If there are contradictions where the application B policy commitments do not meet or exceed the application A policy requirements, then application A may not share data with application B as the appropriate data handling protections are not in place at application B. This comparison may be accomplished mathematically. That is, the policy requirements and policy commitments may each include a set of references to the policy library. Each of the references in the application A policy requirements must correspond to a reference in the application B policy commitments. As a result, in step475, it is determined whether the application B policy is acceptable (non-contradictory) to application A. If yes, then processing continues to step480. If not, then processing continues to step496.

In step480, application A challenges the identity of application B and node 2. This can involve application A challenging application B to solve a problem with the private key stored in node 2 that is associated with a public key contained in the certified policy. If the application B and node 2 identities are authenticated, then processing continues to step495, otherwise processing continues to step496. In step495, a trust connection has now been established where application A can trust sensitive information with application B on node 2.

In step496where A cannot trust B with the requested information, application B determines whether the service cannot be provided without the requested information. If yes, then in step497the service request is denied, otherwise processing continues to step499where B provides the requested service for A.

FIG. 5Ais a block diagram of a certified policy in which various embodiments may be implemented. A certified policy500(also referred to herein as a certificate) is composed of three sections, a header510, a body520and footer530. The header can include a variety of information including an official name515of the node (entity or person) owning the certified policy and a certified policy identifier (CPID)516. The official name515is useful in authenticating the entity of the certified policy with the entity identified during the exchange of certificates in establishing secure communications as described below with reference toFIG. 6B. The certificate policy identifier516may be useful for storage with any data received or provided pursuant to the certified policy. The CPID may also be useful in quickly obtaining another copy of the certified policy if needed in the future.

The body can include a set of policy commitments524. These are data handling policies that the node commits to apply to third party information obtained by the owner. These policy commitments may be identified through a process described below with reference toFIG. 6B. In addition, the policy requirements528of the node may also be included in the certified policy. However, in an alternative embodiment the policy requirements may not be included or may not be included in the digital signature as described below. The footer can also include a variety of information such as a digital signature535. The digital signature may be generated by a certifying authority by hashing header510and body520and then encrypting that hash using the certifying authority private key. The certified policy can then be authenticated by similarly hashing the header and body of the certified policy, decrypting digital signature535using the certifying body public token, and comparing the results. If the certified policy header and footer have not been modified, then the hash results should match the decrypted digital signature, thereby authenticating the certified policy. In addition, name515should match the name of the node providing the certified policy.

FIG. 5Bis a block diagram of a policy library which may be utilized to generate policies in which various embodiments may be implemented. Policy library550includes multiple entries, each entry including a reference number560and a description570. The entries are generally presented in groups580and585(also referred to herein as sets of entries or policies) and within a hierarchical order within each group. That is, the entry with the lowest reference number within a group is the least restrictive and the entry with the highest number is the most restrictive. The group of entries starting with the number 01 includes general policies to be applied across all data types. The group of entries starting with the number 08 includes specific policies to be applied only to social security numbers in this example. For example, entry 0101 is less restrictive or protective of data than entry 0102 or 0103. Many other groups of entries may be generated that apply to other data types, sources of data, etc. by utilizing other starting reference numbers. This approach works well where each group of entries can be ordered sequentially by restrictiveness. For more complex hierarchical arrangements, a separate tree structure may be utilized to accompany the policy library. The tree structure could include a hierarchical ranking of the entries relative to each other in a non-linear fashion. That tree structure could be utilized as a look up table to determine the relative ranking of each policy in terms of restrictiveness. Alternative embodiments may utilize alternative policy structures such as tokens that are machine readable or encoded so that a processor can automatically compare various policies.

FIG. 6Ais a flow diagram of a creation of a certified policy in which various embodiments may be implemented. This flow diagram is from the perspective of the certifying authority that is contacted by Node 1 (N1) to generate a certified policy but could similarly be shown from the perspective of node 2 (N2). In a first step600, secure communications are established between the certifying authority node and N1. This includes obtaining the official name of Node 1 through the exchange of certificates in establishing secure communications. In a second step605, the certifying authority receives the entries (i.e. policies) for the N1 policy commitment. This can be accomplished through a graphical user interface where a Node 1 representative can select the desired entries from the certifying authority policy library. Alternative embodiments may utilize alternative approaches to provide these policies. In a third step610, the certifying authority receives the entries (i.e. policies) for the N1 policy requirement. This can also be accomplished through a graphical user interface where a Node 1 representative can select the desired entries from the certifying authority policy library or through alternative methods such as an automated interface between N1 and the certifying authority node.

Subsequently in step615, the certifying authority verifies the N1 policy commitment. This can include verifying that the N1 policy requirement will sufficiently maintain the N1 policy commitment. This can also include various steps of verifying the veracity of Node 1 such as by contacting third parties and by reviewing prior activity of Node 1. In step620, it is determined whether the N1 policy is verified. If not, then processing ceases, otherwise processing continues to step625.

In step625, the header and body of the N1 certified policy are generated. The header includes the official name of Node 1 that was identified in step600above and a unique certified policy identifier (CPID). The CPID may be used by parties for identifying this policy in the future. The body includes the N1 policy commitments and may include the N1 policy requirements. Subsequently in steps630and635, the header and body are hashed and the resulting hash is encrypted with the certifying authority private key. The encrypted hash is then added to the N1 certified policy as a digital signature in step640, thereby completing the certified policy, also referred to herein as a certificate. The completed certified policy is then sent to N1 is step645.

In an alternative embodiment, the policy commitments may be included in the hash and encryption process of generating a digital signature, but the policy requirements may or may not be included in the process of generating the digital signature. That is, the commitments are certified and as such are non-repudiable, but the requirements may not be certified.

FIG. 6Bis a flow diagram of an authentication of a certified policy (i.e. certificate) in which various embodiments may be implemented. This flow diagram is from the perspective of a Node 2 (N2) that has received a certified policy from Node 1 (N1), but could similarly be shown from the perspective of node 2 (N2) receiving a certified policy from N1 or other node. In a first step650secure communications are established between N2 and N1. This includes obtaining the official name of N1 through the exchange of other types of node certificates in establishing secure communications. In a second step655, N2 receives the N1 certified policy as part of the process described above with reference toFIGS. 4A and 4B. Subsequently in step660N2 determines whether the name in the certified policy header matches the name obtained in step650above. If not, then a failure notification is sent on step665and processing ceases, otherwise processing continues to step670. In step670, N2 hashes the header and body of the N1 certified policy. N2 then decrypts the digital signature using the certifying authority public key in step675. If N1 does not already have the certifying authority public key, it can be obtained directly from the certifying authority. Subsequently in step680, it is determined whether the calculated hash matches the decrypted digital signature. If not, then a failure notification is sent on step665and processing ceases.

Alternative embodiments may be utilized to create and authenticate certified policies including the use of certified exceptions to the certificated commitments and/or requirements. That is, the nodes negotiating commitments and requirements can agree to certain exceptions that can then be certified by the certifying authority node.

FIG. 7is a flow diagram of the operation of a node application registering with a certifying authority node in which various embodiments may be implemented. An application may register when it is initially downloaded to a node such as a mobile phone, or it may register when the application is first utilized by the user or the node. The purpose of the registration is multipurpose including downloading the application certificate to the application and linking that certificate to the node. For illustrative purposes, application A of node 1 as shown inFIG. 3is being registered with the certifying authority node.

In a first step700, application A obtains the configuration data (metadata) from the SDK that was loaded into the application by the developer when the application was developed. This includes information such as the company name (of the developer), the application identifier, and the application version. Additional information may be included. Then in step705, the SDK may then interrogate the application to ensure the configuration data matches the application that is trying to utilize that data. If not, then registration fails and processing ceases. Otherwise processing continues to step710. The application then queries the node in step710to determine whether a public private key pair exists for that node for use by applications. If not, then a new cryptographic key pair is generated for that purpose in step715. Processing then continues to step720.

In step720a secure connection (e.g. SSL) is established between Node 1 and the certifying authority node. Then in step725, the application configuration data and the node 1 public key are transmitted to the certifying authority node. In step730, the certifying authority node looks at its policy database to determine whether there is a matching policy established by the developer for the type of application registering. If not, then processing ceases, otherwise processing continues to step735. In step735, then the policy is augmented with the application configuration data (metadata) and the node 1 public key to generate a certificate that is signed by the certifying authority node with its private key. This certificate is then a node 1 specific certificate for the application that includes the policies set forth by the developer of the application. This certificate is then stored in the certifying authority certificate database and transmitted to the application A SDK in step740. The certificate is then stored in the SDK by application A for use in establishing trust connections with other applications.

FIG. 8is a block diagram of an application developer establishing a policy and generating a custom SDK for an application being developed in which various embodiments may be implemented. A set of nodes800including an application development node810and a certifying authority node850communicate with each other across a network805such as the internet. Application development node desires to obtain a custom SDK (software development kit)820for an application being developed and a user interface830for communicating with the developer. The custom SDK should have a set of configuration data (also referred to as metadata)822and a standard API (application program interface)824. Configuration data822can include a variety of configuration information such as an application identifier that identifies the type of application, a company name of the developer or distributor of the application, a version number that identifies the version of the application, etc. API338is a common interface that may be utilized for communicating with other applications either within node 1 or with other nodes such as node 2 and with the certifying authority node. The application development node obtains this custom SDK from certifying authority node850in the process described inFIG. 9below.

Certifying authority node850can include an SDK generator860, and SDK template865, a policy generator870, a policy database875and a certificate database880containing certain configuration information885. SDK generator860starts with SDK template865to build the custom SDK. SDK generator then communicates with policy generator870to generate a policy for the application with input from application development node810. SDK generator860then stores certain results of the SDK generation process in certificate database880.

FIG. 9is a flow diagram of an application developer establishing a policy and generating a custom SDK for an application being developed in which various embodiments may be implemented. In a first step900, a developer through a communication node (referred to herein as an application development node) may contact a certifying authority node requesting a policy and custom SDK. In a second step905, a secure communication link such as SSL (secure sockets layer) is established between the application development node and the certifying authority node. In a third step910, the SDK generator selects an SDK template to build the custom SDK and to initiate the process of establishing a certified policy. There may be multiple templates and the one selected may require certain inquiries to the application development node with the developer through a user interface.

Subsequently in step915, the developer is queried by the policy generator through the SDK generator and the user interface in the application development node. These queries are to determine the policy commitments and any policy requirements that the developer prefers apply to the application. For example, if the developer is developing a mapping program, the developer may require certain information such as the location of a person requesting service from the application and the developer may be willing to provide certain security and privacy guarantees regarding that location information. The policy generator utilizes the policy database to establish these queries. Alternatively, the policy database may simply be provided to the developer for that developer to pick and choose.

Once the policy commitments and requirements are established, then an application identifier may be generated in step920. That application identifier is then embedded in the configuration data of the custom SDK in step925. Then in step930, the policy commitments and requirements are used to generate a certified policy (also referred to as a certificate). That certificate is then stored in the certificate database with the application identifier in step935. The custom SDK is then provided to the application development node in step940.

In an alternative embodiment, the custom SDK with an application ID may be provided to the developer prior to establishing the policy requirements and commitments. At a later stage of development, the developer can return to the certifying authority node to generate the certificate, which is then stored with the application identifier in the certificate database.

The invention can take the form of an entirely software embodiment, or an embodiment containing both hardware and software elements. In a preferred embodiment, the embodiments are implemented in software or program code, which includes but is not limited to firmware, resident software, and microcode.

Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing. Further, a computer storage medium may contain or store a computer-readable program code such that when the computer-readable program code is executed on a computer, the execution of this computer-readable program code causes the computer to transmit another computer-readable program code over a communications link. This communications link may use a medium that is, for example without limitation, physical or wireless.

A data processing system may act as a server data processing system or a client data processing system. Server and client data processing systems may include data storage media that are computer usable, such as being computer readable. A data storage medium associated with a server data processing system may contain computer usable code such as for managing exchanges of sensitive data. A client data processing system may download that computer usable code, such as for storing on a data storage medium associated with the client data processing system, or for using in the client data processing system. The server data processing system may similarly upload computer usable code from the client data processing system such as a content source. The computer usable code resulting from a computer usable program product embodiment of the illustrative embodiments may be uploaded or downloaded using server and client data processing systems in this manner.