WO2023233173A1

WO2023233173A1 - Implementing self-sovereign identity (ssi) based on configurable individual profiles generated real-time from private attributes stored in the personal secure elements of the users

Info

Publication number: WO2023233173A1
Application number: PCT/HU2023/050023
Authority: WO
Inventors: András VILMOS
Original assignee: Safepay Systems Kft.
Priority date: 2022-05-31
Filing date: 2023-05-09
Publication date: 2023-12-07

Abstract

Disclosed herein is a method for dynamically generating a special purpose electronic ID card containing selected user attributes, the method comprising: - storing user attributes in a storage unit of a secure electronic wallet; - storing a private key of a key pair of asymmetric cryptography in the secure electronic wallet; - receiving, by the secure electronic wallet from a communication device, a command identifying at least one user attribute or at least one property of at least one user attribute; - retrieving, by the secure electronic wallet, data of the at least one attribute or of the at least one property of the at least one attribute identified by the command from the storage unit of the secure electronic wallet; - generating in the secure electronic wallet a dataset containing at least the retrieved data; - signing the dataset in the secure electronic wallet using the private key stored in the storage unit of the secure electronic wallet; and - transmitting the signed dataset from the secure electronic wallet to the communication device such that the communication device can generate a special purpose electronic ID card from the signed dataset.

Description

Implementing self-sovereign identity (SSI) based on configurable individual profiles generated real-time from private attributes stored in the personal secure elements of the users

TECHNICAL FIELD

The present disclosure relates to a method of generating a digitally signed, special purpose ID card in the ID card holder’s secure wallet for the purpose of sharing the least amount of necessary user specific information with an external third party who wishes to identify the ID card holder.

BACKGROUND

In today’s world, especially since the outbreak of the Covid-19 pandemic, people perform more and more activities on the internet, in the virtual world. This shift of activities carries new, previously unknown risks. One of these risks is the loss of privacy, including the potential misuse of one’s personal, sensitive information. This threat has already been recognized by legislators, which led to the introduction of the General Data Protection Regulation (in short GDPR) in 2016. However, the situation has only deteriorated further since working from home and shopping online became the new norm. Several new interactions moved to the net, and large masses unfamiliar with the online presence became active in the virtual space. With the growing exposure threat level increased, new attack types appeared and vulnerability is hard to control. The legal protection may not be enough anymore. New technical approaches are needed, new technologies which can protect people's identity and valuable personal information and prevent misuse.

One of the most critical challenges is the online protection of personal information in situations when people need to identify themselves, when personal identification is a pre-condition of obtaining a service or purchasing products, or simply interacting with another person or even with a machine. In such situations, control over personal information is completely lost. In the physical world such an identification action is simple. In the fairly common situation, when someone purchases a product which is tied to age control, like alcohol, one presents an ID, this ID is read, the picture on the ID card is compared with the person presenting this ID and, if the seller is satisfied and convinced that the ID is valid and not fake, data on the ID is not maliciously altered and the ID holder looks similar to the picture on the ID, then the transaction is approved and the drink is sold. There are no records taken from the ID, no copies are retained, and the whole process is a simple visual check. Sellers do not retain any sensitive, personal information about the buyer, and they have no opportunity to misuse the information which was presented to them.

This interaction is substantially different and a lot more insecure in the online world. To perform identification of the buyer and to make sure that he or she is allowed to buy the drink, the buyer needs to provide his or her ID online or needs to have a third party involved who can legitimately prove that the person is of legal age. This scenario creates threat in respect to privacy no matter which option is selected.

If the buyer presents his/her ID, then, unlike in the physical world where no trace is left and the whole interaction is controlled and monitored by the owner of ID, on the online channels, buyers lose control over the information as soon as they have shared the information. The data arrives to a remote location or remote server, it is processed, presented, and, depending on the small print and the legal compliance of the receiving party, further actions with the personal information of the buyer may occur. It may be deleted, may just be retained, may also be shared with legitimate third parties, or may even be sold to criminals. It is hard to track down the fate of the information.

The situation is somewhat, though not all that much better, if a third party is involved in the transaction. This third party is probably trusted and will not intentionally misuse the buyer’s sensitive information, but as this entity potentially holds a large database full of sensitive information, it may become a preferred target and eventual victim of data theft. Even if such unfortunate situation does not occur, this third party still will be able to collect valuable information about the user, will know where the ID was used, and which sites and services have been used. This means that this third party will be able to track its users, will be able to prepare profiles about them, and then to use this information for whatever purposes it wishes to.

The risks have been identified and multiple attempts can be listed which try to deliver a suitable technology or procedure. The most popular approach to tackle the online identification/authentication sensitivity challenge is the introduction of the decentralized identity concept based on the so-called self-sovereign identity (SSI) model which places the control of their digital identities into the hands of the individuals. According to the European Commission EIDAS (IDentification, Authentication and Trust Services regulation) description, it is generally recognized that for an identity system to be self-sovereign, users control the verifiable documents that they hold, and their consent is required to use those documents. By introducing SSI, the unintended sharing of users' personal data can be reduced. Under the current centralized digital identity framework, these data are generally under the control of entities external to the individual they refer to. In the decentralised identity paradigm, the idea is to put the user at the centre of the framework and so remove the need for these third parties. In an SSI approach, the user has both means of generating and controlling unique identifiers as well as some facility to store identity data. Users are then free to make use of whatever identity data they like. Identity related data, also called attribute, may have several forms. It may be biometric, like one’s gender, fingerprint, heights, weight; it may be social like name, date and place of birth, citizenship, marital status, address, education; it may be official like ID number of national ID card, passport or driving license. Other forms of less formal or more specific attributes may also have relevance in certain situations like, employment relationships, health status, family ties, circle of friends, etc.

A typical use would be for a user to collect attributes from the government, for example that he/she is a citizen, or has a certain national ID number or lives at a certain address. When it is time to make a claim, for example that the user has the right to vote in an election or that he/she is old enough to purchase alcohol (like in the above example), the user can then simply present the appropriate attribute(s). These attributes must be verifiable by some kind of cryptographic tool to be able to serve their purpose.

In SSI, users will have much finer control over how much data they share and with whom. This makes it easy to create different digital identities for different contexts, based on different sets of identity attributes. One may have a digital identity for the healthcare provider, another one for a professional networking site and some more for other purposes. Each of these would present different attributes of the user to the online world, and in a way determined by the user.

Besides flexibly selecting the personal attributes to present in different situations, the other key condition of SSI is the users' ability and obligation to securely store their own personal attributes. This capability allows full control of the users to access their data, without being worried that such access may be withdrawn or be made conditional, as well as assures the protection of sensitive personal information.

SSI is still in its early phase, but it already has a large amount of literature. In related publications, most solutions and concepts are based on blockchain technology. Such an architecture is described by the European Commission in its document “EIDAS SUPPORTED SELF-SOVEREIGN IDENTITY” in which decentralized identifiers (DIDs) are used as verifiable self-sovereign digital identity. DIDs are fully under the control of the DID subject, independent from any centralized registry, identity provider, or certificate authority. DIDs are URLs that relate a DID subject to means for trustable interactions with that subject. DIDs resolve to DID Documents — simple documents that describe how to use that specific DID. Each DID Document may contain at least three things: proof purposes, verification methods, and service endpoints. Proof purposes are combined with verification methods to provide mechanisms for proving things. As DIDs are just identifiers, they do not provide information about the subject itself. In practice, DIDs are used in combination with Verifiable Claims (VC) to support digital interactions in which information about the subject must be shared with third parties, by proving to those third parties that the DID subject has ownership of certain attestations or attributes. This proof is based on the cryptographic link between the VC, the DID subject of whom the VC is about, and the issuer of the VC. Trust on the issuer is established either by trusting the issuer’s DID (e.g. out-of-band, bilateral relationship, trusted lists) or by any other means. The third party can then use the presented cryptographically protected proof to verify the ownership and trustworthiness of the claims about the subject. As the presentation of the claims is managed totally by the users, they can decide on which specific pieces of information they want to share with third parties about themselves; by means of this selective disclosure of attributes privacy and personal data protection is reinforced. For implementing DID and VC, organisations working on Self-Sovereign Identity are relying on the use of Distributed Ledgers I Blockchains to support the registry of identifiers.

In their academic work “In Search of Self-Sovereign Identity Leveraging Blockchain Technology,” Md Sadek Ferdous, Farida Chowdhury, Madini 0. Alassafi (2019, Digital Object Identifier 10.1109/ACCESS.2019.2931173) introduce the relevant properties of blockchain which coincides with some desirable properties of a self-sovereign identity. Blockchain essentially provides a decentralized domain which is not controlled by any single entity. Data stored in any blockchain is readily available (availability property) to any authorized entity (access property). An owner of a particular data (an identity data such as Personally Identifiable Information or PH) has full control over it and dictates how such data can be shared with other users within the blockchain domain, thereby satisfying the disclosure property. In addition to these, a blockchain system can support a few additional advantages in terms of data immutability, provenance, distributed control, accountability and transparency. The document also illustrates three envisioned flows leveraging blockchain technology for a self-sovereign identity. uPort and Jolocom are decentralized identity systems built on top of Ethereum platform. They both consist of a mobile App and several Ethereum smart contracts including a public registry of uPort identity. A user utilizes the respective mobile App to create, update and share identity information with other users. In the backend, such data is controlled by different smart contracts. The bulk of identity data is stored on a distributed file system, whereas the mobile App is used to store the corresponding private key of a uPort identity. The public registry is used to create a correlation between a uPort identity and its data in the file system. Sovrin Identity system utilizes its own blockchain called Sovrin ledger that leverages a novel consensus algorithm called Plenum. A user can utilize a mobile App or a web site which acts as a Sovrin client to interact with the ledger in order to create, update, manage and share their identity data. Sovrin also supports the notion of Agents which can act as a Trusted Third Party to vouch or certify for identity data of a user. Sovrin enables users to exercise control in a way so that they can choose exact the data they want to share with someone else.

These solutions all have some important disadvantages. Number one is the large communication overhead, the need to always connect to a remote server to get access to the required information. Second is the inherent weakness of blockchain technology: its redundancy. Core property of the blockchain-distributed ledger technology (as its name also suggests) is that data is multiplicated and stored simultaneously on several servers. This makes the technology difficult to scale and the elaboration of an associated business model is also a challenge as this huge storage capacity as well as the verification of claims also needs to be financed. A third weakness of these blockchain based solutions is the need to know in advance what type of information will need to be shared in the future with potential third parties as the stored attributes need to be prepared in advance, when the user may not even know how and why the attribute or set of attributes will be used.

Another frequently mentioned scenario is the use of digital mobile wallets for storing the user attributes. In the off-line world, IDs are typically stored in physical wallets. It keeps them all in one place, protects them, and makes them easy to carry around. A digital wallet has the same purpose and must have the same features as well. Mobile wallets may be built into the operating system of smartphones or other communication devices or may even be dedicated hardware wallets with some communication interface to facilitate online connection for them. Wallets may further be server-side or client-side depending on the actual architecture of the system.

These solutions are more flexible than the blockchain based ones, nevertheless they also have substantial shortcomings. One is the need for global interoperability. If a wallet holds the user attributes these need to be presented in multiple scenarios and it must be assured that they are universally accepted. These wallets should be standardized. The level of security is also an issue. If the signed attributes are stored in mobile wallets, then these wallets must be protected. Depending on the sensitivity of the personal information general purpose mobile wallets may just not be able to provide the necessary security, dedicated hardware wallets are needed. The third weakness is the same what has already been explained in case of the blockchain based solution. The signed attributes need to be prestored before the user would know at all, what these attributes will be used for.

Another widely known technology for user identification is FIDO (Fast ID Online). This is a truly decentralized technology using Public Key Infrastructure (PKI) for user authentication. In this scenario the user has a special cryptographic token and with this token the user may generate PKI keypair(s). Upon registration to a third-party online service, the user generates a new keypair and sends it to the service provider. When the user later wishes to access the service, it receives a challenge from the site which it needs to sign with the private key of the keypair stored in the crypto token. The signed challenge is then returned to the service provider who can verify it with the public key it received from the user upon registration. Though this technology provides complete independence from third parties, it can only be used for user authentication and not for user identification. The difference being that while in an authorisation it is possible to verify that the user is really the one who they claim to be, however in absence of any further personal data it is not possible to establish their real identity or any of their individual attributes.

SUMMARY

Based on the above overview of the state of the art of prevailing technology and methods it can be clearly seen that a more secure, more flexible (preferably realtime) and light weight solution is required to make SSI a valid option for online user identification.

The present disclosure describes such a technology and method which overcomes the problems associated with the prior art by using a user side secure wallet which is able to generate pseudo, one-time ID cards, containing any selection of attributes the digital wallet contains.

The inventor realized that it is possible to flexibly configure data, which is presented upon online identification, and to only share the bare minimum required. For example, in the scenario described above of buying alcohol, the buyers do not need to provide their whole ID card and all data included in it, they only need to present proof that they are of the legal age, they are older than 18, 21 , or whatever age the local regulation requires. Having this information, the merchants must be satisfied (and is also legally protected) while they do not have any opportunity to misuse the received information, to use it for any unintended purpose.

According to the present disclosure, the ID holder has the capability to select any attribute or define the property of any attributes contained in their ID card and only present this information for identification purposes.

The solution can be implemented by using a secure chip card or similar secure element, which can provide the legally required security protection for the personal information. The ID holder may define the information needed on a communication device, which may be a mobile phone, a tablet, a laptop or any similar device which comprises at least a user interface for data selection and data presentation, one or multiple processors, data storage, communication interface with the secure element (chip card) and preferably also some remote or proximity communication interface to allow sharing the desired information as well as an application (software program) which supports the expected functionality. When user identification is required, the ID holder selects the attributes it wants to provide or share with the identifying party by either selecting the specific data (e.g., age) or property of a specific data (e.g., older than 18). When the selection is completed, this information is transferred to the secure element (e.g., chip card) which prepares a special purpose ID card for the specific identification transaction. This way, the holder of ID card shares only the information they are comfortable with and still satisfy the identification requirements.

Disclosed herein is a method for dynamically generating a special purpose electronic ID card containing selected user attributes, the method comprising:

- storing user attributes in a storage unit of a secure electronic wallet;

- storing a private key of a key pair of asymmetric cryptography in the secure electronic wallet;

- receiving, by the secure electronic wallet from a communication device, a command identifying at least one user attribute or at least one property of at least one user attribute;

- retrieving, by the secure electronic wallet, data of the at least one attribute or of the at least one property of the at least one attribute identified by the command from the storage unit of the secure electronic wallet;

- generating in the secure electronic wallet a dataset containing at least the retrieved data;

- signing the dataset in the secure electronic wallet using the private key stored in the storage unit of the secure electronic wallet; and

- transmitting the signed dataset from the secure electronic wallet to the communication device such that the communication device can generate a special purpose electronic ID card from the signed dataset.

In one embodiment, the communication device then transfers the signed dataset to a remote party over the internet to allow identification of the ID card holder, or exchanges this information through a proximity interface, like NFC or simply presents it on its display for visual verification.

In another embodiment, the signed data group is shared with external parties together with a PKI certificate which allows verification of the digital signature of the data group.

In a further embodiment, the data received in the secure wallet and related to an attribute is a relational information, or statement which is true in respect of a specific attribute in which case the signed data group contains confirmation of the relation or statement, (e.g., older than a specific age, without sharing exact birth information or exact age of the ID holder.)

In a further embodiment, the data received in the secure wallet identifying at least one attribute stored in the secure wallet is initiated by the external party who will assess the adequacy of the user’s attribute.

In a further embodiment, a time stamp is also included in the signed data group.

In a further embodiment, user authentication data is first stored in the secure wallet and the user needs to authenticate itself with the secure wallet before the special purpose electronic ID card may be generated and signed in the secure wallet.

In another embodiment, the secure wallet may store attributes related to multiple ID cards which may be controlled by the same or different business application(s) running on the communication device.

In another embodiment, multiple signed datasets may be returned to the user communication device, attributes of which may be stored separately in the secure wallet.

In another embodiment, the asymmetric key pair is generated in the secure wallet.

In another embodiment, there may be multiple private keys stored in the secure wallet each having its associated set of attributes, which only they can sign.

In another embodiment, the private key of the asymmetric key pair is generated and loaded into the secure wallet by, or on behalf of the issuer of the original ID card which is virtualized for the user.

In another embodiment, the secure wallet may also store information related to the issuer of the ID card, or about the unique specifics of the ID card itself which are also selectable and may be included in the data group to be signed.

The present disclosure also relates to a secure wallet, including at least one processor configured to perform some or all of the method steps disclosed herein. The present disclosure also relates to a mobile device or a computing device, including at least one processor configured to perform all or some of the method steps disclosed herein. The present disclosure also relates to one or more non-transitory computer readable mediums having stored thereon instructions or a program that, when executed by at least one processor, cause the at least one processor to perform the steps of the method disclosed herein.

In the context of the present disclosure, the secure wallet may be an embedded secure element in the communication device, or a removable card (e.g., SIM card, SD card) of the communication device, or an external smart card connectable to the communication device, or a software application (e.g., Trusted Execution Environment) of the communication device, or a secure storage facility connected to a remote server, or similar. The secure electronic wallet may also contain the necessary application(s) to carry out its functions.

In the context of the present disclosure, user attributes may be any type of user related information (biometric, social, official, other - see above). Attributes may also refer to the ID card itself or its issuer.

In the context of the present disclosure, a special purpose electronic ID card is any type of electronic code, official or informal, which carries any information about the person the document is related to.

Further details will be apparent from the accompanying figures and exemplary embodiments.

BRIEF DESCRIPTION OF THE DRAWINGS

Fig. 1 a is a schematic block diagram of an exemplary embodiment of a system suitable for carrying out the method according to various embodiments.

Fig. 1 b is another schematic block diagram of an exemplary embodiment of a system using a secure wallet connected to a remote server.

Fig. 2a is a more detailed block diagram of certain elements of Fig. 1 a.

Fig. 2b is a more detailed block diagram of certain elements of Fig. 1 b.

Figs. 3a and 3b are flow diagrams illustrating the steps of an exemplary embodiment according to various embodiments.

DETAILED DESCRIPTION

The exemplary embodiment illustrated in Fig. 1 a comprises a communication device 10 and a secure electronic wallet 20, which in this implementation is directly connected to the communication device 10, and an asymmetric cryptography key pair 50 consisting of a private key 50a and a public key 50b. The asymmetric cryptography infrastructure may be based on any kind of cryptographic algorithms, including postquantum cryptographic algorithms as well. The embodiment shown in Fig. 1 b differs from Fig. 1 a in that the secure electronic wallet 20 is directly connected to a remote computer 80, which is connected to the communication device 10 via an electronic communication channel 60, preferably over the Internet 62.

According to the embodiments shown on Fig. 2a and Fig. 2b, respectively, the communication device 10 may be a mobile phone 10a having a processor 11 , a data storage 12, a communication unit 13, and a touch screen (display) 15. Depending on the type and placement of the secure wallet 20, the communication device 10 has a secure wallet interface 14 (see Fig. 2a) or, if the secure electronic wallet 20 is placed on a remote computer, such as a remote server 80, such a secure wallet interface 84 is located on the remote server 80 (see Fig. 2b). Other type of communication devices than mobile phones could be used as well, such as a tablet, laptop, smart watch, etc. These devices have similar structure or may also have additional components like other type of input interface 16 (e.g. keyboard, mouse, etc.).

A program 12a for identifying the at least one attribute/attribute property which should be presented in the special purpose ID card may be stored in the data storage 12 of the communication device (mobile phone) 10.

According to the present embodiments, the secure electronic wallet 20 may be a smart card 20a, which is shown in Fig. 2a and Fig. 2b. It may comprise a processor 21 , a storage unit 22 and a communication interface 23 (such as a Global Platform standard JAVA card) and a software application 28. The communication device 10 communicates with the smart card 20a over the smart card interface 14 (see Fig. 2a). The communication between the communication device 10 and the secure electronic wallet 20 in case the smart card 20a is placed on a remote computer (e.g., server 80) is performed by using the communication interface 13 of the communication device 10 over the Internet-based electronic communication channel 60 between the communication device 10 and the remote server 80 and the remote server 80 comprises the smart card interface 84. (Fig. 2b). In Fig. 2b, only the elements of relevance to the present process, i.e. , processor 81 , communication interface 83, and smart card interface 84, are shown.

The private key 50a is stored in the secure storage 22 of the electronic wallet 20. Preferably, user authentication data 24 and user attributes 25 are also stored in the secure storage 22 of the electronic wallet 20. Other types of secure electronic wallets 20 are also conceivable as will be apparent to a skilled person, for example an embedded secure element in the communication device 10, a removable card (e.g. SIM card, SD card) of the communication device 10, an external smart card connectable to the communication device 10, a software application (e.g. Trusted Execution Environment) of the communication device 10, or a secure electronic wallet in a cloud connected to a remote server.

A public key certificate 50b’ generated from the public key 50b of the asymmetric cryptography key pair 50 is preferably stored in the data storage 12 of the communication device 10 as illustrated in Fig. 2a and Fig.2b.

Figs. 1 b, 2b show the particular embodiment in which the secure electronic wallet 20 is not directly connected to the communication device 10 but is connected to a remote computer, e.g., a server 80, which communicates with the communication device 10 using the Internet 62 via the electronic communication channel 60. The communication device 10 accesses the secure electronic wallet 20 through the remote server 80, during which the remote server 80 may be a simple proxy but may also play an active role in message exchange. The server 80 receives the message of the communication device 10 at the communication interface 83 suitable for remote communication, and then transfers it to the secure electronic wallet 20 via the smart card interface 84.

The method according to various embodiments is illustrated in Figs. 3a and 3b as performed with the system schematically depicted in Figs. 1 a, 1 b as follows. It will be appreciated that the order of some of the steps may differ from the order presented here. The user has a secure electronic wallet 20, which may be a smart card 20a in the present example. The asymmetric cryptography key pair 50 is preferably generated in the smart card 20a and the private key 50a is stored in the secure storage 22 of the smart card 20a, while the public key 50b may be transmitted to the communication device 10 where it is stored in the data storage 12 of the communication device 10 and will be used to generate the public key certificate 50b’.

A program 12a is stored in the data storage 12 of the communication device 10, which receives and processes the requests from the user, communicates with the smart card 20a, and presents the results of the smart card 20a actions to the user on the display 15 of the communication device 10.

User attributes 25 (at least one, but preferably multiple of them) are also stored in the secure storage 22 of the smart card 20a.

According to the present example, in step 100 the user authenticates himself by inputting via the input interface 16 (which may be a keyboard, a touchscreen 15, a fingerprint sensor, a camera, an NFC antenna, a mouse, touch pen, etc.) of the communication device 10 user authentication data 24'. The user is authenticated by the smart card 20a connected with the communication device 10 after having received some form of the user authentication data 24' from the communication device 10 by comparing the received user authentication data 24' with the stored user authentication data 24 as will be explained later on. In one approach, the smart card 20a or the software application 28 has a unique PIN 201 which is a form of user authentication data 24 and which the user needs to know and needs to input upon request to be able to perform any transaction with it. Other type of user authentication data 24 may be used as well, such as biometric identifiers. If the client device 10 is such a device which is typically used by a single user (like the mobile phone), additionally the program instance identifier 202 of the program 12a running on the communication device 10 (e.g. or some other specific information related to the user device like telephone number or serial number of the mobile phone, IME I, or MAC address) may also be used to link the user to the smart card 20a, which increases the level of security by implementing multi factor authentication.

It is also possible that the user authentication is performed by/on the communication device 10 instead of the smart card 20a, or it may be omitted completely, for example, in situations where speed and convenience is more important than security or privacy. In step 102 a query command 204 is generated with the program 12a stored in the data storage 12 of the communication device 10 to request information 206 of a set of stored user attributes 25 stored in the chip card 20a. For example, the query command 204 may be generated to find out what kind of user attributes 25 are stored in the storage unit 22 of the secure wallet 20. In the chip card 20a there may be multiple sets of user attributes 25 stored, belonging to different virtual ID cards, each of which may correspond to an original (real life) ID card (or even to such ID cards which are only issued electronically), and the user needs to pick the virtual ID card or the one or multiple of user attributes 25 he/she intends to use. These multiple sets of user attributes 25 may be managed by one or more applications 28 in the smart card 20a. The program 12a in the communication device 10 may manage the multiple sets of user attributes 25 related to different virtual IDs on the chip card 20a together, or a separate program 12a may be necessary for each set of user attributes 25.

In step 104 the user authentication data 24' (for example the unique PIN 201 and program instance identifier 202) and the query command 204 are transmitted to the smart card 20a that is connected to the communication device 10 via the smart card interface 14 of the communication device 10. The user authentication data 24' and the query command 204 may be transmitted in separate steps as well.

In step 106 the smart card 20a or the secure electronic wallet application 28 verifies the user authentication data 24' by comparing it with the user authentication data 24 stored in the storage unit 22 of the smart card 20a and if the verification fails a rejection response 208 is returned to the communication device 10.

In step 108, in case the user authentication was successful, the smart card 20a collects the information 206 of the set of stored user attributes 25.

In step 110 the information 206 of the set of stored user attributes 25 is returned to the communication device 10 where the program 12a outputs the information 206 on the user interface (such as the touch screen 15) for the user in step 111.

In step 112 user selects the user attributes/attribute properties based on the displayed information 206 of the set of stored user attributes 25 with the program 12a stored in the data storage 12 of the communication device 10 which he/she wants to include in the core content 212 of the special purpose electronic ID card 214.

In step 113 a command 210 identifying the selected user attributes/attribute properties is generated by the program 12a. In step 114 the user authentication data 24' (unique PIN 201 and program instance identifier 202) and the command 210 identifying the selected user attributes/attribute properties are transmitted to the smart card 20a that is connected to the communication device 10 via the smart card interface 14 of the communication device 10. The user authentication data 24' and the command 210 containing the information about the selected user attributes/attribute properties may be transmitted in separate steps as well. Alternatively, the user authentication may be omitted as the user has already been authenticated at the start of the transaction or user authentication may not be required at all.

If user authentication is performed, then in step 116 the smart card 20a verifies the user authentication data 24' by comparing it to the stored user authentication data

24 and if the verification fails (the stored and the received user authentication data 24, 24' do not correspond) a rejection response 208 is returned to the communication device 20a.

Turning to Fig. 3b, in step 118 the smart card 20a application 28 collects the selected user attributes and/or attribute properties identified by the command 210 from its secure storage 22 and generates a dataset 216 therefrom.

In step 120 the smart card 20a may append additional data to the dataset 216 like a time stamp, a transaction ID, the ID or name of the issuer of the original ID card, the identification number of the smart card 20a, which data may be mandatory or beneficial for the eventual identification of the user, which data are either already stored on the smart card 20a, or are received from the communication device 10, or are generated by the smart card 20a. Such additional data are used to generate an appended dataset 216’ by the secure wallet 20. The steps of generating the additional data and the steps of appending the various data to the dataset 216 may follow any order or be carried out in more steps sequentially, as is clear for a person skilled in the art.

In step 122 the smart card 20a signs the dataset 216 or appended dataset 216’, whichever was prepared, using the private key 50a stored in its secure storage unit 22, whereby a core content 212 of the special purpose electronic ID card 214 is generated. As the smart card 20a may store multiple different sets of user attributes

25 there may be multiple private keys 50a stored in the secure storage unit 22 each of which, depending on the configuration of the information on the smart card 20a, may need to be specifically used for signing their related dataset 216. Alternatively, one single private key 50a may be used for signing the dataset 216 irrespective of the fact which set of user attributes 25 it contains.

In step 124 the signed dataset 216 or the signed appended dataset 216' (together: the core content 212 of the special purpose electronic ID card 214) is returned to the communication device 10 via the communication interface 23 of the smart card 20a.

In step 126 the program 12a and /or the communication device 10 may further amend or format the secure core content 212 as requested by technology, regulation, standards or other requirements to turn it into the special purpose electronic ID card 214 which can be used for user identification and sharing the least personal data possible.

In step 127 the special purpose electronic ID card is preferably displayed on the user interface (such as the touch screen 15).

In step 128 the user may define, by choosing a service on the communication device 10, where he/she wants to use the special purpose electronic ID card 214 to present its information.

In step 130 the user sends the special purpose electronic ID card 214 to a selected third party 300 to use it for identification together with the public key certificate 50b’ which has been generated from the public key 50b of the asymmetric cryptography key pair 50. The public key certificate 50b’, if sent together with the special purpose electronic ID card 214, will allow the third party 300 to verify the validity of the special purpose electronic ID card 214. The public key certificate 50b’ is preferably signed by the issuer of the ID card the content of which is included in the special purpose electronic ID card 214.

Fig. 4 illustrates the steps of a second preferred embodiment. The same reference numerals have been used for corresponding steps and entities. It will be appreciated that the order of the steps may differ from the order presented here.

In this process the program 12a running on the communication device 10 has already all the information available about the user attributes 25 stored in the smart card 20. The availability of this information may be the result of storing the information 206 of the set of user attributes 25 previously received in step 110 in the program 12a permanently, or at least for a longer period, to spare synchronizing this information each time before user identification is needed. Alternatively, the information 206 of the set of user attributes 25 may be directly loaded into the program 12a running on the communication device 10 over the air, e.g. by the issuer of the ID card to which the information 206 of the set of user attributes 25 relates to.

As the program 12a already has all the information available to identify the selected user attributes/attribute properties steps 102 to 110 in Fig. 3a are unnecessary.

In step 111 the information 206 is displayed for the user following which, in step 112 the user makes the choice to define the selected user attributes/attribute properties and the command 210 identifying the selected user attributes/attribute properties is generated in step 113 by the program 12a.

In this embodiment all further steps performed by the smart card 20a and the program 12a running on the communication device 10 are the same as described above from step 114 to 130 in Figs. 3a and 3b and are not separately illustrated in Fig. 4.

The following two concrete examples are provided to illustrate the application of the various embodiments disclosed herein.

Example 1 : Buying alcoholic drinks online when age needs to be verified.

This is a scenario when the seller does not need to know anything about the buyer other than making sure that the person who is about to buy the drink is over the legally established age limit. Such a purchase may be performed the following way.

The buyer, the user of the communication device 10 (in the present situation a mobile phone 10a) opens the program 12a running on the mobile phone 10a and selects a national ID card from among multiple stored ID cards. The user wants to see what information the national ID card has, which could be used to have the purchase authorized. To initiate the query command 204 which will return the information 206 of the stored user attributes 25, the user must input a 4-digit PIN code 201 , which is going to be validated in the smart card 20a connected to the communication device 10, which in the present scenario is a SIM size smart card 20a inserted into to second SIM slot of the mobile phone 10a. As the user will want to access information related to the national ID card two factor user authentication will be required by the smart card 20a, using the program instance ID (RegID) 202 of the program 12a running on the communication device 10 as the second factor.

After inputting the PIN 201 the user authentication data 24' (unique PIN 201 and program instance identifier 202) and the query command 204 are transmitted to the smart card 20a that is connected to the communication device 10 via the smart card interface 14 of the communication device 10.

In the smart card the application 28 will verify the user authentication data 24' by comparing it to the stored user authentication data 24 and if the received and stored information correspond then the transaction may continue. Otherwise, the smart card 20a will return an error message to the communication device 10, that user authentication failed, PIN input needs to be repeated. Preferably, after the third consecutive erroneous attempt the application 28 will be permanently blocked and it will need to be reinstalled and re-personalized with the user specific attributes. It is also conceivable that the overall smart card 20a is blocked, and may not even be revived.

Following the successful user authentication, the application 28 will prepare the information 206 of the stored user attributes 25 and will return it to the communication device 10 to have it presented to the user on the display of the communication device 10, which is the mobile phone.

The user does not want to show his actual birth data, only wants to assure the seller that he is older than the legal requirement. For this reason, he does not select the birthday information as the attribute to present but rather will inform the merchant about his age. The age of the user is not stored as attribute on the smart card 20a instead it is a property of the stored attribute (birthday) which can be obtained by subtracting the birthday date of the user from the current day of the operation. The user also wants to inform the seller that the information is originated from the national ID card.

The program 12a running on the communication device 10 prepares the command identifying selected user attributes 210 (e.g. name of the national ID card and its expiration date) and the selected property of a selected user attribute (e.g. age of the user being a property of the birthdate) and sends it together with the user authentication data 24' (unique PIN 201 and program instance identifier 202) to the smart card 20a that is connected via the smart card interface 14 of the communication device 10. The command containing the information of the selected property of the selected user attribute 210 may further contain additional information like current time, message ID, or other complementary information.

In the smart card 20a the application 28 verifies again the user authentication data 24' by comparing it to the stored user authentication data 24 and if the verification is successful, it starts processing the received command. The application 28 calculates the age of the user by subtracting his birthday date from the current data and will use this data, the name of the national ID card and its expiration date to prepare dataset 216.

The application 28 appends a time stamp to the dataset 216and prepares the appended dataset 216”. This time stamp helps proving that the data has been generated quasi real-time and is not a pre-stored information.

The application 28 uses the private key 50a stored in the secure storage 22 of the smart card 20a, to digitally sign the appended dataset 216” and thereby generates the core content 212 of the special purpose electronic ID card 214. As there may be multiple set of user attributes stored in the smart card 20a, related to more than one ID cards, they may all share the same private key 50a or may have their own individual private key 50a’ to be used to prepare the digital signature.

The core content 212 of the special purpose electronic ID card 214 is returned to the communication device 10 and the user is informed that the special purpose electronic ID card 214 has been prepared and is ready to be used. Before usage however, there may be some further technical steps necessary to allow transmission and sharing of the special purpose electronic ID card 214 with external third parties.

When the special purpose electronic ID card 214 is ready to be presented, the user will include this digitalized document and the public key certificate 50b’ related to the private key 50a used for signing the appended dataset 216” in his purchase request which he sends to the merchant. This message contains only the minimum necessary information about the buyer.

Upon receiving the purchase request the merchant first will make sure that the special purpose electronic ID card 214 is valid, its content has not been modified, it is signed by the person who claims to be signatory and that the data it contains is derived from the ID card, referred to in the core content 212. If these controls are successful, and the user can demonstrate that he/she is old enough then the sale is approved and the purchase transaction may proceed.

Example 2: Claiming local student benefits.

Businesses frequently offer services with special conditions only available for local residents. In addition, students may claim further benefits if they can prove that they are studying in the schools of the city or region.

With the new special purpose electronic ID card 214 of the present disclosure, students can easily prove their place of residency and student status without the need to share either their name, exact address or other personal information which may be used for profiling by the businesses, and thus they can avoid unsolicited commercial offers and advertisement.

In this scenario the student has a mobile phone as the communication device 10, but the secure electronic wallet 20 this time is located remotely and connected to a remote server 80 in the form of a chip card 20a.

The physical architecture of the system is transparent for the user, he/she does not recognize the difference between having a smart card 20a inserted into the mobile phone or having the smart card 20a hundreds of kilometers away somewhere in the cloud. The physical transaction flow is obviously more complex in the remote secure wallet 20 configuration as more devices and communication channels are involved in the transaction flow. To avoid the need to describe repeatedly identical technical solutions at each step of the transaction, first a summary description will be provided about the overall transaction flow.

When the user issues a command to the smart card 20a via the program 12a of the communication devices 10, the command is transmitted to the remote server 80 through the communication interface 13 of the communication device 10 and the communication interface 83 of the remote server 80 - both being suitable for remote communication - using the Internet 62 over an electronic communication channel 60. The remote server 80 is connected through a smart card interface 84 with the smart card 20a. In the present configuration the remote server 80 has no other role than to transfer the messages received from the communication device 10 to the smart card 20a and return responses of the smart card 20a to the communication device 10.

The student identification using the special purpose electronic ID card 214 of the present disclosure is performed as follows.

The student has a student card application as the program 12a in her mobile phone. This application is synchronized with the application 28 running in the smart card 20a, as it received related data which is stored in the application 28 when it was loaded into the smart card 20a.

Having all the attributes available in the student card program 12a in the mobile phone, the student does not need to query the smart card 20a instead the student can directly define which attributes she wants to present to the local business. The student selects the ZIP code of her address and the name of the school where she studies which attributes are included in the information 206 of the stored user attributes 25. These attributes 25 prove that she is local and is a student. Using these data, the student satisfies the requirements of being eligible for the benefits, but does not share any sensitive information like her name, address, age, etc.

By choosing these two attributes the student prepares the command identifying the selected user attributes 210.

The user also must authenticate herself and this time her face ID is used for authentication which is controlled locally in her mobile phone. To also have some type of user authentication at the smart card 20 the application instance ID 202 of the student card program 12a is also used as the second factor.

Upon the successful verification of the face ID in the mobile phone, the communication device 20 automatically sends the command identifying the selected user attributes 210 together with the application instance ID 202 to the remote smart card 20a as described above.

When the student card application 28 in the smart card 20a receives the command, it first verifies the application instance ID 202. If the verification is successful, the application prepares the dataset 216 comprising the ZIP code and the school name as defined by the user.

The application 28 appends a time stamp to the dataset 216and prepares the appended dataset 216”.

The application 28 uses its own dedicated private key 50a stored in the secure storage 22 of the smart card 20a, to digitally sign the appended dataset 216” and to thereby prepare the core content 212 of the special purpose electronic ID card 214.

The core content 212 of the special purpose electronic ID card 214 is returned to the communication device 10 as described above.

The student card application 12a links the special purpose electronic ID card 214 with the public key certificate 50b’ containing the public key 50b of the asymmetric cryptography (PKI) key pair 50, which public key certificate 50b’ is digitally signed by the same entity which issued the official student card.

The student card application 12a presents the special purpose electronic ID card 214 which has been generated for this specific transaction, to the user on the display of the mobile phone.

The student appends the special purpose electronic ID card 214 and the linked public key certificate 50b’ to her online service request and claims the benefits she is entitled to, based on the attached electronic document. Various modifications to the above disclosed embodiments will be apparent to a person skilled in the art without departing from the scope of protection determined by the attached claims.

Claims

1. A method for dynamically generating a special purpose electronic ID card containing selected user attributes, the method comprising:

- storing user attributes in a storage unit of a secure electronic wallet;

2. The method according to claim 1 , further comprising transferring the special purpose electronic ID card by the communication device to a remote party over the Internet.

3. The method according to claim 1 , further comprising transferring the special purpose electronic ID card by the communication device through a proximity interface.

4. The method according to claim 1 , further comprising displaying the special purpose electronic ID card on a display of the communication device.

5. The method according to claim 1 , further comprising: storing a PKI certificate generated from a public key of the key pair of asymmetric cryptography in the communication device; and sharing the special purpose electronic ID card with an external party together with the PKI certificate, wherein the PKI certificate is configured to allow verification of the digital signature of the signed dataset contained in the special purpose electronic ID card.

6. The method according to claim 1 , wherein the command identifying at least one property of the at least one attribute contains a relational property or statement which is verified in respect of the identified at least one property of the at least one attribute.

7. The method according to claim 6, wherein the signed dataset contains confirmation of the relational property or statement in response to the relational property or statement being true.

8. The method according to claim 1 , wherein the command received in the secure wallet identifying the at least one attribute stored in the secure wallet is initiated by an external party with whom the special purpose electronic ID card is shared as a proof of certain user attributes.

9. The method according to claim 1 , further comprising including, by the secure electronic wallet, a time stamp in the dataset before signing the dataset.

10. The method according to claim 1 , further comprising storing user authentication data in the electronic storage unit of the secure wallet and requesting user authentication with the secure electronic wallet before generating and signing the dataset in the secure electronic wallet.

11. The method according to claim 1 , further comprising storing attributes related to multiple ID cards in the storage unit of the secure electronic wallet.

12. The method according to claim 11 , further comprising receiving, by the secure electronic wallet, separate commands from separate programs of the communication device for different ID cards identifying at least one attribute or at least one property of the at least one attribute related to the different ID cards.

13. The method according to claim 1 , further comprising generating, signing and transmitting multiple datasets to the communication device, containing data of attributes which are stored separately in the storage unit of the secure electronic wallet.

14. The method according to claim 1 , further comprising generating the asymmetric key pair in the secure electronic wallet.

15. The method according to claim 1 , further comprising storing multiple private keys in the storage unit of the secure electronic wallet, each private key being associated with a set of attributes and signing the dataset with the private key associated with that set of attributes to which the at least one attribute contained in the dataset relates to.

16. The method according to claim 1 , wherein the private key of the asymmetric key pair is generated and loaded into the storage unit of the secure electronic wallet by, or on behalf of an issuer of an original ID card the content of which are stored in the storage unit of the secure electronic wallet.

17. The method according to claim 1 , further comprising storing in the storage unit of the secure electronic wallet data related to an issuer of an original ID card, the attributes of which are stored in the storage unit of the secure electronic wallet, or data related to unique specifics of the original ID card which data are also selectable and may be included in the dataset to be signed.

18. A secure electronic wallet comprising a data storage and a processor configured to perform the method according to any one of claims 1 to 17.