EP3219074A1

EP3219074A1 - Network based identity federation

Info

Publication number: EP3219074A1
Application number: EP15797147.4A
Authority: EP
Inventors: Adrian Waller; David Williams
Original assignee: Thales Holdings UK PLC
Current assignee: Thales Holdings UK PLC
Priority date: 2014-11-12
Filing date: 2015-11-12
Publication date: 2017-09-20
Also published as: WO2016075467A1; GB2532248B; GB2532248A; GB201420166D0

Abstract

The disclosure concerns the establishment of a network based system for executing information transactions. An identity assertion, confirmed by one computer in the network, can be distributed to other computers in the network, on the basis of trust based relationships between computers. Trust based relationships between computers can be delegated along trust pathways linking computers not in direct communication in the network.

Description

Network based identity federation

FIELD Embodiments described herein relate to the field of internet security, and particularly to the establishment of trust between users and service providers.

BACKGROUND

The concept of Federated Identity Management (FIM) involves the provision of facilities which enable management of identity and trust across plural users, devices and organisations. One example of FIM is WS-Federation, developed collectively by BEA Systems, Inc., BMC Software, CA, Inc., International Business Machines Corporation, Layer 7 Technologies, Microsoft Corporation, Inc., Novell, Inc. and VeriSign, Inc.

The WS-Federation specification defines a Federation as a collection of realms that have established a producer consumer relationship whereby one realm can provide authorized access to a resource based on an identity, and possibly attributes, that are asserted on another realm. A "realm", in the context of WS-Federation, is a single unit of security administration or trust, and could be exemplified by a single computer, or by a computer network wholly confined to, associated with, or managed by a single commercial entity. A WS-Federation realm is an example of an identity management system domain. A domain can be implemented at a physical level or at a layer of abstraction away from the physical. That is, at the physical level, a domain may be created around the control of access to a particular computer, or a group of computers, using secure identity authentication.

For instance, a user may be authenticated by insertion of a computer readable card into a receptacle of the computer - without this card, the user cannot use the computer. The domain could cover either this one computer, or a group of networked computers, each of which is accessible only to authorised carriers of an authentication card. At another layer of abstraction, a computer may be operable to execute a plurality of programs. One of these programs is only executable when a user establishes that he has authority to do so. This could be established by use of authentication information, such as a user identity name and a password, issued to the user. The domain, in this context, is the program as accessible only to authorised users. Similarly, the program code could be networked, and accessible from any number of computers, or may be internet accessible in which case any computer could be used for appropriate access. In this case, the domain is not limited to particular hardware, only to particular access of software facilities.

A combined approach might involve ensuring that a computer implemented program or data facility is only accessible to particular users when using particular networked machines. So, even though another computer may have direct connection to a computer storing data the subject of the security measures, a user on that computer would not be authorised to access the data if that computer were not part of the defined domain.

For reasons of clarity, the term "domain" is used through this disclosure as the present disclosure is not tied to the WS-Federation specification.

So, an identity management system domain need not be constrained to a particular piece of physical equipment. That is, an implementation of a domain may be distributed across a plurality of computers. It is not essential that all computers which collectively host a domain should be directly managed by a single entity. For instance, a commercial entity implementing a domain could source at least part of its computing resources from third parties, using cloud-based computing. An identity management system domain can still be implemented in these circumstances, if the data and processing within the domain can be contained within a single security policy. Further, several domains can be implemented on a single computer, or a plurality of interconnected computers. This can be achieved by way of access control and encryption. A process within a particular domain does not necessarily obtain access to all domains hosted on the same computer or computers. A primary aim of FIM is to enable a user to access multiple resources across security domains having been authenticated just once. The alternative requires a user to hold multiple accounts in order to access the resources they require. In such a scenario, each service would be responsible for its own access control and each user is required to register with every resource that they wish to consume. This puts a burden on users, who have to register multiple times, as well as resources, who are responsible for verifying user identities and attributes themselves.

FIM is achieved by each security domain having one Identity Provider (IdP) to which all its users register. This IdP issues tokens to its users that assert their identity and/or attributes, which can then be used to access resources in the domain. In FIM, two IdPs in different domains establish a trust relationship, which allows them to recognise and accept tokens from each other, thus allowing users in one domain to access resources in the other without having to register again.

Federated Identity Management (FIM) is a means of enabling single sign-on functionality for users of multiple resources. In the commercial sphere, various examples of FIM exist. For instance, Microsoft Account, offered by Microsoft Corporation of Redmond, WA, USA, provides a third party service provider with a mechanism to establish a trusted relationship with a user, by virtue of a user identity (Microsoft Account ID) associated with a user signed up to Microsoft Account. If the third party service provider establishes a trust relationship with the Microsoft Account system, then the third party service provider can establish a trust relationship with users with a Microsoft Account ID, without further user identification processes being necessary.

Therefore, Microsoft Account provides a facility whereby a user can sign in to a website provided by a third party using a single set of credentials. A website using this service would indicate, on its website, that it supports Microsoft Account, which would encourage users who had previously established their Microsoft Account ID to use this ID to sign in to the website. It is a matter of considerable convenience to users to be able to use pre-existing web identities such as Microsoft Account, for two reasons. Firstly, it avoids the need to execute a laborious sign-up process, including data entry of names, addresses, personal details such as date of birth and financial information, each time a user wants to engage with a new website. Secondly, it immediately forms, in the user's mind, the same level of trust for the operator of the third party website as the user might associate with the Identity Provider, Microsoft in this example.

In current implementations of FIM, only pairwise FIM relationships are possible. That is, for example, the fact that a third party website is enabled with Microsoft Account, has no bearing on the trust relationship between that third party website and other similarly enabled third party providers. In other words, two IdPs are able to establish a trust relationship with each other, and accept each other's tokens, but where there are multiple domains, and associated IdPs, it is necessary for each pair of IdPs to separately establish trust relationships with each other. As the number of domains increases, this becomes impractical, as the number of such relationships that have to be established and maintained is 0(n²) , where n is the number of domains.

A few technologies support the concept of "brokered trust", such as WS-Trust. WS- Trust is a specification administered by OASIS of Burlington, MA, USA. In this model, two IdPs which do not have an existing trust relationship can establish such a relationship by brokering it through a third-party IdP with whom they have both established trust. By using this approach, the number of trust relationships in total, and the number of trust relationships that each individual IdP has to establish and manage can, at least theoretically, be considerably reduced. However, existing technologies do not provide a way of constructing a network of trusted IdPs based on this model, and only use it in a very simple way. For example, each IdP trusts a single central IdP which is used to broker trust between all pairs of IdPs. In practice, such a model is very constraining as each IdP has no option but to trust this central IdP, and of course it places a significant burden on the central IdP. In this approach, the number of IdP relationships that have to be established and maintained will be 0(n²) , where n is the number of IdPs, and so the same scalability problem as for pairwise FIM exists with WS-Trust also.

It is desirable to provide users with freedom to choose which IdPs to use to assert their identities. Indeed, there may be regulatory reasons which particular IdPs need to be used in particular circumstances. For instance, for controlling access to medical records, a medical services provider may require that a particular level of identity authentication be used, which some IdPs may not be able to fulfil. In contrast, a provider of a multiple player on-line game may not need this degree of authentication, and will need to be able to use an identity authentication method accessible to its chosen demographic. In the case of children and other informal users, this may best be served by relying on identity authentication services provided by social networking services.

The number of sources of IdP facilities that currently exists is potentially very large. Already, government agencies, financial institutions, social networking services and other subscription organisations are providing or could provide certain levels of authentication, to a variety of different degrees of trust. If a service provider wants to offer a user a choice of different ways to authenticate user identity, then it is likely to be impractical for the service provider to make arrangements with every conceivable identity provider. DESCRIPTION OF DRAWINGS

Figure 1 is a schematic diagram showing interconnections between actors establishing the internet;

Figure 2 is a schematic diagram illustrating transactions between internet enabled parties;

Figure 3 is a schematic diagram of a user computer in accordance with an embodiment described herein; Figure 4 is a schematic diagram of a webpage server in accordance with an embodiment described herein;

Figure 5 is a diagram showing a peer-to-peer (P2P) network in accordance with an embodiment described herein;

Figure 6 is a process diagram showing establishment of the P2P network illustrated in figure 5;

Figure 7 illustrates a process of establishing a distributed hash table (DHT) underlying the P2P network illustrated in figure 5; Figure 8 is a schematic diagram of an IdP computer in accordance with an embodiment described herein; Figure 9 is a process diagram illustrating a user registration process in accordance with an embodiment described herein;

Figure 10 is a schematic diagram of a federated authentication arrangement in accordance with an embodiment described herein;

Figure 1 1 is a diagram of a vendor website framework in accordance with an embodiment described herein;

Figure 12 is a schematic screen layout of a sign-in webpage offered by a vendor website in accordance with an embodiment described herein;

Figure 13 is a schematic screen layout of a delegated IdP sign-in webpage offered through a vendor website in accordance with an embodiment described herein; and Figure 14 is a flow diagram for an authentication process executed through the federated authentication arrangement illustrated in figure 10.

DESCRIPTION OF EMBODIMENTS

In general terms, embodiments described herein provide a mechanism to allow a trust domain, implemented in a computer network, to establish communication with another trust domain, despite the absence of a direct trust relationship between them. This is achieved by arranging that a trust pathway message be sent from a sending trust domain, towards an intended destination domain, via one or more intermediary trust domains. Each trust domain holds a record of at least some of the trust relationships that that domain has established with other domains. Any trust pathway message is sent to one of the domains identifiable from that trust relationship record. At each intermediary domain, incoming trust pathway messages are passed on (or repackaged, as the case may be) to a trust domain similarly identifiable from the local trust relationship record.

Certain embodiments employ the concept of proximity, so that the selection of a trust domain to act as intermediary is carried out on the basis that the message should be sent to that domain closest to the intended destination. Proximity is, in certain embodiments, measured with reference to the number of degrees of separation, by trust relationship, between the candidate domain and the intended destination. Particular embodiments conceptually arrange the trust domains as partitions (nodes) of a coordinate space. In one embodiment, the coordinate space is a ring, and the partitions are positions on that ring. Other embodiments are envisaged whereby the coordinate space is a surface, such as a multi-torus. Routing of messages in the network of trust domains is described in further detail with regard to the following specific description of embodiments.

As shown in Figure 1 , the described embodiment is implemented using the internet. The term "internet" is widely used to encompass the worldwide interconnection of numerous computers and computer networks. The term is, by virtue of its extensive use, nebulous and rather indeterminate. The Internet is in essence a network of networks. Using generally agreed communication protocols, communication can be effected between computers by virtue of the existence of interconnections between them. Then, data can be transferred from one computer to another, using further layers of communications protocols.

A simple way of understanding the layering of protocols is the Open Systems Connection (OSI) model, which is a conceptual way of explaining how an application executed on one computer can communicate with an application executed on another computer. Various publicly available references provide a detailed explanation of the OSI model, and the model will therefore not be described in depth in this disclosure.

In essence, using the OSI model, the processing capabilities of a computer can be organised into layers, usually seven in number. Applications generally reside at a highest layer. Communication facilities are served by lower layers to higher layers. The lowest layer in the OSI model is a conceptual representation of the direct physical connection from one computer to another.

By this, the communication of data from an application on one computer to an application on another computer can be organised consistently and effectively. The internet operates because there is a widespread acceptance of the OSI model, and there are widely adopted protocols at each layer, with considerable compatibility between protocols in adjacent layers. Thus, information packaged and sent using the Internet Protocol (IP) will be capable of being unpacked at a recipient computer, regardless of the nature of the physical connection (i.e. wireless, wired, direct or indirect) between those computers.

By this, users of internet capable devices can access data, processing facilities and other capabilities, stored on computers at remote locations. Typically, much use of the internet is focused on the retrieval of information organised in documents, expressed in a mark-up language such as Hypertext Mark-up Language (HTML), referred to as web pages. Web pages are made available for download using a web server, which is an application, executed on a server computer, responsive to requests for download. A browser is also able to send data to computers hosting web pages, for instance to enable the submission of information or to effect commercial transactions.

Interconnection of user equipment to the resources available via the internet can be achieved in numerous ways. Many interconnection protocols exist. The arrangement illustrated in figure 1 is merely an example embodiment, and variations on that will be evident to the reader.

Figure 1 illustrates a typical arrangement of computers involved in the establishment of an internet service. In particular, it illustrates the physical connections which are involved in establishing a link between a user computer 100 and other devices in the internet which may be storing information or data processing facilities of interest to the user of the user computer 100.

The nature of the user computer 100 is not specified, but it could be a personal computer (PC), laptop, tablet, smartphone, or any other item of equipment with internet connectivity facilities. Nowadays, even refrigerators are being provided with such connectivity. Also, the reader will appreciate that the internet is increasingly being used for "machine to machine" (M2M) interactivity, that is, by devices which may be focused more on automatic monitoring of processes and information, and may be less focused on providing a sophisticated user interface. The internet is a means of distributing information, and is not solely a means of enabling the download of web- pages for them to be viewed by a human user.

The user computer 100 connects to a wireless hub 12 by means of a wireless connection, with communications established in accordance with a pre-agreed wireless communications protocol. A popular choice of wireless communications protocol is that described in the various technical standards under the 802.11 heading produced by the Institution of Electrical and Electronic Engineers (IEEE). The wireless hub 12 is connected to a DSL modem 14 by means of a wired Ethernet connection. The function of the DSL modem 14 is to establish connection, via physical communications infrastructure, to internet access facilities provided by an internet service provider. To do this, the DSL modem 14 is operable to emit and receive signals over a wideband communications channel established on a physical medium. The DSL modem 14 is physically connected to communications infrastructure, in this case the public switched telephone network (PSTN).

The operator of the PSTN 16 establishes connection of subscribers' DSL modems with a DSL access multiplier 18. This enables multiplexing of individual subscribers' DSL signals for reasons of efficiency. The DSL access multiplier 18 is in communication with a network gateway 20, which provides access to a network 22 operated by the provider of the internet access service to the user, otherwise known as the Internet Service Provider (ISP). The ISP network 22 manages internet access requests from users, and the transport of information to and from remote locations via the internet. It is, in essence, a gateway to the network of networks which is described conceptually as "the Internet".

In this example, the ISP network 22 is shown as being interconnected with other Internet Protocol (IP) enabled networks 30. These may be very large networks of many interconnected computers, or they may be trivial in comprising a single computer. Alongside these, the ISP network 22 has access to a domain name system (DNS) server 32. The ISP network 22 can make reference to the DNS server 32 to resolve access requests expressed as uniform resource locators (URLs) into numerical IP addresses. The manner in which this is achieved is well-known, and will not be described in depth herein.

As shown in figure 1 , the illustrated IP enabled networks 30 may be connected to further computing facilities. Repetition of this interconnection eventually leads to worldwide interconnectedness, to the great benefit of internet users.

While the user computer 100 has been illustrated, in this example, as being connected to the DSL modem by means of the wireless connection established by the wireless hub 12, other modes of connection are entirely possible. For instance, an Ethernet connection might be established by a direct wire connection between the user computer 100 (if suitably configured for Ethernet connection), or power line communication may achieve the same result. The choice of connection is not material to this disclosure.

In some examples, the function of the wireless hub 12 and the DSL modem 14 are combined into a single device.

Figure 2 illustrates the same arrangement as figure 1 , but on a functional basis. In this figure, the user computer 100 is shown as connected via "the Internet" (using the physical facilities described above) to web page servers 40. Four web page servers are illustrated in figure 2 but, as will be clear from following description, the present disclosure contemplates that a higher number of web page servers may be accessible.

Each web page server 40 is implemented on a computer operating in one of the IP enabled networks 30 illustrated in figure 1. Using a browser, the user computer 100 can download information from one of the web page servers 40, and can send information in return.

A typical client device is illustrated in figure 3. As illustrated, the user computer 100 comprises a processor 120 coupled with a mass storage unit 122. A working memory 124 is also accessible by the processor 120. The user computer 100 is shown, in use, with user applications 126 and a communications controller 128, which are software components loaded into the working memory 124. Also provided is a browser 129. The processor 120 is thus capable of executing software instructions of the user applications 126, the communications controller 128, or the browser 129 as required.

The processor 120 accesses other electronic components of the user computer 100 using a bus 130. Among these components includes a communications unit 132, which is a processing component devoted to the management of and access to a communications channel. The communications channel may be in this case a wireless communications channel, such as using the Wi-Fi protocol. A user input unit 136 offers the user a facility to enter information for control of the user computer 100, and, for instance, to enter information for use of the browser 129. The user input unit 136 could be, in use, a touch sensitive screen (with software which, when executed by the processor 120, causes a soft keyboard to be displayed on screen for use by the user), or a physical keyboard and mouse, depending on the implementation. A user output unit 138 can include any means of outputting information to a user, including a screen (with appropriate graphics and display drivers), an audio output device (e.g. a loudspeaker) or other appropriate output devices such as means for generating vibration which would be discernible to a user of a handheld device.

Similarly, a typical web page server is illustrated in figure 4. The web page server 40 is typically a general purpose computer apparatus, but one suitable to fulfil a server function. As illustrated, the web server device 40 comprises a processor 220 coupled with a mass storage unit 222. A working memory 224 is also accessible by the processor 220. The web server device 40 is shown, in use, with user applications 226 and a communications controller 228, which are software components loaded into the working memory 224. Also provided is a server application 229. The processor 220 is thus capable of executing software instructions of the user applications 226, the communications controller 228, or the server application 229 as required.

The processor 220 accesses other electronic components of the web server device 40 using a bus 230. Among these components includes a communications unit 232, which is a processing component devoted to the management of and access to a communications channel. For the purpose of fulfilling the server functionality of the web server device 40, the communications channel is likely to be a DSL channel established on a wired connection, given the likely volume of traffic which will be experienced. An administrator input unit 236 offers an administrator a facility to enter information for control, configuration and administration of the web server device 40. The administrator input unit 236 would most likely be a physical keyboard and mouse, depending on the implementation. A user output unit 238 can include any means of outputting information to a user, most likely including a screen (with appropriate graphics and display drivers), and an audio output device (e.g. a loudspeaker).

A user may wish to purchase goods online, for home delivery. To meet this demand, the web page server 40 may be operated by a commercial entity for presentation of a commerce website, to enable commercial transactions to be carried out by users, and to enable goods to be selected and purchased, and for such home delivery to be initiated. The commerce website is defined by html information stored in the mass storage unit 222. The web page server 40 is operable to serve this html information to client computers, on receipt of appropriate browser requests and through execution of the web server application 229.

As will be understood, this type of commercial transaction requires several trust relationships to be established. For instance, at a human level, the user will need to trust the commercial entity to honour a commitment to deliver goods once they are purchased. The user will also need to be able to trust the commercial entity not to divulge personal information provided by the user, such as the home address of the user, without authority. If payment by the user is effected by credit card, the commercial entity will need to be able to trust the financial institution providing the credit card that payment so effected will be delivered upon within agreeable payment terms. Further, the financial institution may impose rules as to the level of data security to be applied to data exchanges between the commercial entity and the user, to authenticate the user and the credit card information. In establishing internet based commerce, these demands for human level trust relationships need to be translated into technical trust relationships - the ability of computers to establish the source and authenticity of information received from other computers.

A request for download of a web page is typically made by a browser or a crawler. As shown in figure 3, the illustrated user computer 100 is executing a browser 129. A browser is an application which, when executed by a computer, is able to send requests to other computers for the retrieval of specific web pages. The computer hosting the browser can be referred to as the client computer. A browser is able to receive input information, such as from a user interface, to initiate a browser request. To obtain a download of a desired website, a user would type a URL into an address field of the graphical interface manifested by the browser 129 running on the user computer 100. When the user then presses the carriage return key, or selects a "go" option, the browser then sends a request to the ISP network 22. The browser request contains, at least, a numerical IP address for the computer hosting the browse and a text string identifying the URL of the requested website. The URL is resolved by the ISP network 22 by referring the text string to the DNS server 32, which returns a numerical IP address. The browser then uses the newly obtained IP address to generate a page request, addressed to that IP address. Routers, integral to the internet, store portions of a distributed database enabling IP addresses to be resolved to physical locations of servers and, through employment of one or more such routers, the page request will reach the server on which the requested page, represented by the IP address and ultimately by the URL, is stored.

The web page server 40 then sends HTML information to the user computer 100 on a return path established by the browser request. The browser then creates a display to the user on the basis of the received HTML information.

For online commerce, a web page typically includes graphics and text describing goods offered for sale, and associated on-screen selectable buttons or links which, if selected by a user, will create the effect of adding a selected item to a shopping cart. In essence, the website developer generally tries to conform use of a website to a natural shopping experience. Each time a user input interaction with the website takes place, such as selection of a hypertext link on screen, a URL associated with that hypertext link is sent to the ISP network 22 for DNS resolution. This can result in return of new HTML information, which can lead to modification of the on-screen representation displayed to the user. So, for instance, if a user selects an item for purchase, the screen may indicate the number of items that that user has selected for purchase and the cumulative total cost. Eventually, on completion of the selection of items for purchase, the user will need to conduct a financial transaction to pay for the goods. In past examples, this might need to have been done by establishment of an SSL session with the trader, and the submission of credit card details. In the presently described embodiment, this can be avoided.

Identification of users is central to all internet based commercial transactions. However, this has two elements. Firstly, the trader needs to be able to trust the information that the user has provided. Secondly, the user needs to be able to trust the safekeeping of his personal information by the trader.

To achieve this, the web page operator needs to be able to identify the user, and the user needs to be able to associate the web page operator with an appropriate standard of trust.

User identification may be straightforward, for standard commercial transactions, as widely accepted forms of identification already exist, such as credit card details which can be authenticated electronically with a credit card issuer. Other forms of transaction may require rather more specific user identification, such as national security based transactions (e.g. access to information) or medical transactions (in which the authority of the user to be provided with information or materials needs to be determined, such as if the user is a licensed medical practitioner).

Likewise, many users implicitly trust online traders, based for instance on reputation, or past experience. This has, of course, led to well-known examples of abuse, such as spoofing. In general, users are more likely to use an online service from a known and trusted service provider, than one where the service provider is unknown or cannot be satisfactorily verified.

Thus, service providers face a challenge in obtaining the trust of users of their websites, particularly in circumstances whereby a service provider needs information from the user in order to identify that user, but wherein the user may be reluctant to give personal information to an unknown third party. Indeed, the use, by a service provider, of a user authentication service which the user trusts, may increase the perceived value of the provided service in the mind of the user.

The process of user identification can take place before, during or after the user has completed other parts of the transaction associated with the website. Whether a user is provided with a facility to gather information from the website while not being in a "signed in" state, depends on the circumstances of the desired information transaction. For instance, if the intention of the provider of the website is to convey product and price information to the potential buyer, it will be desirable to maximise the flexibility of sign-in - a user might be discouraged from using a trader's website if that website insisted that a user sign in before product information is made available. On the other hand, if a website were implemented to offer, to a user, personal medical information, managed by the website owner under licence from a healthcare service provider (such as a national medical authority, a contractor of medical services, or an insurance company) then, in that case, the user would desirably be required to sign in before such potentially sensitive information is made available.

Whatever the circumstances of the transaction, the user will be required to sign in before the transaction can be completed. In accordance with this embodiment, this is achieved by use of an identity provider (IdP). An IdP is an entity which provides a user with confidence that user identification information will be handled in a trustworthy manner, and will provide a website owner with confidence that a user identity is genuine. An IdP, in accordance with this example, will design, implement and operate an IdP website hosted on an IdP server. The IdP website will offer two facilities.

Firstly, it will offer a user with a facility to create a user identity, for use in the system provided by the IdP. The present disclosure includes the possibility that user facilities, other than user identification, might be offered by the IdP. For instance, the IdP may be an operator of online services such as search, navigation, email, social networking, online banking, or any other online service for which a user may be content to create a user account.

Secondly, it will offer third parties a user identity authentication service. A third party will sign up to the user identity authentication service in a manner to be described in due course. Then, a website operated by that third party can include a notification to users that the website makes use of the user identity authentication service offered by the IdP. This may have the effect of encouraging users to use that third party website, because the trust relationship which that user has with the IdP is then translated across to the third party website, and because a single sign-in process, as would be used by the user in dealing with the IdP, can also be used in signing into the third party website. This effectively outsources the user sign-in process, which would otherwise need to be implemented by the third party website, to the IdP. This means that the third party website does not need to include implementation of user sign-in facilities and does not need arrange for the storage of user information. This has two consequences.

Firstly, users, who might otherwise be discouraged from using a website because of the need to submit personal information, may now be inclined to use the website. An otherwise doubtful or sceptical user might be encouraged to use a website if it were evidence that the website offered a sign-in facility with which the user were already familiar, and which the user trusted.

Secondly, the removal of the need for the third party website to store personal user information is significant. It removes the need for maintenance of personal user records, which reduces the amount of storage information that a website might otherwise imply. Of course, the third party website might hold certain information about users (such as browsing history, purchase history), as convenience dictates, but the elimination of a need to store personal information still provides a substantive change on preceding approaches. Further, the removal of personal information from the stored information is potentially important from the perspective of data protection - many legal requirements exist concerning the safe retention of personal information, particularly in electronic form, and embodiments described herein may reduce the exposure of third party websites to these legal requirements, thus reducing constraints on how website specific information need be stored.

It will be noted that the above example scenarios are predicated on a user being a human. However, the reader will appreciate that this need not be the case. The internet is increasingly being used for communication not requiring, or not initiated by human intervention. Many examples exist of the use of internet based communications by devices without direct human control.

To name but a few, on-body medical monitors, electricity consumption meters (so- called smart meters), environmental monitors, domestic appliances, industrial equipment, and vehicles could avail themselves of internet based communication to send and receive data and to access services, as required. They could even initiate commercial transactions without human intervention.

For example, a photocopier could be set to order consumables (paper, toner) if it detected that its existing supply were close to exhaustion. For any or all of these, a level of transaction security, such as authorisation and identity assertion, may be required.

The manner in which this is achieved, in the presently described embodiments, will now be set out.

Embodiments disclosed herein look to solve three FIM problems: how a new IdP can determine with which existing IdPs it can establish trust relationships;

how two IdPs in a network, lacking a direct trust relationship, can establish a brokered trust path between them using existing trust relationships; and how a discovered trust path can be used to recognise (e.g. trust and translate) tokens between the two end IdPs.

A Distributed Hash Table (DHT) enables IdP lookup without a centralised directory. Instead of a centralised directory, unique keys identifying each IdP are stored against IdP addresses in a DHT distributed across a network. Each IdP is responsible for storing and sharing a subset of all key/value pairs (i.e. just those of its "neighbours" in the network).

The DHT implements a single function that takes a key as input and returns a trust path of the IdP responsible for this key. Underlying this is a principle that, if a resource's IdP receives a token from a user computer that it does not recognise, it needs to establish trust in that token from the user's IdP. The resource's IdP requests a trust path to the user's IdP from an IdP that it knows in the network. Every IdP must be able to either return a trust path to the user's IdP directly to the resource's IdP, or request that an IdP closer to the user's IdP returns the trust path instead. The trust path lookup request thus traverses through the network, progressively converging on the IdP responsible for the user with each hop, until finally the user's IdP is reached. Finally, the trust path to the user's IdP is returned to the requesting resource.

To achieve this, a lookup function is required. A suitable approach is to use a lookup presently associated with peer-to-peer (P2P) information sharing. Various P2P models may be suitable for use in an embodiment as described herein but, for the sake of example, a method known as Chord will be employed here. Chord is described in "Chord: A scalable peer-to-peer lookup service for internet applications" (Stoica, I., Morris, R., Karger, D., Kaashoek, M. F., and Balakrishnan, H. 2001. SIGCOMM Comput. Commun. Rev. 31 , 4 (Oct. 2001), 149-160).

Other approaches may be used, as alternatives to Chord. Different algorithms vary in the keys they use to uniquely identify resources, in how they evaluate the distance between key values, how they address the concept of closeness, and also in load- balancing of the mapping of keys to nodes and the corrective response to events including node failures and joining of nodes to the network. One such example is the CAN infrastructure, implemented by reference to a multi-dimensional Cartesian coordinate space, which can be visualised as a multi-torus. Other examples exist, including Pastry and Tapestry, and the reader will envisage that other P2P architectures may well be developed in due course.

In Chord, each IdP and key are given an m-bit "random" identifier by hashing each IdP's IP address (or other unique identifier), and each key value, respectively. SHA-1 (FIPS PIB 180-4: "Secure Hash Standard (SHS)"; US Department of Commerce, 2012) is suggested as an appropriate hash function for this purpose. As such, the identifiers of IdPs and keys lie upon a circular number line modulo 2^m . Successor nodes, the first node with an equal or higher identifier than a key, are attributed responsibility for this small subset of all keys. Figure 5 shows an example implementation of SHA-1 , as applied to a network comprising a user computer, a vendor computer, and a plurality of IdP computers. 32 nodes are illustrated (i.e. m=5 in this example). Each node is outlined either by solid or broken line. A node outlined with broken line indicates that no computer has been assigned thereto - i.e. no application of the hash function has led to that hash result. A node outlined with solid line corresponds to an assignment of a computer thereto - i.e. an application of the hash function has led to that result being returned. Note that the numerals 0..31 are indicators, and not the hash keys themselves - using the SHA-1 hash function will result in 160 bit (20 byte) hash keys. As illustrated in figure 5, the user computer is in a trust relationship with a computer hosting an identity provider service (IdP); this computer will be referred to as the user IdP computer from here. The manner in which that trust relationship, between the user and the user IdP computer, is established, will be described in due course. The user IdP computer hashes to node 8. Likewise, the vendor computer, offering a service with which the user of the user computer wishes to transact, is in a trust relationship with another computer hosting an IdP service. This latter computer will be referred to as the vendor IdP computer from here. The vendor IdP computer hashes to node 0. In order to complete a data transaction, the vendor computer requires authentication of the user computer. To do this, the user computer volunteers the use of its associated IdP. In this scenario, the vendor computer has no trust relationship with the user IdP computer, and neither does the vendor IdP computer..

The user IdP computer at node 8 can be identified to the vendor computer in a number of ways. One example provides that the user enters a URL for the IdP in a website offered by the vendor computer. The vendor computer is then able to apply the hash function to discover that the user's preferred IdP service is hosted at a computer hashing to node 8.

While a specific method, by which the used computer can engage with the IdP and thence for the IdP to issue an authentication result to the vendor computer, will be described in detail in due course, a simple, generalised description will now be set out.

In general terms, specific embodiments involve issuance of a message, by the user computer, to the vendor computer. The message includes a portion recognisable only by the IdP nominated by the user computer. The message will then be passed on, by the vendor computer, to the user IdP computer. A trust path to the user IdP computer will be determined by using a network discovery process.

When the message has reached the user IdP computer, that portion of the message only recognisable by the user IdP computer will be processed. When correctly identified, by the intended recipient IdP computer, the message portion will identify the user computer to the user IdP computer. The user IdP computer will then confirm that the user computer is correctly in a trust relationship with the user IdP computer. If the user computer can be properly authenticated by the user IdP computer, an authentication message is then sent back by the user IdP computer to the vendor computer.

The message from the IdP will be accepted by the vendor computer, as long as there is a chain of trust relationships between the user IdP computer and the vendor computer. There is no need for the user IdP computer and the vendor computer to be in a direct trust relationship, though that scenario is not in itself excluded. The vendor computer will accept the authentication by the user IdP computer if computers routing the authentication messages between the vendor computer and the user IdP computer are in acceptable mutual trust relationships.

In one specific embodiment (but by no means considered an essential feature), trust relationships between routing computers may be assessed against imposed security policies. That is, two computers may be in a trust relationship but incapable of complying with a security policy imposed by either the vendor computer or the user IdP computer. For example, an IdP might impose a requirement that all computer data transactions take place within a particular jurisdiction. If intermediate computers were located outside that jurisdiction, trust relationships with those intermediate computers would, in this specific example, be discounted. This method is predicated on an authentication request message being capable of being sent by a vendor computer and arriving at a user IdP computer. To achieve this, it is not essential for a vendor computer to have complete information describing the network of computers at which IdP facilities may be hosted. That is, a vendor computer in association with the vendor IdP computer at node 0 would not necessarily need to have information enabling it to send the authentication request message directly to the user IdP computer hashing to node 8. In this example, the vendor IdP computer stores information locating a computer hashing to node 2. The computer hashing to node 2 stores information locating computers hashing to nodes 4 and 6. The computer hashing to node 6 stores information locating (at least) node 8. It follows that a suitable route for forwarding an authentication message through the vendor IdP computer hashing to node 0, with the intention that the user IdP computer at node 8 should authenticate, would be from node 2 via node 6. A specific example as to how this can be achieved will be described in detail in due course. A specific embodiment can be considered as a plurality of distinct phases of operation and configuration of cooperating computers. While these phases are distinct, there will be discussion, in due course, of aspects thereof which can be combined or conflated.

A computer registration (or joining) phase consists of engaging a computer with other computers to form a network in accordance with the present embodiment. The purpose of the computer registration phase is to establish a trust-based network, to exchange information between computers to ensure that each computer can route messages through the network efficiently and securely, and to ensure that computers exchange information pertaining to their respective security policies. This registration phase provides network discovery and is carried out by each participating computer in the network, as part of an initialisation process and as a periodically repeated maintenance process. It will be evident to the reader that it is desirable for each participating computer, including the vendor computer, to be able to recognise other computers in the network and then be able to forward messages, as required, to those other computers. Each computer within the authentication network stores a local portion of a Distributed Hash Table (DHT). That DHT will identify all participating computers/networks within the authentication network.

At each computer, the local portion of the DHT will include at least a selection of the most local next populated node in the network, including the hash key associated with that node and the location (for instance, IP address) of that node. In one embodiment, the local portion of the DHT will include two or more entries.

The number of entries to be stored in each locally stored portion of the DHT is chosen as a balance between the convenience of a node having information enabling efficient routing of messages and the increased burden placed on the network implicated by increased exchange of data between connected nodes and then stored at each node. The central issue is that each stored connection reflects establishment of a trust relationship following the principles of Federated ID Management. A link can only exist if the two IdP computers making the connection have agreed to recognise, and vouch for, each other's ID assertions - this requires them to assess each other's procedures (as defined, and also as implemented) for ID management, to agree and maintain policies, to swap keys and so on. The reader will appreciate that maintaining a complete copy of the DHT, including this exchange of information for each connection, at each node may place an undue network traffic burden on the network, particularly in the case of large networks. Each change in one local portion of the DHT will need to be replicated in all other affected locally stored portion. Thus, if each local portion stores most if not all of the possible entries of the DHT, each change will implicate a plurality of replication messages to other local portions. On the other hand, if each local portion stores only a very small number (for example, one) of the possible entries of the DHT, replication messages can be minimised, but the usefulness of the local portion of the table is diminished. Therefore, the number of entries to be held in each local DHT will depend on the implementation.

A user registration phase consists of an internet-based interaction between a user computer and an IdP computer. The intent of the user registration phase is to provide the IdP computer with sufficient information to enable the user of the user computer to be identified, and authenticated, in future transactions. The nature and extent of the user registration phase will depend on the implementation, and various scenarios will be described in due course. However, in general, the user registration phase will result in the issuance, by the IdP computer, of a user computer identification token, to be stored at the user computer. This user computer identification token may be in the form of a cookie, stored at the user computer. The user computer identification token identifies the user computer to the IdP computer. A table of all cookies issued by the IdP computer is held at the IdP computer, or is accessible thereto. As is commonplace, user computer identification tokens may be time-limited, in that they may expire after a period of time.

This therefore provides a period of time within which a user, using a particular computer, can re-use an authentication service offered by a particular IdP, in the knowledge that the user computer will be recognised and that certain information (such as a user identifying name field and, optionally, a password) will be pre-populated for user convenience. Thus, the table held by or accessible by the IdP would in this case also store either a cookie creation time or a cookie expiry time.

Depending on the implementation, and the level of rigour imposed by the relevant security policy, the user registration phase may include issuance of a user identification token. This token may take physical form, such as in the form of a PIN activated key fob, a USB compatible stick, a memory card, a magnetic swipe card (for cooperation with a suitable reader), a smart card, an RFID card, or any other physical means by which a user can be identified. The token might alternatively (or additionally, depending on the level of rigour applied by the relevant security policy) take the form of a software implementation, including a personal identification number (PIN) (perhaps issued by SMS to a user's mobile telephone, or on physical media by post) to be used with a screen-generated keypad presenting symbols (which may be letters, digits or otherwise) which can then be selected by the user in correspondence with the issued PIN. For instance, one implementation of a soft keypad approach presents a ten digit on-screen keypad in the standard 3-3-3-1 formation. Instead of the digits 0..9 being allocated to the keys in the usual way, the keys of the keypad are assigned apparently randomly generated letters or other keyboard characters. The user will then be invited to enter a sequence of characters, the characters corresponding to the key positions which would normally be associated with the respective digits of the user's PIN.

Once a user has been registered, the user registration phase will not need to be repeated for that user, subject to expiry of the user computer identification tokens or user identification tokens. A security policy might be defined such that, for instance, an expiry date is set for user computer identification tokens, perhaps for a period of weeks or months from issue. Similarly, a security policy might define a lifespan for a user identification token. For a key fob based implementation, it may be sufficient to rely on the natural lifespan of the battery powering such a device. On successful registration of the user computer with the IdP computer, the IdP computer issues to the user computer a means of enabling the user computer to encrypt messages to the IdP computer, to an extent such that no intercepting computer can discern the content of such messages. A suitable encryption approach involves the issuing of a public (encryption) key of a public-private key pair. The private (decryption) key of that pair is retained, securely, by the IdP computer. In that way, messages can be encrypted by the user computer before they are sent to the IdP computer, and only the IdP computer can decrypt messages so encrypted.

Likewise, the user computer may send a public key of a public-private key pair to the IdP computer. Then, the private key held by the user computer can be used to generate a digital signature to be associated with any message sent by the user computer. The IdP computer would then use the user computer-issued public key to verify the digital signature. This would provide additional certainty to the IdP computer as to the source of the message.

A transaction phase comprises data interactions between the user computer and the vendor computer. During the transaction phase, as described below, a user authentication phase is initiated, to confirm to the vendor the authenticity of the user computer, and the user using the user computer. The initiation of the user authentication phase can take place at any point in the transaction phase.

The position of the user authentication phase may depend on the nature of the transaction implemented between the vendor computer and the user computer. For instance, if the transaction is a commercial transaction, it may be convenient to offer, to the user, the opportunity to "sign in" to the vendor website, but it may not be essential to do so at the outset. To a user, it may be convenient to browse a website offered by a vendor without committing identification information, until the user is satisfied that the vendor website offers goods or services to which the user wishes to commit. It might be inconvenient and off-putting for a user to be required to sign in to a vendor website before having had an opportunity to browse. On the other hand, a user might wish to sign in to a vendor website early in the browsing and purchasing process, to take advantage of any facilities which rely on browsing or trading history of that user. For instance, if a website offers user recommendations, or an opportunity to view purchase history, a user may wish to sign in to enable such facilities to be viewed.

On the other hand, a vendor computer may be configured to offer availability of confidential information, such as medical records. As an example of this, a vendor computer may be implemented by a provider of medical services, tailored to a particular user. Medical information of that user would need to be released, in confidence, to the vendor computer to enable correct serving of information to the user computer. It would be inappropriate to offer such information without first authenticating the user. In such a case, it would be appropriate to require user sign-in before proceeding to offer such information to the user.

The aforementioned user authentication phase is normally initiated when a user decides to commence a "log in" process to a service offered by the vendor computer. This will involve the user computer sending a request to the vendor computer for log in, and then the vendor computer will, in response, send an authentication request message to the user computer. The user computer will then present an authentication display to the user, for the user to respond to. In response, the vendor computer receives an authentication request packet from the user computer. The authentication request packet will contain information identifying the IdP computer which the user computer nominates for provision of a user authentication service. The vendor computer will be capable of determining, on the basis of that information, how the authentication request packet can be directed to the user IdP computer. The authentication request packet also comprises a payload. The payload is intended for processing by the user IdP computer. As noted above, the payload should be protected from discernment by a third party computer, other than the intended user IdP computer. As suggested above, it would be appropriate for the user computer to encrypt the payload using the public key issued by the user IdP computer to the user computer during the user registration phase described above. Also, appropriately, the payload can contain a digital signature generated by the user computer using the private key, the corresponding public key having been issued to the user IdP computer during the same user registration phase.

The vendor computer will determine how to relay the payload to the user IdP computer, and will send the authentication request packet, bundled with a vendor request payload. This vendor request payload will generally include information enabling the IdP to determine appropriate details of the vendor computer, such as the location (e.g. IP address) of the vendor computer, and any security policy information appropriate to the transaction. The vendor computer may identify itself, so that the user IdP computer can determine whether the user computer's engagement with the vendor computer is contrary to an appropriate security policy. The end result of this is that the IdP computer sends a confirmation message to the vendor computer, that the user computer and, implicitly, the user, are to be trusted, and that the user ID is authentic. The IdP computer can also send a message to the user computer that the vendor computer has passed whatever security considerations have been imposed by the IdP. Referring now to the example illustrated in figure 5, a network is shown having established itself through the execution of a computer registration phase. The network is illustrated schematically, mapped to an identifier circle marked up with 32 possible identifier nodes. The registered computers (or networks, as the case may be) are mapped to particular identifier nodes by a process which will be described in due course. In this embodiment, the registered computers are distributed within the set of available identifier nodes in the identifier ring, using a consistent hashing technique, but the disclosure should not be read as limited thereto.

Joining phase

To join a network in accordance with this embodiment, a computer initiates a joining method as illustrated in figure 6. The process in figure 6 is influenced by the disclosure of the above mentioned Chord paper. However, there are differences from that approach, which will become apparent from the following. The joining process is initiated by an external mechanism, such as a user input to start the process of a computer to join an existing established network. As will be appreciated, this joining process will be a trivial process when no network exists, as the network will then consist only of two computers in communication with each other.

For a computer to join an existing network, it should be appraised of an existing node. This could be done by manual user input. The computer then performs a first step, S1 - 2, to send a look-up message to that existing node, to retrieve information from which the computer can construct information establishing its own place in the network.

The computer in receipt of this look-up message will already have stored information concerning its own place in the network. It will use this stored information to construct information applicable to the node requesting to join the network. Any computer engaged in the network stores a routing table to enable the forwarding of messages around the loop of the network as illustrated conceptually in figure 5. As shown in figure 6, step S2-2, the computer in receipt of this look-up message retrieves its routing table from local storage.

The routing table stores a number of entries. Each entry in the routing table provides a correspondence between computers in the network (identified by their hash keys) and IP addresses. In a practical embodiment, for networks above a trivial size, the routing table of any one computer will have fewer entries than there are computers in the network. This means that each routing table can be considered only a portion of a distributed hash table (DHT), distributed across the network.

Alongside the routing table (or, alternatively, stored in the routing table), information is stored which describes a predecessor node to the computer. In essence, this provides information about an immediate neighbour node, in the ring as illustrated in figure 5, to enable messages to be circulated around the network, one node at a time.

The look up message will trigger the recipient thereof to send, to the requesting computer, a copy of its stored routing table (step S2-4). This acts as a starting point for the assembly, by the requesting computer, of its own routing table (step S1-2). While it would be incorrect for the requesting computer to adopt, wholesale, the imported routing table as its own, one benefit of using the Chord approach is the likelihood that few changes will be made to the table by the joining node and then there will be few consequent changes to the table by the computer that supplied the copy. The reason for this is that, in each table, only a limited number of nodes are identified. The basis for the table stored at each node will now be described.

The foundation for the table, at node n in an identifier ring of size 2^m is the following formula:

((n + 2' ^l)mod2^m) where i is a table entry index. Thus, for the present example, the basis for the table at node 0 is the set of nodes {1 , 2, 4, 8, 16}, that is:

Table 1 - Local DHT portion for node ID 0

This does not account for the fact that not all nodes of the identifier ring will necessarily be occupied. In fact, as indicated above, in each table entry, details for a successor node are stored. The successor node is the first occupied position at or beyond the actual Start Node ID position in the identifier ring.

So, in the present example, the table for node 2 will be as follows:

Table 2 - Local DHT portion for node ID 2

Using this approach, a device at a particular node can navigate to another node using the identifier of that node in the identifier ring. So, for instance, if, as indicated in figure 5, the computer at position 16 needs to send a message to the computer at node 8, it uses its table to find the best node to forward the message to:

Table 3 - Local DHT portion for node ID 16

Start Node ID Interval Successor IP Address 17 [17, 18] 19 ggg.ggg.ggg.ggg

18 [18,20] 19 ggg.ggg.ggg.ggg

20 [20,24] 20 hhh.hhh.hhh.hhh

24 [24,0] 25 JU-JU -JU-JU

0 [0, 16] 0 mmm.mmm.mmm.mmm

Using Table 3, the computer at node 16 will identify that node 8 lies in the interval [0, 16]. Thus, the identified successor node for that interval is node 0. The message is thus passed to node 0. At node 0, using Table 1 , node 8 is then found to be in interval [8, 16] and thus the message can be sent directly to node 8 for which node 0 stores location details (i.e. an IP address).

That is, the algorithm tends to provide each computer with a table with a concentration of near neighbours and then fewer, disparate entries for nodes farther distant from the node in question. This means that, for any particular node, the immediate neighbouring nodes will generally be known. This enables messages to be forwarded efficiently.

When a computer joins the network, it adopts information from existing nodes. For example if a computer were to join the network, and that computer had an IP address which hashes to node 31 (currently unoccupied), it would acquire information from node 0. In fact, the table at node 31 would be seeded by the node identifier sequence [0, 1 ,3,7, 15] derived from the above formula (steps S4-2 and S4-4 in figure 7). As a starting point, the information received from node 0 would be loaded into the local table for node 31 (step S4-6) thus:

Table 4 - initial condition of local DHT portion for node 31

Start Node ID Interval Successor IP Address

0 [0, 1] 2* aaa.aaa.aaa.aaa

1 [1 ,3] 2* aaa.aaa.aaa.aaa

3 [3,7] 4* bbb.bbb.bbb.bbb

7 [7, 15] 8* ccc.ccc.ccc.ccc

15 [15,31] 16* ddd.ddd.ddd.ddd The asterisk (*) indicates the provisional nature of these entries. The next step would be, for each identified successor node, to send a message to that successor node (step S4-8) to test the proposition that that node remains the correct successor node. To do this, each node stores a predecessor pointer. The predecessor pointer points to the preceding occupied node location on the identifier ring. For node 2, the predecessor pointer points to node 0. The predecessor pointer for the identified successor node is returned to the requesting node in step S4-10. In step S4-12, this is then compared with the Start Node ID and the Interval information seeded in the table. If the predecessor pointer points to a node which is at or beyond the Start Node ID, then the Successor node currently identified in the DHT is wrong. In step S4-14, the received predecessor pointer information will be used to update the DHT entry.

Thus, for the entry in Table 4 for start node ID 0, the successor node should be updated to node 0, as this is evidently occupied. For the entry for start node ID 1 , the predecessor node for the provisional successor node (again, node 2) is node 0. This precedes the start node ID, so the provisional successor node value is confirmed. This process is continued for each entry. The result of this is set out in table 5 below:

Table 5 - Local DHT portion for node 31 on completion of joining process

The reader will appreciate that the final portion of the local table for node 31 is able to rely on over half of the entries initially received from node 0. This would particularly arise in relatively sparsely populated indicator rings.

The predecessor pointer for the joining node 31 is adopted from the computer at node 0, and will thus point to node 30 (Step 1-6). The joining node then sends a message to the computer at node 0 to prompt it to update its predecessor pointer to point to the joining node at node 31 (step 2-6). Then, the computer at node 31 needs to notify other computers in the indicator ring as to its addition to the network (step S3-2). This can be done, in a brute force approach, by walking back using the predecessor pointer at each node, replacing each instance of node 0 as a successor node where the successor node ID value exceeds the start node ID value. A more refined approach would take account of the expected locations at which this can arise, taking account of the formula ((n + 2'^~l)mod2^m) stated above.

This is described in more detail in the Chord paper.

The joining process as described enables a joining node to adopt considerable information about its neighbourhood from the successor node from which it acquired its initial copy of the DHT.

In the present embodiment, there is a key additional consideration which can lead to variance from the arrangement provided for in Chord. This is that, while the above formula may be useful guidance, as it is likely to produce an efficient list of routing options for a node, the present embodiment has a security aspect which may preclude adoption of all of the entries in the ideal table. Instead, for each entry adopted from the neighbour, the joining node validates the entry against its security policy. It does this by sending a request, to each node in the draft table, to assess mutual compliance with the security policy of that node. Numerous pieces of information can be exchanged at this stage. The aim is to ensure that a computer, entering into a mutual trust relationship with another computer, has assessed the security policies of that other computer, to ensure that each can agree to accept and vouch for each other's ID assertions. An audit process to enable this could appropriately include the exchange of files, in an agreed format, laying out how each computer handles information, the extent to which its data can be trusted, and any other information appropriate to the particular implementation envisaged. It can also include establishing a policy for future exchange of messages, such as the mode and level of encryption to be used, and the exchange of keys to enable such future encryption.

So, for example, if the present case is considered in figure 5 with the joining of a node at node identifier entry 31 , the node will initially receive a copy of the table stored at node 0. As shown in Table 1 , the table at node 0, in this example, contains entries for nodes 0 (itself), 2, 4, 8 and 16. Thus, in this case, the table at node 0 strictly complies with the formula above. However, the situation may arise whereby the computer at node 0 cannot, for security reasons, entertain direct communication with, say, the computer at node 8. In that case, the entry for Start Node 8 would be advanced to the next acceptable node. For example, the computer at node 11 may be deemed acceptable. In that case, Table 1 would be modified as follows:

Table 6 - modified local portion of DHT for node 0

In an alternative embodiment, the line for Start Node 8 could be omitted. In a further alternative embodiment, the Successor node for Start Node 8 could be advanced to node 16.

This is achieved by testing, on joining, the nominated successor node for each entry in the table. When the successor node is found, the joining node will send a security policy enquiry to the identified successor node. If the identified successor node is accepted, based on the security policy, then the identified successor node is written into the local portion of the DHT. If not, then the successor of the identified successor node is tested. This is repeated until a suitable successor node for the start node is identified. Additionally, a computer may be specified as having a direct link to another computer in the network, regardless of the formal Chord based approach. For instance, it may be that the computer at node 0 is operated by a vendor organisation with a direct commercial link to an operator of an IdP service at, for example, node 6. According to the Chord process, this direct link would not be utilised, unless of course positions 4 and 5 in the identifier ring were vacant. It may be considered commercially advantageous for the computer at node 0 to make use of the facility for a direct link to the computer at node 6. This might particularly be the case if the volume of traffic between the computer at node 0 and the computer at node 6 is sufficiently high as to merit inclusion of this link in the scheme. To achieve this, the portion of the DHT stored locally at node 0 is augmented with the direct link to node 6. This will lead to the table further being modified as follows:

Table 7 - modified portion of DHT at node 0 including discretionary additional line

In one embodiment, the table is augmented by further information, per entry. This further information may include a file, or a pointer to a file, containing security policy information. Security policies can be expressed in a variety of different ways. In any network, a protocol can be established whereby computers' security policies can be exchanged in a reliable manner, so that each computer can readily understand the policy applied by another computer. Various languages exist to express security policies, such as WS-SecurityPolicy adopted as a standard by OASIS (Organization for the Advancement of Structured Information Standards) of Burlington, MA, USA.

Further information to be stored per entry could include a public key, issued by the identified successor node. This public key can then be used to encrypt messages sent to that successor node. Other metadata may be stored also, for example as laid out in the WS-Federation standard.

The result of this joining process is that the joining computer will be allocated a node number in the peer-to-peer (P2P) network. The node number is allocated through a result of hashing the computer's IP address using the SHA-1 algorithm. The reader will appreciate that the IP address is used here as a piece of information which is usually unique to a particular computer. It is considered unlikely that two computers sharing a single IP presence will make separate attempts to join the same P2P network in this way. However, other ways of uniquely identifying a computer in the network may exist. Then, the hash key, which is the product of the SHA-1 algorithm, is subjected to a modulo 2^m (where m is the length of the hash key, in bits) operation. This forms the basis for the node number allocation. If the result of the modulo operation has already been allocated to another computer, then the next vacant node is allocated to the joining computer. The outcome of this is a generally random allocation of computers to nodes in the P2P network.

By reference to a successor computer, the joining computer acquires a local portion of the DHT for the network. This results in changes to other local copies of the DHT, and these changes permeate through the network by the described process.

The structure of the Chord based process endows the network with the characteristic that the portion of the DHT stored at each node stores details for only a selection of the nodes in the network. The distribution of stored nodes in each DHT is non-linear - the gap between stored nodes increases with increased distance from the storing node. For example Node 16 need only store locations for nodes 19, 20, 25 and 2. With each hop, the lookup arrives at a node at least half the remaining distance to the target node and therefore the maximum number of hops requires 0(log(n)) growth as the size of the network n grows.

User registration phase

In a user registration phase, a user engages with the service offered by an IdP. This service is offered on-line, through a website provided by the IdP. The purpose of the website is to gather identity information about the user, so that the user can establish an account with the IdP. The user will be identifiable to the IdP by any suitable means. In this example, the user is identifiable to the IdP by means of a self-selected user identification, which may be an email address, and a password. The IdP may dictate the structure and complexity of the password. For instance, the IdP website can be configured to check whether the password selected by the user is at least as long as a predetermined minimum length (8 characters is normal) and to check whether an appropriate mixture of numerals, lower case and upper case letters are used. As shown in figure 8, an IdP computer 300 is illustrated in schematic form. In terms of hardware, the IdP computer 300 will be substantially the same as the webpage server 200 illustrated in figure 4. The IdP computer 300 comprises a website serving module 302 which is configured to serve a website (for instance, in HTML form) to a requesting browser. The website serving module 302 is supported by website data 304 defining the form, appearance and structure of the website to be served. An identity provider (IdP) management module 310 offers an identity provider management service, on request through the website served by the website serving module, or on request by a vendor computer 200. In this example, the vendor computer 200 is a specific implementation of the previously described web page server 40. The IdP management module 310 is supported by identity provider data 312. A user account data store 320 is maintained by interactions from the website serving module 302 and the IdP management module 310, as will become clear from the following description.

To initialise the user registration phase, the user computer 100 will download the served information defining the website offered by the IdP computer 300 (steps S5-2, S5-4 and S6-2 in figure 9). The website will display fields inviting data entry. The data to be entered will vary from one implementation to another. The reader will appreciate that, in one format, the data to be entered will include verifiable information such as name, address and payment details, from which the IdP computer 300 can establish that the registering user is identifiable and trustworthy. The information is gathered from the user (S5-6) and then submitted (S5-8) to the IdP computer 300. This submission may be made through a secure connection, such as established through the TLS protocol, if this is considered appropriate. Certainly, if payment information, such as credit card numbers, is included in the information to be submitted, it may be considered appropriate to include measures to inhibit interception of the information during its submission.

The IdP computer 300, in receipt of the user submission, verifies and stores the user identity and payment information in the user account data store 320 (step S6-4). Verification can take a variety of forms. For instance, the IdP computer 300 may make a test payment transaction using the payment information provided by the user. This transaction may comprise charging a token amount to the submitted user account details, followed by an immediate refund. The IdP computer may test the address information against an address database to determine if the address is real. The IdP computer may check the user identity information against other public data, such as census information or electoral roll information, to determine if the identity of the user is valid. The IdP computer may check the identity of the user against a pre-existing database (such as a medical record database) to check the existence of the user on that database. The checks to be made will depend on the circumstances of the implementation and the information accessible by the IdP computer.

If the verification is completed satisfactorily (step S6-6) then the IdP computer 300 proceeds to issue an IdP token and an IdP public key (step S6-8). A copy of the IdP token is stored in the IdP data store 312 with a reference to the particular user to which that IdP token refers. In this example, the IdP token comprises a cookie. The IdP token has an expiry time, which is stored alongside the IdP token in the IdP data store 312. The IdP public key has a corresponding private key.

The public key and private key may be unique to the particular user, or may be re-used for different users. Which of these arrangements is implemented will depend on the level of security required for the particular application.

The issued IdP token and IdP public key are transmitted back to the user computer 100. The user computer 100 stores these data items (step S5-10), in a manner such that, in future transactions, they are accessible for further use. For instance, the reader will appreciate that cookies are stored in recognised locations such that a browser is able to retrieve a cookie on request by a website server, to personalise a user experience of that website. This will be discussed in further detail in due course.

In step S5-12, the user computer 100 then sends a user public key to the IdP computer. In one embodiment, the user public key is encrypted using the IdP public key provided by the IdP computer 300. This ensures that only the IdP computer will be able to capture the user public key. The user public key is then stored (step S6-10) by the IdP computer 300 in the user account data store. As the reader will appreciate, if the user public key has been encrypted using the IdP public key, it will be necessary to remove the IdP public key encryption using the IdP private key first. At this point, user registration is complete. The IdP computer 300 serves a web page to the user computer 100 to indicate this (step S6-12). The user computer 100 displays this to the user, to confirm thereto that the registration has been successful.

If the earlier verification step, step S6-6, failed in some way, then the intervening steps are not performed, and the process ends abruptly. An error message, optionally, might be served to the user computer 100, but it is also possible that the process will rely on the inevitable time-out message which will arise from lack of response by the IdP computer 300 to the submission in step S5-8.

The end result of this is that information is stored at the IdP computer 300 relating to the user, with log-in details and security data to enable secure transactions between the user computer 100 and the IdP computer 300. The user computer 100 will store a cookie providing an IdP token which effectively registers the user computer 100 with the IdP computer, and an encryption key to enable secure transactions from the user computer 100 to the IdP computer 300.

Registration may, alternatively or additionally, include providing other means of security to enable a registered user to be later identifiable and capable of authentication to an IdP. For instance, as an outcome of registration, a physical token may be issued by the IdP to the user. This might take the form of a Personal Identification Number (PIN), for instance sent on paper by post. Other examples of security measures might include a hardware token, such as a key-fob with the ability to generate a key number for entry, by a user, when prompted to do so by the IdP computer 300. The type of security measures deployed in a particular case will depend on the level of security required for the circumstances and the particular level of trust required.

User Identity Authentication Service

An IdP offers a service to a vendor such that the vendor can trust the IdP's authentication of users registered to that IdP. This is achieved, in technical terms, by the vendor computer executing software which offers a facility to enable a user to select an authentication service, to which the user has been pre-registered, and the result of which the vendor computer treats as a validation of the identity of the user. In a particular embodiment, the service may also include a payment service. That is, the vendor computer may delegate the implementation of a payment transaction to a third party, which may be the user IdP.

Figure 10 illustrates interrelationships between computers in a scenario whereby, the vendor computer 200 and user computer 100 are registered to distinct IdP services, on different IdP computers (300v, 300u respectively). This approach relies on viable communication between IdP computers. This communication will be described later. The registration interaction of the user computer 100 with the user IdP computer 300u is shown in broken line, as having occurred prior to the transaction. This sets out the arrangement shown in Figure 5, in a different format.

To carry out a transaction, the user initiates a browsing session for a website served by the vendor computer 200. To authenticate the user, the vendor website offers an authentication step to the user. This could be a self-contained registration process, or could be a call to the service offered by the IdP. This may, for instance, be indicated by a selectable on-screen button defined in a webpage of the vendor website. Selection of that button will cause creation of an in-line frame in the displayed web page, the in-line frame being defined by a tool, supplied by the vendor IdP computer 300v to the vendor computer 200. As shown in figure 13, the in-line frame offers a prompt to the user to enter information identifying that user and the user IdP, as predetermined in the registration process. The entered user information is then encrypted by the user computer 100, and sent to the vendor computer 200.

The vendor computer 200 in receipt of an IdP sign-in request of this type must redirect the request to the IdP indicated in the sign-in request. In one arrangement, this could be carried out by direct communication from the vendor computer to the user IdP, but in this embodiment the message is directed first to the vendor IdP computer 300v. This is because direct communication between the vendor computer 200 and the user IdP computer 300u may only be possible if the vendor computer has established a direct trust relationship with the user IdP computer 300u beforehand. This may be possible, in specific circumstances, as a special case where the user IdP computer 300u and the vendor IdP computer 300v are one and the same. However, a more general case is covered by the present embodiment, where no assumption is made as to a pre-existing trust relationship between the vendor computer 200 and the user IdP computer 300u. That is, the vendor computer 200 may or may not have a trust relationship with the user IdP computer 300u.

A trust relationship may already exist between the vendor IdP computer 300v and the user IdP computer 300u, or the process of the present embodiment can initiate an attempt to establish such a trust relationship. Assuming that such a trust relationship is established, then the message is passed on from the vendor IdP computer 300v to the user IdP computer 300u for checking.

In this scenario, the vendor computer 200 is itself registered with the authentication service offered by the vendor IdP computer 300v. It therefore can implicitly trust authentication results sent thereto by the vendor IdP computer 300v. To effect authentication, the vendor computer 200 sends a packet of information, including information encrypted and submitted by the user computer, to the vendor IdP computer 300v. This information is sufficient to identify the user computer 100, the user using the user computer 100, and the vendor computer 200 making the submission. The packet of information identifies the intended destination as the user IdP computer 300u. The routing of that packet will be described in due course. On receipt, the user IdP computer 300u checks the information against information it holds, and sends a message back to the vendor computer 200 (via the vendor IdP computer 300v) accepting or denying the user authentication.

The submission by the vendor computer 200 can, in one embodiment, be encrypted with a public key issued by the IdP to the vendor computer 200 during a vendor computer registration process. Figure 1 1 illustrates the architecture of a website hosted by the vendor computer 200 in this scenario. As previously mentioned, the vendor computer 200 implements a web page server as described above. The web site implemented by the vendor computer 200 is defined by website data 400 which, in use, will be stored in the mass storage unit 222 and retrieved as required to respond to client browser requests. As with many websites, the present website is constructed from a plurality of components. Some of these components will be commercial off-the-shelf (COTS) elements, and so their implementation will be familiar to the reader. Other elements will be specific to the implementation, and the precise structure thereof will depend on the form and appearance desired by the website designer. No detailed description of the aesthetics of the website is required for an understanding of the present disclosure.

The website data 400 has a primary, structural element, determined here as website framework data 410. This provides the structure of the website, including indexes, calls to other elements, and responses to client specific elements such as screen size and capability. For instance, the website framework data 410 may include information to enable adaptation of webpages to a smartphone, or to a tablet, in so-called "mobile" format. The website framework data 410 includes a product display framework 420, which defines the manner of display of product information on screen of the client device. The product display framework 420 refers to a product data file 422, including text and image information pursuant to particular products. A shopping cart framework 430 provides the website with a facility to register product selection information by a user, to capture desired selected products in a shopping cart list, and to enable that information to be retained until a user transaction is to be proceeded with. To do this, the shopping cart framework 430 references a shopping cart data file 432.

A user information framework 440 provides the website with a facility to store information about users of the website, to issue tokens to user computers to enhance the user experience of returning users, and, potentially, to monitor particular users' activity to optimise the website operation for that user. The user information framework 410 stores information relating to users in a user information data store 442.

Likewise, a vendor information framework 450 manages the distribution of vendor information which will circulate to IdPs as required. The vendor information is stored in a vendor information data entity 452. A sign-in framework 460 governs the presentation of a sign-in dialogue to users, and interacts with a sign-in process entity 462. In this embodiment, the sign-in process 462 is defined by the provider of IdP services and may comprise a software product downloaded from the vendor IdP computer 300v when the vendor computer 200 registers therewith.

Figure 12 illustrates a typical webpage which will be displayed to a user, on a user computer, when that user selects a sign-in facility offered on the vendor website (here identified by the fictitious URL "www.examplewebsite.com"). In this page, the user is presented with two options.

On the left side of the screen, a region is defined for users who have signed-in to the vendor website on a previous occasion, or who have a pre-existing IdP registration. Such a user is presented with two options in that region. The user can either enter a user ID and password specific to www.examplewebsite.com, or the user can utilise the pre-existing IdP registration (by selecting the button indicated as "SIGN IN USING IdP".

On the right side of the screen, a region is defined for users to sign up as a direct registrant to www.examplewebsite.com. The present disclosure envisages that this option may still be accommodated, alongside the IdP model, though users may choose to authenticate through a trusted IdP rather than directly with a website of which they may have limited knowledge.

If the SIGN IN USING IdP button is selected, then the vendor computer 200 serves a webpage as shown in figure 13, as referred to above. This webpage consists of two regions. An outer region is defined by the user sign-in framework 460. An inner region is defined by the sign-in process 462, served by and interacting with the vendor IdP computer 300v,. In detail, therefore, the process by which IdP based user authentication takes place will now be described.

The process begins when the vendor computer 200 receives an input from the user computer 100 indicating that sign-in using the IdP method is to be carried out, i.e. by selection of the aforementioned button. This then presents the screen as shown in figure 13, and the IdP sign-in information is sent by the user computer 100 to the vendor computer 200 in the form of a packet comprising:

• The user ID for the user as registered with the IdP

· The user password for the user as registered with the IdP

• The user token, issued by the IdP when the user registered with the IdP

The user token may be used as a signature on the user ID and password - the signature can then be verified by the issuing IdP as a further layer of authentication.

The packet is encrypted, prior to submission by the user computer 100, using the public key issued to the user computer 100 by the user IdP computer 300u during user sign-up to the user IdP service. By this, the packet is inaccessible to the vendor computer 200. The submitted information is then sent to the vendor IdP computer, by the vendor computer 200, including the encrypted packet, for the vendor IdP computer then to use in establishing authentication of the user and the user computer.

Figure 14 illustrates a system based view of the transaction. For reasons of clarity, text labels in figure 14 have been kept to a minimum, and reference numerals are used instead.

In step S8-2, a user computer 100 is prompted (by user action or for any other reason) to initiate sign-up to a service offered by a vendor computer 200. This is done by way of sending a sign-up request message from the user computer 100 to the vendor computer 200. The sign-up request message from the user contains a user token issued by the user IdP computer 300u beforehand. The user token is encrypted using a public key issued by the user IdP computer. Thus, the user token is only retrievable by the user IdP computer, using its corresponding private key. In response, in step S8-4, the vendor computer 200 sends a message to its vendor IdP computer 300v, containing the sign-up request message issued by the user computer 100. Also, in step S8-6, the vendor computer 200 serves a sign-in framework webpage to the user computer 100. The process can then take one of two paths. The first of these paths will be described in full first. In this first path, the vendor IdP computer 300v attempts to decrypt the user token. If it fails to do so, it determines that the user computer 100 is not registered with the service offered thereby. Then, in step S8-8, the vendor IdP computer serves an in- line frame to the user computer 100, for inclusion in the sign-in framework webpage served by the vendor computer.

The in-line frame presents to the user of the user computer 100 a dialog for entry of user IdP information. This creates a packet of information. The packet of information comprises a secured portion, signed by the user IdP public key, and an unsecured portion. The unsecured portion identifies the user IdP computer, by IP address. The secured portion contains the user token issued to the user computer 100 by the user IdP computer 300u, a session token for the user computer 100 (if a session is already under way) issued by the user IdP computer 300u, and identity and authentication information (such as a password).

The packet of information assembled in the in-line frame dialog is sent, in step S8-10, to the vendor IdP computer 300v. The vendor IdP computer 300v hashes the IP address using the pre-agreed hashing function, and looks up in a local look-up table to determine if it has established an IdP trust relationship with the user IdP computer 300u. If it has not, then it will seek to establish this relationship now in step S8-12. This is achieved on the pathway established by reference to the locally stored DHT. This will enable the message to be routed efficiently around the P2P network. It will look to find a trust path to the user IdP computer 300u using the peer-to-peer network of which it is a member. Clearly, if the user IdP computer 300u cannot be found in the peer-to-peer network, this is because the user IdP computer 300u has failed to negotiate membership of the peer-to-peer network. If the user IdP computer can be found, by the previously described stepwise communications allowed using DHTs, then the trust pathway can be said to have been established.

Exchange of information then takes place to determine if a trust relationship can be established. The nature of this trust negotiation may vary from one implementation to another. The process of finding the user IdP computer 300u by the vendor IdP computer 300v results in the definition of a trust path, comprising one or more intervening computers in the peer-to-peer network. Of course, in the trivial case, the user IdP computer 300u and the vendor IdP computer 300v are in a direct trust relationship - the present disclosure is not concerned with resolving this trivial example which does not exhibit the issues to be addressed by the described embodiment.

The present disclosure is concerned with situations where the vendor IdP computer 300v has not established a direct trust relationship with the user IdP computer 300u. The presently described embodiments do not impose a requirement for such a trust relationship to be established. Indeed, the presently described arrangement avoids the need for such trust relationships to be established.

The trust path is used as a substitute for a direct trust relationship between the vendor IdP computer 300v and the user IdP computer 300u. Each computer on the path between the vendor IdP computer 300v and the user IdP computer 300u verifies the response it receives from the next node on the path, and reissues a response to the preceding node indicating that it vouches for the next node on the path. This process is repeated, at each node, until a trust vouching signal reaches the vendor IdP computer 300v from the user IdP computer 300u, via the intervening nodes on the trust path identified in the network.

This trust vouching signal will either be a confirmation message or a denial message from the user IdP computer 300u to the vendor IdP computer 300v (step S8-14). If this message is a denial, then the vendor IdP computer must return a message, via the in-line frame, to the user computer 100, presenting information to the user that the intended federated trust relationship cannot be established. The user might be invited to attempt another arrangement, for instance using another trust authority. This might, for example, be possible if the user has alternative means of payment, but one of these means of payment does not offer sufficient trust attributes to meet the vendor IdP computer's own trust policies.

If the message is a confirmation, then the transaction between the vendor computer and the user computer can proceed, as the indirect trust relationship between the vendor IdP computer 300v and the user IdP computer 300u has been established for the purpose of the transaction. This condition may then persist, beyond the scope of the particular transaction. The trust relationship may be maintained for a period to be defined by both parties to the relationship, or until certain technical conditions change (such as if the communication link between the two devices is severed or diminished in quality), or it may be persistent. The extent to which this facility will be implemented is a matter of policy. Once the vendor IdP computer 300v has received confirmation of a user's identity, this is reusable in future transactions. Precisely how this will be achieved is dependent on the method of authentication employed in the particular case. For instance, if a digital certificate, with a public key, is presented, if the key is reused to authenticate the user, the vendor IdP can simply accept the identity as it has previously verified the authenticity of the key by mapping it to user ID.

Of course, steps S8-12 and S8-14 are redundant if the vendor IdP computer 300v and the user IdP computer 300u already have established this trust relationship.

In either event, the previously referenced packet, submitted from the user computer 100, is then passed to the user IdP computer 300u, in step S8-16. The packet can then be authenticated. This happens on several levels. Firstly, the packet is encrypted using a public key to which only the user IdP computer has the corresponding private key. Without correspondence between the public key and the private key, the secured portion of the packet would be garbled.

Secondly, the secured portion contains a user token. The user IdP computer looks up to determine if this token is valid. Validity of a token means that the token has not expired, that it is not corrupted in some way, and that it applies to the user computer in question. The user computer is identifiable by its IP address and by the identity of the user, such as from the entered user ID information. Thirdly, the user submits a password in the in-line screen, and this can be checked against locally stored user information for the user account in question.

It may be possible for the user IdP computer 300u then to serve a further in-line screen to the user computer 100 to seek further information. This could, for instance, consist of security token information, such as a periodically varying number on a key-fob or an on-screen algorithm. By this, the user IdP computer 300u can authenticate the user to the extent required by the circumstances.

In the event that the user (and user computer) is authenticated by the user IdP computer, this fact is communicated to the vendor IdP computer (step S8-18). By virtue of the trust path between the vendor IdP computer and the user IdP computer, this information can be trusted, and is not subject to further verification by the vendor IdP computer. The vendor IdP computer can record information relating to this. For instance, the vendor IdP computer can issue a token (step S8-20), to the user computer, indicating that it is satisfied with the identity of the user computer 100, and this latter token can then be used for further sessions between the user computer and the vendor IdP computer. This token might be subject to an expiry time, not least because the identification is due to a third party trust provider, rather than being that of the vendor IdP computer itself.

The authentication result is then passed from the vendor IdP computer 300v to the vendor computer 200 in step S8-22. Again, the vendor computer 200 can issue a token (step S8-24) to the user computer 100, to enable sign-in to be bypassed on future occasions. This is known as a "remember me" capability in web based commerce applications. In any event, the vendor computer 200 would normally be expected to respond to the receipt of an authentication result by serving a new web- page to the user computer 100 (step S8-26). This would normally happen whether or not the authentication was successful. There may further be a time-out facility so that, if an authentication result does not arrive at the vendor computer in a reasonable period of time, the vendor computer serves a time-out screen to the user computer and ceases the process, inviting another attempt.

As noted above, the path from step S8-6 can take one of two paths. The second path will now be described. This case applies to the scenario where the user enters information in the sign-in dialog served by the vendor IdP computer, indicating that the user is using the IdP service offered by the vendor IdP computer. That is, the user is pre-registered to the same IdP service as the vendor.

This path also arises where the user computer already stores a token issued by the vendor IdP computer. This token might be present because it has been issued in step S8-20 mentioned above, or because, the user of the user computer 100 is a customer of the IdP service offered by the vendor IdP computer and the user computer has already been through the sign-in process managed thereby. In that case, where a token already exists, this token will be passed to the vendor computer when the user computer requests sign-in to the vendor computer's service, and this token will then be passed on to the vendor IdP computer as part of the normal submission (as per step S8-4). The vendor IdP computer will immediately recognise that the user computer is already registered. The vendor IdP computer may then require further authentication information, for which it may serve a sign-in in-line frame to the user, suited to these circumstances. This may be simply a user name and password based authentication, or a token based authentication as described above.

Routing messages

By using P2P networking in this way, an IdP computer in the network can establish that the user IdP computer can be trusted and that user authentication can be delegated into a federated approach. The authentication results offered by one IdP can be trusted by other IdPs. As a corollary, the method provides for the return of the location of the user's IdP, the user's IdP's public key, and any other information pertinent to the transaction in hand. Further, in certain embodiments, the discovered trust path between two IdPs can be used for the exchange of tokens between them. In one approach, on receipt of a message from another IdP, a token is issued by the receiving IdP and is then signed by that IdP for verification by the next node in the return trust path. The next node on the return trust path then verifies and re-signs the token for the next node back in the trust path, and so on until the token reaches the intended recipient of the token. The trust path is used to validate the token from one IdP to the other. The two IdPs do not need to enter into a direct trust relationship. Optionally, it may be useful to carry information in the token, for receipt by the intended recipient IdP. To do this, the token may be translated by each recipient nodes on the return trust path, so that the information borne therein is understandable by each subsequent node along the return trust path. This does not require any agreement on token syntax or semantics beyond that which would be required for the established trust relationships anyway.

A further modification to the latter approach maintains privacy. Firstly, the user's token could either be encrypted, or an identifier sent instead, on each step on the path discovery out to the user's IdP. For the return route, where the token must be translated, if attribute tokens that do not contain identities are returned, then each broker IdP only learns the attribute from the preceding hop. As the routing makes use of random identifiers, each such broker IdP learns nothing about the identity of the user (except, perhaps, some of their attributes), and it learns nothing about the identity of the user's IdP or the resource's IdP, except for the next and previous hops on the brokered trust path.

Note that with the described P2P approach (and, indeed, with other P2P approaches which will be known to the reader), to which node in the network a new IdP connects to is well-defined. However, in an embodiment, the connection rules could be modified to provide a choice of potential connections. For example, this could allow those with existing trust relationships (perhaps from other non-FIM related areas) to be leveraged, or for the IdP to avoid having to establish direct trust relationships with those IdPs with which it would prefer to avoid engagement. Through the properties of the described P2P methodology, the routing, token translation etc. described above for will be operable even with such modification, but with perhaps an acceptable deterioration in efficiency. However, the extra flexibility that this grants could be of benefit in many scenarios.

The above examples do not discount the possibility that the path from one trust domain (as embodied on a particular computer, in the described embodiments) to another trust domain, need be the same as the path in the reverse direction. A recipient computer, wishing to acquire a trust path back to the sending computer, can pursue the same process of polling its trust relationships to obtain an appropriate trust path in the network, without needing to know how the message it received from the sending computer was transmitted through the network. This limits the amount of information that it is essential for a message to convey to the recipient, as the recipient computer can make its own enquiries to send its own messages. In general terms, the embodiments described above lend themselves particularly to cases where two security domains (e.g. the vendor IdP and user IdP computers of the above examples) have no pre-existing trust relationship. This can occur where the two domains are in a network containing four or more trust domains, with an incomplete set of trust relationships between them. So, for instance, in such a scenario, at least one of the networked trust domains would have trust relationships with fewer than all of the other networked trust domains. In this case, if the trust domain needed to establish a trust pathway with another trust domain with which it lacked a direct trust relationship, it would need to develop a trust pathway through one or more other trust domains, by which pathway both trust domains could gain sufficient assurance, in accordance with their respective policies, as to the identity assertions required for a transaction to be completed.

The reader will appreciate that this does not impose a limitation on the deployment of an implementation in accordance with a described embodiment. An implementation could be deployed even in networks where all networked domains have trust relationships with all other existing networked domains. In such a case, though the need for establishing indirect trust pathways would not necessarily be self-evident, it would still provide greater flexibility and functionality.

Another consequence of deploying an embodiment as described above, is that it reduces the expectation that trust domains will need to establish direct trust relationships. Presently, there is a perceived need to establish trust relationships, in a computing sense, whereas no trust may exist at a human or commercial level. So, for instance, institutions operating trust domains may feel forced to enter into technical trust relationships to facilitate identity or attribute assertion, regardless of the information security risk this may implicate, because of a need to effect commercial transactions. Thus, inappropriate technical trust relationships may be established which, commercial imperatives aside, may be inadvisable. Embodiments described herein provide an alternative to this arrangement. By making use of intermediaries, a trust domain can establish a better assertion of identity or attributes, through mutual trust of the intermediaries, than would actually be possible by two trust domains whose trust relationship may be imperfect and founded on false assumptions. While many of the examples provided above relate to identity assertion, the present disclosure is not so limited. Any attribute could be asserted using the arrangements provided. There is a significant commercial and regulatory pressure to control the exchange of personal information. User privacy is an important issue. Users are often discouraged from using online services that seek information for which they have no credible and justifiable need.

So, for instance, for a multi-media business distributing material which is age classified, it is essential, for compliance purposes, that that business can have comfort that the user is old enough to view the material. There may be legal consequences for any business that fails to make adequate checks of this nature. However, it is not necessary for the business to be able to identify the user. A service may thus be established, to which the user may sign up, to assert the user's age, to the multi-media business, to satisfy this legal requirement. This age assertion is an example of an attribute that may be delivered to the business, other than identity information.

In fact, the age of the user may be superfluous even in this example. It may be sufficient, for compliance purposes, for the age assertion service merely to provide to the multi-media business an age assertion attribute indicating that the user is old enough to view the material. So, for instance, if a movie is graded for viewing by persons of 15 years of age or older, it would be sufficient for the service to provide a confirmation to the multi-media business that this is the case. The multi-media business does not need to know the actual age of the user. Similarly, in the case of an information provider service, such as in a medical information database, such as implementing a pharmacopoeia, it may be a requirement that, to access certain parts of the database, the user needs to be a qualified medical professional. In such a case, a service could be established which asserted that a subscriber is so qualified. One or more such services could be provided in each regulated territory.

So, for instance, each college of medicine in the United Kingdom could host, or subcontract, such a service. It would not be necessary, and may be impractical, for a medical database provider to have a trust relationship with each medical practitioner database. An embodiment such as described herein may enable definition of a trust policy which enables the pharmacopoeia database provider to establish that the medical database provider is genuine and provides assertion that its signatories are sufficiently qualified to view the information provided in the pharmacopoeia. Then, a user wishing to view information in the pharmacopoeia can assert his qualification as a medical practitioner by using the service to which he has signed up to.

The medical practitioner database service would need to send to the pharmacopoeia database provider is a qualification assertion attribute. Again, this attribute would not need to be accompanied by information sufficient to identify the medical practitioner; it would merely need to assert that the person wishing to view the restricted part of the pharmacopoeia was sufficiently qualified to view the information. So, this example also demonstrates the use of an embodiment without exchange of identity information.

While certain embodiments have been described, these embodiments have been presented by way of example only, and are not intended to limit the scope of the inventions. Indeed, the novel methods and systems described herein may be embodied in a variety of other forms; furthermore, various omissions, substitutions and changes in the form of the methods and systems described herein may be made without departing from the spirit of the inventions. The accompanying claims and their equivalents are intended to cover such forms or modifications as would fall within the scope and spirit of the inventions.

Claims

CLAIMS:

1. A computer network comprising a plurality of computers, wherein, in the network, a plurality of trust domains are implemented, each of said trust domains having associated therewith a trust relationship information record pertaining to a trust relationship that said trust domain has with at least one other of said trust domains implemented in the network, the computers being configured, collectively or individually, such that a requesting trust domain of said trust domains, having a trust relationship established with an intermediary trust domain of said trust domains in its associated trust relationship information record, and seeking a trust pathway to an intended destination trust domain of said trust domains, is operable to send a trust pathway message via the intermediary trust domain, the trust pathway message comprising information which, when processed by the intermediary trust domain, is operable to cause the intermediary trust domain to send a trust pathway message to the intended destination trust domain if the intended destination trust domain is identified in its associated trust relationship information record, and towards the intended destination trust domain via a further intermediary trust domain selected from its associated trust relationship information record if the intended destination trust domain is not identified in its associated trust relationship information record.

2. A computer network in accordance with claim 1 wherein the requesting trust domain is operable to select the intermediary domain from the trust relationship information record on the basis of a proximity measure, the proximity measure being a measure indicative of proximity to the intended destination trust domain.

3. A computer network in accordance with claim 2 wherein the trust domains of the network are mapped to partitions of a coordinate space, the proximity measure of a candidate intermediary trust domain being a count of the number of partitions of the coordinate space between the candidate intermediary trust domain and the intended destination trust domain.

4. A computer network in accordance with claim 3 wherein the coordinate space is a ring.

5. A computer network in accordance with claim 3 wherein the coordinate space is a multi-dimensional coordinate space.

6. A computer network in accordance with claim 4 or claim 5 wherein the count is from the candidate intermediary trust domain towards the intended destination trust domain, in a selected sense, for all candidates.

7. A computer network in accordance with any one of claims 2 to 5 wherein the requesting trust domain is operable to select the intermediary domain having the lowest proximity measure of the trust domains identified in the trust relationship information record.

8. A computer network in accordance with any preceding claim wherein the trust pathway message sent by the intermediary trust domain comprises a trust assertion message asserting trust on the basis of the trust relationship established between the intermediary trust domain and the intended destination trust domain.

9. A computer network in accordance with any preceding claim wherein the intermediary trust domain is operable to apply an authentication to the received trust pathway message, the authentication being identifiable, by the trust domain identified in the trust relationship information record associated with the intermediary trust domain, as being associated with the intermediary trust domain.

10. A computer network in accordance with claim 9 wherein the authentication comprises a signature, the signature being identifiable as being associated with the intermediary trust domain, by the trust domain identified in the trust relationship information record associated with the intermediary trust domain.

1 1. A computer network in accordance with claim 10 wherein the authentication comprises the application of a public key, a private key associated therewith being held by the trust domain identified in the trust relationship information record associated with the intermediary trust domain.

12. A computer network in accordance with any preceding claim wherein the computers are configured, collectively or individually, such that a trust pathway message bears information attributable to the trust domain sending the message.

13. A computer network in accordance with claim 12 wherein the trust pathway message bears information enabling the intended destination trust domain to assert, in a return message back to the requesting trust domain, authenticity of the return message.

14. A computer network in accordance with claim 13 wherein the information enabling assertion of authenticity comprises information enabling application of an electronic signature.

15. A computer network in accordance with claim 14 wherein the information comprise a public key, the requesting trust domain holding the corresponding private key.

16. A computer network in accordance with any one of the preceding claims wherein the trust pathway message bears trust specification information.

17. A computer network in accordance with claim 16 wherein the trust specification information comprises information defining a trust specification to be assessed for compliance by the intended destination trust domain.

18. A computer network in accordance with claim 16 or claim 17 wherein the trust specification information comprises information defining a level of data security to be complied with by the intended destination trust domain.

19. A computer network in accordance with any one of claims 16 to 18 wherein the trust specification information comprises information defining a level of data security complied with by the requesting trust domain.

20. A computer network in accordance with any one of claims 16 to 19 wherein the trust specification information comprises information which, when processed by the intended destination trust domain, causes the initiation of an attribute mapping process, the attribute mapping process being operable to create a mapping between security policy attributes of a security policy of the requesting trust domain, and security policy attributes of a security policy of the intended destination trust domain.

21. A computer network in accordance with any one of the preceding claims wherein a trust pathway message contains source identifier information indicative of the requesting trust domain, and recipient identifier information indicative of the intended destination trust domain.

22. A computer network in accordance with claim 21 wherein the source identifier information is an internet protocol address of the requesting trust domain.

23. A computer network in accordance with claim 21 wherein the source identifier information is a function of an internet protocol address of the requesting trust domain.

24. A computer network in accordance with claim 23 wherein the source identifier information is a hash result of a hash function applied to an internet protocol address of the requesting trust domain.

25. A computer network in accordance with any one of claims 21 to 24 wherein the recipient identifier information is an internet protocol address of the intended destination trust domain.

26. A computer network in accordance with any one of claims 21 to 24 wherein the recipient identifier information is a function of an internet protocol address of the intended destination trust domain.

27. A computer network in accordance with claim 26 wherein the recipient identifier information is a hash result of a hash function applied to an internet protocol address of the intended destination trust domain.

28. A computer network in accordance with claim 24 or claim 27 wherein each trust domain is capable of processing a hash function, of predetermined form, for the production of a hash result from an internet protocol address.

29. A computer network in accordance with claim 28 wherein, for each trust domain, the associated trust relationship information record identifies, for each possible hash result, a corresponding trust domain to be selected as a second trust domain.

30. A computer network in accordance with any one of the preceding claims wherein each trust relationship information record identifies up to a maximum number of trust domains.

31. A computer network in accordance with claim 30 wherein the maximum number of trust domains identifiable in each trust relationship information record is a function of the number of trust domains implemented in the computer network.

32. A computer network in accordance with any one of the preceding claims wherein each trust domain in the network is identified in at least one trust relationship information record associated with another of the trust domains.

33. A computer network in accordance with claim 32 wherein each said trust domain has associated therewith a neighbour identifier, the neighbour identifier identifying a trust domain whose associated trust relationship information record identifies said trust domain therein.

34. A computer network in accordance with claim 33 and operable to accept introduction of another trust domain into said network, the introduced trust domain having a trust relationship with an existing trust domain of the network, wherein introduction is facilitated by associating with said introduced trust domain a trust relationship information record based on the existing trust domain, by updating the neighbour identifier of the existing trust domain to identify the introduced trust domain, by associating with the introduced trust domain a neighbour identifier identifying the trust domain previously identified by the neighbour identifier of the existing trust domain, and by conveying, to other trust domains in the network, a trust relationship record update message which, when received by another trust domain, causes that trust domain to assess the introduction of the introduced trust domain and to make any appropriate consequent changes to its associated trust relationship information record.

35. A computer network in accordance with claim 34 wherein the introduction of another trust domain into the network is further facilitated by the validation, by the introduced trust domain, of trust relationships identified in the trust relationship information record associated with the introduced trust domain.

36. A computer network in accordance with any one of claims 33 to 35 and operable to manage the departure of a trust domain from the network, operable to provide, to a trust domain identified in the trust relationship record associated with the departing trust domain, a neighbour identifier update message containing information identifying the neighbour trust domain identified by the neighbour identifier of the departing trust domain, and operable to provide, to the neighbour trust domain, a trust relationship record update message comprising information enabling the neighbour trust domain to update its associated trust relationship record with information identifying the trust domain identified in the trust relationship record associated with the departing trust domain.

37. A computer network in accordance with claim 36 wherein the departure of a trust domain from the network is further facilitated by the validation, by the neighbour trust domain, of the trust relationship with the trust domain identified in the trust relationship record associated with the departing trust domain.

38. A computer network implementing a plurality of trust domains, the trust domains together forming a federation, wherein each trust domain has associated therewith a record identifying other trust domains with which it has a trust relationship, and wherein, for at least one of the trust domains, the record identifies fewer than all of the trust domains implemented in the network, a trust domain seeking to access a facility offered by another trust domain with which it lacks a trust relationship, being configured to identify an intermediary trust domain with which it has a trust relationship and to instruct the intermediary trust domain to initiate contact with the facility offering trust domain, each trust domain being configured such that, on receipt of an instruction to initiate contact with a facility offering trust domain, the trust domain is operable: in the case that the trust domain has a trust relationship with the facility offering trust domain, to establish contact with the facility offering trust domain; and in the case that the trust domain has no trust relationship with the facility offering trust domain, to identify a further trust domain, with which it has a trust relationship, and instructing that further trust domain to initiate contact with the facility offering trust domain.

39. A computer network in accordance with claim 38 wherein each trust domain is operable, in identifying a further trust domain, to select said further trust domain from a record of trust domains with which said trust domain has a trust relationship.

40. A computer network in accordance with claim 39 wherein each trust domain is operable, in identifying a further trust domain, to select said further trust domain on the basis of a measure of proximity to the facility offering trust domain.

41. A computer network in accordance with claim 40 wherein said proximity is determined in terms of trust relationship topology in the network.

42. In a computer network comprising a plurality of computers, wherein, in the network, a plurality of trust domains are implemented, a method of establishing communication from a requesting trust domain to an intended destination trust domain, comprising, associating with each of said trust domains a trust relationship information record pertaining to a trust relationship that said trust domain has with at least one other of said trust domains implemented in the network, sending a trust pathway message from a requesting trust domain of said trust domains, to an intermediary trust domain having a trust relationship established with the requesting trust domain recorded in its associated trust relationship information record, the trust pathway message causing said intermediary trust domain to send a trust pathway message to a further trust domain, having a trust relationship established with the intermediary trust domain recorded in its associated trust relationship information record, the trust pathway message comprising information which causes the intermediary trust domain either, if the intermediary trust domain identifies the intended destination trust domain in its trust relationship information record, to send a trust pathway message to the intended destination trust domain, or, if the intermediary trust domain does not identify the intended destination trust domain in its trust relationship information record, to send a trust pathway message towards the intended destination trust domain via a further intermediary trust domain selected from its associated trust relationship information record.

A computer apparatus configured by processor executable instructions to implement a trust domain within a computer network in which a plurality of trust domains are implemented, the apparatus comprising associated trust relationship information record storage means operable to associate, with the trust domain, a record of trust relationships of the trust domain with other trust domains, the apparatus being operable to execute processor code to effect the sending of a trust pathway message towards an intended destination trust domain, by selecting an intermediary trust domain from the record of trust relationships, and by sending the trust pathway message to the intermediary trust domain, wherein the trust pathway message comprises information which, when processed by the intermediary trust domain, will be operable to cause the intermediary trust domain either, if the intermediary trust domain identifies the intended destination trust domain in its trust relationship information record, to send a trust pathway message to the intended destination trust domain, or, if the intermediary trust domain does not identify the intended destination trust domain in its trust relationship information record, to send a trust pathway message towards the intended destination trust domain via a further intermediary trust domain selected from a trust relationship information record associated therewith.

A computer apparatus configured by processor executable instructions to implement a trust domain within a computer network in which a plurality of trust domains are implemented, the apparatus comprising associated trust relationship information record storage means operable to associate, with the trust domain, a record of trust relationships of the trust domain with other trust domains, a message processor capable of receiving a trust pathway message from an originator trust domain, the trust pathway message comprising an indication of an intended destination trust domain, and operable in response either, if the trust domain identifies the intended destination trust domain in its trust relationship information record, to send a trust pathway message to the intended destination trust domain, or, if the trust domain does not identify the intended destination trust domain in its trust relationship information record, to send a trust pathway message towards the intended destination trust domain via a further intermediary trust domain selected from the trust relationship information record.

45. A computer program product comprising processor executable instructions to cause a computer apparatus to become configured as apparatus in accordance with claim 43 or claim 44.

46. A computer program product comprising processor executable instructions which, when executed by a computer network, cause the computer network to become configured as a network in accordance with any one of claims 1 to 41.