[go: up one dir, main page]

WO2008005909A2 - Formulation de dépendance d'informations, procédé d'utilisation et appareil - Google Patents

Formulation de dépendance d'informations, procédé d'utilisation et appareil Download PDF

Info

Publication number
WO2008005909A2
WO2008005909A2 PCT/US2007/072622 US2007072622W WO2008005909A2 WO 2008005909 A2 WO2008005909 A2 WO 2008005909A2 US 2007072622 W US2007072622 W US 2007072622W WO 2008005909 A2 WO2008005909 A2 WO 2008005909A2
Authority
WO
WIPO (PCT)
Prior art keywords
user
information
networked
identity provider
identity
Prior art date
Application number
PCT/US2007/072622
Other languages
English (en)
Other versions
WO2008005909A3 (fr
Inventor
Samir Dilipkumar Saklikar
Subir Saha
Original Assignee
Motorola, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Motorola, Inc. filed Critical Motorola, Inc.
Publication of WO2008005909A2 publication Critical patent/WO2008005909A2/fr
Publication of WO2008005909A3 publication Critical patent/WO2008005909A3/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/30—Profiles
    • H04L67/306—User profiles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/102—Entity profiles

Definitions

  • This invention relates generally to networked identity providers and more particularly to networked identity providers having a federation capability.
  • identity providers are accessible and/or provide their corresponding services via the Internet. Such identity providers typically maintain separate identity records for their various authorized users. Such identity records often contain more than more identification information (such as name, email address, password, and so forth). In many cases such identity records also contain information that comprises or otherwise reflects various user preferences and/or characterizing information as pertains relatively specifically to each user.
  • Identity federation technologies such as Liberty Alliance are also known in the art.
  • the Liberty Alliance comprises a consortium that supports the formation and promulgation of standards-based specifications for federated identity and identity-based Web services.
  • Such technologies permit, for example, the storage and control of identity information for registered users in user profiles (often denoted as "identity services").
  • identity services Such technologies provide for a certain amount of information sharing with respect to such networked identity providers.
  • identity providers typically between an identity provider and a so- called service provider (which is a term typically used to identify an identity information consumer in identity federation parlance).)
  • identity information can comprise user preferences and/or user details that, at least in some cases, a given user will likely prefer to retain in at least some degree of confidence. This also tends to hold true, at least in part, because some identity provider prefer to control and/or own this information for business reasons. Control over a user's information and preferences, for example, can be a control point to ensure that user's loyalty. This, in turn, tends to restrict the capabilities of users from conveniently using multiple sets of identity information from different identity providers in aggregation.
  • FIG. 1 comprises a flow diagram as configured in accordance with various embodiments of the invention
  • FIG. 2 comprises a schematic screen shot as configured in accordance with various embodiments of the invention
  • FIG. 3 comprises a schematic screen shot detail as configured in accordance with various embodiments of the invention.
  • FIG. 4 comprises a schematic screen shot detail as configured in accordance with various embodiments of the invention.
  • FIG. 5 comprises a communications flow diagram as configured in accordance with various embodiments of the invention.
  • FIG. 6 comprises a flow diagram as configured in accordance with various embodiments of the invention.
  • FIG. 7 comprises a block diagram as configured in accordance with various embodiments of the invention.
  • this networked identity provider can provide an opportunity to a user to establish a dependency between, on the one hand, at least one item of information in a first networked identity provider user identity as is maintained by that networked identity provider and, on the other hand, at least one item of information in a second networked identity provider with which the first networked identity provider can be federated. This networked identity provider can then facilitate establishment of that dependency.
  • these teachings will further support the provision of an opportunity to also establish relative user characterization levels with respect to these items of information to thereby influence subsequent sharing of identity information as between the first and the second networked identity providers. This permits, for example, varying privacy levels to be established for these various items of information.
  • this dependency information can serve in the first instance to identify useful information as may reside at another networked identity provider or providers. If desired, the aforementioned relative user characterization levels can then serve to determine which of the networked identity providers shall use the information of the other(s) to form the desired response to the query.
  • a corresponding process 100 provides 101 an opportunity to establish a dependency between items of information as are maintained by a plurality of networked identity providers.
  • the networked identity provider extends this opportunity to, for example, a user.
  • This opportunity can comprise an opportunity to establish a dependency between, on the one hand, at least one item of information in a first networked identity provider user identity as is maintained by the first networked identity provider and, on the other hand, at least one item of information in a second networked identity provider user identity as corresponds to a second networked identity provider with which the first networked identity provider can be federated.
  • this opportunity can be extended via a browser-based interface 201.
  • this browser-based interface 201 (as offered, for example, by the aforementioned first networked identity provider) can provide a display area 202 for federation information.
  • One or more items of information comprising, in this illustrative example, user preferences 203 and 204 are also displayed to thereby refresh the user's recollection with respect to their expressed choices in this regard.
  • Candidate and/or already-linked other networked identity providers 205 and 206 are also presented in an area where dependencies are shown and/or facilitated.
  • a standard cursor 207 mechanism can serve to facilitate the manipulation of one or more of these displayed elements.
  • the aforementioned dependency creation opportunity can comprise, in part, the opportunity to select and drag a given user preference into a given networked identity provider space.
  • click and drag facilities are well known in the art and require no further elaboration here.
  • this process 100 extends an opportunity to establish a dependency between items of user identity information.
  • this can relate to networked identity provider user identities that both relate to a same user. If desired, however, these networked identity provider user identities can relate to different users. So configured, a dependency establishment opportunity could be provided as regards an item of information in a first networked identity provider user identity as corresponds to a first user and an item of information in a second networked identity provider user identity as corresponds to a second, different user.
  • this opportunity relates to two items of information and two networked identity provider user identities. Those skilled in the art, however, will recognize and understand that this opportunity can be extended to encompass three or more such items of information/networked identity provider user identities as may be desired. Only two such items are shown here for the sake of simplicity and clarity and not as a point of limitation.
  • This process 100 then provides for facilitating 102 establishment of this dependency.
  • This can comprise receiving from a user a selection of at least one of the items of information. Referring again to FIG. 2, for example, this can comprise the user using the cursor 207 to select a given one of the items of information represented by the user-identified preference items 203 and 204.
  • This step of establishing a dependency can further comprise receiving from the user a selection of a target second networked identity provider. Again as noted above, this can comprise the user using the cursor 207 to drag a previously selected user-identified preference item 203 or 204 to a user-selected networked identity provider 205 or 206.
  • the first networked identity provider and the selected second networked identity provider should be capable of establishing and maintaining a state of federation between themselves. It is not necessary, however, that such a state exist at the time of initiating facilitation of the dependency establishment process.
  • establishing such a dependency as between two items of information contained in networked identity provider user identities as maintained at different networked identity providers entails establishing a user-based policy that uses information contained in each of these networked identity provider user identities to thereby provide a user-based policy that comprises a composite policy containing information that may be relatively unique to each of the networked identity provider user identities.
  • this user-based policy can be established at whichever of the first and second networked identity providers the user selects (wherein the selection can be relatively direct or indirect as the case may be).
  • this process 100 will further optionally accommodate providing 103 an opportunity to establish relative user characterization levels with respect to these items of information in the first and second networked identity provider user identities to thereby influence subsequent sharing of identity information as between the first and second networked identity providers.
  • the user characterization itself can vary as desired with the application setting, user requirements and preferences, and so forth. Some illustrative examples include, but are not limited to, characterizations regarding value of the information, importance of the information, priority of the information, and so forth. By one approach, this user characterization can usefully comprise a characterization regarding privacy.
  • this comprises a first opportunity 301 that will permit the user to establish the item of information as corresponds to the first networked identity provider to be more private and a second opportunity 302 that permits the user to instead establish the item of information as corresponds to the second networked identity provider to be more private.
  • a lack of a selection in this regard can be taken as a user representation that neither item of information has a relatively higher level of privacy expectation. Lack of a selection from the user may also serve as a trigger for a default system-wide policy to set in.
  • One illustration in this regard would be a policy that all health-related information always defaults to a relatively higher privacy level in the absence of a specific user selection in this regard.
  • a policy selection can be based, at least in part, on some user characterization and a policy that is viewed as being most suitable to this category of users (as determined, for example, by the aforementioned user characterization). Also, if desired, such a decision may be reached based on some negotiation between the two involved identity providers themselves using resolution criteria of choice and a negotiation protocol as may be appropriate to the needs, requirements, and/or limitation of a given application setting.
  • such relative degrees of user characterization requirements can be used, for example, to control and determine where the aforementioned user-based policy will be established and maintained (and hence which of the networked identity providers will have possession of information from the other networked identity provider).
  • the user characterization requirement comprises a privacy characterization
  • this can serve to ensure that the networked identity provider having the higher privacy rating will be the entity to access the item of information from the other networked identity provider. This, in turn, aids in preventing more private information from being accessed by a less private (and perhaps less trusted) entity.
  • this process 100 readily accommodates the establishment of user-based policies.
  • the user can be presented with an opportunity to select from amongst a plurality of candidate policies 401 and 402.
  • the candidate policies are pre-configured (for example, by the networked identity provider itself). If desired, this may be supplemented or supplanted by an opportunity for the user to themselves construct a particular policy.
  • cuisine user preference information from a first networked identity provider is used with user medical information from a second networked identity provider to form corresponding policies that can be used, for example, when responding to subsequent queries regarding user preferences.
  • the user uses their browser to present their username and password 501 to a cuisine-based networked identity provider to thereby login with the latter.
  • the user clicks 502 on a provided link to enable the federation functionality of the cuisine-based networked identity provider.
  • the cuisine-based networked identity provider responds by providing 503 a profile display for the user that prompts the user for federation enablement specifics.
  • This can comprise, for example, providing a page that displays a plurality of cuisine- based items of information as comprise the user's identity profile.
  • Each such item can further include a check box. So configured, the user can be prompted to check on the check-box for items of information for which the user wishes to create a federation- enabled dependency.
  • the user selects 504 a particular cuisine-based item of information for which a federation-enabled dependency is desired.
  • This can comprise, as disclosed above, also identifying the target networked identity provider as well as a given user-selected relative level for a given user characterization (such as, for example, a given level of privacy to be accorded to the item of information).
  • the cuisine-based networked identity provider then responds by redirecting 505 the user's browser to the target networked identity provider (which in this example comprises a health information-based networked identity provider).
  • this latter transaction can comprise a new element that is added to an AuthnRequest as is already known in the art.
  • This new element could take the form, for example, of ⁇ profileLink> (A more detailed illustrative example in this regard appears further below).
  • This new element can indicate to the recipient networked identity provider that in addition to seeking to establish a federation there is also identity information to be linked in a dependent manner.
  • the user characterization such as privacy
  • this transaction can also include the corresponding item of information itself that is to be linked to information at the health-based networked identity provider.
  • the recipient networked identity provider could instead be compelled or requested to provide the item of information to the cuisine-based networked identity provider.
  • this transaction can further include an assertion from the cuisine-based networked identity provider to indicate that the user has already been authenticated by the cuisine-based networked identity provider.
  • This can serve to prove to the health-based networked identity provider, for example, that the cuisine- based networked identity provider is also a networked identity provider for this particular user.
  • This can be used by the health-based networked identity provider to permit subsequent acceptance of other assertions or submissions as proffered by the cuisine-based networked identity provider.
  • the user's browser can act upon the redirection message 505 by forwarding the provided AuthnRequest message 506 (as known in the art and as modified as described above) to the health-based networked identity provider.
  • the health-based networked identity provider responds with a login request 507 to which the user replies with their login information 508.
  • the health-based networked identity provider analyzes 509 the AuthnRequest message including the dependency content described above. This analysis can comprise, for example, identifying the various elements described above and facilitating a cooperative use of this content.
  • the health-based networked identity provider then responds with page content 510 to confirm for that user that the dependency request is acknowledged and will be honored.
  • This page can further comprise, for example, one or more prompts to encourage the user to identify one or more specific items of information in the identity profile for this user at this health- based networked identity provider that are to be linked with the provided item of information from the cuisine-based networked identity provider.
  • the user in turns provides their selection 511 in this regard.
  • the health-based networked identity provider then prompts 512 the user to specify a particular policy that relies upon the aforementioned items of information.
  • the health-based networked identity provider redirects 514 the user's browser back to the cuisine- based networked identity provider.
  • This redirection message can comprise a federation Response message that includes additional content as per these teachings.
  • this additional content can comprise further information regarding the established dependency.
  • this might comprise, for instance, information regarding which cuisine-based networked identity provider items of information have been linked with items of information at the health-based networked identity provider.
  • This information can further comprise, for example, a network address for a location within the health-based networked identity provider where a query regarding this dependency can be directed.
  • a different network address (such as a different uniform resource locator) can be provided for each individual element of the linked identity profile.
  • a different URL for example, i%i ⁇ P31 ⁇ LLl2: ⁇ ?:A2 ⁇ 12:L ⁇ .Q ⁇ iQ ⁇ A
  • a more revelatory URL such as 'Svww.health.com/poliey 1
  • the user's browser then forwards that Response 515 to the cuisine- based networked identity provider which then stores 516 at least the aforementioned network address.
  • Information 517 can then be provided to the user to indicate a successful conclusion of the federation and dependency establishment activity.
  • the cuisine-based networked identity provider provided its item of information to the health-based networked identity provider because the user established a relatively low privacy level for the cuisine-related information.
  • the cuisine-based networked identity provider would proceed as described above though while retaining its information.
  • the health-based networked identity provider would then include its item of information in its Response message.
  • the cuisine-based networked identity provider would then carry out the policy- establishment activity described above. This could include, for example, presenting an additional message via the user's browser to inform the health-based networked identity provider of the network address where the dependency result can now be accessed.
  • this process 600 upon receiving 601 a query regarding a user for whom the receiving networked identity provider has a corresponding user identity, the receiving networked identity provider then effectively determines 602 whether the query requires access to a dependent item of information that is held by a different federated networked identity provider. When true, and when the information in question is not available to the networked identity provider, generally speaking the networked identity provider nevertheless uses the corresponding user-created dependency to facilitate responding to this query.
  • this process 600 can simply provide for that receiving networked identity provider using 604 that dependent item of information to facilitate responding to the query. This can comprise, for example, accessing an internal (to the receiving networked identity provider) network address where the receiving networked identity provider has previously placed the dependent item(s) of information and/or a corresponding user-specified policy.
  • networked identity providers are able to more fully respond to a given query without also requiring that all items of information be disclosed to all other federated networked identity providers. This, in turn, permits the user to assign and rely upon any number of user characterizations regarding such information (including but not limited to the use of any number of user-assigned levels as correspond to such user characterizations).
  • This networked identity provider 700 can comprise a processor 701 that operably couples to a first memory 702, a second memory 703, and a third memory 704.
  • the first memory 702 has a user identity for a user of the networked identity provider 700 stored therein.
  • this user identity can be relatively complete and include, for example, corresponding identity information, preferences, and so forth.
  • a fourth optional memory 705 can serve to retain, in whole or in part, such content.
  • the second memory 703 has information regarding federation status with other networked identity providers stored therein while the third memory 704 has information regarding the aforementioned user-established user identity information dependencies between the networked identity provider 700 and other networked identity providers with which the networked identity provider 700 has a federation stored therein.
  • the process 701 is configured and arranged (via, for example, corresponding programming as will be well understood by those skilled in the art) to provide the aforementioned opportunity to establish dependencies between at least one item of information in a first networked identity provider user identity and at least one other item of information in another networked identity provider user identity with which the networked identity provider 700 can be federated and further to facilitate the establishment of such a dependency.
  • This can comprise, if desired, further configuring and arranging the processor 701 to establish such dependencies as a function, at least in part, of user-assigned levels of user characterization to thereby control which of the networked identity providers is provided with user identity information from an opposing networked identity provider.
  • a processor 700 can further be configured and arranged to formulate query replies (at least to user-authorized queries) in a manner that leverages the availability of such dependencies.
  • Such an apparatus 700 may be comprised of a plurality of physically distinct elements as is suggested by the illustration shown in FIG. 7. It is also possible, however, to view this illustration as comprising a logical view, in which case one or more of these elements can be enabled and realized via a shared platform. It will also be understood that such a shared platform may comprise a wholly or at least partially programmable platform as are known in the art.
  • a first element ⁇ LinkCreate> can be used to create a link between profile elements of a Data Service 1 with a Data Service 2.
  • This element can be sent from one Web Service Provider (who wants to set up the dependency) to another Web Service Provider (with whom the dependency is to be set).
  • This request can be sent, for example, to a target URL that is exposed by the Destination Web Service Provider for receiving requests related to establishing federation. It is possible, however, that a new URL (specific to receiving resolves for Dependency Creation) may be standardized and exposed if desired.
  • This element identifies the subject within the domain of the Originating Web Service Provider (that is, the one originating the LinkCreate Request).
  • a User Characterization Level - A level defining whether the
  • Originating Web Service Provider is at a higher or lower User Characterization level with respect to the destination Web Service Provider, for this particular set of Profile Elements (as decided, for example, by the following parameter).
  • the content of this element can be decided, for example, by the user of the Web Service Provider and can reflect, for example, whatever profile elements within the domain of the Originating Web Service Provider that the user wants to create a link with some other profile elements in the domain of the Destination Web Service Provider.
  • this set can be null when the Originating Web Service Provider is at a higher user characterization level that the Destination Web Service Provider.
  • each element of this parameter would contain the
  • Profile Type Personal Profile, Employee Profile, and so forth
  • Profile Parameter that is being linked with the Destination Web Service Provider.
  • a ⁇ LinkCreateResponse> element can be sent in response to the above element and can contain the status of the Link request.
  • this element can contain the following information:
  • LinkCreate Request It may also contain appropriate error codes, if there was some failure in executing a ⁇ LinkCreate> request. For example, a "User Characterization level not agreeable" message can be sent back if the User Characterization level as suggested by the Originating Web Service Provider is not acceptable to the Destination Web Service Provider. This may happen either because of a User decision, an applicable policy, or some applicable global policy.
  • a Local Dependency Identifier A unique identifier that identifies this dependency in this domain of the Destination Web Service Provider. It may be in the form of a URL. It would be used by the Originating Web Service Provider to identify this dependency, resolve it, or delete it.
  • This element can identify the subject within the domain of the Destination Web Service Provider (the one who is accepting the LinkCreate Request).
  • a User Characterization Level - A level defining whether the
  • Destination Web Service Provider is at a higher or lower User Characterization level with respect to the Originating Web Service Provider, for this particular set of Profile Elements (as decided by the following parameter). This will preferably conform to the User Characterization Level that was indicated within the ⁇ LinkCreate> Request. For example, if the Originating Web Service Provider claimed to be at a higher User Characterization level, then the Destination Web Service Provider will preferably agree to be at a lower User Characterization level.
  • the content of this element can be decided, for example, based on those elements for which the User agrees to have a dependency established from the Destination Web Service Provider to the Originating Web Service Provider.
  • this set can be null when the Destination Web Service Provider has a higher user characterization level as in such a case, no profile element information is shared with the Originating Web Service Provider (who is at a lower user characterization level).
  • a request comprising a ⁇ LinkResolve> element can serve to resolve a dependency between two Web Service Providers as established by the above ⁇ LinkCreate> process.
  • This element would be sent typically from any Web Service Provider to the other. It is not mandated that it be necessarily sent by the Web Service Provider that had initiated the ⁇ LinkCreate> request. For example, it may be sent by the Web Service Provider that had responded to the ⁇ LinkCreate> request.
  • Such flexibility allows in setting up the links from one Web Service Provider to another, but having them resolved from any Web Service Provider, wherever a Query was made.
  • the User Characterization levels as selected by the User should be honored when resolving the dependencies as Identity Information should preferably not travel from a higher User Characterization to a Lower User Characterization -level Web Service Provider. This request can be targeted towards the URL that was exposed by the Resolvee Web Service Provider as its Local Dependency Identifier during the Link Creation process.
  • a Local Dependency Identifier The unique identifier that identifies this particular dependency in the Resolver Web Service Provider domain. It may be in the form of a URL. This is used by the Resolvee Web Service Provider to verify whether the appropriate dependency is being triggered.
  • This element identifies the subject within the domain of the Resolver Web Service Provider (the one who is originating the ⁇ LinkResolve> Request).
  • the content of this element can be decided, for example, based on the Profile Elements which were linked during the ⁇ LinkCreate> process and can reflect, for example, whatever profile elements and their associated values within the domain of the Originating Web Service Provider for which a link has been created and is being resolved with some other profile elements in the domain of the Destination Web Service Provider.
  • this set can be null when the Originating Web Service Provider is at a higher user characterization level than the Destination Web Service Provider.
  • a ⁇ LinkResolveResponse> element can be sent in response to a Link
  • Resolve Request It is sent towards the Resolver Web Service Provider who had issued the Link Resolve request to resolve the dependency that was setup between the two different information profiles at the respective Web Service Provider.
  • LinkResolve request It may also contain appropriate error codes, if there was some failure in executing a ⁇ LinkResolve> request. For example, "Dependency not found" can be sent back if there is no dependency between the two Web Service Providers as identified for this particular subject and the given dependency identifier.
  • a Local Dependency Identifier The unique identifier that identifies this particular dependency in the Resolvee Web Service Provider domain. It may be in the form of a URL.
  • This element can identify the subject within the domain of the Resolvee Web Service Provider (the one who is responding to the ⁇ LinkResolve> Request).
  • the content of this element can be decided, for example, based on those profile elements and their values for which the User agrees to have a dependency established from the Destination Web Service Provider to the Originating Web Service Provider.
  • this set can be returned after the execution of a Policy within the domain of the Destination Web Service Provider, which is associated with the Local Dependency Identifier for this dependency.
  • the User Characterization levels may be considered to be one or more of, but not limited to, levels corresponding to Privacy, Importance, Value, or Priority.
  • a ⁇ LinkDelete> element can be used to delete a link/dependency that was created between Profile elements of Data Service 1 with Data Service 2. It can be sent from one Web Service Provider (who wants to delete the dependency) to another Web Service Provider (with whom the dependency is to be set). This request can typically be sent to the URL that is exposed by the Destination Web Service Provider for receiving requests related to de-establishing federation. It is also possible, however, that it be sent to the URL that was exposed in the Local Dependency Identifier during the Link Creation process.
  • a Local Dependency Identifier The unique identifier that identified this dependency in this domain. It may be in the form of a URL.
  • a Subject The User for whom this dependency is being deleted. This element can identify the subject within the domain of the Originating Web Service Provider (the one who is originating the LinkDelete Request).
  • a ⁇ LinkDeleteResponse> element can be sent in response to the
  • a Local Dependency Identifier The unique identifier that identified this dependency in this domain. It may be in the form of a URL.
  • the User When the User has federated and setup a dependency between two information profiles, they can also have the option to set up rules/policies to govern how the Profile Data elements from the two profiles can interact with each other.
  • the term Policy is used to reflect User- defined personalization-related policies that control the system behavior as per User expectations. The meaning of the term is thus more generic than the "Access-control" connotation that is often associated with "Policy.”
  • this Policy can be associated with the Local Dependency URL that identifies a dependency within a given domain.
  • Rules/Policies are used in the same domain, where they belong and are stored. This would happen, for example, when the User federates some other profile information from some other Web Service Provider to a present Web Service Provider, but writes the policy/rule that works over these two pieces of User information at this Web Service Provider itself.
  • the Web Service Provider can store the Policy in any format that is most suitable for it since there is no need to share these policies with other domains.
  • the Policy representation format can indeed be proprietary. It may be appropriate, however, that at least a conversion mechanism be allowed so that Policies can be shared if and when the need arises.
  • policies are usable in different domains.
  • a Policy that is written in one domain (by one Web Service Provider or Identity Provider) needs to be shared with another domain. Such sharing can be for any of a variety of reasons. The following are some examples in this regard.
  • the Rule/Policy can be returned to the Web Service Provider in the Query result.
  • the Web Service Provider makes a Query regarding Call-routing related preferences.
  • the Web Service Provider may return a rule indicating something like, "When I get a call from Paul, reject it."
  • the Policy is owned by a certain domain/ Web Service Provider, but it needs to be shared with the other Web Service Provider.
  • the Policy needs to be shared to the other Web Service Provider notwithstanding that the other Web Service Provider has not agreed to share its profile information because the User wants the behavior from one Web Service Provider to be applicable at another Web Service Provider (though for a different set of Profile Data).
  • an Airline Reservation counter is selecting movies/games that should be accessible to the User during her long flight.
  • the User has Music and Video Preferences stored by one Web Service Provider, whereas her Gaming-related preferences are stored with another Web Service Provider.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

La présente invention concerne un prestataire d'identité en réseau (101) qui peut fournir l'opportunité à un utilisateur d'établir une dépendance entre, d'un côté, au moins un élément d'information dans une première identité d'utilisateur de prestataire d'identité en réseau telle qu'elle est maintenue par ce prestataire et, de l'autre côté, au moins un élément d'information chez un second prestataire d'identité mise en réseau avec lequel le premier prestataire peut être fédéré. Ce prestataire d'identité en réseau peut ensuite proposer l'établissement (102) de cette dépendance. Ces enseignements soutiendront aussi la provision d'une opportunité (103) d'établir aussi des niveaux relatifs de caractérisation d'utilisateur en ce qui concerne ces éléments d'information afin d'influencer le partage ultérieur d'informations d'identité comme entre le premier et le second prestataire d'identité en réseau.
PCT/US2007/072622 2006-07-05 2007-07-02 Formulation de dépendance d'informations, procédé d'utilisation et appareil WO2008005909A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
IN1589DE2006 2006-07-05
IN1589/DEL/2006 2006-07-05

Publications (2)

Publication Number Publication Date
WO2008005909A2 true WO2008005909A2 (fr) 2008-01-10
WO2008005909A3 WO2008005909A3 (fr) 2008-09-25

Family

ID=38895399

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2007/072622 WO2008005909A2 (fr) 2006-07-05 2007-07-02 Formulation de dépendance d'informations, procédé d'utilisation et appareil

Country Status (1)

Country Link
WO (1) WO2008005909A2 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11064725B2 (en) 2015-08-31 2021-07-20 British American Tobacco (Investments) Limited Material for use with apparatus for heating smokable material

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030005090A1 (en) * 2001-06-30 2003-01-02 Sullivan Robert R. System and method for integrating network services
GB0123403D0 (en) * 2001-09-28 2001-11-21 Tamesis Ltd Publish subscribe system
US7236973B2 (en) * 2002-11-27 2007-06-26 Sap Aktiengesellschaft Collaborative master data management system for identifying similar objects including identical and non-identical attributes
US20070203893A1 (en) * 2006-02-27 2007-08-30 Business Objects, S.A. Apparatus and method for federated querying of unstructured data
US7519711B2 (en) * 2006-06-15 2009-04-14 International Business Machines Corporation Method for middleware assisted system integration in a federated environment
US7657639B2 (en) * 2006-07-21 2010-02-02 International Business Machines Corporation Method and system for identity provider migration using federated single-sign-on operation

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11064725B2 (en) 2015-08-31 2021-07-20 British American Tobacco (Investments) Limited Material for use with apparatus for heating smokable material

Also Published As

Publication number Publication date
WO2008005909A3 (fr) 2008-09-25

Similar Documents

Publication Publication Date Title
JP6840295B1 (ja) グループベース通信システムにおけるグループベースオブジェクトに選択的に許可を付与する方法、装置、及びコンピュータプログラム製品
US9860234B2 (en) Bundled authorization requests
US10084823B2 (en) Configurable adaptive access manager callouts
CN100474263C (zh) 用于用户概况表管理的方法
US8688813B2 (en) Using identity/resource profile and directory enablers to support identity management
US20040034799A1 (en) Network system allowing the sharing of user profile information among network users
US20100217716A1 (en) Method and apparatus for restricting access to an electronic product release within an electronic software delivery system
EP2582118B1 (fr) Procédé, système et serveur pour partager du contenu
US8271387B2 (en) Method and apparatus for providing limited access to data objects or files within an electronic software delivery and management system
WO2008005909A2 (fr) Formulation de dépendance d'informations, procédé d'utilisation et appareil
KR102651391B1 (ko) 회원 정보 관리 방법 및 그 장치
KR20120020501A (ko) 인터넷 쇼핑몰의 회원 정보 연동 시스템 및 그 연동방법
WO2018102912A1 (fr) Systèmes et procédés de commande d'accès au réseau par des utilisateurs délégués
HK1071453B (en) A method for user profile management
KR20040099231A (ko) 프라이빗 다중 사용자의 선택적 공유를 지원하는 웹상의 하드 디스크 운용 방법

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 07812536

Country of ref document: EP

Kind code of ref document: A2

NENP Non-entry into the national phase

Ref country code: DE

NENP Non-entry into the national phase

Ref country code: RU

122 Ep: pct application non-entry in european phase

Ref document number: 07812536

Country of ref document: EP

Kind code of ref document: A2