WO2004100030A1 - System and method for electronic administration - Google Patents

System and method for electronic administration Download PDF

Info

Publication number
WO2004100030A1
WO2004100030A1 PCT/HU2004/000046 HU2004000046W WO2004100030A1 WO 2004100030 A1 WO2004100030 A1 WO 2004100030A1 HU 2004000046 W HU2004000046 W HU 2004000046W WO 2004100030 A1 WO2004100030 A1 WO 2004100030A1
Authority
WO
WIPO (PCT)
Prior art keywords
electronic
role
data
certificate
entity
Prior art date
Application number
PCT/HU2004/000046
Other languages
French (fr)
Inventor
Péter ECKHARDT
Károly JÁNOSI
Julianna JÁNOSI
Ilona Kakuk
Tamás RIBÁRSZKY
Tamás SZABÓ
Ferenc Veres
Zoltán PETO
Original Assignee
Eckhardt Peter
Janosi Karoly
Janosi Julianna
Ilona Kakuk
Ribarszky Tamas
Szabo Tamas
Ferenc Veres
Peto Zoltan
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from HU0301239A external-priority patent/HU0301239D0/en
Priority claimed from HU0400788A external-priority patent/HU227168B1/en
Application filed by Eckhardt Peter, Janosi Karoly, Janosi Julianna, Ilona Kakuk, Ribarszky Tamas, Szabo Tamas, Ferenc Veres, Peto Zoltan filed Critical Eckhardt Peter
Publication of WO2004100030A1 publication Critical patent/WO2004100030A1/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31User authentication
    • G06F21/34User authentication involving the use of external additional devices, e.g. dongles or smart cards
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements

Definitions

  • the invention relates to an information system and method for implementing electronic administration.
  • Public key infrastructure has created an opportunity for supplying natural persons with individual electronic identification markers, but the utilization options of these electronic identification markers are extremely limited due to the non-existence of a model embracing the whole society.
  • Applications based on public key infrastructure have so far only focused on issuing and handling of key certificates primarily.
  • attribute certificates have also been elaborated. Any information other than public key can be considered to be an attribute.
  • the attribute certificate organizations (CA: certificate authority) grant rights to the given entities (entities) by issuing attribute certificates.
  • the attribute certificate (AC) is a data structure signed digitally by the certificate authority, which data structure ties certain attribute values to the identification information associated with its owner.
  • the standards dealing with attribute certification are very general, and leave ample room for different interpretations.
  • the definition of attribute certificates had been introduced by the standard No. X.509 (ITU-T Recommendation X.509 (08/1997)) established for the syntax of public key certificates, and the attribute certificates are very useful for many applications (e.g. access control), the authentication of attributes is not so well interpreted as that of public keys.
  • the model according to the invention regards the authentic electronic document as the basis of electronic administration.
  • an electronic document of course does not only mean a file created by a word processor program, but also any information created and forwarded electronically (e.g. text, video, audio, etc. information).
  • the model according to the invention uses the electronic signature key for verifying the authenticity of the electronic documents issued by entities already identified.
  • - Electronic administration can be implemented by a system in which the following are executed in a consistent way: the authentication of participants, the confidential nature of documents handled and stored in the system, the undeniable nature of operations carried out, and the fact that in this system only the authorized participants may carry out operations.
  • a virtual meeting point To create a system enabling any kind of electronic administration between any natural persons, companies with legal entity status, companies without a legal entity status or other entities (hereinafter: entities), there is a need for a virtual meeting point to receive various files, documents, applications, forms, etc.
  • entities entities
  • the various documents can be drawn up and interpreted by automated applications, the necessary activities can be carried out, and then the results of administration may also be displayed here. Consequently, this is the point where the processing logic encounters the documents; and preferably this is the point where the citizen encounters the office, i.e. the state.
  • This virtual meeting point must also store the documents for a shorter or longer period, especially because of the different periods required for the completion of various processes, and it is also a requirement that the handling and storing of the documents should be sufficiently safe, both in the case of private and corporate documents.
  • This virtual point is suitable for the unambiguous electronic identification of entities, and this is the point where entities are 'born' in electronic space, i.e. the electronic citizen is hence created.
  • Administration may be implemented in an automatic way only if the system does not pass the document to be handled to an outside entity independent of the system, but the system proper is able to guarantee a response time. This is only possible if the clerks are internal entities in the system. This does not mean that the activities of the institutional, sectoral and internal information technology systems, databases, and document handling systems are shouldered by the system established, but the fact that the document requiring human intervention lands in the hands of an identified and authorized clerk in a verifiable and undeniable way, and the clerk must carry out the relevant activity within a response time determined by the instructions and code of procedures applying to his/her own job.
  • an authorized clerk pursued an activity in an area covered by his/her authorization e.g. a doctor expert of an insurance company is not necessarily the doctor expert of another insurance company
  • region must be introduced. An authorization covering a certain region must be made controllable and verifiable.
  • each natural person is also an internal entity of the system according to the model established, and therefore this entity has a qualified key certificate and a qualified signature creation device of system level, which preferably satisfies the relevant legal provisions, and in addition, regarding the authenticity of a secure token, it advantageously corresponds to the German SigG, SigV - DIN V66291 standard, which - regarding the interface of the secure token - is identical with the new European standard 'Application Interface Standard for Smart Card Used as Secure Signature Creation Device',
  • each natural person performing administration has (a) qualified role certificate(s), which means authentication by a separate authority (role authentication authority) authorized to evaluate the substance of the role (the definition of authority in this case is not necessarily an office, but an authorization issued by an entity authorized to issue the role to another an entity),
  • the role certificates - in a way authenticated by the relevant authority (region authentication authority) - include the region associated with each role (the definition of a region is not primarily a regional coverage, although it is also suitable for this, but a group of virtual identities that can be determined according to certain conditions, which can be for example a family, a school, a workplace, a profession, a community, etc.)
  • a system for electronic administration, in which data communication among entities having an electronic signature key is executed by means of electronic documents.
  • the system comprises a virtual identity assigned to an entity, which virtual identity has an electronic address, a storage area, and cryptographic data controlling access to the virtual identity, a signature key certificate assigned to the entity, and a role certificate assigned to the entity and authorizing the entity to an administration role by using a signature key corresponding to the key certificate.
  • the invention is a method for electronic administration, according to which data communication among entities having an electronic signature key is implemented by means of electronic documents.
  • the inventive method comprises the steps of assigning a virtual identity to an entity participating in the system, which virtual identity comprises an electronic address, a storage area and cryptographic data controlling access to the virtual identity, assigning a signature key certificate to the entity, and assigning a role certificate to the entity, the role certificate authorizing the entity to an administration role by using a signature key according to the key certificate.
  • each entity has a virtual identity.
  • the virtual identity comprises a secure electronic storage place called eSafe (electronic data safe), to which the following are assigned: an electronic address, and furthermore cryptographic identification data enabling unambiguous identification of entities against the electronic space.
  • eSafe electronic data safe
  • the electronic data safe it is indispensable to have at least one electronic storage place (data drawer or data folder) which is accessible by an electronic virtual address, and through which communication with the electronic data safe can be implemented.
  • This storage place is called incoming mail center according to the invention.
  • At least one qualified key certificate must be assigned to the entity having virtual identity.
  • This qualified key certificate serves as the basis for further role certificates.
  • the certification of a role of a citizen means that a person having a secret key associated with a public key given in the key certificate has the right to the role described in the role certificate, approved and authenticated by the role certificate authority, and fitted with an electronic signature by the issuer of the role certificate. Accordingly, the system according to the invention is of equal strength on the level of qualified electronic signature, i.e. this is the lowest security level below which no operation may take place in the system.
  • region certificates are required, which do not have to appear in the form of independent certificates, because analogously with the interpretation of role certificates, the authentication of a region means that the entity who has a secret key corresponding to the public key signed by the issuer of the given key certificate is entitled to the role shown, approved and authenticated by the role certificate authority, and signed by the issuer of the role certificate, regarding the region approved and authenticated by the region certificate authority.
  • the system according to the invention can be especially advantageous, if it is able to carry out real time authentication, which is not limited exclusively to the authentication of certificates, but the transaction itself is authenticated. (It is advisable to execute the authentication test - if the transaction is subject to payment - prior to the coverage examination necessary for completing the payments.)
  • This authentication testing system service can be defined as a security carrier technology, and it is to be considered as a separate layer in the architecture.
  • Fig. 1 is an overview diagram of a system according to the invention, including authorities, virtual identities and roles in the system,
  • Fig. 2 is a part of a database containing entries about virtual identities
  • Fig. 3 is a schematic diagram of links established with roles between natural and legal entities
  • Fig. 4 shows the schematic structure of a role certificate according to the invention
  • Fig. 5 shows a diagram of the layers in a system according to the invention
  • Fig. 6 shows a schematic structure of a system according to the invention
  • Fig. 7 is a schematic structure of a virtual identity depicted by way of example
  • Fig. 8 is a schematic functional diagram of the eSafe space in the system depicted in Fig. 6, with a governmental portal data supply system known perse.
  • the object of the invention is a role certificate based virtual social model and a system and method built thereupon, which are able to handle on-line activities between arbitrary entities, on the basis of system level metadata of electronic documents related to the administration, i.e. on the basis of the data and processes which assist the guiding of the document.
  • the documents may be in a passive or active, free or archived format, and an on-line payment may be tied thereto.
  • An active document is a document with which a series of transactions to be performed by the electronic clerk between virtual identities is associated on the basis of its metadata, and no such series of transactions is associated with a passive document).
  • Fig. 1 shows the overall diagram of a system according to the invention, with the authorities and virtual identities within the system.
  • Certificate authorities 10 shown in the figure preferably imply a key certificate issuing authority 11, a role certificate authority 12, a region certificate authority 13 and a role certificate issuing authority 14.
  • the key certificate issuing authority 11 comprises a key certificate authenticating organization 11C and a key certificate registration organization 11R.
  • the key certificates issued to entities participating in the system by the key certificate issuing authority 11 represent the basis of the system, because all activities in the system that make an impact on the data handled and stored in the system and on the entities using the system are only possible by a signature with the key according to the key certificate. This is shown by the arrows pointing from the key certificate issuing authority 11 to the other authorities.
  • the role certificate authority 12 comprises a role substance authentication organization 12C and a role type registration organization 12R.
  • the authentication issued by the role certificate authority 12 serves as a basis for the role certificate, which relationship is symbolized by the arrow pointing from the role certificate authority 12 to the role certificate issuing authority 14.
  • the region certificate authority 13 comprises a region authentication organization 13C and a region registration organization 13R.
  • the authentication issued by the region certificate authority 13 also serves as a basis for the role certificate, which relationship is symbolized by the arrow pointing from the region certificate authority 13 to the role certificate issuing authority 14.
  • the role certificate issuing authority 14 comprises a role certificate authenticating organization 14C and a role certificate registration organization 14R.
  • Fig. 1 shows on the basis of the model according to the invention the ability to link the state, the institutes, the companies and the citizens on the basis of different roles.
  • VID ⁇ ... VID n at the nodes, which identities represent a natural person, a legal entity, a company without legal entity status or a different organization.
  • the edges of the graph are the actual ROLEi ... ROLE n roles, representing the relations between the nodes.
  • the role certificates 15 issued according to the invention by the role certificate issuing authority 14 refer to these roles.
  • the role certificates 15 are symbolized in the drawing by dotted line arrows pointing to each role ROLEi ... ROLE n .
  • the roles are primarily administration roles, which ensure authorization to the procedures interpreted in the system, to the electronic documents and/or data in the system.
  • a role is understood in the widest possible sense, and it includes all conceivable activities.
  • the system shown in Fig. 1 handles all entities on an equal level. This means that starting from the head of state, and the head of the government, through public administration, courts, courts of registration, and corporate authorizations (e.g. representation, assignment rights) according to the deed of foundation (statutes, articles of association) to the citizens or other natural persons, all actors along the whole route have a role certificate, which can be checked in the transactions.
  • the role certificates include attributes fitted with a qualified signature. Similarly to the real world, all qualifications and eligibilities (in summary, the role) must come from an authentic source.
  • the role is signed by the certificate authority. This signature takes place when the documents according to the specifications are available either as a hard copy or electronically and when the relevant authority, in this case the role certificate issuing authority 14 makes a statement that the given role certificate can be issued to the relevant person.
  • the authorization controls take place in the issuing phase of role certificates, when there is no time pressure on the administration.
  • the last signatory is the role certificate authority 14 in all cases. In this way it can be ensured that during the transaction, the checking of a single electronic signature in real time (the signature of the role certificate issuer) includes the authentication of all attributes (role, region).
  • VI D - Virtual Identity An abstract identity, which identifies an arbitrarily selected entity of the society in the virtual space. This person can be a natural person or a non-natural person associated with a regulation environment.
  • VHP - Virtual Human Person A natural person who has a Qualified Public Key Certificate (PKC) qualified according to X.509, and an associated token.
  • PDC Public Key Certificate
  • VLP - Virtual Legal Person A non-natural person (institute, legal entity, company without legal entity status, organization etc.) which can be unambiguously identified in a regulation environment, and which is represented through the role certificates directly or indirectly or even through another VLP, in each case by a predefined group of VHPs, but at least one VHP.
  • VIDR - VID Registration An entry associated with the VID, which entry may include attributes relating to an arbitrary number of VIDs (VIDAi, VIDA 2 , ... VIDA n ).
  • VIDA - VID Attribute Describes a certain characteristic of the VID.
  • VIDREF - VID Reference a group of attributes associated with a particular VID (VIDA 1 , VIDA 2 . VIDA 3 , ...), which group jointly and unambiguously identifies the VID.
  • VIDRL - VID Registration List A logic database containing VIDR entries, where each VID is associated with an entry characterizing only this particular VID. The details of the logical structure of a VIDRL are depicted by way of example in Fig. 2.
  • ROLE Role means the right(s) to given activity (activities) that originate(s) from a regulation environment.
  • ROLE_DEF An expression defining a given ROLE.
  • ROLSRC - Role Source The regulation environment associated with the roles, which can be for example statutory provisions, code of practice, contract or list. It is a requirement in this respect that it may only be identified in the system by. an individual series of characters characterising this source only.
  • ROLA - ROLE Attribute Describes a certain specified characteristic of a ROLE.
  • ROLREG - ROLE Registration An entry associated with the ROLE, which may include an attribute relating to an arbitrary number of ROLEs (ROLA ⁇ ROLA 2 , ••• ROLA ⁇ ).
  • ROLREF - ROLE Reference A group (ROLA ⁇ ROLA 2 . ROLA 3 , 7) of those attributes associated with a certain ROLE, which jointly and unambiguously identify the ROLE.
  • ROLRL - ROLE Registration List A logic database containing ROLREG entries, where each role is associated with an individual entry characterising this list only.
  • RGN - VID Region An arbitrary group of VIDs.
  • RGNDEF - VID Region Definition An expression defining a given RGN.
  • RGNA - RGN Attribute Describes a certain characteristic of RGN.
  • RGNREG - Region Registration An entry associated with the RGN, which entry may include an arbitrary number of attributes applying to RGN (RGNA-i, RGNA 2 , ... RGNAn).
  • RGNREF - Region Reference A group of attributes associated with a certain RGN (RGNA-i, RGNA 2 . RGNA 3 , ...), which jointly and unambiguously identify the RGN.
  • RGNRL - RGN Registration List A logic database containing RGNREF entries, where each RGN is associated with an unambiguous entry characterising this RGN only.
  • RCA - Role Certificate Authority A role certificate authentication organization. An organization providing rights through the issuing of role certificates.
  • ROLECERT - Role Certificate A role certificate, i.e. an attribute certificate, by which role(s) and thereby right(s) can be provided to the entities (entities) in the system according to the invention.
  • Fig. 3 shows by way of example a schematic diagram of role relations among the entities participating in the system. Squares depict the virtual identities of non- natural persons in the system, and ellipses present the virtual identities of natural persons. Graph edges among the entities represent the roles according to the description above.
  • VHP 4 can be for example the representative of VLP 2 , and VLP 2 can be a legal entity acting as a legal guardian for VLP-i.
  • VHP 3 is a natural person providing legal representation for VLPi, while VHPi and VHP 2 are authorized to sign jointly (using an authorized signature) on behalf of VLPi. It can be seen that in the system any role between the entities can be mapped and hence the structure according to the invention is suitable for building a set of relations covering the whole society.
  • Fig. 4 shows the formal structure of the ROLECERT, i.e. the role certificate 15 defined above. Parts of the role certificate 15 are the following.
  • ROLECERT : ATTR_CERT_FIELDS OWNER_CERT_REF ROLE_DEF [ROLE_DEF...] GRANTOR RCA SIGN
  • ROLE DEF ROLREF [ROLREF...]
  • ATTR_CERT_FIELDS fields obligatory according to attribute certificate X.509.
  • OWNER_CERT_REF reference to the public key certificate of the role certificate owner.
  • ROLREF reference to a role in an authentic ROLRL, which role identifies the role provided by the role certificate.
  • RGNREF reference to a region in an authentic RGNRL, which is supposed to define the scope of the role(s) to be provided.
  • JOINT_CERT_REF reference to the public key certificate of the entity, with whom the owner of the role certificate is only jointly entitled to the given role.
  • GRANTOR_ROLREF reference to a role in an authentic ROLRL, which identifies the role of the entity who prolongs the role certificate (GRANTOR).
  • GRANTOR_ROLECERT_REF reference to the role certificate of the entity who issues (grants) the role certificate.
  • GRANTOR_SIGN the signature of the entity who prolongs the role certificate.
  • JOINT_GRANTOR_ROLECERT_REF reference to the role certificate of the joint grantor who prolongs the role certificate in case the GRANTOR is only jointly authorized to the role of the GRANTOR_ROLREF with the JOINT_GRANTOR.
  • JOINT_GRANTOR_SIGN the signature of the joint grantor issuing the role certificate, in case the GRANTOR is only jointly entitled with the JOINT 3RANTOR to the role of the GRANTOR_ROLREF.
  • the role certificates can be organized logically into a hierarchy, by which each role certificate will become subordinated to the role certificate identified by GRANTOR_ROLECERT_REF in the given role certificate. Furthermore, the VHP determined by the OWNER_CERT_REF receives the given ROLE_DEF role from the VHP determined by the GRANTOR_ROLECERT_REF - i.e. by the OWNER_CERT_REF therein - and this VHP prolongs this in the role of the GRANTOR_ROLREF, taking responsibility for it (GRANTOR_SIGN).
  • Fig. 5 shows a schematic diagram of the layers in the system according to the invention.
  • the meaning of the abbreviation API is application programming interface.
  • Fig. 6 shows a schematic diagram of the structure of a system according to the invention.
  • clients 34 and 35 are linked via the Internet 29 to their virtual identities VID 34 and VID 35 .
  • the system may include any number of clients.
  • the clients can be natural persons participating in the system.
  • the figure shows the entities (entities) involved in the course of executing the administration (transaction) initiated by the client 34.
  • two offices 30 and 31 are required, and beyond that a fee is also to be paid.
  • Thick arrows indicate the logical path of the transaction.
  • the system furthermore comprises virtual identities VID 3 o and VID 3 ⁇ of the offices 30 and 31.
  • the virtual space including the virtual identities is called eSafe space or eSafe pool.
  • the eSafe space 33 is actually an information technology public utility, i.e. an electronic infrastructure established for enabling authenticated activities among authenticated actors.
  • the electronic document related to the administration is passed from the virtual identity VID 3 to the virtual identity VID 30 .
  • Office 30 detects that an electronic document agent or in other words an electronic clerk is required for the administration, and therefore the agent 36 is actuated in relation to the administration.
  • Virtual identity VID 36 of the agent 36 detects during the transaction that administration by the office 31 is required. Therefore, the transaction goes on to the virtual identity VID 3 ⁇ of the office 31, which detects that another agent is required for administration, and therefore the administration actuates agent 37, and virtual identity VID 3 of the agent 37 passes on to the virtual identity VID 34 of the client 34 the electronic document compiled and finalized during the administration.
  • An eSafe engine 43 shown in Fig. 6 is an application controlling and performing the processes and storage archiving tasks within the eSafe data folders. In the framework of this function, it handles the definitions associated with the data safes, along with the role certificates, controlling and executing the processes within the data safe, handling the data on the level of the document manager system, handling the metadata on a database level, and controlling the disaster proof archiving of the data.
  • the system according to Fig. 6 comprises a security center 42 linked to an authentication center 32, a processing center 41 which enables the tackling of tasks related to electronic administration in addition to controlling and executing the processes participating in the communication, a payment center which enables the payment of fees related to electronic administration, a logistic center 39 and the agents 36 and 37, i.e. a document agent store 38 which comprises the standard document-agent processes.
  • the logistic center 39 controls the movement of document agents and the document containers handled by them, and monitors the performing of related processes among the elements of authentic document space to be described later.
  • the payment center 40 is an application that performs the reporting and warning of electronic payment obligations, followed by actual execution.
  • the payment verification is placed into the document container.
  • a payment obligation arises, which is processed and performed by the payment center 40 either immediately, or prior to the complete finishing of the transaction.
  • the payment relations implemented through the virtual identities are marked by a dotted line.
  • the security center 42 is responsible for identifying the participants and for the authenticity of transactions within the system.
  • the communication within the system according to the invention is preferably implemented by means of intelligent document containers.
  • the document container is a collecting folder, which comprises one or more electronic document and/or other container or containers, and metadata, instructions and procedures required for storing, archiving, handling, administering and authenticating the documents.
  • the processes to be carried out between or within the data folders can be specified by the metadata and processes associated with the document, and their sequence may also be determined.
  • the document container mentioned above participates in the document based communication, and this container includes furthermore the passive metadata attached to the document, the addressing delivery data and the information for the electronic signature, encrypting and security carrier level. This information is required for the independent administration of the document.
  • an intelligent document based active case description database in the system.
  • it comprises the identifier of the matter that can be handled in electronic administration, the forms suitable for electronic administration in the format of a document which can be electronically completed, the implementation instructions of the process, i.e. the list of generated processes which must be passed by the document agent with the document, in association with the administration launched. (These can be the adjustments of the addresses and roles of the data folders to which the document must be forwarded for processing in an appropriate sequence in the course of processing).
  • the database also comprises the completing instructions.
  • the processes attached to the data folder comprise the instructions within the data folder, while the processes attached to the document comprise primarily the instructions between the data folders (e.g. delivery, waiting, copy sending, access, etc. instructions).
  • the system attaches a document agent to the documents, which agent makes sure that the processes attached to the document or assigned in the data folders are executed in time.
  • the communication model according to the invention implements an open system.
  • any communication portal, surface or application handling personal or official data can be developed.
  • Fig. 7 shows a schematic diagram of the structure of an electronic data safe 53 (eSafe) included in a VID virtual identity as an example.
  • the electronic data safe 53 comprises a storage area, in which data folders 52 and an incoming mail center 51 are arranged.
  • the incoming mail center 51 is a special eSafe data folder 52, ensuring the communication between the data safes and the outside world. This can be, for example, the first data folder provided on the basis of 'birth right' to legal and natural persons, which data folder allows the receiving and storing of official letters.
  • Data folders 52 represent a secret personal data storage platform handled by the eSafe system. Each data folder is only accessible by the owner or by the entities and roles defined by the owner, and its content behaves as a 'black box' even for the system administration.
  • Communication with the electronic data safe 53 is enabled by the electronic address 50, which functions as a virtual home address or registered office address.
  • the electronic address corresponds to an e-mail addresses, but it could also be, for example, a
  • the electronic data safe 53 furthermore comprises cryptographic data 54, serving for controlling access to the virtual identity VID.
  • the cryptographic data 54 preferably represent cryptographic attributes, wherein the entity corresponding to the virtual identity VID has a secret identifier key corresponding to the cryptographic attributes and enabling access to the virtual identity VID.
  • the secret identifier key enabling access to the virtual identity VID is the first level of identification, which is necessary for the entity participating in the system to have access to the virtual identity VID.
  • the second level of identification is represented by the fact that the entity corresponding to the virtual identity VID may only carry out in the system an activity having an impact on the data handled and stored in the system and on entities using the system, with a signature using the key that corresponds to the key certificate.
  • the range of activities to be carried out by the given entity in the system is determined by the role according to the role certificate 15, and by the region corresponding to the region certificate.
  • Fig. 8 shows the schematic diagram of the eSafe space 33 in the system corresponding to Fig. 6, with a prior art government data supply system.
  • the government data supply system comprises a government portal 71, a government data center 72 accessible through this portal and government databases 73.
  • the government databases 73 can be, for example, company registration, real estate property registration or vehicle registration databases. So far, these databases have only been accessible isolated from each other, by individual entering. According to the invention, these well known databases are linked to the eSafe space 33 (as an information utility) containing virtual identities corresponding to the entities in the society.
  • the eSafe space 33 symbolizes the electronic world, and the part outside it represents the real world.
  • An entity in the real world can exist and handle transactions in the electronic world if according to the invention a safe storage space is defined for him/her according to the invention, in which storage space he/she can safeguard his/her data by arranging them in an arbitrary structure. Consequently, the entity receives a VID virtual identity with an electronic address and cryptographic attributes, and furthermore a secret identification key corresponding to the cryptographic attributes, by which key the electronic safe can be entered and documents there can be accessed.
  • This entrance can be implemented preferably by asymmetric authorization known per se.
  • the VID virtual identity can be identified in the electronic world by an SI number (if the person is in communication with Social Insurance) taken from or typed into the data folder of the electronic safe, a tax identification number (if the person is in communication with the Tax Office), etc. and/or by means of the entity's electronic home address, the way this is done by real entities in the real world.
  • An entity may have several data folders or data folders in its eSafe, in fact each conventional identifier can be stored in a separate data folder.
  • the entities may enter the virtual world by means of a secret identifier key.
  • the role certificates of a virtual identity determine what roles the entity can have. Consequently, according to the invention, the identification of the entity against the electronic space and the role identification of virtual identity are implemented separately. In this way it is not necessary to identify the entity in each transaction, which enables the implementation of an administration system corresponding to the objectives mentioned in the introduction.
  • the secret key according to a known solution can be stored for example in a multifunctional intelligent card 70, but any other tool in a different form may also be applied if it satisfies the requirements covering a secure token and mentioned in the introduction, for example a mobile phone SIM card.
  • client 60 is represented in the eSafe space 33 with virtual identity VID 6 o, client 61 with virtual identity VID 6 ⁇ , company 62 with virtual identity VID 62 , office 63 by virtual identity VID 6 3, and international identity 64 by virtual identity VID 64 .
  • the virtual identities VID are linked to an authentic document space 76 in the eSafe space 33.
  • the authentic document space 76 is the surface which operates under the supervision of the eSafe engine 43, and it is the platform for delivering the electronic documents 75.
  • the transfer and communication of authentic eSafe documents take place in this document space, and document agents also operate through this document space.
  • the data providers 74 providing data necessary for administration are also linked to the authentic document space 76.
  • Such data suppliers can be, for example, bank data suppliers, commercial data suppliers, data suppliers handling keys and/or accesses, content providers, electronic mailing systems or legal data providers, as shown in the figure.
  • the system can be supplemented with any other necessary data supplier.
  • the data providers 74 may also perform registration tasks.
  • the documents signed electronically may be stored by the entities in their eSafe data folders, and can be sent from there.
  • the eSafe engine 43 is applied.
  • the on-line real time transaction authentication function and the security center 42 is indispensable.
  • the electronic administrators take the applications from the data folders, interpreting and executing them, followed by displaying the result of transaction at the same place. This is controlled by the processing center 41.
  • the processing center 41 For running the system, the following are necessary: standard forms, document standards, a process store, an active case description database, and authenticated administrators (clerks) who are preferably at the government portal 71.
  • role certificates 15 can be stored by the role certificate issuing authority 14, in one of the data folders 52 assigned to the virtual identity VID of the relevant entity, and also on the electronic device containing the secret identifier key. From the aspect of the invention it is significant that the role certificates 15 are available in real time for electronic administration purposes.
  • the system according to the invention is also able to handle the functions of a payment system serving for the purposes of administration.
  • the payment related to administration or transactions may be implemented for example on the basis of e-cash, via so-called ePay-boxes.
  • the electronic safe that is eSafe, comprises a group of data folders that can be organized into a hierarchy. Consequently, we can define an ePay-box data folder, in which the stored value represents the cash therein.
  • the system preferably comprises an eSafe-bank, which performs the following tasks:
  • the tasks of the eSafe bank do not differ from those of any other on-line, realtime accounting bank.
  • the difference is represented by on-line real-time authentication, i.e. that each payment transaction is authenticated prior to payment.
  • the eSafe electronic payment center 40 conducts electronic cash transactions on an on-line, real time basis among the ePay-boxes of eSafe entities (members). It provides an on-line, real time monitoring opportunity in order to make sure that the cash flow is tracked on an ongoing basis. Furthermore, the payment center 40 issues an eSafe purse in relation to the ePay-boxes, i.e. the system level qualified signature creation device e.g. the multifunction chip card is also a multipurpose payment device, on which platform the eSafe system installs an application for handling the low amount payments and also the payments made according to the client's requirements. It also ensures on-line, real time authentication and archiving of payment transactions.
  • the system level qualified signature creation device e.g. the multifunction chip card is also a multipurpose payment device, on which platform the eSafe system installs an application for handling the low amount payments and also the payments made according to the client's requirements. It also ensures on-line, real time authentication and archiving of payment transactions.
  • the tasks of the eSafe electronic payment center 40 differ from those of the already operating payment centers in that it carries out real time authentication and sends an immediate notification about effecting the payment both to the buyer and seller or to the service provider, respectively.
  • the ePay-box is a virtual tool located in the eSafe and suitable for storing electronic cash.
  • the person participating in the system that is the client or the eSafe member, handles the daily cash flow.
  • the system operates as if there were on-site account handling with the client, because the eSafe center sends continuous notifications about the completion of payments. This enables the eSafe members to handle their own cash flow themselves, by means of electronic cash, without the contribution of the bank.
  • the client has an opportunity to track (monitor) his/her cash flow on an ongoing basis.
  • the ePay-boxes are filled up from the client's bank account.
  • the electronic money can be kept not only in ePay-boxes, but also on a chip card serving also as an identification tool, or on an intelligent card 70.
  • This mobile payment tool is called an electronic purse or eSafe purse.
  • the clients may carry out their mobile payments by means of the eSafe purse. Filling up the purse is carried out from the ePay-boxes.
  • the electronic purse function is identical with the already operating other e-purses, and the difference again is represented by the real time transaction authentication.
  • Handling the payment is carried out in the eSafe payment system by means of electronic cash, through the ePay-boxes, in the following way.
  • the handling of the payment is performed by the eSafe electronic payment center. Because the eSafe was defined as a safe storage area which is only accessible to the assigned entity or to those for whom this entity has given authorization, we have a storage area where the valuables can be safeguarded securely. In this way it is possible to keep money there, preferably at least as much as required for ensuring continuous liquidity.
  • a secure channel is established between the actors, which channel is only accessible to the participants involved in this transaction - e.g. buyer, seller, electronic notary, payment center - and this provides security for the actors (participants).
  • the deal abstracts reflecting the buyer's and seller's intentions are collected by an electronic notary.
  • the electronic notary identifies the actors by authentication, and hence their participation in the transaction can be proved undeniably. If the authenticated documents prove that the intentions of the buyer and the seller are identical (the two deal abstracts are the same), the electronic notary allows the buyer to pay.
  • the payment center reduces the buyer's ePay-box with the relevant amount, and increases the seller's ePay-box with the same amount.
  • An immediate notification is sent to both the buyer's and the seller's ePay-boxes about the established payment transaction. This enables the ongoing tracking (monitoring) of payments.
  • the payment documents are registered by the payment center 40, while the documents also covering the commercial part of the transaction are safeguarded in the eSafe, for eventual subsequent investigation or restoration. Because the authentication center 32 associated with the security carrier of the eSafe - the authenticating center acting as the electronic notary - safeguards in an encrypted form the abstracts of documents generated during the transaction, a regulatory inspection is possible any time according to the relevant regulations on the basis of globally individual transaction identifiers if this is necessary, but this can only be done with the consent of the relevant person.
  • the payment document stored at the payment center associated with one transaction, the documents covering the commercial part of the transaction and stored in the eSafe, and the deal abstracts stored in an encrypted way by the electronic notary are identically associated on the basis of the globally individual transaction identifiers.
  • the e-cash necessary for handling the daily cash flow is in the eSafes, which operates the same way as the ePay-box in the case of companies or as the cash kept by natural persons at home. Payments can be launched and crediting can be received by the ePay-box, but only items which are approved by the electronic notary. Not only one, but more entities may have access to a given ePay-box.
  • Several members of a family can be allowed to have access, and it may also be allowed to provide access for several employees in the case of companies, with these employees being authorized to initiate remittances.
  • the system may also be set up in a way that remittance can only be made on the basis of the joint signature of two or more entities.
  • the account of the electronic payment center 40 is handled by the eSafe bank, consequently replenishing during the day is done through this account. Only the so-called electronic cash moves between the ePay-boxes, while the actual money remains on the eSafe bank account of the electronic payment center 40. The amount of electronic cash in the system is identical with the bank account money on the electronic payment center bank account 40.
  • the money amount contained by the ePay-box can be reduced by remitting the electronic cash to the bank account or if the cash in the ePay-box is excessively reduced, it can be replenished from the bank reserves. Thereby it can be achieved that the ePay-box is kept by the relevant person on a level which is just sufficient for handling the daily cash flow.
  • Entities participating in the system i.e. the eSafe members use eSafe purse for handling payments to be made at mobile points of purchase (news stand, greengrocer's, supermarket, when purchasing goods, etc.).
  • the purse is also suitable for low and high amount payments of the clients. Replenishing is carried out from the ePay-box, and if there is too much money in the purse, it can be refunded to the ePay-box.
  • the payment is carried out by the electronic payment center 40 in a way that the relevant amount is taken from one purse and added to the other purse.
  • the payments by purse are also made by real time transaction authentication, and hence when leaving the purse (i.e. for example the chip card) it can be banned immediately, and on the basis of the records kept by the center, the amount of electronic cash stored in the purse can be restored according to the requirement and with the approval of the client.
  • the handling of the risks can be carried out in the following way in the eSafe based payment system.
  • the bank account money on the bank account of the electronic payment center 40 must be identical with the electronic money handled in the ePay-boxes and electronic purses. Checking this and the tracking of the electronic money can be implemented in the system according to the invention, and hence the forgery of the electronic money can be prevented, and the risk of forfeiting money may also be eliminated.
  • the database handling manufacturers do not assume financial guarantee for the stored data within the database handling unit, even within an arbitrary time window. This problem is generally shifted to the scope of responsibilities of the manufacturer of the computer technology platform.
  • the computer technology facilities manufacturer does not assume a responsibility for the delivered memory, consequently the operative memory and the cash units are uncovered.
  • the background stores represent the least problematic area, because there are solutions for providing redundant storage. However, without regular control, doing away with bit errors may not be guaranteed in this case either.
  • Directive 93/1999 EU about the Community framework of electronic signature has a basic importance in the future European application of public key infrastructure (PKI) directly in the field of electronic signature, and indirectly in other areas primarily involving the encrypting of electronic documents.
  • the directive determines uniform principles for the member countries, and defines requirements for authentication service providers issuing qualified certificates, regarding the services which are to be and may be rendered by them, the qualified certificates, the devices which create a signature, and the environment of creating and controlling the signature.
  • the following security carrier technology as an authentication system recommended for the eSafe system corresponds to all European standardization efforts elaborated for applying PKI (public key infrastructure) recently in the field of electronic signature.
  • an authentication policy which corresponds to the non-public qualified certification policy requirements identified in the technical specification ETSI TS 101456 (Policy requirements for certification authorities issuing qualified certificates).
  • the authenticity of actors is preferably based on qualified certificates which correspond to the principles and formats identified in the technical specification ETSI TS 101862 (Qualified Certificate Profile).
  • the central authentication service provider preferably uses reliable systems and products which are protected from external intervention, and ensure the technical and encrypting protection of the processes supported by them, and which meet the safety requirements of the document CEN/ISSS: WS/E-Sign N129 (Security Requirements for Trustworthy Systems Managing Certificates for Electronic Signatures).
  • the information technology system is preferably based on processes and protocols identified in international standards, and uses such cryptographic algorithms with such a parametering which correspond to the European standardization efforts, for example feature among the algorithms approved in the EESSI document Acceptable Cryptographic Algorithms.
  • the users may apply an intelligent card or chip card, which satisfies all security requirements of the CEN/ISSS: WS/E-Sign N136 (Secure Signature- Creation Devices).
  • the digital signature creation environment in the system i.e. the access protected cryptographic resource card readers and chip cards used in charging the card preferably meet the requirements of CEN/ISSS: WS/E-Sign N141 (Security Requirements for Signature Creation Systems).
  • control aspects of digital signature e.g. the card readers, PC software applets and cards preferably correspond to the requirements of CEN/ISSS: WS/E-Sign N140 (Procedures for electronic signature verification).
  • the currently operating system is suitable to provide for the subscribers also through the Internet various public company data, by subsequent accounting for each data package.
  • the companies can be found on the basis of the name, registration number or scope of activities, and the following may also be retrieved about a company: certificate of incorporation, official copy of company records, trade register and balance sheet figures. All this may also be accessible in the given case by an on-line method, for a limited number of users, from the government portal.
  • the operation of the system according to the invention consists of the following steps as an example when requesting corporate information:
  • the user entity enters the eSafe system with its own identifier tool (e.g. intelligent card),
  • the client selects the required case and may have access to the associated case description, and then
  • the client requires from the portal the active administration document associated with the case and the selected subject.
  • the portal immediately sends the document together with its definitions and procedures to the interested party's eSafe incoming mail center, which immediately appears on the 'one stop shopping 1 administration surface.
  • the document compiled in this way is submitted by the system as an outgoing letter to the document agent waiting in the outgoing data folder of the incoming mail center, in a way that it is supplemented by known information, like the client's electronic signature, if this is requested it is encrypted, etc. and the document container is compiled.
  • the container is launched, but because the given operation is subject to payment, when starting out it has to proceed through a payment gate, where the system has the client confirm that he/she has acknowledged the utilization of a paying service. If the type of case requires pre-payment, the payment is done by the agent upon first passing through the gate.
  • the container arrives at the central incoming mail center of the court of registration, where the system recognizes the case on the basis of the case number, and forwards it without storage to the incoming mail center of the company information service.
  • the system examines whether there is an application which automatically implements the requested task. If so, the case is handed to the application, while the agent is waiting for his/her document in a provisional store. If not, the document is sent to the incoming mail center where it is waiting for manual processing.
  • the agent contacts local application with the personal electronic identification data of the applicant.
  • the local application tackles its task outside the eSafe system.
  • the requested data are given in an authentic way with the electronic signature of the approving registration officer and time stamp as well as the electronic stamp of the institutional data folder, and they are given to the courier, i.e. the document agent. Even if the result is obtained by a fully automatic procedure, the proceeding registration officer and clerk electronically sign the stored and issuable information, therefore his/her responsibility is continuing through the application.
  • the agent packs the response into a document container next to or replacing the original, as required by the case or by the client.
  • the document container is returned by the eSafe engine or by the logistic center to the sender.
  • the document starts payment on the basis of the requested data volume, prior to the arrival of the document.
  • the system according to the invention may provide electronic administration and data supply based on public interest and personal as well as protected data.
  • the system according to the invention creates a structure though eSafe data storage by means of which the privately owned data can be handled as well as the verified document exchanged between entities.
  • the eSafe model By means of the eSafe based system, a uniform approach information type social communication model can be set up. In addition to e_government and e_business, the eSafe model also creates the communication foundations of the e_civil sphere. In this way it provides a totally uniform, simple and transparent framework for communication among all the participants of the society. It enables a safe electronic communication among the offices, and among the offices and their clients, in addition to electronic administration, as well as the forwarding of authentically and electronically signed documents. Therefore, practically anyone may participate in a full social level electronic administration provided that he/she has Internet access and an electronic address.
  • the enforcement of constitutional rights, the protection of personal data, and the publicity of public interest data can be ensured according to the data protection statutory provisions, in addition to the protection of ownership rights (real estate property, company ownership, etc.) and the self-disposal rights over the personal data.
  • the model according to the invention reverses the logic of social data handling. It becomes possible to introduce a compulsory data supply to the data owner, in the framework of which the data owned must be made available to the relevant person. The owner, the involved person can be automatically notified in the system about events involving the person, his/her data or changes in the data.

Abstract

The invention is a system and a method for electronic administration, in which data communication among entities having an electronic signature key is executed by means of electronic documents. According to the invention, a virtual identity (VID) is assigned to an entity, which virtual identity (VID) has an electronic address (50), a storage area, and cryptographic data (54) controlling access to the virtual identity (VID), a signature key certificate is assigned to the entity, and a role certificate is assigned to the entity and authorizing the entity to an administration role by using a signature key corresponding to the key certificate.

Description

SYSTEM AND METHOD FOR ELECTRONIC ADMINISTRATION
TECHNICAL FIELD
The invention relates to an information system and method for implementing electronic administration.
BACKGROUND ART
Various models had already been described for creating an information society. Standardization initiatives have already been launched for European models, but most of the approaches only cover one part of social communication and administration.
The known solutions primarily deal with e_govemment and e_business area, and within those fields they aim at the communication between the government and the general public, and between the government and the business community. It is envisaged to handle the public and personal data mostly via the same channel, by the very costly conversion of the already existing databases and applications, so that the simultaneous servicing of a large number of identified users can be ensured through a government portal having a joint entry point.
Systems serving for the implementation of electronic administration and for related personal identification were described for example in US 2003/0145205 A1 and US 2003/0172090 A1.
Implementing these models is very costly, and furthermore in such a model the handling of personal data is very difficult, due to the data protection regulations. For these reasons, expensive and duplicate developed identification concepts using a heterogeneous design and lots of cards and chips were put forward in spite of the EU directive No. 93/1999, the express aim of which is to support the proliferation of multifunctional personal identification means through the application of electronic signatures.
Public key infrastructure (PKI) has created an opportunity for supplying natural persons with individual electronic identification markers, but the utilization options of these electronic identification markers are extremely limited due to the non-existence of a model embracing the whole society. Applications based on public key infrastructure have so far only focused on issuing and handling of key certificates primarily.
So-called attribute certificates have also been elaborated. Any information other than public key can be considered to be an attribute. The attribute certificate organizations (CA: certificate authority) grant rights to the given entities (entities) by issuing attribute certificates. The attribute certificate (AC) is a data structure signed digitally by the certificate authority, which data structure ties certain attribute values to the identification information associated with its owner. The standards dealing with attribute certification are very general, and leave ample room for different interpretations. Although the definition of attribute certificates had been introduced by the standard No. X.509 (ITU-T Recommendation X.509 (08/1997)) established for the syntax of public key certificates, and the attribute certificates are very useful for many applications (e.g. access control), the authentication of attributes is not so well interpreted as that of public keys. In addition, the methods of handling attribute certificates are extremely diverse depending on the application, and therefore the processes handling the attribute certificates are not canonical either; they may not be divided into separate and independent parts. All these factors make it difficult to apply the systems based on attribute certificates for the purposes of the invention.
Systems already existing in relation to electronic administration primarily intend to meet their objectives by building database relations and out of these first of all by a data service appearing on the screen. These systems primarily intend to use the electronic signature key for the identification of entities.
On the contrary, the model according to the invention regards the authentic electronic document as the basis of electronic administration. According to the invention, an electronic document of course does not only mean a file created by a word processor program, but also any information created and forwarded electronically (e.g. text, video, audio, etc. information). The model according to the invention uses the electronic signature key for verifying the authenticity of the electronic documents issued by entities already identified.
DISCLOSURE OF INVENTION
It is an object of the invention to provide a system that enables administrating the most diverse matters of citizens quickly, smoothly, at a low operating cost and automatically, which system covers the whole society, and takes as much as possible into consideration the personal rights and the security requirements, in which system the citizens' self-determination rights over their own data is manifest via the official meeting point of citizens, other entities (entities) and the state.
To make sure that in society, primarily in public administration and also in the business sphere, the foundations of electronic administration are laid, the following factors are indispensable for conducting operations between virtual identities created for electronic administration.
- Electronic administration can be implemented by a system in which the following are executed in a consistent way: the authentication of participants, the confidential nature of documents handled and stored in the system, the undeniable nature of operations carried out, and the fact that in this system only the authorized participants may carry out operations.
- To create a system enabling any kind of electronic administration between any natural persons, companies with legal entity status, companies without a legal entity status or other entities (hereinafter: entities), there is a need for a virtual meeting point to receive various files, documents, applications, forms, etc. When such a virtual meeting point is applied, the various documents can be drawn up and interpreted by automated applications, the necessary activities can be carried out, and then the results of administration may also be displayed here. Consequently, this is the point where the processing logic encounters the documents; and preferably this is the point where the citizen encounters the office, i.e. the state. This virtual meeting point must also store the documents for a shorter or longer period, especially because of the different periods required for the completion of various processes, and it is also a requirement that the handling and storing of the documents should be sufficiently safe, both in the case of private and corporate documents. This virtual point is suitable for the unambiguous electronic identification of entities, and this is the point where entities are 'born' in electronic space, i.e. the electronic citizen is hence created.
- Administration related to electronic documents is handled by clerks authorized to do so. For the appropriate running of the system, it is to be ensured that the entity initiating the administration has a confirmation or receives a guarantee that the qualified clerk authorized to do so handles the case covered by the documents, applications and files, and this clerk may be identified and his/her authority checked if necessary.
Administration may be implemented in an automatic way only if the system does not pass the document to be handled to an outside entity independent of the system, but the system proper is able to guarantee a response time. This is only possible if the clerks are internal entities in the system. This does not mean that the activities of the institutional, sectoral and internal information technology systems, databases, and document handling systems are shouldered by the system established, but the fact that the document requiring human intervention lands in the hands of an identified and authorized clerk in a verifiable and undeniable way, and the clerk must carry out the relevant activity within a response time determined by the instructions and code of procedures applying to his/her own job. In this way, the personal responsibility of the employee (clerk) does not disappear, in fact quite the contrary, because the document, file, reply letter, etc. generated as a result of the administration may proceed only in an authenticated way by means of an identifying tool associated with the particular person.
To make sure that an application, document or file are handled in the given matter in accordance with the relevant legal and other provisions applicable to that area, the procedures themselves must be authenticated.
To determine who is entitled to initiate a given procedure or represent a person, the role in which the relevant natural person may initiate an administration procedure must be made controllable and verifiable.
To determine whether an authorized clerk pursued an activity in an area covered by his/her authorization (e.g. a doctor expert of an insurance company is not necessarily the doctor expert of another insurance company), the notion of region must be introduced. An authorization covering a certain region must be made controllable and verifiable.
Consequently, according to the discussion above, the natural person proper must be made verifiable in association with each administration process, in addition to his/her authorization (role) and the region covered by his/her authorization. This makes it necessary to have access in real time to some complicated authentication chains during each administration procedure, which may not be done during a transaction by conventional public key infrastructure mechanisms. It is to be resolved consequently that confirmation is obtained and an authentic statement is made in real time about the authorization of the initiating and executing entity or of the automated procedure.
■ The required functionality of the system, i.e. active document handling in an environment of arbitrary complexity with several participants may only be implemented, if it is possible to pay in real time the different duties and fees, because in most cases the further activities are subject to these payments.
Consequently, in summary, a system is required in which • each natural person is also an internal entity of the system according to the model established, and therefore this entity has a qualified key certificate and a qualified signature creation device of system level, which preferably satisfies the relevant legal provisions, and in addition, regarding the authenticity of a secure token, it advantageously corresponds to the German SigG, SigV - DIN V66291 standard, which - regarding the interface of the secure token - is identical with the new European standard 'Application Interface Standard for Smart Card Used as Secure Signature Creation Device',
■ each natural person performing administration has (a) qualified role certificate(s), which means authentication by a separate authority (role authentication authority) authorized to evaluate the substance of the role (the definition of authority in this case is not necessarily an office, but an authorization issued by an entity authorized to issue the role to another an entity),
■ it may be authenticated (verified) whether the authorization of the relevant person is valid for the given region, therefore the role certificates - in a way authenticated by the relevant authority (region authentication authority) - include the region associated with each role (the definition of a region is not primarily a regional coverage, although it is also suitable for this, but a group of virtual identities that can be determined according to certain conditions, which can be for example a family, a school, a workplace, a profession, a community, etc.)
- each process (script) falling into the scope of responsibility of the system is authenticated in the system, regardless of the technology applied, e.g. web service, UDDI protocol (Universal Description, Discovery and Integration protocol), and finally
- it implements the conditions of secure real time payment. Thus, according to one aspect of the invention, a system is provided for electronic administration, in which data communication among entities having an electronic signature key is executed by means of electronic documents. The system comprises a virtual identity assigned to an entity, which virtual identity has an electronic address, a storage area, and cryptographic data controlling access to the virtual identity, a signature key certificate assigned to the entity, and a role certificate assigned to the entity and authorizing the entity to an administration role by using a signature key corresponding to the key certificate.
According to a second aspect, the invention is a method for electronic administration, according to which data communication among entities having an electronic signature key is implemented by means of electronic documents. The inventive method comprises the steps of assigning a virtual identity to an entity participating in the system, which virtual identity comprises an electronic address, a storage area and cryptographic data controlling access to the virtual identity, assigning a signature key certificate to the entity, and assigning a role certificate to the entity, the role certificate authorizing the entity to an administration role by using a signature key according to the key certificate.
Preferred embodiments of the invention are defined in the dependent claims.
In the system and method according to the invention, each entity has a virtual identity. By means of the virtual identity, a virtual meeting point which is the most important basic element of the automatic electronic administration is created. The virtual identity comprises a secure electronic storage place called eSafe (electronic data safe), to which the following are assigned: an electronic address, and furthermore cryptographic identification data enabling unambiguous identification of entities against the electronic space. By means of the fact that a virtual identity is associated with each citizen or a other entities, it is ensured that a clerk having an authorization within any office, body, company or organization is now an internal entity of the system, where different roles may be assigned to the virtual identity. A citizen who can be identified by the virtual identifier of his/her own eSafe may have several role certificates, issued to authorize to various social roles.
In the electronic data safe, it is indispensable to have at least one electronic storage place (data drawer or data folder) which is accessible by an electronic virtual address, and through which communication with the electronic data safe can be implemented. This storage place is called incoming mail center according to the invention.
At least one qualified key certificate must be assigned to the entity having virtual identity. This qualified key certificate serves as the basis for further role certificates. The certification of a role of a citizen means that a person having a secret key associated with a public key given in the key certificate has the right to the role described in the role certificate, approved and authenticated by the role certificate authority, and fitted with an electronic signature by the issuer of the role certificate. Accordingly, the system according to the invention is of equal strength on the level of qualified electronic signature, i.e. this is the lowest security level below which no operation may take place in the system.
In order to interpret the roles described in each role certificate for each region, region certificates are required, which do not have to appear in the form of independent certificates, because analogously with the interpretation of role certificates, the authentication of a region means that the entity who has a secret key corresponding to the public key signed by the issuer of the given key certificate is entitled to the role shown, approved and authenticated by the role certificate authority, and signed by the issuer of the role certificate, regarding the region approved and authenticated by the region certificate authority.
The system according to the invention can be especially advantageous, if it is able to carry out real time authentication, which is not limited exclusively to the authentication of certificates, but the transaction itself is authenticated. (It is advisable to execute the authentication test - if the transaction is subject to payment - prior to the coverage examination necessary for completing the payments.) This authentication testing system service can be defined as a security carrier technology, and it is to be considered as a separate layer in the architecture. BRIEF DESCRIPTION OF DRAWINGS
Hereinafter, the invention will be described by means of preferred embodiments as shown in the drawings, where
Fig. 1 is an overview diagram of a system according to the invention, including authorities, virtual identities and roles in the system,
Fig. 2 is a part of a database containing entries about virtual identities,
Fig. 3 is a schematic diagram of links established with roles between natural and legal entities,
Fig. 4 shows the schematic structure of a role certificate according to the invention,
Fig. 5 shows a diagram of the layers in a system according to the invention, Fig. 6 shows a schematic structure of a system according to the invention, Fig. 7 is a schematic structure of a virtual identity depicted by way of example, and
Fig. 8 is a schematic functional diagram of the eSafe space in the system depicted in Fig. 6, with a governmental portal data supply system known perse.
MODES FOR CARRYING OUT THE INVENTION
Hence, the object of the invention is a role certificate based virtual social model and a system and method built thereupon, which are able to handle on-line activities between arbitrary entities, on the basis of system level metadata of electronic documents related to the administration, i.e. on the basis of the data and processes which assist the guiding of the document. The documents may be in a passive or active, free or archived format, and an on-line payment may be tied thereto. (An active document is a document with which a series of transactions to be performed by the electronic clerk between virtual identities is associated on the basis of its metadata, and no such series of transactions is associated with a passive document).
Fig. 1 shows the overall diagram of a system according to the invention, with the authorities and virtual identities within the system. Certificate authorities 10 shown in the figure preferably imply a key certificate issuing authority 11, a role certificate authority 12, a region certificate authority 13 and a role certificate issuing authority 14.
"Authority" according to the invention does not only imply the 'official' authority in the conventional sense, but this definition also includes all natural persons, companies with a legal entity status, companies not having legal entity status or different entities, which have a regulatory role according to the invention.
The key certificate issuing authority 11 comprises a key certificate authenticating organization 11C and a key certificate registration organization 11R. The key certificates issued to entities participating in the system by the key certificate issuing authority 11 represent the basis of the system, because all activities in the system that make an impact on the data handled and stored in the system and on the entities using the system are only possible by a signature with the key according to the key certificate. This is shown by the arrows pointing from the key certificate issuing authority 11 to the other authorities.
The role certificate authority 12 comprises a role substance authentication organization 12C and a role type registration organization 12R. The authentication issued by the role certificate authority 12 serves as a basis for the role certificate, which relationship is symbolized by the arrow pointing from the role certificate authority 12 to the role certificate issuing authority 14.
The region certificate authority 13 comprises a region authentication organization 13C and a region registration organization 13R. The authentication issued by the region certificate authority 13 also serves as a basis for the role certificate, which relationship is symbolized by the arrow pointing from the region certificate authority 13 to the role certificate issuing authority 14.
The role certificate issuing authority 14 comprises a role certificate authenticating organization 14C and a role certificate registration organization 14R.
Fig. 1 shows on the basis of the model according to the invention the ability to link the state, the institutes, the companies and the citizens on the basis of different roles. In the graph shown in the figure, there are virtual identities VIDι ... VIDn at the nodes, which identities represent a natural person, a legal entity, a company without legal entity status or a different organization.
The edges of the graph are the actual ROLEi ... ROLEn roles, representing the relations between the nodes. The role certificates 15 issued according to the invention by the role certificate issuing authority 14 refer to these roles. The role certificates 15 are symbolized in the drawing by dotted line arrows pointing to each role ROLEi ... ROLEn. According to the invention, the roles are primarily administration roles, which ensure authorization to the procedures interpreted in the system, to the electronic documents and/or data in the system. According to the invention, a role is understood in the widest possible sense, and it includes all conceivable activities.
To a certain extent, the system shown in Fig. 1 handles all entities on an equal level. This means that starting from the head of state, and the head of the government, through public administration, courts, courts of registration, and corporate authorizations (e.g. representation, assignment rights) according to the deed of foundation (statutes, articles of association) to the citizens or other natural persons, all actors along the whole route have a role certificate, which can be checked in the transactions. In order to check the role certificates, in the system according to the invention the role certificates include attributes fitted with a qualified signature. Similarly to the real world, all qualifications and eligibilities (in summary, the role) must come from an authentic source. As the last signatory in the process of issuing the role certificate, the role is signed by the certificate authority. This signature takes place when the documents according to the specifications are available either as a hard copy or electronically and when the relevant authority, in this case the role certificate issuing authority 14 makes a statement that the given role certificate can be issued to the relevant person.
For the appropriate functioning of the system, it is indispensable that the authorization controls take place in the issuing phase of role certificates, when there is no time pressure on the administration. When issuing the role certificate, the last signatory is the role certificate authority 14 in all cases. In this way it can be ensured that during the transaction, the checking of a single electronic signature in real time (the signature of the role certificate issuer) includes the authentication of all attributes (role, region).
Preferably, there is at least one default role and region in the system, which are established when creating a virtual identity, and this can be for example a citizenship covering a country.
For describing the system according to the invention, the following definitions are given. VI D - Virtual Identity: An abstract identity, which identifies an arbitrarily selected entity of the society in the virtual space. This person can be a natural person or a non-natural person associated with a regulation environment.
VHP - Virtual Human Person: A natural person who has a Qualified Public Key Certificate (PKC) qualified according to X.509, and an associated token.
VLP - Virtual Legal Person: A non-natural person (institute, legal entity, company without legal entity status, organization etc.) which can be unambiguously identified in a regulation environment, and which is represented through the role certificates directly or indirectly or even through another VLP, in each case by a predefined group of VHPs, but at least one VHP.
VIDR - VID Registration: An entry associated with the VID, which entry may include attributes relating to an arbitrary number of VIDs (VIDAi, VIDA2, ... VIDAn).
VIDA - VID Attribute: Describes a certain characteristic of the VID.
VIDREF - VID Reference: a group of attributes associated with a particular VID (VIDA1, VIDA2. VIDA3, ...), which group jointly and unambiguously identifies the VID.
VIDRL - VID Registration List: A logic database containing VIDR entries, where each VID is associated with an entry characterizing only this particular VID. The details of the logical structure of a VIDRL are depicted by way of example in Fig. 2.
ROLE: Role means the right(s) to given activity (activities) that originate(s) from a regulation environment.
ROLE_DEF: An expression defining a given ROLE.
ROLSRC - Role Source: The regulation environment associated with the roles, which can be for example statutory provisions, code of practice, contract or list. It is a requirement in this respect that it may only be identified in the system by. an individual series of characters characterising this source only.
ROLA - ROLE Attribute: Describes a certain specified characteristic of a ROLE.
ROLREG - ROLE Registration: An entry associated with the ROLE, which may include an attribute relating to an arbitrary number of ROLEs (ROLA^ ROLA2, ••• ROLAπ). ROLREF - ROLE Reference: A group (ROLA^ ROLA2. ROLA3, ...) of those attributes associated with a certain ROLE, which jointly and unambiguously identify the ROLE.
ROLRL - ROLE Registration List: A logic database containing ROLREG entries, where each role is associated with an individual entry characterising this list only.
RGN - VID Region: An arbitrary group of VIDs.
RGNDEF - VID Region Definition: An expression defining a given RGN.
RGNA - RGN Attribute: Describes a certain characteristic of RGN.
RGNREG - Region Registration: An entry associated with the RGN, which entry may include an arbitrary number of attributes applying to RGN (RGNA-i, RGNA2, ... RGNAn).
RGNREF - Region Reference: A group of attributes associated with a certain RGN (RGNA-i, RGNA2. RGNA3, ...), which jointly and unambiguously identify the RGN.
RGNRL - RGN Registration List: A logic database containing RGNREF entries, where each RGN is associated with an unambiguous entry characterising this RGN only.
RCA - Role Certificate Authority: A role certificate authentication organization. An organization providing rights through the issuing of role certificates.
ROLECERT - Role Certificate: A role certificate, i.e. an attribute certificate, by which role(s) and thereby right(s) can be provided to the entities (entities) in the system according to the invention.
Fig. 3 shows by way of example a schematic diagram of role relations among the entities participating in the system. Squares depict the virtual identities of non- natural persons in the system, and ellipses present the virtual identities of natural persons. Graph edges among the entities represent the roles according to the description above. VHP4 can be for example the representative of VLP2, and VLP2 can be a legal entity acting as a legal guardian for VLP-i. VHP3 is a natural person providing legal representation for VLPi, while VHPi and VHP2 are authorized to sign jointly (using an authorized signature) on behalf of VLPi. It can be seen that in the system any role between the entities can be mapped and hence the structure according to the invention is suitable for building a set of relations covering the whole society.
Fig. 4 shows the formal structure of the ROLECERT, i.e. the role certificate 15 defined above. Parts of the role certificate 15 are the following.
ROLECERT := ATTR_CERT_FIELDS OWNER_CERT_REF ROLE_DEF [ROLE_DEF...] GRANTOR RCA SIGN
ROLE DEF := ROLREF [ROLREF...]
[RGNREF...]
[JOINT_CERT_REF...]
GRANTOR GRANTOR_ROLREF GRANTOR_ROLECERT_REF GRANTOR_SIGN [JOINT_GRANTOR ...]
JOINT GRANTOR := JOINT_GRANTOR_ROLECERT_REF JOINT GRANTOR SIGN
where:
ATTR_CERT_FIELDS: fields obligatory according to attribute certificate X.509.
OWNER_CERT_REF: reference to the public key certificate of the role certificate owner.
ROLREF: reference to a role in an authentic ROLRL, which role identifies the role provided by the role certificate.
RGNREF: reference to a region in an authentic RGNRL, which is supposed to define the scope of the role(s) to be provided. JOINT_CERT_REF: reference to the public key certificate of the entity, with whom the owner of the role certificate is only jointly entitled to the given role.
GRANTOR_ROLREF: reference to a role in an authentic ROLRL, which identifies the role of the entity who prolongs the role certificate (GRANTOR).
GRANTOR_ROLECERT_REF: reference to the role certificate of the entity who issues (grants) the role certificate.
GRANTOR_SIGN: the signature of the entity who prolongs the role certificate.
JOINT_GRANTOR_ROLECERT_REF: reference to the role certificate of the joint grantor who prolongs the role certificate in case the GRANTOR is only jointly authorized to the role of the GRANTOR_ROLREF with the JOINT_GRANTOR.
JOINT_GRANTOR_SIGN: the signature of the joint grantor issuing the role certificate, in case the GRANTOR is only jointly entitled with the JOINT 3RANTOR to the role of the GRANTOR_ROLREF.
It follows from all this that the role certificates can be organized logically into a hierarchy, by which each role certificate will become subordinated to the role certificate identified by GRANTOR_ROLECERT_REF in the given role certificate. Furthermore, the VHP determined by the OWNER_CERT_REF receives the given ROLE_DEF role from the VHP determined by the GRANTOR_ROLECERT_REF - i.e. by the OWNER_CERT_REF therein - and this VHP prolongs this in the role of the GRANTOR_ROLREF, taking responsibility for it (GRANTOR_SIGN).
In case the OWNER and/or GRANTOR is only entitled to the given role jointly with someone else (e.g. joint signature), then the JOINT_CERT_REF and the JOINT 3RANTOR, respectively, must be used. The role certificate proper is authenticated by the RCA (RCA_SIGN).
Hence, it can be seen that on the basis of the model shown, all authentic actors of the society can be organized into an authentic hierarchy from any aspect, and they can be electronically authenticated during any transaction involving them.
Fig. 5 shows a schematic diagram of the layers in the system according to the invention. In the figure, the meaning of the abbreviation API is application programming interface. Fig. 6 shows a schematic diagram of the structure of a system according to the invention. In the system, clients 34 and 35 are linked via the Internet 29 to their virtual identities VID34 and VID35. Of course, the system may include any number of clients. For example, the clients can be natural persons participating in the system. The figure shows the entities (entities) involved in the course of executing the administration (transaction) initiated by the client 34. In the case shown, for handling the matters of the client 34, two offices 30 and 31 are required, and beyond that a fee is also to be paid. Thick arrows indicate the logical path of the transaction. The system furthermore comprises virtual identities VID3o and VID3ι of the offices 30 and 31. The virtual space including the virtual identities is called eSafe space or eSafe pool. The eSafe space 33 is actually an information technology public utility, i.e. an electronic infrastructure established for enabling authenticated activities among authenticated actors.
During the administration, the electronic document related to the administration is passed from the virtual identity VID3 to the virtual identity VID30. Office 30 detects that an electronic document agent or in other words an electronic clerk is required for the administration, and therefore the agent 36 is actuated in relation to the administration. Virtual identity VID36 of the agent 36 detects during the transaction that administration by the office 31 is required. Therefore, the transaction goes on to the virtual identity VID3ι of the office 31, which detects that another agent is required for administration, and therefore the administration actuates agent 37, and virtual identity VID3 of the agent 37 passes on to the virtual identity VID34 of the client 34 the electronic document compiled and finalized during the administration.
An eSafe engine 43 shown in Fig. 6 is an application controlling and performing the processes and storage archiving tasks within the eSafe data folders. In the framework of this function, it handles the definitions associated with the data safes, along with the role certificates, controlling and executing the processes within the data safe, handling the data on the level of the document manager system, handling the metadata on a database level, and controlling the disaster proof archiving of the data.
The system according to Fig. 6 comprises a security center 42 linked to an authentication center 32, a processing center 41 which enables the tackling of tasks related to electronic administration in addition to controlling and executing the processes participating in the communication, a payment center which enables the payment of fees related to electronic administration, a logistic center 39 and the agents 36 and 37, i.e. a document agent store 38 which comprises the standard document-agent processes.
The logistic center 39 controls the movement of document agents and the document containers handled by them, and monitors the performing of related processes among the elements of authentic document space to be described later.
The payment center 40 is an application that performs the reporting and warning of electronic payment obligations, followed by actual execution. The payment verification is placed into the document container. When crossing the payment gates in the system, a payment obligation arises, which is processed and performed by the payment center 40 either immediately, or prior to the complete finishing of the transaction. The payment relations implemented through the virtual identities are marked by a dotted line.
The security center 42 is responsible for identifying the participants and for the authenticity of transactions within the system.
The communication within the system according to the invention is preferably implemented by means of intelligent document containers. The document container is a collecting folder, which comprises one or more electronic document and/or other container or containers, and metadata, instructions and procedures required for storing, archiving, handling, administering and authenticating the documents. The processes to be carried out between or within the data folders can be specified by the metadata and processes associated with the document, and their sequence may also be determined.
The document container mentioned above participates in the document based communication, and this container includes furthermore the passive metadata attached to the document, the addressing delivery data and the information for the electronic signature, encrypting and security carrier level. This information is required for the independent administration of the document.
For the implementation of a uniform social administration system, it is necessary to include an intelligent document based active case description database in the system. As an example, it comprises the identifier of the matter that can be handled in electronic administration, the forms suitable for electronic administration in the format of a document which can be electronically completed, the implementation instructions of the process, i.e. the list of generated processes which must be passed by the document agent with the document, in association with the administration launched. (These can be the adjustments of the addresses and roles of the data folders to which the document must be forwarded for processing in an appropriate sequence in the course of processing). Advisably, the database also comprises the completing instructions.
The processes attached to the data folder comprise the instructions within the data folder, while the processes attached to the document comprise primarily the instructions between the data folders (e.g. delivery, waiting, copy sending, access, etc. instructions). As required, the system attaches a document agent to the documents, which agent makes sure that the processes attached to the document or assigned in the data folders are executed in time.
The communication model according to the invention implements an open system. For the public API surfaces shown in Fig. 5, any communication portal, surface or application handling personal or official data can be developed.
In association with the standard document participating in electronic administration or in the definition part of the data folder it can be specified what authorization a clerk must have for processing or receiving for access the relevant matter. The roles may be adjusted by the owner proper for each data folder, and distributed within the scopes of the data folder. Private individuals may acquire roles in a way that on the basis of activities of offices, companies or other data owners, the given role certificate is downloaded to the personalizing tool of the relevant private individual, and it will remain active until an instruction to the contrary is received.
Fig. 7 shows a schematic diagram of the structure of an electronic data safe 53 (eSafe) included in a VID virtual identity as an example. The electronic data safe 53 comprises a storage area, in which data folders 52 and an incoming mail center 51 are arranged. The incoming mail center 51 is a special eSafe data folder 52, ensuring the communication between the data safes and the outside world. This can be, for example, the first data folder provided on the basis of 'birth right' to legal and natural persons, which data folder allows the receiving and storing of official letters. Data folders 52 represent a secret personal data storage platform handled by the eSafe system. Each data folder is only accessible by the owner or by the entities and roles defined by the owner, and its content behaves as a 'black box' even for the system administration. Communication with the electronic data safe 53 is enabled by the electronic address 50, which functions as a virtual home address or registered office address. Preferably, the electronic address corresponds to an e-mail addresses, but it could also be, for example, a given IP address.
The electronic data safe 53 furthermore comprises cryptographic data 54, serving for controlling access to the virtual identity VID. The cryptographic data 54 preferably represent cryptographic attributes, wherein the entity corresponding to the virtual identity VID has a secret identifier key corresponding to the cryptographic attributes and enabling access to the virtual identity VID.
It can be seen that by means of the system according to the invention, we have implemented a two-level identification. The secret identifier key enabling access to the virtual identity VID is the first level of identification, which is necessary for the entity participating in the system to have access to the virtual identity VID. The second level of identification is represented by the fact that the entity corresponding to the virtual identity VID may only carry out in the system an activity having an impact on the data handled and stored in the system and on entities using the system, with a signature using the key that corresponds to the key certificate. In addition, the range of activities to be carried out by the given entity in the system is determined by the role according to the role certificate 15, and by the region corresponding to the region certificate.
Fig. 8 shows the schematic diagram of the eSafe space 33 in the system corresponding to Fig. 6, with a prior art government data supply system.
In a way known per se, the government data supply system comprises a government portal 71, a government data center 72 accessible through this portal and government databases 73. The government databases 73 can be, for example, company registration, real estate property registration or vehicle registration databases. So far, these databases have only been accessible isolated from each other, by individual entering. According to the invention, these well known databases are linked to the eSafe space 33 (as an information utility) containing virtual identities corresponding to the entities in the society.
In Fig. 8, the eSafe space 33 symbolizes the electronic world, and the part outside it represents the real world. An entity in the real world can exist and handle transactions in the electronic world if according to the invention a safe storage space is defined for him/her according to the invention, in which storage space he/she can safeguard his/her data by arranging them in an arbitrary structure. Consequently, the entity receives a VID virtual identity with an electronic address and cryptographic attributes, and furthermore a secret identification key corresponding to the cryptographic attributes, by which key the electronic safe can be entered and documents there can be accessed. This entrance can be implemented preferably by asymmetric authorization known per se. Furthermore, the VID virtual identity can be identified in the electronic world by an SI number (if the person is in communication with Social Insurance) taken from or typed into the data folder of the electronic safe, a tax identification number (if the person is in communication with the Tax Office), etc. and/or by means of the entity's electronic home address, the way this is done by real entities in the real world.
An entity may have several data folders or data folders in its eSafe, in fact each conventional identifier can be stored in a separate data folder.
As already explained, the entities may enter the virtual world by means of a secret identifier key. In the virtual world, the role certificates of a virtual identity determine what roles the entity can have. Consequently, according to the invention, the identification of the entity against the electronic space and the role identification of virtual identity are implemented separately. In this way it is not necessary to identify the entity in each transaction, which enables the implementation of an administration system corresponding to the objectives mentioned in the introduction.
The secret key according to a known solution can be stored for example in a multifunctional intelligent card 70, but any other tool in a different form may also be applied if it satisfies the requirements covering a secure token and mentioned in the introduction, for example a mobile phone SIM card.
As shown in Fig. 8, client 60 is represented in the eSafe space 33 with virtual identity VID6o, client 61 with virtual identity VID6ι, company 62 with virtual identity VID62, office 63 by virtual identity VID63, and international identity 64 by virtual identity VID64.
Through their respective incoming mail centers, the virtual identities VID are linked to an authentic document space 76 in the eSafe space 33. The authentic document space 76 is the surface which operates under the supervision of the eSafe engine 43, and it is the platform for delivering the electronic documents 75. The transfer and communication of authentic eSafe documents (documents started from the eSafe) take place in this document space, and document agents also operate through this document space.
Preferably, the data providers 74 providing data necessary for administration are also linked to the authentic document space 76. Such data suppliers can be, for example, bank data suppliers, commercial data suppliers, data suppliers handling keys and/or accesses, content providers, electronic mailing systems or legal data providers, as shown in the figure. Of course, the system can be supplemented with any other necessary data supplier. In the given case, the data providers 74 may also perform registration tasks.
The documents signed electronically may be stored by the entities in their eSafe data folders, and can be sent from there. For this purpose, the eSafe engine 43 is applied. For authentic communication of authentic documents, the on-line real time transaction authentication function and the security center 42 is indispensable. The electronic administrators take the applications from the data folders, interpreting and executing them, followed by displaying the result of transaction at the same place. This is controlled by the processing center 41. For running the system, the following are necessary: standard forms, document standards, a process store, an active case description database, and authenticated administrators (clerks) who are preferably at the government portal 71.
According to the invention, role certificates 15 can be stored by the role certificate issuing authority 14, in one of the data folders 52 assigned to the virtual identity VID of the relevant entity, and also on the electronic device containing the secret identifier key. From the aspect of the invention it is significant that the role certificates 15 are available in real time for electronic administration purposes.
As it is to be described later on, the system according to the invention is also able to handle the functions of a payment system serving for the purposes of administration.
The payment related to administration or transactions may be implemented for example on the basis of e-cash, via so-called ePay-boxes. The electronic safe, that is eSafe, comprises a group of data folders that can be organized into a hierarchy. Consequently, we can define an ePay-box data folder, in which the stored value represents the cash therein. In this case, the system preferably comprises an eSafe-bank, which performs the following tasks:
- Handles the bank account of clients, eSafe members, and the account of the eSafe electronic payment center.
- It provides on-line real time access to the client's and to the electronic payment centre's bank account so that the replenishing of electronic cash during the day can be carried out flexibly according to the requirements.
- It collects deposits and extends credits.
- According to the clients' instructions, it invests their savings.
- As required, it renders credit card and bank card services.
The tasks of the eSafe bank do not differ from those of any other on-line, realtime accounting bank. The difference is represented by on-line real-time authentication, i.e. that each payment transaction is authenticated prior to payment.
The eSafe electronic payment center 40 referred to above conducts electronic cash transactions on an on-line, real time basis among the ePay-boxes of eSafe entities (members). It provides an on-line, real time monitoring opportunity in order to make sure that the cash flow is tracked on an ongoing basis. Furthermore, the payment center 40 issues an eSafe purse in relation to the ePay-boxes, i.e. the system level qualified signature creation device e.g. the multifunction chip card is also a multipurpose payment device, on which platform the eSafe system installs an application for handling the low amount payments and also the payments made according to the client's requirements. It also ensures on-line, real time authentication and archiving of payment transactions.
The tasks of the eSafe electronic payment center 40 differ from those of the already operating payment centers in that it carries out real time authentication and sends an immediate notification about effecting the payment both to the buyer and seller or to the service provider, respectively.
The ePay-box is a virtual tool located in the eSafe and suitable for storing electronic cash. By means of this tool, the person participating in the system, that is the client or the eSafe member, handles the daily cash flow. The system operates as if there were on-site account handling with the client, because the eSafe center sends continuous notifications about the completion of payments. This enables the eSafe members to handle their own cash flow themselves, by means of electronic cash, without the contribution of the bank. The client has an opportunity to track (monitor) his/her cash flow on an ongoing basis. The ePay-boxes are filled up from the client's bank account.
The electronic money can be kept not only in ePay-boxes, but also on a chip card serving also as an identification tool, or on an intelligent card 70. This mobile payment tool is called an electronic purse or eSafe purse. The clients may carry out their mobile payments by means of the eSafe purse. Filling up the purse is carried out from the ePay-boxes. The electronic purse function is identical with the already operating other e-purses, and the difference again is represented by the real time transaction authentication.
Handling the payment is carried out in the eSafe payment system by means of electronic cash, through the ePay-boxes, in the following way.
The handling of the payment is performed by the eSafe electronic payment center. Because the eSafe was defined as a safe storage area which is only accessible to the assigned entity or to those for whom this entity has given authorization, we have a storage area where the valuables can be safeguarded securely. In this way it is possible to keep money there, preferably at least as much as required for ensuring continuous liquidity.
Prior to payment, a secure channel is established between the actors, which channel is only accessible to the participants involved in this transaction - e.g. buyer, seller, electronic notary, payment center - and this provides security for the actors (participants). The deal abstracts reflecting the buyer's and seller's intentions are collected by an electronic notary. The electronic notary identifies the actors by authentication, and hence their participation in the transaction can be proved undeniably. If the authenticated documents prove that the intentions of the buyer and the seller are identical (the two deal abstracts are the same), the electronic notary allows the buyer to pay. Now the payment center reduces the buyer's ePay-box with the relevant amount, and increases the seller's ePay-box with the same amount. An immediate notification is sent to both the buyer's and the seller's ePay-boxes about the established payment transaction. This enables the ongoing tracking (monitoring) of payments.
The payment documents are registered by the payment center 40, while the documents also covering the commercial part of the transaction are safeguarded in the eSafe, for eventual subsequent investigation or restoration. Because the authentication center 32 associated with the security carrier of the eSafe - the authenticating center acting as the electronic notary - safeguards in an encrypted form the abstracts of documents generated during the transaction, a regulatory inspection is possible any time according to the relevant regulations on the basis of globally individual transaction identifiers if this is necessary, but this can only be done with the consent of the relevant person. The payment document stored at the payment center associated with one transaction, the documents covering the commercial part of the transaction and stored in the eSafe, and the deal abstracts stored in an encrypted way by the electronic notary are identically associated on the basis of the globally individual transaction identifiers.
By establishing an ePay-box located in the eSafe, the complete transparency of cash flow is ensured, along with the ongoing traceability of the liquidity, the observation of changes during the day, and all this is possible with the authentication of the real time transaction by the electronic notary.
Keeping track of the cash flow continuously makes sure that the relevant person immediately spends the electronic cash once it is received, which leads to an acceleration of the turn-around rate of cash and to an upturn in the economy. As a result, unusable 'on the way' money is eliminated. The e-cash necessary for handling the daily cash flow is in the eSafes, which operates the same way as the ePay-box in the case of companies or as the cash kept by natural persons at home. Payments can be launched and crediting can be received by the ePay-box, but only items which are approved by the electronic notary. Not only one, but more entities may have access to a given ePay-box. Several members of a family can be allowed to have access, and it may also be allowed to provide access for several employees in the case of companies, with these employees being authorized to initiate remittances. The system may also be set up in a way that remittance can only be made on the basis of the joint signature of two or more entities.
The account of the electronic payment center 40 is handled by the eSafe bank, consequently replenishing during the day is done through this account. Only the so-called electronic cash moves between the ePay-boxes, while the actual money remains on the eSafe bank account of the electronic payment center 40. The amount of electronic cash in the system is identical with the bank account money on the electronic payment center bank account 40.
The money amount contained by the ePay-box can be reduced by remitting the electronic cash to the bank account or if the cash in the ePay-box is excessively reduced, it can be replenished from the bank reserves. Thereby it can be achieved that the ePay-box is kept by the relevant person on a level which is just sufficient for handling the daily cash flow.
Entities participating in the system, i.e. the eSafe members use eSafe purse for handling payments to be made at mobile points of purchase (news stand, greengrocer's, supermarket, when purchasing goods, etc.). The purse is also suitable for low and high amount payments of the clients. Replenishing is carried out from the ePay-box, and if there is too much money in the purse, it can be refunded to the ePay-box. The payment is carried out by the electronic payment center 40 in a way that the relevant amount is taken from one purse and added to the other purse. The payments by purse are also made by real time transaction authentication, and hence when leaving the purse (i.e. for example the chip card) it can be banned immediately, and on the basis of the records kept by the center, the amount of electronic cash stored in the purse can be restored according to the requirement and with the approval of the client.
The handling of the risks can be carried out in the following way in the eSafe based payment system.
The bank account money on the bank account of the electronic payment center 40 must be identical with the electronic money handled in the ePay-boxes and electronic purses. Checking this and the tracking of the electronic money can be implemented in the system according to the invention, and hence the forgery of the electronic money can be prevented, and the risk of forfeiting money may also be eliminated.
Since the setting up of a secure environment, i.e. a system level security, is established already at the time of launching the transaction - e.g. purchase at a POP, remittance - the information required for tackling the electronic notary's task (who, from whom, when, where, what, how much) is available securely. As a result, the unambiguous identification of the actors becomes possible. In addition, it can also be examined whether the transaction is concluded according to the intention of the actors, which is unambiguously proven by the documents drawn up. Each actor only acquires information necessary for handling the transaction. Therefore, the risk inherent in the system is identical with the risk stemming from the availability of the information technology facilities applied. Therefore the risks become determinable. On this basis, a full (100 %) guarantee can be assumed not only regarding the running of the centers but also in the whole process, even if the Internet is used.
Further requirements imposed on the system are the following:
- Authentic, integrated and undeniable handover and takeover of data and documents provided to and handled in the system, and eliminating unauthorized access to the data and documents provided to and handled in the system. These requirements can be met by an appropriately selected security carrier technology, using prior art solutions.
- In the system, data must be stored without damage for an undefined period of (long) time. It may happen that documents in the system - which have a high value in the given case - only exist in the eSafe, and even there in an encrypted form. This requirement is beyond the scope of the secure carrier technology, therefore its full responsibility is carried by the eSafe service provider.
From this requirement, two ranges of issues arise: the range of issues of archived technological migration, which can be resolved by a migration policy, and the range of issues related to the necessary regular and periodical re-saving of the archived data necessary due to the integration protection, for which a data saving policy must be established.
The database handling manufacturers do not assume financial guarantee for the stored data within the database handling unit, even within an arbitrary time window. This problem is generally shifted to the scope of responsibilities of the manufacturer of the computer technology platform. The computer technology facilities manufacturer does not assume a responsibility for the delivered memory, consequently the operative memory and the cash units are uncovered. The background stores represent the least problematic area, because there are solutions for providing redundant storage. However, without regular control, doing away with bit errors may not be guaranteed in this case either.
In the case of openly stored data, a bit error is unrecognizable. Storing encrypted documents is the biggest challenge for database handlers, because in this case a bit error could result in serious consequences, which in the given case may prevent the opening of the document. This is equivalent to losing the document. - The documents stored for an undefined (long) period in the system must lend themselves to authentication. This requirement is a need applying to the electronic signature of archived documents, which is properly regulated now in the European Union. Because in eSafe, in most of the cases, the duration of storage may not be determined, the service is only feasible by meeting the requirement applying to an archived form of signature.
- Making sure about access to the system and availability falls basically into the scope of the secure carrier technology, but it can be seen that back-up routes and back-up technologies must also be provided for the services, and this falls into the scope of responsibility of the service providers.
In the field of secure eSafe service, business continuity is an important requirement. When planning the setting up of the service, it is an important consideration to select a qualified authentication service provider, who has the most steady background, consequently which is the most solvent undertaking, in order to minimize the risk of liquidation without a legal successor. It is advisable to make sure that an undertaking of similar solvency and stability renders the eSafe service.
Regarding the security carrier technology and the authentication system, the following requirements arise.
Directive 93/1999 EU about the Community framework of electronic signature has a basic importance in the future European application of public key infrastructure (PKI) directly in the field of electronic signature, and indirectly in other areas primarily involving the encrypting of electronic documents. The directive determines uniform principles for the member countries, and defines requirements for authentication service providers issuing qualified certificates, regarding the services which are to be and may be rendered by them, the qualified certificates, the devices which create a signature, and the environment of creating and controlling the signature.
The following security carrier technology as an authentication system recommended for the eSafe system corresponds to all European standardization efforts elaborated for applying PKI (public key infrastructure) recently in the field of electronic signature.
Behind the information technology system, preferably there is an authentication policy, which corresponds to the non-public qualified certification policy requirements identified in the technical specification ETSI TS 101456 (Policy requirements for certification authorities issuing qualified certificates).
In the information technology system, the authenticity of actors is preferably based on qualified certificates which correspond to the principles and formats identified in the technical specification ETSI TS 101862 (Qualified Certificate Profile).
The central authentication service provider preferably uses reliable systems and products which are protected from external intervention, and ensure the technical and encrypting protection of the processes supported by them, and which meet the safety requirements of the document CEN/ISSS: WS/E-Sign N129 (Security Requirements for Trustworthy Systems Managing Certificates for Electronic Signatures).
The information technology system is preferably based on processes and protocols identified in international standards, and uses such cryptographic algorithms with such a parametering which correspond to the European standardization efforts, for example feature among the algorithms approved in the EESSI document Acceptable Cryptographic Algorithms.
Preferably, the users may apply an intelligent card or chip card, which satisfies all security requirements of the CEN/ISSS: WS/E-Sign N136 (Secure Signature- Creation Devices).
The digital signature creation environment in the system, i.e. the access protected cryptographic resource card readers and chip cards used in charging the card preferably meet the requirements of CEN/ISSS: WS/E-Sign N141 (Security Requirements for Signature Creation Systems).
In the system, the control aspects of digital signature, e.g. the card readers, PC software applets and cards preferably correspond to the requirements of CEN/ISSS: WS/E-Sign N140 (Procedures for electronic signature verification).
The requirements of electronic signature in relation to archiving are appropriately satisfied by signature format ES-A (Electronic Signature with Archive validation data) defined in ETSI (European Telecommunication Standards Institute) technical specification TS 101733 Electronic Signature Format.
The following example will show the differences between conventional data supply and the service according to the invention, for example in the case of electronic company registration system implemented by the courts of registration and the company information service based thereon.
The currently operating system is suitable to provide for the subscribers also through the Internet various public company data, by subsequent accounting for each data package. In the system, the companies can be found on the basis of the name, registration number or scope of activities, and the following may also be retrieved about a company: certificate of incorporation, official copy of company records, trade register and balance sheet figures. All this may also be accessible in the given case by an on-line method, for a limited number of users, from the government portal.
The operation of the system according to the invention consists of the following steps as an example when requesting corporate information:
(1) The user entity enters the eSafe system with its own identifier tool (e.g. intelligent card),
(2) a personal electronic administration window appears on the screen,
(3) the client selects e-government administration,
(4) the system contacts the government portal,
(5) it offers to the client the active case descriptions that can be selected on the portal,
(6) the client selects the required case and may have access to the associated case description, and then
(7) the client requires from the portal the active administration document associated with the case and the selected subject.
(8) The portal immediately sends the document together with its definitions and procedures to the interested party's eSafe incoming mail center, which immediately appears on the 'one stop shopping1 administration surface.
(9) The client fills in the form with his/her data,
(10) also specifying the requested additional metadata and the accompanying letter.
(11) The document compiled in this way is submitted by the system as an outgoing letter to the document agent waiting in the outgoing data folder of the incoming mail center, in a way that it is supplemented by known information, like the client's electronic signature, if this is requested it is encrypted, etc. and the document container is compiled. (12) The container is launched, but because the given operation is subject to payment, when starting out it has to proceed through a payment gate, where the system has the client confirm that he/she has acknowledged the utilization of a paying service. If the type of case requires pre-payment, the payment is done by the agent upon first passing through the gate.
(13) The container arrives at the central incoming mail center of the court of registration, where the system recognizes the case on the basis of the case number, and forwards it without storage to the incoming mail center of the company information service.
(14) At that point the system examines whether there is an application which automatically implements the requested task. If so, the case is handed to the application, while the agent is waiting for his/her document in a provisional store. If not, the document is sent to the incoming mail center where it is waiting for manual processing. Let us assume that the system finds an automatic application. The agent contacts local application with the personal electronic identification data of the applicant. The local application tackles its task outside the eSafe system. The requested data are given in an authentic way with the electronic signature of the approving registration officer and time stamp as well as the electronic stamp of the institutional data folder, and they are given to the courier, i.e. the document agent. Even if the result is obtained by a fully automatic procedure, the proceeding registration officer and clerk electronically sign the stored and issuable information, therefore his/her responsibility is continuing through the application.
(15) The agent packs the response into a document container next to or replacing the original, as required by the case or by the client. The document container is returned by the eSafe engine or by the logistic center to the sender.
(16) If the operation only requires subsequent payment, the document starts payment on the basis of the requested data volume, prior to the arrival of the document.
(17) By means of the document returned to the incoming mail center of the sender, the transaction had been carried out automatically during the specified period.
The description above shows a great advantage of the system according to the invention, namely that in the case of passive or active documents containing completing instructions, it becomes possible to use centrally predetermined and authenticated case descriptions to assign electronic agents and clerks for obtaining verifications, data and documents necessary for administration. This enables the actual automatic handling of administration.
It can be seen that by means of the system according to the invention, we have separated data handling based on personal data from data handling in the public interest. The government portal and the central databases are not burdened by tasks related to identification, consequently the portal may perform its primary function, i.e. information supply in the public interest. And, the system according to the invention may provide electronic administration and data supply based on public interest and personal as well as protected data.
The system according to the invention, as a virtual social model based on role certificates, creates a structure though eSafe data storage by means of which the privately owned data can be handled as well as the verified document exchanged between entities.
By means of the eSafe based system, a uniform approach information type social communication model can be set up. In addition to e_government and e_business, the eSafe model also creates the communication foundations of the e_civil sphere. In this way it provides a totally uniform, simple and transparent framework for communication among all the participants of the society. It enables a safe electronic communication among the offices, and among the offices and their clients, in addition to electronic administration, as well as the forwarding of authentically and electronically signed documents. Therefore, practically anyone may participate in a full social level electronic administration provided that he/she has Internet access and an electronic address.
By means of the system according to the invention, the enforcement of constitutional rights, the protection of personal data, and the publicity of public interest data can be ensured according to the data protection statutory provisions, in addition to the protection of ownership rights (real estate property, company ownership, etc.) and the self-disposal rights over the personal data.
The model according to the invention reverses the logic of social data handling. It becomes possible to introduce a compulsory data supply to the data owner, in the framework of which the data owned must be made available to the relevant person. The owner, the involved person can be automatically notified in the system about events involving the person, his/her data or changes in the data.
The invention is of course not restricted to the embodiments shown in details in the description, but different modifications and changes are possible within the scope of determined by the following claims.

Claims

1. A system for electronic administration, in which data communication among entities having an electronic signature key is executed by means of electronic documents, c h a r a c t e r i z e d by comprising a virtual identity (VID) assigned to an entity, which virtual identity (VID) has an electronic address (50), a storage area, and cryptographic data (54) controlling access to the virtual identity (VID), a signature key certificate assigned to the entity, and a role certificate (15) assigned to the entity and authorizing the entity to an administration role (ROLE) by using a signature key corresponding to the key certificate.
2. The system according to claim 1 , characterized in that the authorization to the role (ROLE) according to the role certificate (15) is limited to a given region, preferably by means of a region certificate assigned to the entity.
3. The system according to claim 2, characterized in that the cryptographic data (54) in the virtual identity (VID) are cryptographic attributes, and the entity corresponding to the virtual identity (VID) has a secret identifier key corresponding to the cryptographic attributes, which key enables access to the virtual identity (VID).
4. The system according to claim 3, characterized in that the storage area comprises data folders (52) storing data for electronic administration, one of these data folders (52) being an incoming mail center (51) data folder allowing communication with the storage area and being accessible on the electronic address (50).
5. The system according to claim 4, characterized by comprising a key certificate issuing authority (11), a role certificate authority (12) and a region certificate authority (13), and the role certificate (15) assigned to the entity is issued on the basis of a key certificate, a role authentication and a region authentication issued by these authorities, respectively.
6. The system according to claim 5, characterized by comprising an eSafe space (33) in which the virtual identities (VID) are arranged, and which eSafe space (33) comprises an authentic document space (76) enabling the forwarding of electronic documents (75).
7. The system according to claim 6, characterized by comprising an eSafe engine (43) handling communication and administration tasks within the storage areas and between the virtual identities (VID), a security center (42) linked to an authentication center (32), a processing center (41) handling communication tasks, a payment center (40) enabling the payment of fees related to electronic administration, a document agent store (38) containing electronic agents (36, 37) and a logistic center (39) controlling the movement of electronic agents (36, 37) and the movement of document containers forwarded by the electronic agents (36, 37).
8. The system according to claim 7, characterized in that data providers (74) supplying data required for electronic administration are linked to the eSafe space (33).
9. The system according to claim 8, characterized in that one of the electronic data folders (52) in the storage area is formed as an ePay-box storing electronic money.
10. The system according to claim 1, characterized in that the entities are natural persons, legal entities, companies not having a legal entity status, offices, states and/or international legal entities.
11. A method for electronic administration, according to which data communication among entities having an electronic signature key is implemented by means of electronic documents, c h a r a c t e r i z e d by comprising the steps of assigning a virtual identity (VID) to an entity participating in the system, which virtual identity (VID) comprises an electronic address (50), a storage area and cryptographic data (54) controlling access to the virtual identity (VID), assigning a signature key certificate to the entity, and assigning a role certificate (15) to the entity, the role certificate (15) authorizing the entity to an administration role (ROLE) by using a signature key according to the key certificate.
12. The method according to claim 11 , characterized in that the authorization to the role (ROLE) according to the role certificate (15) is limited to a given region, preferably by means of a region certificate assigned to the entity.
13. The method according to claim 12, characterized in that the cryptographic data (54) in the virtual identity (VID) are cryptographic attributes, and the entity corresponding to the virtual identity (VID) is supplied with a secret identifier key corresponding to the cryptographic attributes, which key enables access to the virtual identity (VID).
14. The method according to claim 13, characterized in that the storage area comprises data folders (52) storing data for electronic administration, one of these data folders (52) being an incoming mail center (51) data folder allowing communication with the storage area and being accessible on the electronic address (50).
15. The method according to claim 14, characterized in that a key certificate issuing authority (11), a role certificate authority (12) and a region certificate authority (13) are used, and on the basis of a key certificate, a role authentication and a region authentication issued by these authorities, respectively, a role certificate assigned to the entity is issued by a role certificate issuing authority (14).
16. The method according to claim 15, characterized by applying an eSafe space (33) in which the virtual identities (VID) are arranged, and which eSafe space (33) comprises an authentic document space (76) enabling the forwarding of electronic documents (75).
17. The method according to claim 16, characterized by applying an eSafe engine (43) handling communication and administration tasks within the storage areas and between the virtual identities (VID), a security center (42) linked to an authentication center (32), a processing center (41) handling communication tasks, a payment center (40) enabling the payment of fees related to electronic administration, a document agent store (38) containing electronic agents (36, 37) and a logistic center (39) controlling the movement of electronic agents (36, 37) and the movement of document containers forwarded by the electronic agents (36, 37).
18. The method according to claim 17, characterized in that data providers (74) supplying data required for electronic administration are linked to the eSafe space (33).
19. The method according to claim 18, characterized in that one of the electronic data folders (52) in the storage area is formed as an ePay-box storing electronic money.
20. The method according to claim 10, characterized in that the entities are natural persons, legal entities, companies not having a legal entity status, offices, states and/or international legal entities.
PCT/HU2004/000046 2003-05-07 2004-05-06 System and method for electronic administration WO2004100030A1 (en)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
HU0301239A HU0301239D0 (en) 2003-05-07 2003-05-07 Informational social model and system based on virtual model of society
HUP0301239 2003-05-07
HUP0400788 2004-04-14
HU0400788A HU227168B1 (en) 2004-04-14 2004-04-14 System and method for electronic administration

Publications (1)

Publication Number Publication Date
WO2004100030A1 true WO2004100030A1 (en) 2004-11-18

Family

ID=89982125

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/HU2004/000046 WO2004100030A1 (en) 2003-05-07 2004-05-06 System and method for electronic administration

Country Status (1)

Country Link
WO (1) WO2004100030A1 (en)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000057318A1 (en) * 1999-03-18 2000-09-28 Rdm Corporation Method and system for processing electronic documents
WO2002073341A2 (en) * 2001-03-07 2002-09-19 Diebold, Incorporated Automated transaction machine digital signature system and method
WO2003021405A2 (en) * 2001-09-03 2003-03-13 Trusted Hub Ltd Authentication of electronic documents

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000057318A1 (en) * 1999-03-18 2000-09-28 Rdm Corporation Method and system for processing electronic documents
WO2002073341A2 (en) * 2001-03-07 2002-09-19 Diebold, Incorporated Automated transaction machine digital signature system and method
WO2003021405A2 (en) * 2001-09-03 2003-03-13 Trusted Hub Ltd Authentication of electronic documents

Similar Documents

Publication Publication Date Title
US11868998B2 (en) System and method for tracking of provenance and flows of goods, services, and payments in responsible supply chains
Guerar et al. A fraud-resilient blockchain-based solution for invoice financing
US20040158723A1 (en) Methods for providing high-integrity enrollments into biometric authentication databases
US6105010A (en) Biometric certifying authorities
CN111164629A (en) Methods, apparatus, and computer-readable media for compliance-aware tokenization and control of asset value
CN108648056A (en) A kind of house lease contract processing method and system based on block chain
US20070033139A1 (en) Credit applicant and user authentication solution
US20030115148A1 (en) Method and apparatus for processing a secure transaction
US20030074315A1 (en) System and apparatus for remotely printing certified documents
US20060161435A1 (en) System and method for identity verification and management
JP2003521754A (en) System, method and product for e-commerce interface with government agencies
CA2260533A1 (en) Method and apparatus for electronic commerce
KR20030019466A (en) Method and system of securely collecting, storing, and transmitting information
JP2002245243A (en) Private and secure financial transaction system and method
EA002175B1 (en) Authentication card system
CA2464410A1 (en) System and method for secure data and funds transfer
CA2675854A1 (en) Secure money transfer systems and methods using biometric keys associated therewith
KR20190107601A (en) Method and system for the generation of user-initiated federated identities
CN114897596A (en) Letter service platform and electronic equipment
KR100745446B1 (en) A method and service for the authentication of a public key certificate by means of quality characteristics
KR20190140869A (en) Method, system and non-transitory computer-readable recording medium for supporting securities short sale
US20210185036A1 (en) Secure authentication system
WO2004100030A1 (en) System and method for electronic administration
US20200104228A1 (en) Asynchronous self-proving transactions
Alliance Using smart cards for secure physical access

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DPEN Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed from 20040101)
122 Ep: pct application non-entry in european phase