WO2006126875A1

WO2006126875A1 - Method to register a user at a service

Info

Publication number: WO2006126875A1
Application number: PCT/NL2006/000263
Authority: WO
Inventors: Hendrikus Johannes Maria Joosten; Geert Kleinhuis; Peter Joannes Mathias Veugen
Original assignee: Nederlandse Organisatie Voor Toegepast-Natuurwetenschappelijk Onderzoek Tno
Priority date: 2005-05-25
Filing date: 2006-05-24
Publication date: 2006-11-30

Abstract

Method for the registration of a user (E) at a service (RA1) which is part of a subdomain (D1). The user asks registration at said service under identity Id1. The service requests a registration service (RA) outside the subdomain and/or another service (RA2) within the same subdomain to send a subdomain specific user code (IdKey1) which is valid within the subdomain concerned. If the requested subdomain specific user code does not exist, the registration service asks the user to send a user code (Id) which is valid for that registration server, after which the registration service generates a subdomain specific user code (IdKey1) being valid for the subdomain concerned, e.g. by means of a cryptographic operation, such as 'secure hashing', of a secret, not subdomain specific user code (IdKey). If the requested subdomain specific user code (IdKey1) already exists or after being generated by the registration service, this code is sent to the service (RA1) where the user asks to be registered.

Description

Title: Method to register a user at a service

Field

The invention concerns a method to register a user at a service which is accessible via a network and which is part of a subdomain.

Background

Generally known is that users can register at services which are accessible via a network (e.g. the Internet) by means of e.g. a username and password, with which users can identify and authenticate themselves afterwards during "logging in" at the service concerned.

As a problem can be felt that one user can register at different services under different usernames. Particularly this can be a problem if was registered at services more or less belonging to a cluster of services which organizationally and/or technically belong to the same conglomerate or, to be called herinafter, subdomain, e.g. different services offered by a modern telecom operator offering telephony, data and internet related services, usually divided further into services for ISDN, ADSL, Internet access, mail services etc. etc. Usually, new users can register at those services under a self-chosen username (ID). The result is that the organization, e.g. the telecom operator, managing the different services, in fact does not have an image about the profile of the user who after all is able to pose under different, not-related usernames.

So, at the side of operators of more or less (organizational, technical and/or commercial) linked services the need is felt to form, without making violation of the privacy of the individual users, a more or less complete image of the profiles of those users, in order to be able to base on such profile information new or adjusted facilities, rates, etc. and e.g. to offer those facilities differentiated to profile sort. One solution direction is the use of a universal ID (UID) as e.g. a National Insurance Number. However, in practice this gives rise to the following problems:

- Information collected by parties concerned with the help of UIDs simply can be related to each other, which could result into privacy problems.

- Besides, this kind of translation systems are mostly the property of commercial parties, which can provide problems, as e.g. in the case ChoicePoint (see www.siliconvalley.com/mld/siliconvalley/news- /editorial/11276462.htm).

Summary

The present invention aims to meet said objections by providing a method for registering a user (or user entity) at a service which is accessible via a network and which is part of a subdomain, the method comprising next steps:

- the user asks registration at the relevant service;

- the service requests a registration service outside the same subdomain and/or another service within the same subdomain to send a subdomain specific user code which is (only) valid within the subdomain;

- if the requested subdomain specific user code does not exist, the registration service asks the user to send a user code which is valid for that registration server, after which the registration service generates a subdomain specific user code which is valid for the subdomain;

- if the requested subdomain specific user code already exists or after it has been generated by the registration service, this code is sent to the service where the user asks to be registered. This service is able to store the subdomain specific user code together with other data like (service specific) user code (log-in name, username) and password of the new user. In this way it is achieved that to a (new) user who registers at a service, a subdomain specific user code is assigned, which is equal for all services within the same subdomain. By this especially a party having the management over that subdomain, e.g. a telecom operator, is able to formulate a reliable user profile of that user, based on the (additionally) registered subdomain specific user code, viz. by collecting information at various services (within the same subdomain) in which the user has been registered.

It is noted that in the case that the requested subdomain specific user code does not exist, the registration service will ask the user to send a user code which is valid for that registration server, after which the registration service is able to generate a subdomain specific user code. If the user wishes to abandon such a "subdomain wide" registration, then the user can inform the registration server so. Besides, it is noted that the user, if not already done, has to make, at any moment, an initial registration at the registration server, after which the user will be able to authenticate at the registration server. The registration server can serve various subdomains. However, the user needs to register - initially- at this (generic) registration server once, which registration is valid and can be used then for the subsequent generation of subdomain specific user codes for each served subdomain.

If the user - in the initial phase- registers at the registration server, the registration server preferably generates a generic, not subdomain specific user code, which serves as a basis for the generation of subdomain specific user codes. In view of the privacy, a not subdomain specific user code prefably is a secret code which e.g. is used as a "secret key" in a cryptographic process which is appropriate for the generation of the subdomain specific user code concerned. So the registration service may generate the subdomain specific user code by means of a cryptographic operation of the subdomain-using a code indicating th subdomain- and the not subdomain specific user code, viz. the "secret key". The cryptographic operation is e.g. a "secure hash" operation of the subdomain (viz. a subdomain indicator code) and the not subdomain specific user code. Systems which make use of the method presented here and which are located within the same sub domain (e.g. within a company or a country), will thus be able to recognize each user every time again as the same one, viz. by his (her/its) subdomain specific user code, regardless of the different e.g. self chosen identities with which the user is registered at different services and regardless of the method of authentication applied.

For e.g. public bodies it means that citizens do not need to input their data every time again if they have to fill in an (electronic, digital) form. For e.g. a company it means that a customer can not pose as another anymore e.g. to be recognized as a defaulter.

The method presented here does not allow that user information over the borders of subdomains can be exchanged based on the identity of the user.

The proposed method leads to more transparency in relation to the storage and exchange of data and to better data protection.

The invention meets the objections of the existing methods as follows:

- No privacy problems will arise anymore caused by interlinking identities of different subdomains . After all, to this end it is required to retrieve the not subdomain specific user code. And that is only possible if that code for all participating subdomains gets a status which is equal to or comparable with the status of a code distributed (supra domein) "Trusted Third Party" (TTP), which TTP status is assigned to the registration server.

- It cannot be prevented that information is linked, but it can be prevented that such happens by means of identities (such as the subdomain specific user codes). So to be able to link information, active participation of parties within different subdomains is needed, and in that case the parties can be held responsible for it.

- By means of the method presented here it is guaranteed that each user (entity) within a certain subdomain has exactly one universal identity for that subdomain, regardless of the authentication method, if each service follows the registration protocol according to this method (discussed more in detail below). In this way each user of any service within a subdomain will always be recognised as the same user (entity), such as is necessary e.g. for registrations in conformity with the American Sarbanes-Oxley Act which was instituted to protect investors against fraudulent accounting practices at companies.

Exemplary embodiment

Figure 1 shows schematically the example of a system which is adapted to carry out the above presented method.

Figure 2 shows the schematic representation of an example protocol Pl which is derived from the presented method.

Figure 3 shows the schematic representation of a supplementary example protocol P2.

Figure 4 schematically outlines the example of an additional protocol P3.

Figure 5 schematically outlines the example of an alternative additional protocol P4.

Figure 1 shows a (supra) domain D, comprising a registration authority RA which keeps up a register R of entities (users) which are registered in that domain. Register R comprises records which link per user —here indicated as entity E- a not subdomain specific user code IdKey and authentication information (e.g. username/password) Authlnfo, at which:

1. each IdKey identifies one of the registered entities in domain D and each registered entity has its own, unique ID Key;

2. IdKey is a search key with which the corresponding Authlnfo of the entity concerned can be found;

3. register R does not know more than one IdKey for any entity in domain D; 4. Authlnfo is a bit row within register R, which can be used to find the IdKey which identifies an entity E within domain D by means of information (e.g. username/password) resulting from a successfull authentication procedure.

5. Authlnfo can be (re)constructed with the help of the information which has been (come) available in protocol step 3 of the protocol P2 to be discussed herinaffcer.

Note that because of the above mentioned properties 1 and 2, IdKey is an identity for the entity which it identifies. However, this identity IdKey is not made known by the RA within any subdomain of D (Dl, D2, etc.), nor outside domain D itself, except for to an any possible super domain of D (if that does exist), if at least there exist compelling reasons for that. Therefore it is of interest that RA is a reliable (trusted) party for the (whole) domain. Should there be needed a universal identity for the whole domain D, this simply can be derived from IdKey, e.g. by means of a secure hash function, without compromising IdKey.

Each entity E which has been registered in domain D, has an identity Id within domain D and an identity token IdT by means of which the RA within domain D can verify that Id belongs to IdT according to register R. Note that:

- it depends on the used authentication method wether or not it is necessary for authentication service AS to consult register R.

if E should authenticate with identity Id and IdT at RA according to protocol P2, RA is able to construct Authlnfo from the information coming from P2 via protocol step 3, and with that can retrieve the IdKey of E.

RA is the only one which can retrieve the IdKey of E

The protocol Pl, showed in figure 2, runs as follows: 1. If entity E wishes to register itself at a service RAl within a domain Dl, E and RAl set up a sufficiently protected connection Vl, in which E authenticates RAl with a sufficient extent of certainty. Note that RAl does not (yet) authenticate E. E sends a request to RAl via Vl to be registered under identity IdI.

2. RAl and RA set up a sufficiently protected connection V2_; at which RAl and RA authenticate each other with a sufficient extent of certaincy. RAl sends the request of E to RA via V2.

3. RA and E set up a sufficiently protected connection V3 at which E asks RA to identify itself.

4. E sends identity Id and identity token IdT to RA (via V3).

5. RA authenticates E by means of Id and IdT. If that does not succeed, the protocol stops. If it does succeed, RA presents the request to E via V3, and asks E to agree.

6. E sends an agreement or non-agreement to RA via V3. (After this connection V3 is not used anymore.) At a non-agreement the protocol stops.

7. RA constructs by means of Id and IdT the Authinfo, after which RA asks the register R for the unique IdKey belonging to E, which the register R can retrieve by means of Authinfo.

8. Register R sends the retrieved IdKey to RA. RA creates, e.g. by generating a "secure hash" of a code Cl, characterizing subdomain Dl univocally, and the unique IdKey of user E, a bit row IdKey 1 with the following properties:

a. IdKey 1 identifies E within subdomain Dl, i.e. there is within subdomain Dl not any other entity E' which is or can be identified by bit row IdKey 1.

b. Not any bit row IdKey I¹ created by RA before and being unequal to IdKeyl, can be used to identify E within Dl. c. Not any subdomain of D different from Dl is able to use bit row IdKeyl for the identification of E.

d. There is no method known by which Id can be calculated from bit row IdKeyl in a feasable way in a reasonably limited time without consulting register R.

9. RA sends IdKeyl to RAl via V2 (After this, connection V2 is not used anymore). RAl makes identity token IdTl, a token by means of which E is able to authenticate afterwards with identity IdI within subdomain Dl. RAl makes Authlnfol by means of e.g. IdI, IdTl or possibly other information, such that all requirements for the Authlnfo data type will be met.

10. RaI sends IdKeyl and the calculated Authlnfo to register Rl with the request to save it.

11. Register Rl sends Ok' to RA as soon as this has been done.

12. RAl sends IdTl to E via Vl. (After this, connection Vl is not used anymore).

Figure 3 shows an extension to the standard authentication protocol which would be used without the method according to the invention.

Protocol P2 runs as follows:

1. Entity E and server S (which is also situated within subdomain Dl) set up a connection V4, at which E informs S that it has identity IdI and that IdTl is the corresponding identity token. Server S verifies whether IdI is registered within domain Dl, at which the identity token IdTl is used in the usual way to determine the authenticity of IdI. Note that this does not ask any requirements to the used authentication method. If IdI could not be verified (i.e. it is unknown, or the authentication failed), the protocol stops or, if necessary, this step will be repeated.

2. S asks the own register R, with the help of the Authlnfo, constructed (ox- had construct) by S by means of IdI and IdTl, for the IdKeyl belonging to E, which register R retrieves (or lets retrieve), e.g. by consulting or let consult the register Rl of RAl), which is possible because this Authlnfo identifies E univocally within subdomain Dl.

3. Register R sends the IdKeyl belonging to Authinfo to server S, which IdKeyl identifies E within subdomain Dl. By this E has been authenticated and S has at its disposal an identifier for E which is

(universally) valid within subdomain Dl and which is independent of the used authentication method and/or IdI and/or IdTl.

4. Server S informs entity E that its identity IdI has been authenticated.

Additionally, the following extensions could be made, referencing to figures 4 and 5.

An identity broker IB is an entity of domain D (i.e. the same domain as in which RA is located). The function of IB is to facilitate information exchanges, the information concerning a certain entity E and the information being exchanged between two domains D3 and D4, being both subdomains of D. For this function it is necessary for IB, just like RA, to have access to register R to be able to translate an identity IdKey3 which is specific for the one subdomain D3, to an identity IdKey4 which is specific for the other subdomain D4 (and reversely), both domain specific identities referring to the same entity E. The characteristic feature of the functionality of IB is that it does not allow that IdKey 3 and IdKey4 can be related to each other within any subdomain D3 and/or D4. Because of this function IB is, just like RA, a trusted party within domain D.

The problem, to the solution of which the identity broker contributes, is that a server S3 (comparable with the services - or servers - RAl or RA2 in Dl, mentioned above) from subdomain D 3, to be able to carry out a service, needs information from another subdomain D 4, which, concerns a certain entity E. A first example of this is an academic hospital wanting to do a survey among persons not having been treated medically for more than 5 years, and wanting to let them fill in a questionnaire. In order to obtain the current address of these persons, the hospital wants to consult the municipal register. A second example is that a sales department wants to inspect a register of the security department to verify that the customer is not reputed as unreliable, and wants to inspect a register of the financial department to check that the customer is not a defaulter. It is -also giving the legislation such as the Law Protection Personal Details — not obvious that D4 would provide information like this unthinkingly. Besides, there also exist policy rules e.g. within companies, or laws concerning e.g. competition which are able to impose restrictions to the free exchange of information. Besides, it could be undesirable that D4 gets information about identities which are used in D3 and possibly linked to own information, e.g. if the domains concerned have little or nothing to do with each other as in the first example.

An information exchange session can pass as in below mentioned example protocol P3; all requests, answers and other information exchanged between parties, use a sufficiently protected connection at which parties have authenticated each other in a sufficient extent.

Protocol P3 runs as follows (the protocol step numbers refer to the numbers used in figure 4):

1. S3 sends a request to IB for information which has to come from server S4 in domain D4, concerning entity E, being identified in domain D3 with

IdKey3.

2. IB retrieves in register R an identity IdKey4 which is valid within domain D4 and which concerns the same entity E. If this can not be found, the protocol stops. Optionally, IB may verify whether entity E has given permission to exchange information, concerning to E, between S4 and S3, and if that is not the case, to set up a connection to E (comparable with steps 3 to 6 from protocol Pl) and to ask E for permission, the protocol ending if that permission is not given (in due time). Alternatively, IB may verify if there exists permission for other reasons (or even the obligation) to exchange this information, e.g. because of an injunction, or because of legislation or rules.

3. IB sends the request of S3 to S4, IdKey3 being replaced by IdKey4.

4. If S4 does not want or is not able to send the requested information, the protocol stops; otherwise S4 sends the requested information to IB, wchich transfers the information to S3, a possible IdKey4 being replaced by

IdKey3.

An optimization of protocol P3 is that a session is set up between servers S3 and S4, both servers having the own IdKey3 or IdKey4 at its disposal and being able to be trusted that they will not, or at least not in that session, exchange these identities. Such a protocol can e.g. look like as follows (protocol P4); all requests, answers and other information being exchanged between parties, are using a sufficiently protected connection at which parties have been authenticated each other to a sufficient extent.

Protocol P4 runs as follows (the protocol step numbers refer to the numbers used in figure 5):

1. S3 sends a request to IB to obtain a token T with which S3 is able to set up a session with a server S4 within D4, in a way that S3 as well as S4 know an identity IdKey3 respectively IdKey4 of the entity E valid within their domain, about who information is exchanged.

2. IB checks if there is an IdKey4 referring to the same entity as IdKey3, but which is a valid identity within domain D4. Is this the case, then IB constructs the token T by means of IdKey3 and an identification of domain D4 or IdKey4 itself, in a way that neither within D3 nor within D4 a practically performable way exists to derive IdKey3 and/or IdKey4 from the token, but that this is possible for the one who has acces to register R of domain D. IB can do this e.g. by encyphering IdKeyδ and IdKey4 with an asymmetrical encyphering method (e.g. RSA), IB using its own public key for encyphering. Optionally, IB may verify whether entity E has given permission for the exchange of information concerning E between S4 and

S3, and if that is not the case, to set up a connection to E (comparable with steps 3 to 6 from protocol Pl) and to ask E for permission, the protocol ending if that permission is not given (in due time). Alternatively, IB may verify if on other grounds there exists permission for other reasons (or even the obligation) to exchange this information, e.g. based on an injunction, or base don legislation and rules.

3. IB sends this token to S3.

4. S3 sends the request for information, together with the token, to S4.

5. S4 sends the token to IB. IB deciphers the information from the token (e.g. by using its own secret key), and obtains in that way disposal of IdKey3 and IdKey4 (or an identification of domain D4, from which it is able to derive with IdKey3 the concerned IdKey4 by using register R).

6. IB sends IdKey4 back to S4. From this moment a session between S3 and S4 exists, both having disposal of identity of E a valid within the own domain. So within this session information about E can be exchanged.

It is conceivable that additional facilities are implemented at IB, S3 and/or S4 e.g. to prevent that a token is used more than one time, or to prevent that without the knowing of IB, servers from the domains D3 and D4 would be able to exchange information about E to each other. However, this is difficult, because during an anyway valid session, S3 and S4 would be able to conspire with each other and exchange IdKey3 and IdKey4 via another channel, outside the session verified by IB.

With the help of said protocols it is possible that e.g companies can consult a governmental, e.g. municipal register to retrieve the current place of residence of a person, at least if that person has given permission for that. Generally speaking, the invention enables that information between different domains are exchanged with each other according to the permissions the owner of the information concerned has given.

Claims

1. Method for the registration of a user (E) at a service (RAl) which is accessible via a network and which is part of a subdomain (Dl), which method comprises the next steps:

- the user asks registration at said service;

- the service requests a registration service (RA) outside the same subdomain or another service (RA2) within the same subdomain, or both of them, to send a subdomain specific user code (IdKeyl) which is valid within the subdomain concerned;

- if the requested subdomain specific user code does not exist, the registration service (RA) asks the user to send a user code (Id) which is valid for that registration server, after which the registration service generates a subdomain specific user code (IdKeyl) which is valid for the subdomain concerned;

- if the requested subdomain specific user code (IdKeyl) already exists or after being generated by the registration service, it is sent to the service (RAl) where the user asks to be registered;

2. Method according to claim 1, wherein, if the requested subdomain specific user code does not exist and the registration service asks the user to send the user code (IdI) which is valid for that registration server, the registration service generates said subdomain specific user code (IdKeyl) which is valid for the subdomain concerned, from a not subdomain specific user code (IdKey);

3. Method according to claim 2, the registration service generating the subdomain specific user code (IdKeyl) from a secret not subdomain specific user code (IdKey).

4. Method according to claim 2 or 3, the registration service generating the subdomain specific user code (IdKeyl) by means of a cryptographic operation of the subdomain concerned (Dl) and the not subdomain specific user code (IdKey).

5. Method according to claim 4, the cryptographic operation comprising a "secure hash" operation of an indication of the subdonαain concerned (Dl) and the not subdomain specific user code (IdKey).

6. Method according to claim 4, the cryptographic operation comprising the digital signing of an identification of the subdomain concerned (Dl) and the not subdomain specific user code (IdKey).