Classifications

• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F21/60—Protecting data
  • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
  • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
  • G06F21/6245—Protecting personal data, e.g. for financial or medical purposes
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
  • G06F21/31—User authentication
  • G06F21/33—User authentication using certificates
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
  • G06F21/45—Structures or tools for the administration of authentication
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F2221/2111—Location-sensitive, e.g. geographical location, GPS
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F2221/2145—Inheriting rights or properties, e.g., propagation of permissions or restrictions within a hierarchy

Definitions

• Computer systems and related technology affect many aspects of society. Indeed, the computer system's ability to process information has transformed the way we live and work. Computer systems now commonly perform a host of tasks (e.g., word processing, scheduling, accounting, etc.) that prior to the advent of the computer system were performed manually. More recently, computer systems have been coupled to one another and to other electronic devices to form both wired and wireless computer networks over which the computer systems and other electronic devices can transfer electronic data. Accordingly, the performance of many computing tasks are distributed across a number of different computer systems and/or a number of different computing environments. [0002] Stored data can be stored in multiple different scales and at multiple different sites.
• each unambiguous identifier may be associated with a specific set of permissions that specify what information may be obtained via that unambiguous identifier and how it may be used. For example, Jane may wish to separate aspects of her identity pertinent to her current employer from aspects of her identity related to social contexts embodied at www.Facebook.com or at www.hotmail.com.
• identity information is contextualized by location. Locations can include conventional location information such as mailing addresses, as well as geographical presence, such as dynamic or static latitude and longitude coordinates. Similar to relationships, it can be difficult represent such contextual information due at least in part to a variety of different data formats that can be used to store contextual information.
• identity data is typically separated from applications that used the identity data. For example, identity can be maintained in different computer stores in and at different scales tailored to specified application contexts. Thus, identity data is also typically stored separately from application data used by the application. For example, X.500 can silo identity data in a separate identify directory that is not well integrated with application data used by applications that access the X.500 directory. Thus, categorization of identity data, relationships between portions of identity data, and relationships between application data and portions of identity data are typically poorly reflected in these data structures.
• a federated identity fabric models identity data and relationships between portions of identity data in computer storage systems.
• the identity and identity relationship data is modeled in accordance with a logically uniform schema.
• the logically uniform schema can represent the existence of any entity that can be unambiguously identified. For example, an application in one computing environment can readily store, access, modify, delete, and secure identity and identity relationship data provided by another computing environment since the identity data is modeled in accordance with the logically uniform schema.
• the federated identity fabric can federate distributed identity and identity relationship data from computer storage systems within the variety of different computing environments.
• Code and metadata at computing environments associated with the federated identity fabric can interoperate to facilitate uniformly storing, accessing, modifying, deleting, and securing identity and identity relationship data within the federated identify fabric.
• an application in one computing environment can readily store, access, modify, delete, and secure identity data provided by another computing environment since the identity data is modeled in accordance with the logically uniform schema.
• the federated identify fabric is utilized to locate identity related data.
• a first data object is created within a data structure.
• the first data object represents an entity from the physical or digital world, within the data structure.
• the data structure is capable of representing, through the logically uniform schema, the existence of any entity that can be unambiguously identified.
• the first data object is stored into the federated identity fabric.
• a second data object is created.
• the second data object represents an unambiguous identifier used within the federated identity fabric.
• the second object is inserted into the federated identity fabric.
• the second data object is related to the first data object. Accordingly, that the second data object can subsequently be used to locate the first data object.
• the unambiguous identifier is subsequently used as a template for locating the second data object.
• the relationship between the first data object and the second data object is then used to locate the first data object subsequent to using the unambiguous identifier to locate the second data object.
• Identity related data for the entity is retrieved from the first data object.
• Embodiments of the invention can model parties, roles, persons, organizations, groups, locations, services, devices, authorities, taxonomies, and identity keys in an identity model. Definitions of and relationships between these objects represented in the identity model can be used to derive an efficient storage mechanism in computer storage systems.
• the identity model provides a mechanism to integrate and consistently maintain these objects.
• an identity key (e.g., the second data object) is used to access identity related data for a party (e.g., the first data object).
• one identity key e.g., the second data object
• another identity key e.g., a third data object.
• Figure 2B illustrates a portion of the computer architecture of Figure 2A for accessing party identity data form a key identifier.
• Figure 2C a portion of the computer architecture of Figure 2 A for transforming key identifiers.
• Figure 3 illustrates a flow chart of an example method for modeling and accessing modeled identity data from computer storage systems.
• Figure 4 illustrates a flow chart of an example method for accessing modeled identity data from computer storage systems.
• a federated identity fabric models identity data and relationships between portions of identity data in computer storage systems.
• the identity and identity relationship data is modeled in accordance with a logically uniform schema.
• the logically uniform schema can represent the existence of any entity that can be unambiguously identified. For example, an application in one computing environment can readily store, access, modify, delete, and secure identity and identity relationship data provided by another computing environment since the identity data is modeled in accordance with the logically uniform schema.
• the federated identity fabric can federate distributed identity and identity relationship data from computer storage systems within the variety of different computing environments.
• Code and metadata at computing environments associated with the federated identity fabric can interoperate to facilitate uniformly storing, accessing, modifying, deleting, and securing identity and identity relationship data within the federated identify fabric.
• an application in one computing environment can readily store, access, modify, delete, and secure identity data provided by another computing environment since the identity data is modeled in accordance with the logically uniform schema.
• the federated identify fabric is utilized to locate identity related data.
• a first data object is created within a data structure.
• the first data object represents an entity from the physical or digital world, within the data structure.
• the data structure is capable of representing, through the unified schema, the existence of any entity that can be unambiguously identified.
• the first data object is stored into the federated identity fabric.
• a second data object is created.
• the second data object represents an unambiguous identifier used within the federated identity fabric.
• the second object is inserted into the federated identity fabric.
• the second data object is related to the first data object. Accordingly, that the second data object can subsequently be used to locate the first data object.
• the unambiguous identifier is subsequently used as a template for locating the second data object.
• the relationship between the first data object and the second data object is then used to locate the first data object subsequent to using the unambiguous identifier to locate the second data object.
• Identity related data for the entity is retrieved from the first data object.
• Embodiments of the invention can model parties, roles, persons, organizations, groups, locations, services, devices, authorities, taxonomies, and identity keys in an identity model. Definitions of and relationships between these objects represented in the identity model can be used to derive an efficient storage mechanism in computer storage systems, such as, for example, database servers (e.g., a SQL Server database), in-memory data structures, etc.
• the identity model provides a mechanism to integrate and consistently maintain these objects.
• an identity key (e.g., the second data object) is used to access identity related data for a party (e.g., the first data object).
• one identity key (e.g., the second data object) is used to access identity related data from another identity key (e.g., a third data object). That is, given a first object 'A', a second object can be viewed as the identity of 'A'. A third object can be another identify key of 'A' .
• Embodiments of the present invention may comprise or utilize a special purpose or general-purpose computer including computer hardware, such as, for example, one or more processors and system memory, as discussed in greater detail below.
• Embodiments within the scope of the present invention also include physical and other computer- readable media for carrying or storing computer-executable instructions and/or data structures.
• Such computer-readable media can be any available media that can be accessed by a general purpose or special purpose computer system.
• Computer-readable media that store computer-executable instructions are computer storage media.
• Computer- readable media that carry computer-executable instructions are transmission media.
• embodiments of the invention can comprise at least two distinctly different kinds of computer-readable media: computer storage media and transmission media.
• Computer storage media includes RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store desired program code means in the form of computer- executable instructions or data structures and which can be accessed by a general purpose or special purpose computer.
• a "network” is defined as one or more data links that enable the transport of electronic data between computer systems and/or modules and/or other electronic devices.
• a network or another communications connection either hardwired, wireless, or a combination of hardwired or wireless
• the computer properly views the connection as a transmission medium.
• Transmissions media can include a network and/or data links which can be used to carry or desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer. Combinations of the above should also be included within the scope of computer-readable media.
• program code means in the form of computer-executable instructions or data structures can be transferred automatically from transmission media to computer storage media (or vice versa).
• computer-executable instructions or data structures received over a network or data link can be buffered in RAM within a network interface module (e.g., a "NIC"), and then eventually transferred to computer system RAM and/or to less volatile physical storage media at a computer system.
• a network interface module e.g., a "NIC”
• NIC network interface module
• computer storage media can be included in computer system components that also (or even primarily) utilize transmission media.
• Computer-executable instructions comprise, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing device to perform a certain function or group of functions.
• the computer executable instructions may be, for example, binaries, intermediate format instructions such as assembly language, or even source code.
• the invention may be practiced in network computing environments with many types of computer system configurations, including, personal computers, desktop computers, laptop computers, message processors, hand-held devices, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile telephones, PDAs, pagers, routers, switches, and the like.
• the invention may also be practiced in distributed system environments where local and remote computer systems, which are linked (either by hardwired data links, wireless data links, or by a combination of hardwired and wireless data links) through a network, both perform tasks.
• program modules may be located in both local and remote memory storage devices.
• embodiments of the invention include including a plurality of computer systems connected to one another over (or that are part of) a network, such as, for example, a Local Area Network ("LAN”), a Wide Area Network (“WAN”), and even the Internet.
• LAN Local Area Network
• WAN Wide Area Network
• Applications at least some of the plurality of computer systems can maintain identity and identity relationship data in accordance with a uniform identity model schema.
• identity and identity relationship data can be distributed across a variety of different computing environments (e.g., one or more of: different applications, different computer systems, different contexts, different networks, etc.).
• Each of the computer systems can also create message related data and exchange message related data (e.g., Internet Protocol (“IP”) datagrams and other higher layer protocols that utilize IP datagrams, such as, Transmission Control Protocol (“TCP”), Hypertext Transfer Protocol (“HTTP”), Simple Object Access Protocol (“SOAP”), etc.) over computer networks.
• IP Internet Protocol
• TCP Transmission Control Protocol
• HTTP Hypertext Transfer Protocol
• SOAP Simple Object Access Protocol
• applications maintaining identity and identity relationship data can federate to produce a federated identity fabric. Since each application modeling identity and identity relationship data does so in accordance with a uniform identity model schema, the collective identity and identity relationship data within the federated identity fabric is also modeled in accordance with a uniform identity model schema. Accordingly, identity and identity relationship data can be exchanged across applications through the federated identity fabric.
• the federated identity fabric can federate identity and identity relationship data distributed across computer storage systems within the variety of different computing environments.
• Computer-executable instructions and metadata at computing environments associated with the federated identity fabric can interoperate to facilitate uniform storage, access, modification, deletion, and security for identity and identity relationship data within the federated identify fabric.
• Figures 1A-1D illustrates an example schema 100 that can be used to model identity data for storage in computer storage systems.
• the schema represents information about digital subjects and resources that have relationships.
• Schema 100 is a logically uniform schema that can have varied implementations. That is, any of a variety of schema implementations can be utilized to realize the relationships in example schema 100.
• Different Kinds 101 of digital subject can share many of the same characteristics - while being different.
• the schema represents the common aspects of all digital subjects through an entity called a Party.
• a Party can then be specialized as depicted in Figure IA.
• Figure IA depicts a Party entry that has a name, a description, a time, span, and PrimaryKind (e.g., Person, Organization, Group, Software Service, or Device).
• PrimaryKind e.g., Person, Organization, Group, Software Service, or Device.
• a party type 102 is defined by one of organization 107, person 103, group 104, service 106, and device 171.
• Figure IA depicts a portion of a schema 100 for modeling a party.
• party type 102 is defined to be one its specializations (as an organization, a person, a device, a software service, or a group), one or more party locations, and one or more relationships to and from other parties.
• Parties may have relationships between them. Each party to party relationship is defined by a party to party relationship.
• Each party location is defined by party location 111, representing locations a party can be located at.
• Each party location 111 is defined by a location 112 refined from one or more parent locations.
• Each location 112 is defined by a variety of geographical points 113.
• Parties may be located at more than one Location. For each Location at which the Party is located, there exists information, such as the start date and end date denoting the duration of time that the party was associated with that Location, which must be recorder. In the model, these facts are recorded as instances of the type Party Location, which denotes the facts concerning one Party with respect to one Location.
• Locations may be further defined by a set of geographic coordinates, such as latitude and longitude values.
• a person can be defined by an amalgam of personas 108.
• Persons are an amalgam of Personas.
• a Persona instance contains personal information, such as, for example, personal name, gender, and photo, along with reference to the Party to which the Persona pertains. This allows multiple Personas (potentially also of different Kinds) to be aspects of the same 'Person' Party (one of the Personas being marked as the default) by following references from the Persona to Party. Accordingly, the notion of an individual may be the collective aggregate values of properties across one or more of these Personas.
• an individual person Jane Smith may own multiple Personas which she uses while logged on to different websites, multiple Customer roles which she maintains for her presence at different shopping websites, and an Employee role representing her employment with Microsoft.
• Jane Smith the real person is an instance of a Person type of Party, but anyone wishing to know different facets of Jane Smith must be allowed to inspect all instances of all types of Persona, which describe those different facets of the individual.
• Parties can act or be acted upon. In some embodiments, to be acted upon a party is able to act at least to an extent necessary to provide its identity.
• Schema 100 calls out a specialization of PartyToPartyRelationships called Roles.
• Roles provide a way to define and add information about aspects of a Party that is specific to a given relationship.
• Figure IA portrays examples of roles 109 that a Party can play: Employee 123, Customer 121, Citizen 122, Vendor 126, Authority 127 and ProcessRole 124. Whereas the specializations of Party can be mutually exclusive, Roles are amalgamated. Thus, a party can, and frequently does, have a plurality of different roles.
• Roles hold a reference to the Party which "plays" the Role in addition to a reference known as the ContextParty which refers to the Party for whom the Role is played. Roles may have a StartDate, EndDate and Kind.
• a Person's entire job history at a given organization can be modeled as a set of Employee Roles between the same Person and ContextParty, retaining full knowledge of when each position began and ended.
• the same schema can model all the jobs held by a Person at multiple Organizations, or a single job at a single Organization, or even all the People who have held some job over time.
• the same Person can be represented through different Personas in different contexts - for example, a "home” persona and a "work” persona.
• the relevant Roles e.g., Citizen - potentially of more than one country; Employee information; etc
• information relevant to many aspects of a person can be represented.
• the depicted party types and role types are some examples of the different types of parties and roles that can be exchanged between applications associated with a federated identify fabric. However, other types of parties and roles can also be defined.
• an organization can be a customer of another organization.
• a person can be a "member" of an organization.
• a party has concrete refinements named organization, person, group, software service and device.
• Party represents the common properties of its concrete refinements each of which has specialized properties that further characterize the specific concept.
• software services represent parties that are software agents and computer programs.
• Figure IB depicts a portion of a schema 100 for modeling policies and resources.
• One capability of the Indentity schema is to provide the basis for a distributed Policy Store.
• Policy 134 is used to facilitate and control the actions of Parties on Resources.
• the Service providing access to a Resource 134 employs Policy 133 to determine whether and how a Party 102 can access it.
• a resource (defined by resource 134) can be owned by many parties, each of which may control one or more resource.
• a PartyResource 172 represents an instance of a relationship between Party 102 and Resource 134 by specifying a reference to a particular Resource and to a particular party (defined by party 102).
• the set of Policies which govern access to a particular resource are referenced by an instance of PartyResource 172.
• at least two policy evaluations can be made. The first is to ensure that access conforms to the Policy associated with the Resource. The second is to ensure that access conforms to the Policy specified in the PartyResources relationship - in other words, applicable to the subject Party accessing the given Resource.
• the Policy associated with a Sales Report might say every member of an Organization can access it with Read permission.
• Schema 100 provides for each of these Policies being composed of other Policies as specified through PolicyRelationships 173 so as to allow reuse of Policy components.
• FIG. 1C depicts a portion of a schema 100 for modeling identity keys.
• an identity key can be associated with a set of tokens, each of which supports zero or more claims. Each claim can be an encoding of an assertion that the bearer of the token be permitted to perform specific actions against specific resources.
• each of the different types can have one or more identity keys.
• An identity key is defined by IdentityKey 142, is assigned by an authority (defined by authority 127) and includes one or more tokens.
• a token is defined by token 143 and can include one or more security claims.
• Various portions of this data such as, for example, a description, a value, and a time window, can be represent in key fields 181.
• Figure ID depicts a portion of a schema 100 for modeling taxonomies.
• taxonomy entries are categories that can be used to describe what type of thing a concept is. For example, there are different Kinds of Parties 102, different Kinds of Roles 109, different Kinds of PartyToPartyRelationships, different Kinds of IdentityKeys 142 and different Kinds of Locations 112.
• a taxonomy entry is called a Kind 101.
• one kind of identity key might be an email alias.
• Another kind of identity key might be a Federal Social Security Number.
• the categorization of each identity key would be recorded by an association between instances of identity key and instances of kind.
• kinds can be formulated for each of the different types (person 103, group 104, software service 106, organization 107, and device 171) of parties (defined by party 102) can have one or more identities defined by an identity key.
• kinds can also be formulated for policies 133, authorities 127, and identity keys 142. Relationships between kinds are defined by kind relationships 162.
• kinds generally form a polyarchy (i.e., each kind can have a plurality of parent categories that are also kinds). However, hierarchically arranged kinds are also possibly (i.e., each kind has one parent category that is also a kind). Associations, such as "parent”, are represented as kind relationships. Kind Relationships themselves may be categorized, and hence may also be associated with a kind that represents the kind of relationships between kinds.
• an address (a Kind) may be said to be a type of Location.
• a mailing address and a billing address (each of which is a kind) can be viewed as more refined definitions of an address than the notion of address.
• Address may be recorded as the parent of mailing address and billing address by two instances of kind relationship 162 - one from mailing address to address, the other from billing address to address.
• These instances of taxonomy relationship may be categorized as ParentOf by reference to a kind whose content is RefinementOf (which may itself be associated by a further kind relationship instance that categorizes RefinementtOf to be a type of StructuralRelationship which itself is a kind.
• embodiments of the invention utilize the notion of a party and its more concrete refinements - person, organization, group, service, device and service - which can be used where references to parties are used.
• Parties may represent objects from the physical world or digital world and may represent both consumers and suppliers of services, including digital services offered by authorities.
• Roles may also reference some context to which they apply, for example, some other party.
• “employee” is a role that could be played by one party (e.g., a person) with respect to another (e.g., an organization).
• a person itself is nothing other than an amalgam of separate Roles which people can play - for example, a citizen, a customer, an employee, a process role, and a private person.
• a single party may play multiple types of Roles.
• a person can be an employee as well as a citizen (different types of roles).
• a party can also be in more than one of the same type of role.
• a person can play two employee roles, each for a different organization.
• a party can be in the same type of role - and in the same context - but over different, possibly overlapping, time spans.
• Parties typically support different types of party-to-party relationships (such as "friend of, subordinate, supervisor, etc.).
• Each of the parties and the separate roles a party plays may be uniquely identified in a number of different ways - for example, using an email address, a federal identifier, an employee number, and so on.
• Embodiments of the invention include representing unique identifiers with an identity key data type.
• Identity key data types indicate the secure identities of individual parties (the security characteristics being variable), for example, issued by a known Authority (which itself is a role played by some
• Identity keys can be differentiated through unique values of a given type and reference the relevant party.
• One benefit is that an identity key of any given type can be efficiently located through presentation of any other identity key, and the references to the relevant party and associated role efficiently obtained.
• the use of identity keys permits customization of digital experience - for example, permissions to access individual data.
• Embodiments of the invention also utilize a location type to support different kinds of physical and virtual places at which parties may be located. Locations may be described using text fields (as in an Address) or using geographic coordinates. Since parties, locations, and identity keys can exist in a large number of and can be of very different kinds, a taxonomy mechanism, previously described as Kinds, can be used to define and record the varying types of each. As previously described, kinds can be polyarchical or hierarchical and can themselves be taxonomized (that is, there can be kinds of kinds).
• Computer systems in the different computing environments can include computer-executable instructions and metadata for composing the federated identity fabric.
• the computer-executable instructions and metadata at the computer systems can interoperate to compose the federated identity fabric and reflect a centralized repository back the computer systems.
• the centralized repository can store the data structures and mechanisms (e.g., applications and services) in accordance with various data models of schema 100.
• applications and services built upon and/or integrated into the centralized repository can be configured to process data in accordance with the various data models.
• applications and services can share object-centric data, such as, for example, identity related data, with one another.
• Embodiments of the invention also provide consistent access to information across varied contexts, devices, and scales from a variety of different perspectives. For example, an individual can consistently access his or her information via a wireless Internet connection using a cell phone while traveling in India or via a corporate LAN connection using a desktop computer system in an office in the United States. Services and applications that process such communication can have embedded computer- executable instructions and metadata for processing identity related data defined in accordance with the various data models of schema 100. Accordingly, functionality to navigate across scales, devices, and contexts can be included as components within a federated (e.g., logically unified) identity fabric.
• federated e.g., logically unified
• Embodiments of the invention provide access to information through replication and caching of data employing the same data structures used to master it and metadata facilitating replication.
• Replication and caching provide efficient alternatives to employing telecommunications systems in real time to access information stored elsewhere in a network, including the Internet.
• the identity information of parties related to Jane Doe including the partytoparty relationships, identity keys, location information and more, could be replicated, in the same logical structure as used elsewhere, onto her cell phone.
• applications on her cell phone can also process identity data efficiently even when communication with a central location is difficult or expensive.
• Figure 2A illustrates an example computer architecture 200 that facilitates modeling identity information in computer storage systems.
• computer systems 201, 202, 213, and 214 are connected to federated identity fabric 207.
• Each of computer systems 201, 202, 213, and 214 can include applications having computer-executable instructions and metadata for composing and associating with federated identity fabric 207.
• each of computer systems 201, 202, 213, and 214 can include applications having computer-executable instructions and metadata for presenting federated identity fabric 107 as a centralized repository of identity data to other applications at each of computer systems 201, 202, 213, and 214 respectively.
• Each of computer systems 201, 202, 213, and 214 can also include applications having computer-executable instructions and metadata to interoperate with federated identify fabric 207 to facilitate uniform storage, access, modification, deletion, and security for identity and identity relationship data within federated identify fabric 207.
• computer system 201 can maintain key identification table 20 IK and party identification table 20 IP locally, such as, for example, on disk or in system memory.
• Key identification table 20 IK can include one or more key identification entries defined in accordance with the model in Figure 1C.
• entry 21 IK includes key type 231 (e.g., email alias), key ID value (e.g., jdoe@test.com), party ID 233 (an ID corresponding to the person having the email alias ofjdoe@test.com), and optionally role ID 234 (an ID corresponding to the role the person identified by party ID 233 is in for the email alias ofjdoe@test.com).
• Party identification table 20 IP can include one or more party identification entries defined in accordance with the model in Figure IA.
• entry 21 IP includes party type 235 (the type of party selected from organization, person, group, service, and device), party ID value 236 (the ID value for the party type), role type 237 (a type of role from the those defined for the party type, such as, for example, customer, basic citizen, employee, process role, private person, authority, etc.), and role ID value (the ID value for the role type).
• Entry 21 IP can also include one or more locations and party to party relationships as appropriate.
• Entry 21 IP also includes identity data values 239.
• Identity data values 239 represent the data for the party, such as, for example, a display name.
• Identity data values 239 can include any data associated with a party and may or may be represented in identity keys for the party. For example, a telephone number for a party can be used in an identity key but might also be included in identity data values 239.
• Applications at computer system 201 can also stitch key identification table 20 IK and party identification table 20 IP into federated identity fabric 207.
• key identification table 202K includes entry 212k including key type 241, key ID value 242, party ID value 233, and optionally role ID 234. Since entry 212K includes party ID 233 and potentially role ID 234, entry 212K can indicate a different type of key that corresponds to same party associated with key type 231 (i.e., party ID value 233 and/or role ID 234 link entry 21 IK and 212K).
• party identification table 202P includes entry 212P including party type 245, party ID value 233, role type 246, role ID 234, other fields, and identity data values 249. Since entry 212P includes party ID 233 and potentially role ID 234, key entries associated with party ID value 233 and/or role 234 can be used to locate identity data values 249.
• Similar applications at other computer systems can stitch key identification tables 203K and 204K and party identification table 206P into federated identity fabric 207.
• Applications at computer system 201 can also present federated indentify fabric 207 as a central repository to other applications at computer system 201 (e.g., application 208).
• applications at computer system 201 can collectively view key identification tables 20 IK, 202K, 203K, and 204K as key identification table information 261.
• applications at computer system 201 can collectively view party identification tables 21 IP, 212P, and 206P as party identification table information 262.
• Computer systems 202, 213, and 214 can have applications providing similar functionality. Accordingly, applications at any of computer systems 201, 202, 213, and 214 can securely access, modify and delete identity and identity relationship data within federated identify fabric 207 in accordance with the definitions in schema 100.
• Figure 3 illustrates a flow chart of an example method for modeling and accessing modeled identity data from computer storage systems.
• Method 300 will be described with respect to the components and data in Figure 2A and the definitions in schema 100.
• Method 300 includes an act of creating a first data object within a data structure, the first data object representing an entity from the physical or digital world, within the data structure, the data structure capable of representing, through a logically uniform schema, the existence of any entity that can be unambiguously identified (act 301).
• computer system 202 can create entry 212P in party identification table 202P. Entry 212P can represent an organization in accordance with the data model in Figure IA.
• Method 300 includes an act inserting the first data object into the federated identity fabric (act 302).
• Method 300 includes an act of creating a second data object containing the representation of an unambiguous identifier used within the federated identity fabric (act 303).
• computer system 202 can create entry 212K.
• Various characteristics of entry 212K such as, for example, a combination of field values, can be used to represent an unambiguous identifier for entry 212K within federated identity fabric 207.
• Method 200 includes an act of inserting the second data object into the federated identity fabric (act 304).
• computer system 202 can stitch entry 212K into federated identity fabric 207.
• Method 300 includes an act of relating the second data object to the first data object such that the second data object can subsequently be used to locate the first data object (act 305). Inclusion of the same value in two different entries can be used to relate the entries to one another. For example, the reference to party ID value 233 in entry 212K and in entry 212P relates entries 212K and 212P to one another. Thus, entry 212K can be used to locate entry 212P (and potentially vice versa).
• Method 300 includes a functional result oriented step for accessing identity related data from the first object through the relationship (step 309). Step 309 can include virtually any corresponding acts to achieve the result of accessing identity related data from the first object through the relationship.
• step 309 includes a corresponding act of subsequently using the unambiguous identifier as a template for locating the second data object (act 306).
• application 208 can send query 221 to federated identity fabric 207.
• Query 221 can include the unambiguous identifier for entry 212K.
• Federated identity fabric 207 can receive query 221 from application 208.
• Federated identity fabric 207 can use the unambiguous identifier to locate entry 212K.
• step 309 also includes an act of using the relationship between the first data object and the second data object to locate the first data object subsequent to using the unambiguous identifier to locate the second data object (act 307).
• step 309 also includes an act of retrieving identity related data for the entity from the first data object (act 308).
• identity related data can include information generic to any kind of party, information stored using a schema for the particular kind of party that has been located, information about the relationship of party has to any other party of any other type, or information about alternate unambiguous identifiers related to the same party.
• FIG. 4 illustrates a flow chart of an example method 400 for accessing modeled identity data from computer storage systems.
• Figure 2B illustrates a portion of the computer architecture 200 for accessing party identity data from a key identifier. Method 400 will be described with respect to the components and data in Figures 2 A and 2B.
• Method 400 includes an act of receiving a request for identity related data for a party (act 401). For example, referring to Figures 2B federated identity fabric 207 can receive query 221.
• the request can include an identity key type defined in accordance with a identity key taxonomy within a single schema.
• the single schema is capable of representing the existence of any entity that can be unambiguously identified.
• the request can also include an identity key value indicating a value of the identity key type.
• the combination of identity key type and identity key value representing (unambiguously) an entry within key identification table information.
• query 221 includes key type 231 and key ID value 232.
• the combination key of type 231 and key ID value 232 unambiguously represents (or is an unambiguous identifier for) entry 21 IK within key identification table information 261.
• the request can also include a data request.
• the data request represents a request for a portion of identity related data through the use of the combination of identity key type and identity key value and a relationship to other identification table information.
• the request is a data value request.
• the data value request represents a request for a portion of party related identity data from a party table entry identifiable through the use of the combination of identity key type and identity key value and a relationship to party identification table information.
• query 221 includes data value request 241.
• Data value request 251 represents a request for a portion of party related identity data from a party table entry identifiable through the use of the combination of identity key type 231 and identity key value 232 and a relationship to party identification table information 262.
• Method 400 includes an act of locating the key identification table entry, within the key identification table information, that corresponds to the combination of the identity key type and identity key value (act 402).
• federated identity fabric 207 can locate entry 22 IK, within key identification table information 262, that corresponds to the combination of key type 231 and key ID value 232.
• Method 400 includes an act of accessing a party identifier value from the key identification table entry, the party identifier value corresponding to the party associated with the identity key (act 403).
• federated identity fabric 207 can access party ID value 233 from entry 21 IK.
• Method 400 includes an act of referring to an entry in other table information based on the accessed party identifier and the relationship to the party identifier (act 404).
• federated identity fabric 207 can refer to entry 212P (in party identification table 202P) based on party ID value 233 being included in both entry 21 IK and entry 212P.
• Method 400 includes an act of retrieving identity data responsive to the data request from the entry in the other table (act 405).
• federated identity fabric 405 can retrieve identity data values 249 (e.g., a display name) from entry 212P.
• Identity data values 249 can be responsive to data value request 251.
• Method 400 includes an act of returning the identity data in response to the received request (act 406).
• federated identity fabric 207 can return results 222 (e.g., back to application 208), including data values 249, in response to query 221.
• a data request is a key type request.
• Embodiments of the invention include implementing method 400 for key type requests.
• the key type request represents a request for the corresponding key value of a second identity key type associated with a party.
• the second identity key type is also defined in accordance with the identity key taxonomy within the single schema.
• key type 231 can be a key type for email alias and key ID value 232 can be jdoe@test.org.
• query 221 includes key type request 271.
• Key type request 271 represents a request for a key identification entry of key type 241 within key identification table information 261.
• Key type 241 is also defined in accordance with schema 100.
• Key type 241 can be a key type for telephone number. Accordingly, query 221 can be a request for the telephone number of the party having the email alias jdoe@test.org.
• Federated identity fabric 207 can then locate entry 22 IK, within key identification table information 262, that corresponds to the combination of key type 231 and key ID value 232. That is, federated identity fabric 207 locates a key entry for email alias that has a value ofjdoe@test.org. Federated identity fabric 207 can then access party ID value 233 from entry 21 IK. Party ID value 233 represents the ID value for the party that has the email aliasjdoe@test.org.
• Federated identity fabric 207 can then refer to key identification table information 261 to locate entry 212K.
• Entry 212K is of key type 241 and includes party identifier 233. That is, entry 212K is an identity key for the telephone number for the party that has the email alias jdoe@test.org.
• Federated identity fabric 207 can then retrieve key ID value 242 (e.g., a telephone number) from entry 212K.
• Federated identity fabric 207 can return results 222 (e.g., back to application 108), including key ID value 242, in response to the query 221.
• embodiments of the invention include utilizing an identity key table entry to locate party identity data (e.g., as depicted in Figure 2B) and performing key transformations between different types of identity keys (e.g., as depicted in Figure 2C).
• one data object e.g., the second data object
• the one data object can be configured to provide unambiguous identification of the other data object (e.g., through a configured relationship between the one and the other object).
• existing objects which may not be unambiguously identifiable can still be unambiguously identified through the use of another related object that is unambiguously identifiable.

Landscapes

• Engineering & Computer Science (AREA)
• Theoretical Computer Science (AREA)
• Computer Security & Cryptography (AREA)
• General Physics & Mathematics (AREA)
• Physics & Mathematics (AREA)
• General Engineering & Computer Science (AREA)
• Software Systems (AREA)
• Computer Hardware Design (AREA)
• Health & Medical Sciences (AREA)
• Bioethics (AREA)
• General Health & Medical Sciences (AREA)
• Medical Informatics (AREA)
• Databases & Information Systems (AREA)
• Storage Device Security (AREA)

Priority Applications (3)

Applications Claiming Priority (4)

Publications (2)

Family

ID=42119909

Family Applications (1)

Country Status (5)

Cited By (2)

Families Citing this family (5)

Family Cites Families (17)

• 2009
  • 2009-03-25 US US12/410,680 patent/US8171057B2/en not_active Expired - Fee Related
  • 2009-10-16 CN CN200980142630.XA patent/CN102197399B/zh active Active
  • 2009-10-16 WO PCT/US2009/060966 patent/WO2010048046A2/en not_active Ceased
  • 2009-10-16 EP EP09822476.9A patent/EP2353104A4/en not_active Ceased
  • 2009-10-16 JP JP2011533245A patent/JP5701764B2/ja not_active Expired - Fee Related

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events