Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L63/00—Network architectures or network communication protocols for network security
  • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
  • H04L63/0815—Network architectures or network communication protocols for network security for authentication of entities providing single-sign-on or federations
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L63/00—Network architectures or network communication protocols for network security
  • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
  • H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L63/00—Network architectures or network communication protocols for network security
  • H04L63/18—Network architectures or network communication protocols for network security using different networks or channels, e.g. using out of band channels
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
  • H04W12/06—Authentication
  • H04W12/068—Authentication using credential vaults, e.g. password manager applications or one time password [OTP] applications

Definitions

• the present invention is related to the field of identity management and service access control.
• FIG. 1 shows a system, indicated generally by the reference numeral 1, comprising a client 2, a service provider 4 and an identity provider 6.
• the service provider 4 obtains an authentication assertion containing a service provider-specific user identifier from the identity provider 6, and (assuming that the authentication assertion refers to an existing user at the service provider 4), the service provider provides the personalized service to the client 2.
• FIG. 2 shows a message sequence, indicated generally by the reference numeral 10, that can be used for providing user authentication information to the service provider 4.
• the message sequence 10 makes use of the Security Assertion
• SAML is an XML (extensible Markup Language) standard for exchanging authentication and authorization data between security domains.
• SAML is used for exchanging assertion data between an identity provider (a producer of assertions) and a service provider (a consumer of assertions) .
• SAML is a specification defined by the OASIS (Organization for the Advancement of Structured Information Standards) .
• the message sequence 10 begins with the client 2 issuing an HTTP request 12 to the service provider 4, requesting access to a secure resource at the service provider.
• the service provider 4 issues an HTTP redirect message 14 to the client, instructing the client to obtain user credentials from a particular identity provider.
• the user browser then sends a SAML authentication request 16 to the identity provider 6 indicated in the redirect message 14.
• the identity provider 6 replies with an HTTP redirect message 18, including the requested SAML assertion.
• the client 2 sends a SAML authentication response 20 to the service provider 4, including the SAML assertion obtained from the identity provider 6.
• the service provider provides the user with access to the requested secure resource and sends an HTTP response 22 to the client 2.
• the message sequence 10 described above with reference to Figure 2 is one of many mechanisms that could be used for providing user credentials to the service provider 4.
• the skilled person will be aware of many alternatives, including, for example, mechanisms in accordance with the Generic Bootstrapping Architecture (GBA) , OpenID and Windows ® CardSpace protocols.
• GBA Generic Bootstrapping Architecture
• Telecommunication operators such as mobile network operators, are in a particularly good position for acting as identity providers, since they maintain a trustful relationship with their customers.
• Mobile communication devices are currently authenticated in a secure manner.
• Mobile communication devices can also be used to access services, however many users prefer to use personal computers, such as laptops, for accessing services, for example over the Internet.
• personal computers and similar client devices typically offer better performance and display functionality than mobile communication devices.
• Personal computers typically provide inferior authentication methods than mobile communication devices.
• FIG. 3 is a block diagram of a system, indicated generally by the reference numeral 30, that attempts to combine the advantages of personal computer based service access (high performance, good display etc.) and the advantages of mobile communication devices (strong authentication) .
• the system 30 comprises a client device 32 (such as a personal computer) , a network 34 (such as the Internet) , a service provider 36, a user equipment (UE) 38, a mobile network 40 and an authentication module 42.
• the UE 38 makes use of the mobile network 40 to make telephone calls, send SMS messages etc.
• the authentication module 42 is coupled to the mobile network 40 and is used to authenticate the UE 38 in a manner well known in the art.
• the client device 32 uses the Internet 34 (via a browser of the client device) to connect to a service provider 36.
• a service provider 36 In order to access services provided by the service provider 36, the user client needs to be identified.
• the service provider 36 can obtain identification information from the authentication module 42.
• the authentication module 42 and/or the service provider 36 need to be convinced that the same user is operating both the UE 38 and the user client 32.
• One approach is for the authentication module 42 to send a one-time password (OTP) to the UE 38 in the mobile network 40 (for example, in the form of an SMS message) .
• OTP one-time password
• the user enters this password at the user client 32 in order to demonstrate that the same user is using both the UE (where the OTP is received by the user) and the user client (where the OTP is entered by the user) .
• OTP one-time password
• SMS short message
• the present invention seeks to address at least some of the problems outlined above.
• a method for example, for authenticating a user at a service provider using an identity provider provided by a telecommunication network provider
• the method comprising: receiving, at an identity provider provided by a telecommunications network provider, a request (such as an HTTP or HTTPS request) from a client for user credentials required to access a service provider; sending an authentication request (such as an HTTP Unauthorised response) from the identity provider to the client, the authentication request including a first reference; receiving, at the identity provider (or any other function that the identity provider trusts) , a request from a mobile communication device to identify a user at the client, the request including a second reference, wherein the mobile communication device makes use of the network provided by the telecommunication network provider and is known to an authentication server provided by the telecommunication network provider; and comparing the first and second references and, if they are the same, obtaining identification information (e.g.
• the comparing step may be carried out by the identity provider or by another module or function trusted by the identity provider.
• the identity provider receives the second reference: in other forms of the invention, the identity provider does not receive the second reference (for example, it may be received by a separate module that is trusted by the identity provider) .
• a method for example, for authenticating a user at a service provider using an identity provider provided by a telecommunication network provider
• the method comprising: sending a request from a client to an identity provider (either directly or via an intermediary such as a service provider that redirects the client to the identity provider) requesting user credentials required to access a service provider; receiving, at the client, an authentication request from the identity provider, wherein the authentication request includes a first reference; using the client to send a request to a mobile communication device that is also being used by the user of the client to identify the client at an identity provider, wherein the request includes the first reference, wherein the identity provider is provided by the provider of a telecommunications network to the mobile communications device, and wherein the mobile communication device is known to an authentication server provided by the provider of the telecommunications network; using the mobile communication device to send a request to the identity provider (or to any other function trusted by the identity provider) to identify the user of the client, the request to identify the user
• an apparatus such as an identity provider or a system including an identity provider and possibly additionally including an authentication module
• a first input adapted to receive a request (such as an HTTP request) from a client for access to a service provider;
• a first output adapted to send an authentication response (e.g.
• the apparatus may include a second output (which may be the same physical output as the first output) for providing the user credentials for the requested service provider to the client.
• the apparatus may be an identity provider that is provided by the same telecommunications provider that is used by the mobile communication device and that provider the authentication server .
• an apparatus such as an identity provider
• a first input adapted to receive a request (such as an HTTP request) from a client for access to a service provider; a first output adapted to send an authentication response to the client, the authentication response including a first reference; and a second output for providing user credentials for the requested service provider to the client in the event that the first reference is the same as a second reference sent by a mobile communication device known to an authentication service associated with the identity provider.
• the apparatus may include processing means adapted to compare the first and second references.
• the processing means may form part of the identity provider or may be provided as a separate module that is trusted by the identity provider.
• the apparatus may further comprise means for obtaining identification information for the user of the mobile communication device from the authentication server.
• the apparatus may further comprise a second input for receiving a request from the mobile communication device to identify the user at the client, the request including a second reference; alternatively, the request may be received at a second module that is trusted by the identity provider.
• the present invention further provides a system comprising a client, a mobile communication device and an identity provider, wherein the identity provider is provided by a telecommunication network provider that is used by the mobile communication device, wherein: the identity provider comprises a first input (or some other means) for receiving a request from the client for access to a service provider; the identity provider comprises a first output (or some other means) for sending an authentication response to a first input of the client, the authentication response including a first reference; the client comprises a first output (or some other means) for sending a request to a first input of the mobile communication device to identify the client at the identity provider, the request including the first reference; the mobile communication device comprises a first output (or some other means) for sending a request to the identity provider to identify the user of the client, the request including the first reference; processing means is provided (for example, as part of the identity provider) for comparing the reference sent by the identity provider to the client and the reference sent by the mobile communication device; and the identity provider comprises a second output (or some other means)
• the present invention also provides a method (for example, for authenticating a user at a service provider using an identity provider provided by a telecommunication network provider), the method comprising: sending a request from a client to an identity provider requesting user credentials required to access a service provider; receiving, at the client, an authentication request from the identity provider to the client, the authentication request including a first reference; sending a request from the client to a mobile communication device used by the user of the client to identify the user at an identity provider, wherein the identity provider is provided by the provider of a telecommunications network to the mobile communication device; and receiving, at the client, authentication information for the service provider from the identity provider in the event that it is determined (for example, by the identity provider or by another function trusted by the identity provider) that the same user is operating the mobile communication device and the client.
• a method for example, for authenticating a user at a service provider using an identity provider provided by a telecommunication network provider
• the method comprising: sending a request from a client to an identity provider requesting
• the present invention yet further provides an apparatus (for example, for authenticating a user at a service provider using an identity provider provided by a telecommunication network provider) comprising: a first output for sending a request to an identity provider requesting user credentials required to access a service provider; a first input for receiving an authentication request from the identity provider, the authentication request including a first reference; and a second output for sending a request to a mobile communication device used by the user of the apparatus to identify the user at an identity provider, wherein the identity provider is provided by the provider of a telecommunications network to the mobile communication device, wherein the request includes the first reference.
• the client may be a user device, such as a personal computer, having a suitable browser for accessing the service provider, for example via the Internet.
• At least some forms of the invention provide a new authentication arrangement based on the secure authentication of a mobile communication device (or user equipment UE) .
• This implementation can be a little bit less secure alternative to the 3GPP-GBA mechanism, which is not generally used as operators do not generally own/provide bootstrapping server function (BSF) servers, and mobile communication devices do not widely support 3GPP-GBA.
• BSF bootstrapping server function
• the present invention can be used with a wide range of mobile communication devices without having to modify or install new elements (besides the Identity Management software) into the operator's network.
• the decreased security comes from the fact that the present solution either relies on a shared secret R (the "first reference") or relies on HTTPS/TLS connection between the identity provider and the client, whereas in the 3GPP-GBA solution, the shared secret (K) is generated both in the client and in the BSF and is never transferred on the network. Nevertheless, despite this decrease of security, the resulting solution is still at least as secure as the SMS- based solutions used widely nowadays for banking transactions (in which the shared secret (a passcode) is sent in the SMS) .
• the present solution is more secure than the current SMS-based solutions, because the passcode in the latter is usually less than 10 characters long (approximately 60-bit entropy for alphanumeric passcodes of length 10), whereas the shared secret in the present solution can be arbitrarily long (128-bits in the examples given below, but, of course, other lengths could readily be implemented) .
• embodiments of the present invention are more secure than simple username/password authentication because a trusted end-device is used for the authentication itself, while entering username/password pairs into a web browser can be spoofed or phished.
• a further advantage of embodiments of the invention is that an already existing authentication of the UE against the identity provider can be reused (for example, by relying on the already existing authentication of the UE against the network of a telecommunications network operator) , while in current methods, the users would have to re-authenticate themselves to the identity provider upon closing the browser.
• the authentication comes from the UE and is kept stable, even over restarts of the client device.
• the identity provider provides the requested user credentials required to access the service provider on the basis of the identification information obtained from the authentication server.
• the requested user credentials may be forwarded to the client, for example in response to a second request from the client.
• the user credentials may be sent directly from the identity provider to the client.
• the user credentials may be sent from the identity provider to the client via the mobile communication device.
• the user credentials are sent from the identity provider to the service provider (either in addition to, or instead of, being sent to the client)
• a second request for user credentials required to access the service provider is sent by the client to the identity provider.
• the second request may include the first reference.
• the identity provider generates a third reference.
• the third reference may be sent to the client, for example, either directly from the identity provider, or from the identity provider to the client via the mobile communication device.
• the second request may include the third reference (either in addition to, or instead of, the first reference) .
• the first reference includes a URL.
• the mobile communication device may use the URL to contact the identity provider, thereby confirming that the mobile communication device has been informed of the first reference.
• the URL may appear in the inbox of the mobile communication device, so that the user can easily follow the link.
• the mobile communication device may be adapted to automatically follow the URL: such an arrangement is more convenient for the user, but it does require the mobile communication device to be provided with a mechanism (such as a locally installed application) for automatically following such a link.
• the first reference is encoded as a telephone number.
• the mobile communication device may use the telephone number to make contact with the identity provider (or with a third party who is in contact with the identity provider) , thereby confirming that the mobile communication device has been informed of the first reference .
• the second reference is sent and/or received as a DTMF sequence (or a similar sequence) .
• the mobile communication device may be used to contact an authentication server or a identity provider using a particular telephone number.
• the second reference can then be entered using a DTMF (or similar) sequence.
• the authentication information may be forwarded from the client to the service provider.
• the request sent from the client to the mobile communication device may be sent via a direct local connection.
• the request sent from the client to the mobile communication device may be sent via a wireless connection (such as a Bluetooth connection) .
• a wireless connection such as a Bluetooth connection
• Other connection formats are possible .
• the first reference discussed above may be a nonce.
• the first reference is a hexadecimally encoded 128-bit nonce.
• that reference may be a similar nonce.
• the present invention also provides computer program product, comprising: means for receiving, at an identity provider provided by a telecommunications network provider, a request (e.g. an HTTP request) from a client for user credentials required to access a service provider; means for sending an authentication request (e.g.
• an HTTP Unauthorised response from the identity provider to the client, the authentication request including a first reference; means for receiving, at the identity provider (or another function trusted by the identity provider) , a request from a mobile communication device to identify a user at the client, the request including a second reference, wherein the mobile communication device makes use of the network provided by the telecommunication network provider and is known to an authentication server provided by the telecommunication network provider; and means for comparing the first and second references and, if they are the same, obtaining identification information (e.g. IMSI etc.) for the user of the mobile communication device from the authentication server provided by the telecommunication network provider.
• identification information e.g. IMSI etc.
• the present invention also provides computer program, comprising: code for receiving, at an identity provider provided by a telecommunications network provider, a request (e.g. an HTTP request) from a client for user credentials required to access a service provider; code for sending an authentication request (e.g.
• the computer program may be a computer program product comprising a computer-readable medium bearing computer program code embodied therein for use with a computer.
• the present invention further provides a computer program product comprising: means for sending a request from a client to an identity provider requesting user credentials required to access a service provider; means for receiving, at the client, an authentication request from the identity provider, wherein the authentication request includes a first reference; means for sending a request from the client to a mobile communication device that is also being used by the user of the client to identify the client at the identity provider, wherein the identity provider is provided by a provider of a telecommunications network to the mobile communications device, and wherein the mobile communication device makes use of the telecommunications network and is known to an authentication server provided by the authentication server; means for sending a request from the mobile communication device to the identity provider (or to another module, for example a module trusted by the identity provider) to identify the user of the client, the request to identify the user including the first reference; means for comparing, at the identity provider, the reference sent to the client and the reference received from the mobile communication device; and means for obtaining identification information for the user of the mobile communication device from the authentications server in the
• the present invention further provides a computer program comprising: code for sending a request from a client to an identity provider requesting user credentials required to access a service provider; code for receiving, at the client, an authentication request from the identity provider, wherein the authentication request includes a first reference; code for sending a request from the client to a mobile communication device that is also being used by the user of the client to identify the client at the identity provider, wherein the identity provider is provided by a provider of a telecommunications network to the mobile communications device, and wherein the mobile communication device makes use of the telecommunications network and is known to an authentication server provided by the authentication server; code for sending a request from the mobile communication device to the identity provider (or to another module, for example a module trusted by the identity provider) to identify the user of the client, the request to identify the user including the first reference; code for comparing, at the identity provider, the reference sent to the client and the reference received from the mobile communication device; and code for obtaining identification information for the user of the mobile communication device from the authentications server in the event
• Figure 1 is a block diagram demonstrating the use of identity management in the prior art
• Figure 2 is a message sequence showing an exemplary use of the system of Figure 1;
• Figure 3 is a block diagram of a system for providing user credentials;
• Figure 4 is a block diagram of a system for providing user credentials in accordance with an aspect of the present invention
• Figure 5 is a message sequence showing an exemplary use of the system of Figure 4, in accordance with an aspect of the present invention.
• FIG. 4 is a block diagram of a system, indicated generally by the reference numeral 50, in accordance with an aspect of the present invention.
• the system 50 comprises a client device 52 (for example, a personal computer or some other device having a suitable browser) , a UE 53, a service provider 54, an identity provider 56 provided within the domain of a telecommunications operator 58 (for example, a mobile network operator) and an Authentication, Authorization and Accounting (AAA) server 59 also provided within the domain of the operator 58.
• client device 52 for example, a personal computer or some other device having a suitable browser
• UE 53 for example, a personal computer or some other device having a suitable browser
• a service provider 54 for example, a service provider 54, an identity provider 56 provided within the domain of a telecommunications operator 58 (for example, a mobile network operator) and an Authentication, Authorization and Accounting (AAA) server 59 also provided within the domain of the operator 58.
• AAA Authentication, Author
• the client device 52 is in two-way communication with the UE 53, the service provider 54 and the identity provider 56.
• the client requests access to a service provided by a service provider 54.
• the identity provider 56 is used to provide user credentials for the user at the client 52.
• the user of the client device 52 is also using the UE 53, with that UE making use of the network provided by the telecommunications operator 58; the UE 53 is in two-way communication with the identity provider 56 and the AAA server 59 (as well as with the client 52) .
• the identity provider 56 is in two-way communication with the AAA server 59 and uses that server to identify the user of the UE 53.
• Figure 5 is a message sequence, indicated generally by the reference numeral 60, demonstrating an exemplary use of the system 50, in accordance with an aspect of the present invention .
• the message sequence 60 begins with the user client 52 issuing a request 61 (typically an HTTP Request) to the service provider 54, requesting access to a secure resource at the service provider.
• a request 61 typically an HTTP Request
• the service provider issues a redirect message 62 (such as an
• HTTP Redirect message instructing the client 52 to obtain user credentials from a particular identity provider (i.e. the identity provider 56) .
• the client 52 sends a message 63 to the identity provider 56 seeking the authentication details required to access a service provided by the service provider 54.
• the message 63 may, for example, be an HTTP or HTTPS message.
• the identity provider 56 determines that the user client 52 is not authenticated at the identity provider and responds to the message 63 by sending a message 64 asking the user client to authenticate itself to the satisfaction of the identity provider 56.
• the message 64 includes a reference R, as discussed further below.
• the message 64 may be sent as a special HTTP response, and this HTTP response is recognized at the client 52 by an extension to the browser.
• the extension can also be contained within the HTTP response (e.g. an HTML-Page containing a Java Applet or active-X plugin) .
• the authentication response 64 may take the form of an HTTP 401 Unauthorized response, in which the realm field of the WWW-Authenticate header contains a specific string, e.g.:
• the client 52 On receipt of the message 64, the client 52 sends a message 66 to the UE 53, instructing the UE to contact the identity provider 56 in order to convince the identity provider that the user of the client 52 is the same as the user of the UE 53, which user is already known to the AAA server 59.
• the message 66 includes the reference R that was provided by the identity provider 56. In this way, the UE 53 obtains the reference R.
• the UE 53 sends a message 68 to the identity provider 56.
• the message 68 includes the reference R that was included in the messages 64 and 66 described above.
• the reference R is used by the identity provider 56 to correlate the request 68 from the UE 53 with the earlier authentication request 63 received from the client 52.
• the message 66 sent from the client 52 to the UE 53 may include the following URL:
• the UE 53 may contact the identity provider at the above URL, thereby confirming to the identity provider that the UE 53 has been informed of the reference R and must therefore be connected with the user of the client device 52.
• the HTTPS scheme is denoted in the URL for higher security, but if the implementer trusts the encryption of the radio interface between the UE and the operator' s network, then HTTP may be used.
• the identity provider 56 can determine from the reference R that the same user is at the client 52 and the UE 53.
• the identity provider retrieves the user ID for the user of the UE 53 from the AAA server 59.
• This user ID is typically an internal identifier (e.g. IMSI, MSISDN) .
• the identity provider 56 may retrieve the user ID based on the source IP address or it may receive it as an asserted ID in an HTTP header.
• the identity provider 56 is able to provide the authentication assertion to the service provider.
• an authentication assertion is typically provided by an identity provider as a response to a request, and is transferred to the service provider via the client device by means of Web redirection, the message sequence 60 includes a number of further steps.
• the identity provider 56 sends a response 72 to the UE 53 (the originator of the request 68) and the UE 53 returns a response to the client 52 (response 74) .
• the client 52 then sends a further request (access request 76) to the identity provider.
• the identity provider now knows the identity of the client 52 and can therefore respond to the access request 76 by providing an authentication assertion 78 to the client 52.
• the assertion is sent from the client 52 to the service provider 54 as message 80.
• the service provider 54 checks the assertion and then deliver the request service to the user 52 (message 82) .
• the message sequence 72, 74 and 76 may take a number of different forms, as described further below.
• the response 72 sent from the identity provider 56 to the UE 53 includes a secret value S (which is in fact another nonce) :
• the client 52 contacts the identity provider once again, in message 76 requesting access to the service provider, in a similar manner to the request 63.
• this request when contacting the identity provider once again, this request must be linked to the Client's first request (message 63) . This may be done e.g. by including the reference R into the request
• the nonce value again plays the role of the reference R
• the username is left intentionally empty and the response is calculated from this empty username and the secret value S treated as a password, by means of the HTTP Digest response calculation algorithm as specified by RFC 2617 (see, for example, www.ietf.org/rfc/rfc2617.txt) .
• the identity provider can then verify the authenticity of this request by verifying the response against the shared secret value S (doing the same calculation as the client 52) .
• the message sequence 72, 74 and 76 can be simplified as follows.
• step 70 when the identity provider 56 has received the request 68 from the UE, it is convinced that the user sitting behind the original connection (message 63) is the same user as the one owning the UE 53, because of the reference R (the nonce) which is acting as a shared secret. So the identity provider does not have to return another shared secret (the nonce S discussed above) ; it is enough to respond with HTTP 200 OK with no payload.
• message 76 when contacting the identity provider 56 once again, the client 52 does not need to include an Authorization header at all (assuming that the underlying connection (such as a TLS connection) has been maintained.
• the request 76 is sent to the identity provider 56 and the identity provider provides a response to that request, in accordance with the SAML protocol.
• the message 78 returns the authentication assertion for the requested service to the client 52.
• the client 52 then forwards the assertion to the service provider as message 80 and the service provider delivers the requested service (message 82), as discussed above .
• the authentication assertion will typically contain a different identifier than the user ID retrieved in step 70: an identifier/pseudonym specific to service provider 54; the mapping is maintained by the identity provider.
• the message 68 including the reference R is described as being sent from the UE 53 to the identity provider 56.
• the message 68 may be sent to another device that is trusted by the identity provider. That other device may compare to reference sent from the identity provider 56 to the client 52 (as part of the message 64) and inform the identity provider whether or not the references match.
• the identity provider 56 needs to be convinced that the same user is operating the client and the UE; this is done by comparing the references discussed above, but it does not matter to the invention whether or not the identity provider itself carries out that comparison .
• the identity provider could simply return the user credentials required by the service provider 56 to the client 52, without needing to wait for a further request (thereby omitting the steps 72, 74 and 76 of the message sequence) .
• the identity provider could simply return the user credentials required by the service provider 56 to the service provider itself (thereby omitting the steps 72, 74 and 76 of the message sequence 60, sending the message 78 to the service provider instead of (or in addition to) the client and omitting step 80 of the message sequence) .
• the client 52 sends a message 66 instructing the UE 53 to contact the identity provider 56.
• the message 66 may be transferred from the client 52 to the UE 53 in any one of a number of ways. A number of options are discussed below, although the skilled person would be aware of alternatives that could be used.
• the message 64 contains a Web address of the identity provider 56.
• the address also contains the reference R, e.g. as a URL parameter.
• this address is passed on to the UE by standard Bluetooth means (OBEX) .
• OBEX Bluetooth means
• message 68 the UE contacts the address via cellular access (e.g. GPRS, 3G etc.) .
• the user typically receives the Web link into their inbox on the UE 53, has to open it and then follow the link .
• the protocol used for passing the Web address on to the UE may be proprietary and the server on the UE is implemented as a MIDlet (a JAVA application that is typically implemented on a Java-enabled mobile device) .
• the Web link is automatically followed by the UE.
• the use of a MIDlet or some other arrangement that enables the UE to automatically follow a link is clearly more convenient for the user than providing a link that needs to be manually followed at the UE by the user.
• this case requires the deployment of the MIDlet (or some other application) to the UE 53. This way, even more security can be used, because the connection between the UE 53 and the identity provider 56 is not necessarily based on HTTP.
• the UE is reached not via Bluetooth, but by some other means of short-range connectivity, such as an infrared connection.
• connection between the client 52 and the UE 53 can take many forms, many of which are secure, e.g. based on Bluetooth pairing, cable connection, data encryption and authentication in case of WLAN, etc.
• the received authentication request contains a telephone number (e.g. a so- called service number such as *1234567890#) .
• the number itself encodes the reference R, i.e. the number is unique to the request.
• message 66 the following steps are performed:
• the client 52 instructs the UE 53 via a USB link (or some other connection) to call this number.
• the UE 53 places a call.
• the identity provider 56 gets contacted by the network function that has processed the call.
• the received authentication request (message 64) contains a telephone number and a separate number which in fact is the reference R, i.e. the number is unique to the request.
• the message 66 the following steps are performed: • The client 52 instructs the UE 53 via a USB link (or Bluetooth or some other connection) to call this telephone number.
• the UE 53 places a call.
• the client 52 instructs the UE 53 to send the digits of the number R as a DTMF (dual-tone multi-frequency) sequence (or in some other way) .
• DTMF dual-tone multi-frequency
• the UE 53 sends the DTMF sequence.
• the identity provider 56 gets contacted by the network function that has processed the call.
• the client 52 can use a proprietary remote call initiation function of the UE, for example, or it could contact a MIDlet on the UE which in turn could initiate the call.
• a proprietary remote call initiation function of the UE for example, or it could contact a MIDlet on the UE which in turn could initiate the call.
• Other examples will be apparent to the person skilled in the art. It should be noted that an embodiment of the invention may combine two or more of the arrangements discussed above (e.g. Web link via USB, Call via Bluetooth, etc) .
• the communications between the client 52 and the UE 53 can take many forms.
• communications between the client 52 and the UE 53 may be based on shared files, provided that the UE can also appear as a mass storage to the client via a USB (or some other) connection; or the UE may also be a card phone that can be physically connected to the client .

Landscapes

• Engineering & Computer Science (AREA)
• Computer Security & Cryptography (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Computer Hardware Design (AREA)
• Computing Systems (AREA)
• General Engineering & Computer Science (AREA)
• Telephonic Communication Services (AREA)
• Mobile Radio Communication Systems (AREA)

Priority Applications (1)

Applications Claiming Priority (3)

Publications (1)

Family

ID=45023406

Family Applications (1)

Country Status (1)

Cited By (1)

• 2010
  • 2010-02-05 EP EP10702681A patent/EP2399408A1/de not_active Withdrawn

Non-Patent Citations (1)

Similar Documents

Legal Events