WO2023233658A1 - ワークフロー制御方法、ワークフロー制御プログラムおよび情報処理装置 - Google Patents

ワークフロー制御方法、ワークフロー制御プログラムおよび情報処理装置 Download PDF

Info

Publication number
WO2023233658A1
WO2023233658A1 PCT/JP2022/022645 JP2022022645W WO2023233658A1 WO 2023233658 A1 WO2023233658 A1 WO 2023233658A1 JP 2022022645 W JP2022022645 W JP 2022022645W WO 2023233658 A1 WO2023233658 A1 WO 2023233658A1
Authority
WO
WIPO (PCT)
Prior art keywords
information
authentication
data
document
signature
Prior art date
Application number
PCT/JP2022/022645
Other languages
English (en)
French (fr)
Inventor
宏一 鉾之原
Original Assignee
富士通株式会社
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
Application filed by 富士通株式会社 filed Critical 富士通株式会社
Priority to PCT/JP2022/022645 priority Critical patent/WO2023233658A1/ja
Publication of WO2023233658A1 publication Critical patent/WO2023233658A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures

Definitions

  • the present invention relates to a workflow control method, a workflow control program, and an information processing device.
  • a workflow system manages a workflow that indicates the order of a series of procedures performed by multiple users. For example, a workflow system supports approval procedures by multiple users by requesting users to approve data such as digitized documents according to a predetermined approval route and accepting user approvals. Data approved by a user may be given an electronic signature of the user.
  • the present invention aims to suppress the provision of invalid signatures.
  • a workflow control method controls a workflow that involves signing data.
  • the computer detects that data has been registered, it adds requirement information regarding the authentication required of the signer when signing the data to the workflow definition information included in the data, and signs the data according to the definition information.
  • the signer is requested to authenticate according to the requirement information added to the definition information.
  • a workflow control program is provided. Further, in one aspect, an information processing device including a storage section and a processing section is provided.
  • FIG. 1 is a diagram illustrating an information processing device according to a first embodiment.
  • FIG. 3 is a diagram illustrating an example of an information processing system according to a second embodiment.
  • FIG. 3 is a diagram illustrating an example of hardware of a control server.
  • FIG. 3 is a diagram illustrating a functional example of a control server.
  • FIG. 3 is a diagram illustrating an example of a workflow for a document. It is a figure which shows the example of a process of a control server.
  • FIG. 3 is a diagram showing an example of a data structure of a document. It is a figure showing an example of generation of claim information.
  • FIG. 3 is a diagram illustrating an example (part 1) of processing based on claim information.
  • FIG. 1 is a diagram illustrating an information processing device according to a first embodiment.
  • FIG. 3 is a diagram illustrating an example of an information processing system according to a second embodiment.
  • FIG. 3 is a diagram illustrating an example of hardware of a control
  • FIG. 7 is a diagram showing an example of processing based on claim information (Part 2). It is a figure which shows the example (part 3) of a process based on claim information.
  • FIG. 3 is a diagram showing an example of verifying claim information.
  • FIG. 3 is a diagram illustrating an example of an abstract definition rule.
  • FIG. 6 is a diagram illustrating an example of adding a TaaS signature according to a verification result of claim information.
  • FIG. 3 is a diagram illustrating an example of processing according to a verification result of a TaaS signature.
  • FIG. 3 is a diagram illustrating a display example of a verification result of a TaaS signature.
  • FIG. 7 is a diagram illustrating a display example of a message corresponding to complaint information.
  • FIG. 3 is a diagram showing an example of a document display screen.
  • 3 is a flowchart illustrating an example of transmitting a document with a TaaS signature.
  • 12 is a flowchart illustrating an example of receiving a document with a TaaS signature.
  • FIG. 3 is a diagram showing an example of an authentication policy table.
  • FIG. 1 is a diagram illustrating an information processing apparatus according to a first embodiment.
  • the information processing device 10 controls a workflow that involves signing data.
  • the storage unit 11 may be a volatile storage device such as a RAM (Random Access Memory), or a nonvolatile storage device such as an HDD (Hard Disk Drive) or flash memory.
  • the processing unit 12 may include a CPU (Central Processing Unit), a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), and the like.
  • the processing unit 12 may be a processor that executes a program.
  • a "processor” may also include a set of multiple processors (multiprocessor).
  • the information processing device 10 is connected to terminal devices 20, 20a, and 20b via a network.
  • the terminal devices 20, 20a, and 20b are used by users A, B, and C, respectively. Users A, B, and C can operate the terminal devices 20, 20a, and 20b, respectively, to sign data forwarded in the workflow.
  • the data is, for example, data such as a document that requires approval from multiple users.
  • the signature on the data can be performed by at least one of adding an image of a handwritten signature or a stamp image of the user to the data, or adding an electronic signature of the user to the data.
  • the processing unit 12 detects that the data 30 targeted for the workflow has been registered.
  • the data 30 may be registered in a storage accessible from the information processing device 10 via a network, or may be registered in the storage unit 11.
  • the data 30 includes workflow definition information 31.
  • the definition information 31 has information indicating the order of forwarding destinations of the data 30.
  • the definition information 31 is held in the data 30 as meta information separate from the data body, such as the main text of a document that is viewed or edited by the user, for example.
  • the definition information 31 may be information indicating a plurality of signature frames to which a handwritten signature, an image of a seal stamp, or the like is added as the signer's signature.
  • the order in which the frames are written in the document corresponds to the order in which the workflow is forwarded.
  • the definition information 31 indicates that the data 30 is to be forwarded to users A, B, and C in this order.
  • the processing unit 12 When the processing unit 12 detects that the data 30 has been registered, it adds requirement information 32 regarding the authentication required of the signer when signing the data 30 to the definition information 31. For example, the processing unit 12 adds requirement information 32 including authentication requirement L1 for user A, authentication requirement L2 for user B, and authentication requirement L3 for user C to the definition information 31.
  • the data 30a is obtained by adding requirement information 32 to the definition information 31 of the data 30.
  • the definition information 31 only contains information such as the job title of each user who is the forwarding destination, and does not contain information that identifies each individual user. You don't have to.
  • the information for identifying each user may be added to the definition information 31 after the requirement information 32 is set.
  • the authentication requirements may be, for example, the authentication level defined by NIST (National Institute of Standards and Technology) SP800-63 AAL (Authenticator Assurance Level).
  • the authentication requirements may be an authentication method using FIDO2 (Fast IDentity Online 2) or MFA (Multi-Factor Authentication) that supports AAL.
  • FIDO is a registered trademark.
  • the authentication requirement may be an authentication level such as AAL1 (single-factor authentication), AAL2 (software-based multi-factor authentication), or AAL3 (multi-factor authentication including authentication using hardware).
  • authentication requirements include a combination of ID (IDentifier)/password authentication and biometric authentication using a terminal device (equivalent to AAL2), or a combination of ID/password authentication and authentication using a predetermined hardware authentication device (equivalent to AAL3).
  • An example of a hardware authentication device used for authentication equivalent to AAL3 is YubiKey (registered trademark).
  • the authentication requirements can be said to be the strength of authentication, that is, the requirements for authentication strength.
  • Authentication strength is the level of ability to confirm identity. The higher the authentication strength, the higher the ability to confirm identity. For example, in terms of AAL authentication levels, the larger the number at the end, such as AAL1, AAL2, and AAL3, the higher the authentication strength.
  • the processing unit 12 can determine authentication requirements for the user, that is, the signer, according to at least one of the attributes of the data 30 and the attributes of the user signing the signature.
  • the attributes of the data 30 may be determined depending on the claimant and the contents of documents such as contracts and applications included in the data 30.
  • the attributes of a user may be determined according to the department to which the user belongs in the organization, the position of the user, and the like.
  • Authentication requirements depending on at least one of the attributes of the data 30 and the attributes of the user signing the signature may be determined by a policy within the organization to which users A, B, and C belong, or by a policy or law agreed between the organizations.
  • the storage unit 11 may store in advance information indicating authentication requirements according to at least one of the attributes of the data 30 and the attributes of the user signing the signature, as determined by the policy, law, or the like. In that case, the processing unit 12 can add the requirement information 32 to the definition information 31 based on the information stored in the storage unit 11.
  • the processing unit 12 controls the workflow for the data 30a.
  • the processing unit 12 requests signatures from users A, B, and C, who are signers, in this order, based on the definition information 31 included in the data 30a.
  • a request to add a signature may be made, for example, by sending an e-mail to the e-mail address of the user in question, or by other methods such as sending a message on a message application used by the user in question. It's okay to be hurt.
  • Each user operates the terminal device that he or she uses to check the contents of the data 30a, and when approving the data 30a, adds his or her own signature to the data 30a. When the corresponding user's signature is added to the data 30a, the processing unit 12 requests the next user to add a signature.
  • the processing unit 12 When requesting the signer to add a signature to data according to the definition information 31, the processing unit 12 requests the signer to perform authentication according to the requirement information 32 added to the definition information 31. For example, based on the requirement information 32, the processing unit 12 requests the user A to authenticate according to the authentication requirement L1. More specifically, the processing unit 12 may control the data 30a so that the signature of the user A can be added to the data 30a after the user A has been authenticated according to the authentication requirement L1. In one example, the processing unit 12 causes the terminal device 20 to display a screen prompting the user A to authenticate according to the authentication requirement L1, and after the user A satisfies the authentication requirement L1 and is authenticated according to the screen, the data 30a is viewed. Alternatively, a screen for editing may be displayed on the terminal device 20.
  • the processing unit 12 records the authentication method performed by the user A when the signature is added to the data 30a in the storage unit 11 as an authentication log, and the processing unit 12 records the authentication method performed by the user A when the signature is added to the data 30a in the storage unit 11. It may be possible to verify whether or not the authentication has been performed after the fact. For example, after the user A's signature is added to the data 30a, the processing unit 12 may verify whether the data 30a was signed by a valid user A in order to verify the validity of the data 30a. .
  • the processing unit 12 determines, based on the authentication log stored in the storage unit 11 and the requirement information 32 included in the data 30a, that the user A performs authentication that satisfies the authentication requirements L1 defined by the requirement information 32. It is possible to verify whether this has been done or not. If user A is not authenticated to satisfy the authentication requirement L1, the reliability of the user's signature attached to the data 30a decreases, and thus the data 30a may be treated as fraudulent data.
  • the processing unit 12 requests user B to authenticate according to the authentication requirement L2 based on the requirement information 32. Further, based on the requirement information 32, the processing unit 12 requests the user C to authenticate according to the authentication requirement L3.
  • the information processing device 10 when it is detected that data has been registered, requirement information regarding the authentication required of the signer when signing the data is added to the definition information of the workflow included in the data. be done.
  • the signer is requested to perform authentication according to the requirement information added to the definition information.
  • the information processing device 10 can suppress the addition of invalid signatures.
  • requirements regarding the authentication of a signer who signs data may be determined according to internal or inter-organizational policies, laws, and the like.
  • the signer can only be authenticated using a uniform authentication method, there is a possibility that a signature made without sufficient verification of the signer's identity, that is, an invalid signature, may be added to the data.
  • an invalid signature There is sex.
  • the information processing device 10 can appropriately identify the requirements regarding the authentication of each signer for the relevant data from the requirement information, and Each signer can be required to authenticate according to the following. Therefore, the information processing device 10 can improve the reliability of verifying the identity of the person signing the data. As a result, the information processing device 10 can suppress the provision of invalid signatures that violate requirements such as policies and laws. Furthermore, the information processing device 10 can improve the reliability of data handled in workflows executed within or between organizations.
  • FIG. 2 is a diagram illustrating an example of an information processing system according to the second embodiment.
  • the information processing system of the second embodiment includes a control server 100, client devices 200, 200a, 300, and 300a, and a cloud system 400.
  • Control server 100 and cloud system 400 are connected to network 40.
  • Network 40 is, for example, the Internet.
  • the cloud system 400 is an information processing system that provides cloud services via the network 40.
  • the cloud system 400 includes a plurality of physical machines and storages, and provides resources of the physical machines and storages to client computers via the network 40.
  • cloud services executed by cloud system 400 include cloud-based storage services.
  • the client devices 200 and 200a are client computers owned by organization X.
  • Organization X is, for example, a company.
  • Client devices 200 and 200a are used by users belonging to organization X.
  • Client devices 200 and 200a are connected to a network 50.
  • the network 50 is a LAN (Local Area Network) installed within the organization X.
  • Network 50 is connected to network 40.
  • a user belonging to organization X operates the client device 200, 200a to use the cloud service provided by the cloud system 400.
  • the client devices 300 and 300a are client computers owned by organization Y.
  • Organization Y is a different company from organization X, for example.
  • Client devices 300 and 300a are used by users belonging to organization Y.
  • Client devices 300 and 300a are connected to network 60.
  • Network 60 is a LAN installed within organization Y.
  • Network 60 is connected to network 40 .
  • a user belonging to organization Y operates the client devices 300, 300a to use the cloud service provided by the cloud system 400.
  • the control server 100 is a server computer that controls a workflow (WF) for approving electronic documents across multiple organizations using the cloud system 400.
  • An electronic document is simply called a document.
  • An electronic document may also be referred to as document data.
  • An image of the user's seal and the user's electronic signature are added to the document approved by the user. Instead of the image of the user's seal, an image of the user's handwritten signature may be used.
  • the assignment and verification of electronic signatures is realized using a pair of a private key and a public key based on public key infrastructure (PKI).
  • PKI public key infrastructure
  • the control server 100 is an example of the information processing device 10 of the first embodiment.
  • control server 100 provides a function that supports approval procedures across organizations while making it possible to verify the reliability of documents.
  • a service that supports ensuring data reliability is sometimes called TaaS (Trust as a Service).
  • the control server 100 is an example of the information processing device 10 of the first embodiment.
  • control server 100 and the cloud system 400 function as a web server.
  • client devices 200, 200a, 300, and 300a function as web browsers.
  • users of the client devices 200, 200a, 300, and 300a can use a GUI (Graphical User Interface) provided by a Web server executed by the control server 100 or the cloud system 400 by operating a Web browser.
  • GUI Graphic User Interface
  • the user can use the GUI to input to the control server 100 that the user approves the WF forwarded to him/her, input other information regarding the WF, and the like.
  • FIG. 3 is a diagram showing an example of hardware of the control server.
  • the control server 100 includes a CPU 101, a RAM 102, an HDD 103, a GPU (Graphics Processing Unit) 104, an input interface 105, a media reader 106, and an NIC (Network Interface Card) 107.
  • the CPU 101 is an example of the processing unit 12 of the first embodiment.
  • the RAM 102 or the HDD 103 is an example of the storage unit 11 of the first embodiment.
  • the CPU 101 is a processor that executes program instructions.
  • the CPU 101 loads at least part of the program and data stored in the HDD 103 into the RAM 102, and executes the program.
  • the CPU 101 may include multiple processor cores.
  • the control server 100 may include multiple processors. The processing described below may be performed in parallel using multiple processors or processor cores.
  • a set of multiple processors is sometimes referred to as a "multiprocessor" or simply "processor.”
  • the RAM 102 is a volatile semiconductor memory that temporarily stores programs executed by the CPU 101 and data used for calculations by the CPU 101.
  • the control server 100 may include a type of memory other than RAM, or may include a plurality of memories.
  • the HDD 103 is a nonvolatile storage device that stores software programs such as an OS (Operating System), middleware, and application software, and data.
  • the control server 100 may include other types of storage devices such as flash memory and SSD (Solid State Drive), or may include a plurality of nonvolatile storage devices.
  • the GPU 104 outputs an image to the display 41 connected to the control server 100 according to instructions from the CPU 101.
  • the display 41 any type of display can be used, such as a CRT (Cathode Ray Tube) display, a Liquid Crystal Display (LCD), a plasma display, or an Organic Electro-Luminescence (OEL) display.
  • CTR Cathode Ray Tube
  • LCD Liquid Crystal Display
  • OEL Organic Electro-Luminescence
  • the input interface 105 acquires an input signal from the input device 42 connected to the control server 100 and outputs it to the CPU 101.
  • the input device 42 a mouse, a touch panel, a touch pad, a pointing device such as a trackball, a keyboard, a remote controller, a button switch, etc. can be used. Further, a plurality of types of input devices may be connected to the control server 100.
  • the media reader 106 is a reading device that reads programs and data recorded on the recording medium 43.
  • the recording medium 43 for example, a magnetic disk, an optical disk, a magneto-optical disk (MO), a semiconductor memory, etc. can be used.
  • Magnetic disks include flexible disks (FDs) and HDDs.
  • Optical discs include CDs (Compact Discs) and DVDs (Digital Versatile Discs).
  • the media reader 106 copies programs and data read from the recording medium 43 to other recording media such as the RAM 102 and the HDD 103.
  • the read program is executed by the CPU 101, for example.
  • the recording medium 43 may be a portable recording medium, and may be used for distributing programs and data.
  • the recording medium 43 and the HDD 103 are sometimes referred to as computer-readable recording media.
  • the NIC 107 is an interface that is connected to the network 40 and communicates with other computers via the network 40.
  • the NIC 107 is connected to a communication device such as a switch or a router by a cable, for example.
  • NIC 107 may be a wireless communication interface.
  • FIG. 4 is a diagram showing an example of the functions of the control server.
  • the control server 100 has a storage section 110 and a control section 120.
  • a storage area of the RAM 102 or the HDD 103 is used.
  • the control unit 120 is realized by the CPU 101 executing a program stored in the RAM 102.
  • the storage unit 110 stores an approval route template table 111, an authentication policy table 112, an organization information table 113, and an authentication history table 114.
  • the approval route template table 111 holds templates of approval routes according to document attributes.
  • the approval route indicates the approval route in the WF, that is, the order of forwarding destinations of the WF.
  • the approval route template does not include personal information such as the name of the user to be forwarded to, but indicates the position or department to be forwarded to and the forwarding order.
  • templates for approval routes according to attributes of documents such as invoices, contracts, and applications are registered in advance in the approval route template table 111.
  • the authentication policy table 112 holds user authentication requirements according to document attributes.
  • the authentication requirements indicate an authentication method such as FIDO2 that should be imposed on the corresponding user.
  • FIDO2 an authentication method
  • the user is required to authenticate based on the authentication requirements registered in the authentication policy table 112.
  • the authentication requirements registered in the authentication policy table 112 are determined in advance based on policies within organization X, policies agreed upon between organizations X and Y, laws and regulations, and the like. Further, authentication requirements for each document are set for the corresponding document.
  • the organization information table 113 holds information such as the names, contact information, and departments of users who belong to organization X. Although not shown, an organization information table regarding organization Y is also stored in the storage unit 110.
  • the authentication history table 114 holds the user's authentication history. User authentication is performed before the user performs an operation related to WF. After successful authentication, the user can sign the document. In the authentication history table 114, an authentication log indicating what kind of authentication method was used to authenticate the user when signing the document is recorded in association with the identification information of the document.
  • the storage unit 110 stores private keys of each user, organization, and control server 100 that are used to give electronic signatures, and public keys of each user, organization, and control server 100 that are used to verify electronic signatures.
  • the public key is distributed, for example, by a digital certificate containing a digital signature from a predetermined certification authority.
  • each user's private key used for giving the electronic signature may be held in a predetermined device or client device owned by each user.
  • the organization's private key may be held by a predetermined server computer owned by the organization.
  • the organization's private key is used to provide an E-seal, which will be described later.
  • the organization's public key is used to verify the E-seal.
  • the E-seal is information for guaranteeing the legitimacy of the organization from which the data is sourced, and corresponds to the electronic signature of the organization. E-seal is also written as e-seal.
  • the control unit 120 controls the WF that straddles organizations X and Y.
  • the control unit 120 includes a claim setting unit 121, a personal name conversion unit 122, a WF management unit 123, an authentication processing unit 124, a verification unit 125, and a signature adding unit 126.
  • the claim setting unit 121 sets claim information in a document to be approved by the WF.
  • the claim information indicates authentication requirements for a user signing a document.
  • the claim information is an example of the requirement information 32 in the first embodiment.
  • the document is given approval route information that defines the forwarding destination by the WF based on the approval route template table 111.
  • the complaint setting unit 121 adds, to the approval route information, complaint information indicating authentication requirements according to the forwarding destination defined by the approval route information based on the authentication policy table 112.
  • the approval route information is an example of the definition information 31 of the first embodiment.
  • the personal name conversion unit 122 converts the forwarding destination information in the approval route information included in the document into the personal name of the user corresponding to the forwarding destination. Furthermore, the personal name conversion unit 122 adds contact information such as the e-mail address of the user to the approval route information.
  • the WF management unit 123 manages the progress of WF by users of organizations X and Y respectively.
  • the WF management unit 123 requests each user to approve the document in turn by e-mail according to the approval route information included in the document, and in response to the user's approval, adds an image of the user's seal to the document. , adds the electronic signature of the user to the document.
  • the approval request e-mail may include, together with the approval request message, a URL (Uniform Resource Locator) for transitioning to an authentication screen for approval.
  • the authentication screen may be a screen for causing the authentication processing unit 124 to perform authentication according to the authentication requirements requested by the claim information.
  • the authentication processing unit 124 performs authentication for a user to access the control server 100 in response to a request from the WF management unit 123 to approve a document.
  • the authentication method for the corresponding user is managed by the WF management unit 123 as described above.
  • the WF management unit 123 causes the authentication processing unit 124 to execute the authentication method specified for the user in the complaint information included in the document.
  • the authentication processing unit 124 records an authentication log indicating the authentication method executed for the user in the authentication history table 114 in association with the identification information of the document.
  • the PIN, ID/password, biometric information, etc. that are registered in advance for each user and are used for authentication by the authentication processing unit 124 are held in the storage unit 110.
  • the function of the authentication processing unit 124 may be realized by a server computer other than the control server 100.
  • the WF management unit 123 communicates with the server computer that performs the authentication process via the network 40, allows the user to add a signature to the document depending on the success of the authentication, and records the authentication history table 114. Record.
  • the verification unit 125 verifies whether the WF has been properly executed after each user's signature is added to the document. For example, when the WF within organization X is completed, the verification unit 125 verifies the electronic signature of each user of organization X added to the document. The verification unit 125 notifies the signature adding unit 126 whether or not the electronic signature of each user of organization X has been successfully verified.
  • the verification unit 125 also verifies whether the user who signed the document has been properly authenticated. For example, the verification unit 125 checks the claim information included in the document and the authentication log of the user of organization X for the document in the authentication history table 114, and determines whether the authentication method indicated in the authentication log is the Determine whether the requirements are met. Then, the verification unit 125 notifies the signature adding unit 126 of the determination result of whether the authentication log of each user in organization X satisfies the authentication requirements.
  • the signature adding unit 126 adds a predetermined electronic signature to the corresponding document according to the verification result by the verification unit 125. For example, when the signature adding unit 126 is notified from the verification unit 125 that the electronic signatures of each user of organization Replace with sticker. That is, the signature adding unit 126 removes the electronic signature of each user of organization X from the document, and adds the E-seal of organization X to the document.
  • the signature adding unit 126 adds a TaaS signature to the corresponding document.
  • the TaaS signature is an electronic signature of the control server 100 that indicates that the control server 100 has confirmed that each user who signed a document has been properly authenticated according to the authentication policy of the document.
  • the control server 100 adds not only the E-seal of organization X but also the TaaS signature to the document, thereby indicating that the WF was executed in organization can be guaranteed to have been carried out.
  • a user of organization Y can verify that the document was sent through WF by organization X based on the E-seal attached to the document forwarded through WF. Further, the user of organization Y can verify that the document has been approved by an appropriate user of organization X, based on the TaaS signature given to the document.
  • the public key of organization X is used to verify the E-seal of organization X.
  • the public key of the control server 100 is used to verify the TaaS signature.
  • FIG. 5 is a diagram illustrating an example of a workflow for a document.
  • the control server 100 detects that the document 500 to be forwarded to organizations X and Y in order has been registered in the cloud system 400.
  • the document 500 is given approval route information based on the approval route template table 111.
  • the control server 100 may provide the approval route information based on the approval route template table 111.
  • the approval route information for the document 500 indicates an approval route that passes through the person in charge of department W of organization X, the section manager, the general manager, and the legal department of organization X in this order, and then reaches organization Y.
  • the position of the approver does not matter when it comes to approval by the legal department.
  • the control server 100 When the control server 100 detects that the document 500 has been registered in the cloud system 400, it adds complaint information C1 to the approval route information of the document 500 based on the authentication policy table 112.
  • the complaint information C1 indicates authentication requirements for each user in charge, section manager, general manager, and legal department of department W of organization X, according to the attributes of document 500.
  • the control server 100 adds the names and contact information of the person in charge A, section manager B, and manager C of department W of organization X, the contact information of the legal department, etc. to the approval route information of the document 500. Add information.
  • the person in charge A may be identified by the control server 100 as the user who drafted the document 500.
  • the control server 100 may add contact information of a person in charge of organization Y, which is the next forwarding destination of organization X, to the approval route information.
  • the control server 100 requests the person in charge A, who is the first forwarding destination, to approve the document 500.
  • the control server 100 receives the approval of the person in charge A
  • the control server 100 generates a document 501 in which the electronic signature of the person A is added to the document 500 .
  • the document 501 includes information indicating the difference between the document 501 and the document 500.
  • the control server 100 requests approval of the document 501 from section manager B, who is the second forwarding destination.
  • the control server 100 receives the manager B's approval
  • the control server 100 generates a document 502 in which the electronic signature of the manager B is added to the document 501.
  • the document 502 includes information indicating the difference between the document 502 and the document 501.
  • control server 100 requests approval of the document 502 from the third forwarding destination, manager C.
  • the control server 100 When the manager C is authenticated and approval from the manager C is received, the control server 100 generates a document 503 in which the electronic signature of the manager C is added to the document 502.
  • the document 503 includes information indicating the difference between the document 503 and the document 502.
  • the control server 100 requests approval of the document 503 from the legal department, which is the fourth forwarding destination.
  • the approver D of the legal department is authenticated and the control server 100 receives approval from the approver D
  • the control server 100 generates a document 504 in which the electronic signature of the approver D is added to the document 503.
  • Document 504 includes information indicating the difference between document 504 and document 503.
  • the control server 100 verifies the four electronic signatures given to the document 504. For example, each document has differences from the previous document. Therefore, in order to verify the electronic signature, the control server 100 cannot obtain the document data retrospectively, for example, by obtaining the document 503 from the document 504 and further obtaining the document 502 from the document 503. can.
  • control server 100 When the control server 100 successfully verifies the electronic signatures of the person in charge A, the section manager B, the manager C, and the approver D, it replaces these electronic signatures with the E-seal M1. In addition, if the control server 100 determines that the authentication performed for each person satisfies the authentication requirements of the complaint information C1 based on the authentication log at the time of signature of each person in charge A, section manager B, manager C, and approver D, A TaaS signature N1 is attached to the document 504.
  • the document 600 is the same as the document 504 with an E-seal M1 added thereto and a TaaS signature N1 added thereto.
  • the control server 100 notifies the recipient K, who is the person in charge of the organization Y, that the document 600 has been forwarded to the organization Y.
  • the recipient K can use the client device 300 to obtain the document 600, and can use the client device 300 to verify the E-seal M1 and the TaaS signature N1.
  • FIG. 6 is a diagram illustrating an example of processing by the control server.
  • a document 500p is registered in the cloud system 400.
  • approval route information T1 is set in the document 500p, which is a template of an approval route according to the attributes of the document 500p.
  • the setting of approval route information T1 for the document 500p may be executed by the control server 100.
  • Approval route information T1 indicates that the document 500p is forwarded in order to the person in charge, the section manager, the general manager, and the legal department in the department of the organization that originated the draft.
  • the claim setting unit 121 Based on the authentication policy table 112, the claim setting unit 121 adds claim information C1 according to the attributes of the document 500p to the approval route information T1.
  • the claim information C1 indicates authentication requirements at the time of signature of each person in charge, section manager, general manager, and legal department approver.
  • Document 500q is obtained by adding claim information C1 to document 500p.
  • the personal name conversion unit 122 Based on the organization information table 113, the personal name conversion unit 122 adds the names and e-mail addresses of the person in charge A, section manager B, and manager C in department W of organization e-mail address (mailing list), etc. Thereby, the approval route information T1 is converted into approval route information T2.
  • the approval route information T2 includes personal information such as the name and e-mail address of each forwarding destination user set by the personal name conversion unit 122.
  • the document 500 is obtained by converting the approval route information T1 in the document 500q into approval route information T2.
  • the WF management unit 123 controls the WF within the organization X for the document 500, as illustrated in FIG. After the authentication processing unit 124 authenticates the user, the WF management unit 123 allows the user to approve the document 500 and add an electronic signature to the document 500. For example, the authentication processing unit 124 performs authentication such as FIDO2 for each user, and records an authentication log in the authentication history table 114. The authentication method for the corresponding user by the authentication processing unit 124 can be managed by the WF management unit 123 as described above. For example, the WF management unit 123 controls the authentication processing unit 124 to execute the authentication method specified for the user in the complaint information C1.
  • the document 504 is a document with the electronic signatures of the person in charge A, the section manager B, the manager C, and the approver D of the legal department as a result of the WF on the document 500.
  • the verification unit 125 verifies the electronic signatures of the person in charge A, the section manager B, the manager C, and the approver D attached to the document 504, and notifies the signature assignment unit 126 that the verification was successful.
  • the verification unit 125 compares the authentication logs at the time of signatures of each person in charge A, section manager B, manager C, and approver D of the legal department with the authentication requirements of the complaint information C1, and
  • the signature assigning unit 126 is notified that the authentication of each approver D of the department satisfies the authentication requirements.
  • the signature attaching unit 126 attaches an E-seal M1 to the document 504 in response to successful verification of the electronic signatures of the person in charge A, the section manager B, the manager C, and the approver D.
  • illustration of the E-seal M1 is omitted.
  • the signature adding unit 126 adds a TaaS signature N1 to the document 504 because the authentication requirements of the person in charge A, the section manager B, the manager C, and the legal department approver D satisfy the authentication requirements when signing the document 504.
  • the document 600 is the document 504 with the TaaS signature N1 added.
  • the recipient K of the organization Y can use the client device 300 to obtain the document 600 and use the client device 300 to verify the TaaS signature N1 and the E-seal M1.
  • FIG. 7 is a diagram showing an example of the data structure of a document.
  • FIG. 7A illustrates a document 500 that is an OpenXML (eXtensible Markup Language) file.
  • Document 500 has a display data area 510 and a hidden data area 520.
  • the display data area 510 is an area where the main text displayed on the display by a browser such as the client device 300 is stored. For example, an image of the seal of the user who approved the document 500 is stored in the display data area 510.
  • the hidden data area 520 is an area where meta information that is not displayed on the display is stored.
  • the hidden data area 520 is encrypted using, for example, an encryption key held by the control server 100. Therefore, the meta information stored in the hidden data area 520 can only be edited by the control server 100.
  • approval route information T2 and complaint information C1 are stored in the hidden data area 520.
  • the claim information C1 is written, for example, in JSON (JavaScript Object Notation) format, and is managed by being converted to BASE64 or the like depending on the storage location. JavaScript is a registered trademark.
  • the hidden data area 520 also stores the history of differences with respect to the previous document and information on the electronic signature added to the document 500.
  • FIG. 7(B) illustrates a document 500a that is a PDF (Portable Document Format) file.
  • Document 500a has a display data area 510a and a hidden data area 520a.
  • Display data area 510a corresponds to display data area 510.
  • Hidden data area 520a corresponds to hidden data area 520.
  • the hidden data area 520a includes approval route information T2a and complaint information C1a.
  • FIG. 7C illustrates a document 500b that is an ASIC (Associated Signature Containers) file (ZIP file).
  • Document 500b includes files/folders 510b and . It has a META-INF folder 520b.
  • the file/folder 510b corresponds to the display data area 510 and is an area where the main text of the document 500b that can be viewed by the user is stored. ..
  • the META-INF folder 520b corresponds to the hidden data area 520, and is an area where approval route information T2b and complaint information C1b are stored.
  • documents to be approved by the WF can be in various data formats such as OpenXML format, PDF format, and ASIC format (ZIP format).
  • the data format in FIG. 7 is an example, and other types of data formats may be used as the document data format.
  • FIG. 8 is a diagram showing an example of generation of claim information.
  • the attribute of the document 500p is "contract.”
  • the document 500p has seal frames 511, 512, 513, and 514 corresponding to the approval route information T1.
  • the seal frames 511, 512, 513, and 514 are frames for attaching images of seals corresponding to the person in charge of the drafting document of the document 500p, the section manager, the general manager, and the approver of the legal department of organization X, respectively.
  • the seal frames 511, 512, 513, and 514 are described, for example, in the display data area 510 in accordance with the forwarding order of the WF.
  • the complaint setting unit 121 specifies the position or department of the forwarding destination in the approval route by analyzing the approval route information T1 or the description of the seal stamp frames 511, 512, 513, and 514. For example, in OpenXML, a signature frame is described using the Signatureline format.
  • the claim setting unit 121 obtains authentication requirements according to the attribute "contract" of the document 500p based on the authentication policy table 112.
  • the authentication policy table 112 has a record of the authentication requirement "FIDO2" for the document attribute, that is, the document attribute "contract.” This record indicates that user authentication by FIDO2 is required to sign a document with the document attribute "contract.”
  • authentication levels such as AAL1, AAL2, and AAL3 may be defined as authentication requirements in the authentication policy table 112.
  • AAL2 is required for authentication for relatively simple application documents, and for documents that have a relatively large economic impact or impact on the organization's assets and operations, such as documents related to money or contracts.
  • AAL3 may be considered as an authentication requirement.
  • a combination of authentication using a PIN (Personal Identification Number) or ID/password and biometric authentication (equivalent to AAL2), or a combination of authentication using a PIN or ID/password and authentication using a dedicated authentication device such as a YubiKey may be determined.
  • the claim setting unit 121 generates claim information C1 based on the analysis result of the approval route in the document 500p and the authentication requirements obtained from the authentication policy table 112.
  • the claim information C1 is written in, for example, JSON format.
  • each user's authentication requirements are described as elements of the array verifier.
  • the first element shown in the third to fifth lines of the claim information C1 corresponds to the seal frame 511 of the drafter of the document 500p.
  • the description ““FIDO2”: ⁇ “uv”:“required” ⁇ ” in the element of the array verifier indicates that user authentication by FIDO2 is required at the time of signature.
  • uv is an abbreviation for user verification.
  • FIG. 8 a case is illustrated in which a specific authentication method for the description of "FIDO2" (for example, a combination of ID/password authentication and biometric authentication using a terminal device) is determined in advance.
  • other authentication methods using FIDO2 may be specified as elements of the array verifier.
  • "uv" user authentication
  • the WF management unit 123 requests the user to use a predetermined authentication method corresponding to AAL2.
  • the second element shown in the 6th to 9th lines of the claim information C1 corresponds to the seal frame 512.
  • the description ““role”: “level1”” indicates a position.
  • the value level1 for the object role indicates the position of the first-level executive employee (for example, section chief, manager, chief, etc.).
  • the higher the stage of the position the higher the position.
  • the third element shown in the 10th to 13th lines of the claim information C1 corresponds to the seal frame 513.
  • the value level2 for the object role indicates the position of a second-level executive employee (eg, manager, producer, etc.).
  • the fourth element shown in lines 14 to 17 of the claim information C1 corresponds to the seal frame 514.
  • the description ““dept”: “lawdept”” indicates a department.
  • the value lawdept for the object dept indicates the legal department.
  • the value accdept for the object dept indicates the accounting department.
  • the value hrdept for the object dept indicates the general affairs department.
  • the claim setting unit 121 adds the user's identification information to the claim information C1 of the document 500 based on the organization information table 113.
  • the objects described as elements of the array verifier include "email” indicating an email, as will be described later.
  • the value of the object role may include "level3", "csuite”, etc. in addition to the above.
  • the value level3 of the object role indicates the position of the third-level executive employee (eg, general manager, fellow, etc.).
  • the value csuite of the object role indicates the position of the highest level executive employee (for example, Chief Technical Officer (CTO), Chief Digital Transformation Officer (CDXO), etc.).
  • FIG. 9 is a diagram illustrating an example (part 1) of processing based on claim information.
  • the complaint setting unit 121 specifies the person in charge A of the department W who is the drafter of the document 500
  • the complaint setting unit 121 acquires the identification information of the person in charge A from the organization information table 113.
  • the organization information table 113 for each member identification information of the organization X, the department to which the member belongs, the position, and the identification information of the superior are held in association with each other.
  • an e-mail address is used as the member identification information.
  • the person in charge A who is the drafter of the document 500 can be identified from the account information used when registering the document 500q in the cloud system 400.
  • the identification information of person A in charge of department W is "taro@xxx.zzz". Therefore, the claim setting unit 121 adds "email":"taro@xxx.” to the first element of the array verifier in the claim information C1. Add “zzz”.
  • the complaint setting unit 121 identifies the e-mail address "kacou@xxx.zzz" of the section manager B, who is the boss of the person in charge A, from the organization information table 113, and adds it to the complaint information C1. Furthermore, the complaint setting unit 121 specifies the e-mail address "buchou@xxx.zzz” of the manager C from the organization information table 113, and adds it to the complaint information C1.
  • the authentication processing unit 124 authenticates the identification information of the user and the authentication method at the time of authentication in association with the document ID of the document 500. It is recorded in the history table 114.
  • the document ID of document 500 is "id1”.
  • Documents 500p, 500q, 500 to 504, and 600 all have document ID "id1”.
  • the authentication processing unit 124 associates the document ID “id1” with the authentication log of the authentication history “taro@xxx.zzz:FIDO2”. The record shown is added to the authentication history table 114.
  • FIG. 10 is a diagram illustrating a processing example (part 2) based on claim information.
  • the authentication processing unit 124 records the authentication logs for the section manager B and the manager C in the authentication history table 114, similarly to the case of the authentication of the person in charge A, even when the section manager B or the manager C is authenticated.
  • FIG. 11 is a diagram illustrating a processing example (part 3) based on claim information.
  • the complaint information C1 only a department such as the legal department may be set as the forwarding destination.
  • the complaint setting unit 121 sets the e-mail address of the approver D "hanako@xxx.zzz" in the complaint information C1. Good too.
  • the WF management section 123 transmits a WF approval request to the mailing list corresponding to the legal department.
  • the WF management unit 123 requests authentication in accordance with the authentication requirements specified by the claim information C1 when the approver D belonging to the legal department signs in response to the approval request.
  • the authentication processing unit 124 records the authentication log for the approver D in the authentication history table 114.
  • the verification unit 125 Next, an example of verification of claim information by the verification unit 125 will be described.
  • FIG. 12 is a diagram showing an example of verifying claim information.
  • the verification unit 125 detects that the WF management unit 123 has generated a document 504 for which WF within organization X has been completed. Then, the verification unit 125 verifies whether the requirements in the claim information C1 of the document 504 are satisfied based on the organization information table 113 and the authentication history table 114.
  • the verification unit 125 compares the authentication history of the document ID "id1" in the authentication history table 114 with the authentication requirements of each user in the claim information C1, and determines whether each user satisfies the authentication requirements of the claim information C1. Determine whether or not it has been authenticated.
  • the verification unit 125 determines, based on the organization information table 113, that the position and department of each authenticated user meet the requirements regarding the position (“role”) and department (“dept”) defined in the complaint information C1. Determine whether the conditions are met.
  • requirements regarding a user's position and department are referred to as user attribute requirements.
  • the verification unit 125 adds a TaaS signature N1 to the document 504 if all the authentication requirements and user attribute requirements described in the complaint information C1 are satisfied for the person in charge A, the section manager B, the manager C, and the approver D. do.
  • the E-seal M1 is obtained by encrypting the hash value of the information in the display data area 510 of the document 504 using the organization X's private key.
  • the TaaS signature N1 is, for example, the hash value of the entire document 504 including the E-seal M1 encrypted using the private key of the control server 100.
  • the storage unit 110 stores in advance abstraction definition rules that are rules for converting abstract descriptions based on the values of the object “role” and the values of the object “dept” into the names of positions and departments in each organization. Good too.
  • FIG. 13 is a diagram showing an example of abstract definition rules.
  • the abstract definition rule 115 is stored in the storage unit 110 in advance.
  • the abstract definition rule 115 includes items for abstract definition, organization X, and organization Y.
  • the value of the object "role” or the value of the object "dept" is registered in the abstract definition item.
  • the organization X item the name of the position or department of organization X that corresponds to the abstract definition is registered.
  • the organization Y item the name of the position or department of organization Y that corresponds to the abstract definition is registered.
  • the abstract definition rule 115 has records of abstract definition "level 1", organization X "section manager”, and organization Y "manager". This record indicates that the value "level1" of the object “role” corresponds to the position "section manager” in organization X, and corresponds to the position "manager” in organization Y.
  • the abstraction definition rule 115 has records for abstraction definition "level 2", organization X "manager”, and organization Y "director". This record indicates that the value "level2" of the object “role” corresponds to the position "manager” in organization X, and corresponds to the position "director” in organization Y.
  • the abstract definition rule 115 has records for the abstract definition "lawdept", organization X “Legal Department”, and organization Y "Legal Department”. This record indicates that the value "lawdept” of the object "dept” corresponds to the department "Legal Department” in both organizations X and Y.
  • the verification unit 125 converts the value of the object “role” and the value of the object “dept” in the complaint information C1 to the position of the corresponding organization based on the abstraction definition rule 115, and converts the value of the object “role” and the value of the object “dept” in the complaint information C1 into the position of each user in the organization information table 113. Can be compared.
  • FIG. 14 is a diagram showing an example of adding a TaaS signature according to the verification result of claim information.
  • FIG. 14(A) shows a case where the verification result of the claim information C1 is normal.
  • a case where the verification result of the claim information C1 in the document 504 is normal is a case where all of the authentication requirements and user attribute requirements described in the claim information C1 are satisfied for each user of the approval route information T2. .
  • the signature attaching unit 126 generates the document 600 by attaching the TaaS signature N1 to the document 504.
  • the TaaS signature N1 is a valid TaaS signature obtained by encrypting the hash value of the document 504 using the private key of the control server 100.
  • the TaaS signature N1 may be obtained by encrypting the hash value of the document 504 with the E-seal M1 using the private key.
  • FIG. 14(B) shows a case where the verification result of the complaint information C1 is abnormal.
  • a case where the verification result of the claim information C1 in the document 504a is abnormal is a case where at least part of the authentication requirements and user attribute requirements described in the claim information C1 are not satisfied for each user in the approval route information T2a. It is.
  • the department of the approver E indicated by the approval route information T2a of the document 504a whose document attribute is a contract is identified as the general affairs department from the organization information table 113. show.
  • the approval route information T2a is falsified from the original approval route information T2.
  • the e-mail address of the approver E who was authenticated at the time of signing is set in the claim information C1.
  • the complaint information C1 of the document 504a the legal department is designated as the final forwarding destination for organization X in the WF. Therefore, the verification unit 125 determines that the approver E does not satisfy the user attribute requirements described in the complaint information C1.
  • the signature adding unit 126 creates a document 600a by adding an invalid TaaS signature P1 to the document 504a.
  • the TaaS signature P1 is an invalid TaaS signature obtained by encrypting a hash value different from the hash value of the document 504a or the document to which the E-seal has been attached to the document 504a using the private key of the control server 100.
  • the TaaS signature P1 may be obtained by encrypting a hash value different from the hash value of the document 504a with the E-seal M1 using the private key.
  • recipient K of organization Y uses the client device 300 to verify the TaaS signature P1 of the document 600a, the verification always fails. Thereby, the recipient K can recognize that the document 600a is an unauthorized document that has not undergone a proper WF in the organization X.
  • FIG. 15 is a diagram illustrating an example of processing according to the verification result of the TaaS signature.
  • FIG. 15(A) shows the case of normal TaaS signature N1.
  • the client device 300 verifies the TaaS signature N1 added to the document 600. For example, the client device 300 obtains a hash value by decrypting the TaaS signature N1 using the public key of the control server 100, and compares it with the hash value of the portion of the document 600 other than the TaaS signature N1. Since TaaS signature N1 is a normal electronic signature, both hash values match. Therefore, the client device 300 successfully verifies the TaaS signature N1. The client device 300 then moves on to the next process regarding the WF within the organization Y for the document 600.
  • FIG. 15(B) shows the case of an abnormal TaaS signature P1.
  • the client device 300 Upon receiving the document 600a, the client device 300 verifies the TaaS signature P1 added to the document 600a. For example, the client device 300 obtains a hash value by decrypting the TaaS signature P1 using the public key of the control server 100, and compares it with the hash value of the portion of the document 600a other than the TaaS signature P1. Since the hash value obtained by decrypting the TaaS signature P1 is an abnormal hash value, the two hash values do not match. Therefore, the client device 300 fails to verify the TaaS signature P1.
  • the client device 300 sends an email (notification email) to the sender of the document 600a (for example, person in charge A) based on the claim information C1 of the document 600a, etc., notifying that the document 600a is fraudulent. do.
  • the client device 300 also sends the notification email to a predetermined administrator's email address that is predetermined within the organization Y.
  • organization Y can verify the validity of the transmitted document according to the verification result of the TaaS signature, and can decide whether to proceed with the WF within organization Y. For example, if the document in question is processed by an existing WF system in organization Y, the verification of the TaaS signature in FIG. 15 may be performed by an additional verification module for TaaS signatures in the WF system.
  • FIG. 16 is a diagram illustrating a display example of a TaaS signature verification result.
  • the verification result of the TaaS signature N1 may be presented to the recipient K of the organization Y, for example, on the verification result notification screen 700 displayed by the client device 300.
  • a message indicating that the verification result of TaaS signature N1 is normal and that approval has been performed by a user who satisfies the authentication requirements described in complaint information C1 in organization X is displayed on the verification result notification screen 700.
  • An example is shown below.
  • control unit 120 provides the mailer of the client device 300 with a plug-in or add-in for signature verification in advance.
  • the WF management unit 123 then attaches the document 600 to an e-mail addressed to the recipient K and sends it. Then, the document 600 received by the mailer of the client device 300 is automatically verified by the plug-in or the like, and a verification result notification screen 700 is displayed on the client device 300.
  • the client device 300 deletes the attached file using the function of the plug-in and displays a message to that effect on the verification result notification screen 700. You may.
  • FIG. 17 is a diagram showing a display example of a message corresponding to claim information.
  • the WF management unit 123 may allow the client device 300 that has received the document 600 to display the complaint information C1 as is.
  • the WF management unit 123 may be able to display a message obtained by converting the description of the complaint information C1 into the natural language of a UI (User Interface) used by the client device 300.
  • UI User Interface
  • the description ““dept”: “lawdept”” in the complaint information C1 is converted into a message indicating in Japanese that it has been confirmed by the Legal Department and displayed on the verification result notification screen 700. be done.
  • the description ““dept”: “lawdept”” in the complaint information C1 is converted into a message such as “Verified by law dept.” and displayed on the verification result notification screen 700. If a UI in another language is used, the claim information C1 is converted into a message in that language.
  • the verification result of the TaaS signature may be displayed on the document display screen that displays the contents of the document on the client device 300.
  • a document display screen including the TaaS signature verification result will be described.
  • FIG. 18 is a diagram showing an example of a document display screen.
  • FIG. 18A illustrates a document display screen 800 for the document 600.
  • Document display screen 800 is displayed on client device 300.
  • the document display screen 800 has a text display area 801 and a signature display area 802.
  • the text display area 801 is an area where the content of the text of the document 600 is displayed.
  • the text display area 801 also displays images of seal frames corresponding to the approval route and seals of person in charge A, section manager B, etc. attached to each seal frame.
  • the signature display area 802 is an area where the verification result of the TaaS signature N1 attached to the document 600 is displayed.
  • the signature display area 802 may display the electronic signature of the person in charge A, the section manager B, etc., or the verification result of the E-seal M1.
  • the electronic signature of an individual user in organization X such as person in charge A or section manager B
  • the individual user's electronic signature is not displayed.
  • an image of the organization X's seal is displayed in the text display area 801 instead of the user's personal seal.
  • the client device 300 successfully verifies the TaaS signature N1 added to the document 600. Therefore, the signature display area 802 displays that the TaaS signature N1 is valid.
  • FIG. 18(B) illustrates a document display screen 800a for the document 600a.
  • Document display screen 800a is displayed on client device 300.
  • the document display screen 800a has a text display area 801a and a signature display area 802a.
  • the text display area 801a corresponds to the text display area 801.
  • the signature display area 802a corresponds to the signature display area 802.
  • the client device 300 fails to verify the TaaS signature P1 attached to the document 600a. Therefore, the signature display area 802a displays that the TaaS signature P1 is invalid.
  • the recipient K of the organization Y can easily confirm the validity of the received documents 600, 600a by confirming the validity of the TaaS signatures N1, P1 on the document display screens 800, 800a. can.
  • FIG. 19 is a flowchart illustrating an example of transmitting a document with a TaaS signature.
  • the claim setting unit 121 receives input of a document template. For example, when the complaint setting unit 121 detects that a document template, that is, a document 500p, has been registered in the cloud system 400, it acquires the document 500p from the cloud system 400.
  • the document 500p includes a seal frame corresponding to the approval route information T1 set based on the approval route template table 111 according to the text drafted by the person in charge A and the attributes of the document 500p.
  • the claim setting unit 121 identifies an approval route from the seal frame of the document 500p, generates claim information C1 based on the approval route, and adds it to the document 500p. As a result, a document 500q including claim information C1 is generated from the document 500p.
  • the complaint setting unit 121 may specify the approval route from the seal stamp frame or may specify the approval route from the approval route information T1.
  • the claim setting unit 121 sets authentication requirements according to the attributes of the document 500p in the claim information C1 based on the authentication policy table 112.
  • the personal name conversion unit 122 converts the approval route information T1 of the document 500q into approval route information T2 to which information such as the personal name is added.
  • a document 500 including approval route information T2 is generated from the document 500q.
  • the complaint setting unit 121 adds identification information such as the e-mail address of the forwarding destination user to the complaint information C1 based on the organization information table 113.
  • the WF management unit 123 starts executing the WF within the organization X for the document 500 based on the approval route information T2 of the document 500.
  • the WF management unit 123 transmits an approval request to the user's e-mail address according to the approval route indicated by the approval route information T2.
  • the authentication processing unit 124 authenticates the user using an authentication method that satisfies the authentication requirements defined in the claim information C1, before accepting approval from the user in response to the approval request.
  • the authentication processing unit 124 records the user's authentication log in the authentication history table 114 in association with the document ID of the document 500.
  • the WF management unit 123 adds an image of the user's seal and an electronic signature to the document 500 in response to the user's approval.
  • a document 504 is generated from the document 500.
  • Document 504 is the result of approval of document 500 by each user in organization X in turn according to the approval route.
  • the verification unit 125 verifies the electronic signature of each user of organization X included in the document 504. Then, when the verification unit 125 successfully verifies the electronic signatures of all users of the organization X, the signature adding unit 126 adds the E-seal M1 of the organization X to the document 504. At this time, the signature adding unit 126 may delete the electronic signature of each user of organization X included in the document 504 and the approval route information T2 from the document 504. Note that if the verification in step S14 fails, the document 504 may have been tampered with by an unauthorized user, so the WF cannot continue.
  • the verification unit 125 verifies the claim information C1 of the document 504. Specifically, as explained in FIG. 12, the verification unit 125 checks the authentication requirements by comparing the authentication history table 114 and the complaint information C1, and checks the user attribute requirements by comparing the organization information table 113 and the complaint information C1. Check.
  • the signature adding unit 126 adds a TaaS signature to the document 504 to which the E-seal M1 has been added, according to the verification result in step S15. Specifically, if the verification result in step S15 is normal, the signature adding unit 126 creates the document 600 by adding a valid TaaS signature N1 to the document 504. On the other hand, if the verification result in step S15 is abnormal, the signature adding unit 126 creates a document 600a by adding an invalid TaaS signature P1 to the document 504.
  • the WF management unit 123 sends the document with the TaaS signature to the e-mail address of a predetermined user (for example, recipient K) in organization Y, which is the next forwarding destination of the WF.
  • the e-mail address of recipient K may be specified in advance by a user of organization X (for example, person in charge A) at the stage of document 500p or document 500, or may be specified at step S17. Then, the process for transmitting the TaaS signed document ends.
  • FIG. 20 is a flowchart illustrating an example of receiving a document with a TaaS signature.
  • the client device 300 receives the document with the TaaS signature from the control server 100.
  • the client device 300 verifies the E-seal attached to the received document. If the client device 300 successfully verifies the E-seal, the client device 300 determines that the text of the document is authentic and created by organization X. If the client device 300 fails to verify the E-seal, the client device 300 informs the user (for example, recipient K, administrator, etc.) that the text of the document is fraudulent and has been tampered with by a third party other than organization X. to notify.
  • the user for example, recipient K, administrator, etc.
  • the client device 300 verifies the TaaS signature attached to the received document. If the client device 300 succeeds in verifying the TaaS signature, the client device 300 determines that the document has been signed by an appropriate user in organization X. If the client device 300 fails to verify the TaaS signature, the client device 300 notifies the user (for example, recipient K, administrator, etc.) that the document in question is fraudulent and contains a signature by an inappropriate user in organization X. do.
  • the control server 100 may control the execution of the WF in organization Y for the corresponding document in response to a request from the client device 300.
  • the WF in organization Y may be executed by a predetermined WF system that organization Y has.
  • the control server 100 can set the approval route and complaint information according to the attributes of the relevant department, and add an E-seal and TaaS signature, similarly to organization X.
  • step S11 the authentication requirements for the attributes of the document registered in the cloud system 400 may not be registered in the authentication policy table 112.
  • the claim setting unit 121 may add the authentication method actually executed for the user to the claim information C1 when the WF is executed. In this case, only the user attribute requirements will be checked in the verification at step S15. Further, the recipient K of the organization Y can check the authentication method executed for each user of the organization X based on the claim information C1 included in the received document 600.
  • the control server 100 controls the execution of a WF that straddles organizations X and Y.
  • the provider that provides the control server 100 is a different organization from organizations X and Y. Therefore, the trust anchor of the electronic certificate of the control server 100 is a higher-level certification authority than the provider that provides the control server 100.
  • the government of the country or region to which organizations X and Y belong may provide a list of trusted trust anchors (trust list).
  • control server 100 may be used to control WFs within a single organization, for example, WFs only within organization X.
  • the control server 100 only needs to be managed as an in-house system of organization X. Therefore, the trust anchor of the electronic certificate of the control server 100 may be an internal certificate authority of organization X.
  • authentication requirements are defined for document attributes, but authentication requirements are defined for user attributes such as user position and department. It's okay to be hit.
  • FIG. 21 is a diagram showing an example of an authentication policy table.
  • the storage unit 110 may store an authentication policy table 112a in advance.
  • the authentication policy table 112a holds authentication requirements and authentication levels corresponding to the authentication requirements in association with document attributes and user attributes.
  • the authentication policy table 112a includes a record of the authentication requirement "ID/Pass authentication and touch to HW (HardWare) authentication device” and the authentication level “AAL1" for the document attribute "contract” and the user attribute "responsible person”. has.
  • This record requires ID/password authentication and touching a HW authentication device such as YubiKey as authentication requirements when the document attribute is "contract” and the signing user's position is "in charge”. shows. It also indicates that the authentication level corresponding to the authentication requirement is AAL1.
  • the authentication policy table 112a also includes a record of the authentication requirement "ID/Pass authentication and biometric authentication using a HW authentication device" and the authentication level “AAL3" for the document attribute "contract” and the user attribute "manager". have This record requires ID/password authentication and biometric authentication using a HW authentication device such as YubiKey as authentication requirements when the document attribute is "contract” and the signing user's title is “manager”. shows. It also indicates that the authentication level corresponding to the authentication requirement is AAL3.
  • the authentication policy table 112a sets the authentication requirement "ID/Pass authentication and touch to HW authentication device" and the authentication level "AAL1" for the document attribute "XX application form” and the user attribute "-” (no setting). has a record of This record indicates that when the document attribute is "XX application form", ID/password authentication and touching a HW authentication device such as a YubiKey are required as authentication requirements, regardless of the user attribute. It also indicates that the authentication level corresponding to the authentication requirement is AAL1.
  • the authentication policy table 112a may include records indicating authentication requirements that correspond only to user attributes, regardless of document attributes. In this way, the authentication policy table 112a can include authentication requirements according to at least one of document attributes and user attributes.
  • the claim setting unit 121 generates claim information indicating authentication requirements according to the attributes of the document and the user attributes included in the approval route information based on the authentication policy table 112a, and adds it to the approval route information. be able to.
  • requirements regarding the authentication of a signer who signs a document may be determined according to internal or inter-organizational policies, laws, and the like.
  • the signer can only be authenticated using a uniform authentication method, there is a possibility that a signature made without sufficient verification of the signer's identity, that is, an invalid signature will be added to the document. There is sex.
  • the control server 100 can appropriately identify the authentication requirements of each signer for the document from the claim information. , each signer can be required to authenticate in accordance with the authentication requirements. Therefore, the control server 100 can improve the reliability of verifying the identity of the person signing the document. As a result, the control server 100 can suppress the addition of invalid signatures that violate requirements such as policies and laws. Furthermore, the control server 100 can improve the reliability of data handled by WFs executed within or between organizations.
  • the control server 100 executes the following process.
  • the control unit 120 controls a workflow that involves signing data.
  • the control unit 120 detects that the data to be subjected to the workflow is registered in the cloud system 400 or the like. Then, the control unit 120 adds requirement information regarding the authentication required of the signer when signing the data to the workflow definition information included in the data.
  • the control unit 120 requests the signer to perform authentication according to the requirement information added to the definition information.
  • the control server 100 can appropriately authenticate each signer based on the requirement information and have them add a signature to the data. Therefore, it is possible to prevent an invalid signature from being given by a person other than the signer himself/herself.
  • the approval route information T1 and T2 are examples of workflow definition information.
  • Claim information C1 is an example of requirement information.
  • a document is an example of data that is a target of a workflow.
  • control unit 120 may acquire history information regarding authentication performed when a signature is added to data.
  • the control unit 120 may verify whether the acquired history information corresponds to the requirement information, that is, whether the authentication method in the history information matches the authentication method in the requirement information. If the verification result is positive, that is, if the method of authenticating the history information matches the method of authenticating the requirement information, the control unit 120 determines that the requirement information is satisfied and processes the data. may be given an electronic signature.
  • the control server 100 can verify after the fact that each signer has been properly authenticated using the electronic signature given to the data.
  • the TaaS signature N1 is an example of the electronic signature.
  • the authentication history table 114 is an example of history information regarding authentication.
  • the control unit 120 may add an electronic signature to data when the history information about a plurality of signers satisfies all the requirement information for each signer. Further, if the verification result is negative, the control unit 120 treats the data as invalid data in which the signer has not been properly authenticated at the time of signing, and issues an electronic signature (TaaS signature). It does not need to be provided.
  • control unit 120 may generate requirement information according to the data based on policy information indicating authentication requirements according to at least one of the attributes of the data and the attributes of the signer included in the definition information.
  • control server 100 can set appropriate authentication requirements as requirement information according to the attributes of the data and the attributes of the signer.
  • the authentication policy tables 112 and 112a are examples of policy information.
  • the requirement information may include information specifying an authentication method using single-factor authentication or multi-factor authentication that is required of the signer included in the definition information. Further, the requirement information may include information specifying, for each signer, an authentication method using single-factor authentication or multi-factor authentication that is required of each of the plurality of signers included in the definition information.
  • control server 100 can impose authentication on the signer using single-factor authentication or multi-factor authentication.
  • the authentication method using single-factor authentication or multi-factor authentication may be specified by an authentication level such as AAL, for example.
  • the requirement information may include user attribute requirements regarding attributes of the signer in the organization to which the signer belongs.
  • the control unit 120 may add identification information of the authenticated signer to the requirement information. Then, when assigning an electronic signature (TaaS signature), the control unit 120 selects the signer included in the requirement information based on the organization information indicating user attributes corresponding to the identification information of each of the plurality of users belonging to the organization. It may be determined whether the attribute corresponding to the identification information satisfies user attribute requirements. The control unit 120 may add an electronic signature (TaaS signature) to the data when the attribute corresponding to the signer's identification information satisfies the user attribute requirements.
  • TaaS signature electronic signature
  • control server 100 verifies not only the authentication requirements but also the user attribute requirements such as the user's position and affiliation, and adds an electronic signature (TaaS signature) to ensure that the appropriate user identifies the data. This provides greater assurance that the signature has been signed.
  • the organization information table 113 is an example of organization information.
  • control unit 120 may acquire history information regarding the authentication performed when a signature is added to data, and verify whether the acquired history information corresponds to the requirement information. Then, if the verification result is positive, the control unit 120 may add a valid electronic signature (valid TaaS signature N1) to the data. Further, the control unit 120 may add an invalid electronic signature (invalid TaaS signature P1) to the data when the verification result is negative.
  • control server 100 can use the electronic signature (TaaS signature) attached to the data to later verify that each signer was properly authenticated when signing the data. .
  • TaaS signature electronic signature
  • the information processing in the first embodiment can be realized by causing the processing unit 12 to execute a program. Further, the information processing according to the second embodiment can be realized by causing the CPU 101 to execute a program.
  • the program can be recorded on a computer-readable recording medium 43.
  • the program can be distributed by distributing the recording medium 43 on which the program is recorded.
  • the program may be stored in another computer and distributed via a network.
  • the computer may store (install) a program recorded on the recording medium 43 or a program received from another computer in a storage device such as the RAM 102 or the HDD 103, and read and execute the program from the storage device. good.
  • Information processing device 11 Storage unit 12 Processing unit 20, 20a, 20b Terminal device 30, 30a Data 31 Definition information 32 Requirement information

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

有効でない署名の付与を抑制する。　処理部（１２）は、データ（３０）が登録されたことを検出すると、データ（３０）への署名時に署名者に要求する認証に関する要件情報（３２）を、データ（３０）に含まれるワークフローの定義情報（３１）に追加する。データ（３０ａ）は、データ（３０）の定義情報（３１）に対して要件情報（３２）が追加されたものである。処理部（１２）は、定義情報（３１）に従って署名者にデータ（３０ａ）への署名の付与を依頼する際に、署名者に対して、定義情報（３１）に追加した要件情報（３２）に応じた認証を要求する。

Description

ワークフロー制御方法、ワークフロー制御プログラムおよび情報処理装置
　本発明はワークフロー制御方法、ワークフロー制御プログラムおよび情報処理装置に関する。
　複数のユーザによる手続きの支援にワークフローシステムが用いられることがある。ワークフローシステムは、複数のユーザによる一連の手続の順序を示すワークフローを管理する。例えば、ワークフローシステムは、電子化された文書などのデータに対し、予め定めた承認ルートに従ってユーザに承認を依頼し、ユーザの承認を受け付けることで、複数のユーザによる承認手続きを支援する。ユーザにより承認されたデータには当該ユーザの電子署名が付与されることがある。
　例えば、ユーザの電子署名を文書に適用するときに、生体情報によりユーザを認証するシステムの提案がある。
米国特許出願公開第２０２１／０２８１４２１号明細書
　データの属性やユーザの属性などに応じて、データに署名を付与するユーザの認証の強度に要件が課されることがある。しかし、各ユーザに対してシステムにより一律の方法で認証が行われると、例えばユーザの本人性の確認が不十分であるなど、認証の要件が満たされていない状態でデータに署名が付与される可能性がある。
　１つの側面では、本発明は、有効でない署名の付与を抑制することを目的とする。
　１つの態様では、データへの署名を伴うワークフローを制御するワークフロー制御方法が提供される。ワークフロー制御方法では、コンピュータが、データが登録されたことを検出すると、データへの署名時に署名者に要求する認証に関する要件情報を、データに含まれるワークフローの定義情報に追加し、定義情報に従って署名者にデータへの署名の付与を依頼する際に、署名者に対して、定義情報に追加した要件情報に応じた認証を要求する。
　また、１つの態様では、ワークフロー制御プログラムが提供される。また、１つの態様では、記憶部と処理部とを有する情報処理装置が提供される。
　１つの側面では、有効でない署名の付与を抑制できる。
　本発明の上記および他の目的、特徴および利点は本発明の例として好ましい実施の形態を表す添付の図面と関連した以下の説明により明らかになるであろう。
第１の実施の形態の情報処理装置を説明する図である。 第２の実施の形態の情報処理システムの例を示す図である。 制御サーバのハードウェア例を示す図である。 制御サーバの機能例を示す図である。 文書に対するワークフローの例を示す図である。 制御サーバの処理例を示す図である。 文書のデータ構造例を示す図である。 クレイム情報の生成例を示す図である。 クレイム情報に基づく処理例（その１）を示す図である。 クレイム情報に基づく処理例（その２）を示す図である。 クレイム情報に基づく処理例（その３）を示す図である。 クレイム情報の検証例を示す図である。 抽象化定義ルールの例を示す図である。 クレイム情報の検証結果に応じたＴａａＳ署名の付与例を示す図である。 ＴａａＳ署名の検証結果に応じた処理例を示す図である。 ＴａａＳ署名の検証結果の表示例を示す図である。 クレイム情報に対応するメッセージの表示例を示す図である。 文書表示画面の例を示す図である。 ＴａａＳ署名付き文書の送信例を示すフローチャートである。 ＴａａＳ署名付き文書の受信例を示すフローチャートである。 認証ポリシーテーブルの例を示す図である。
　以下、本実施の形態について図面を参照して説明する。
　［第１の実施の形態］
　第１の実施の形態を説明する。
　図１は、第１の実施の形態の情報処理装置を説明する図である。
　情報処理装置１０は、データへの署名を伴うワークフローを制御する。記憶部１１は、ＲＡＭ（Random Access Memory）などの揮発性記憶装置でもよいし、ＨＤＤ（Hard Disk Drive）やフラッシュメモリなどの不揮発性記憶装置でもよい。処理部１２は、ＣＰＵ（Central Processing Unit）、ＤＳＰ（Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field Programmable Gate Array）などを含み得る。処理部１２はプログラムを実行するプロセッサでもよい。「プロセッサ」には、複数のプロセッサの集合（マルチプロセッサ）も含まれ得る。
　例えば、情報処理装置１０は、ネットワークを介して端末装置２０，２０ａ，２０ｂに接続される。端末装置２０，２０ａ，２０ｂは、それぞれユーザＡ，Ｂ，Ｃにより使用される。ユーザＡ，Ｂ，Ｃは、それぞれ端末装置２０，２０ａ，２０ｂを操作して、ワークフローで回送されるデータへの署名を行える。データは、例えば複数のユーザの承認を要する文書などのデータである。データへの署名は、当該データに対する該当のユーザによる手書きサインの画像または印鑑の画像の付与や当該データに対する当該ユーザの電子署名の付与の少なくとも一方により行われ得る。
　処理部１２は、ワークフローの対象のデータ３０が登録されたことを検出する。データ３０は、ネットワークを介して情報処理装置１０からアクセス可能なストレージに登録されてもよいし、記憶部１１に登録されてもよい。データ３０はワークフローの定義情報３１を含む。定義情報３１は、データ３０の回送先の順序を示す情報を有する。
　ここで、定義情報３１は、例えばユーザによる閲覧や編集が行われる文書の本文などのデータ本体とは別個のメタ情報として、データ３０に保持される。あるいは、定義情報３１は、署名者の署名として手書きサインや印鑑の画像などが付与される複数の署名枠を示す情報でもよい。例えば、文書における当該枠の記載順序は、ワークフローの回送先の順序に相当する。一例として、定義情報３１は、ユーザＡ，Ｂ，Ｃに、この順序でデータ３０を回送することを示すものとする。
　処理部１２は、データ３０が登録されたことを検出すると、データ３０への署名時に署名者に要求する認証に関する要件情報３２を、定義情報３１に追加する。例えば、処理部１２は、ユーザＡに対する認証要件Ｌ１、ユーザＢに対する認証要件Ｌ２およびユーザＣに対する認証要件Ｌ３を含む要件情報３２を、定義情報３１に対して追加する。データ３０ａは、データ３０の定義情報３１に対して要件情報３２が追加されたものである。
　要件情報３２が定義情報３１に追加される段階では、定義情報３１には、回送先とする各ユーザの役職などの情報が設定されているだけで、各ユーザ個人を特定する情報は設定されていなくてもよい。定義情報３１に各ユーザ個人を特定する情報が追加されるタイミングは、要件情報３２が設定された後でもよい。
　認証要件は、例えば、ＮＩＳＴ（National Institute of Standards and Technology）　ＳＰ８００－６３のＡＡＬ（Authenticator Assurance Level）で定められる認証レベルでもよい。あるいは、認証要件は、ＡＡＬに対応するＦＩＤＯ２（Fast IDentity Online 2）やＭＦＡ（Multi-Factor Authentication）による認証方法でもよい。ＦＩＤＯは登録商標である。
　より具体的には、認証要件は、ＡＡＬ１（単要素認証）やＡＡＬ２（ソフトウェアベースの多要素認証）やＡＡＬ３（ハードウェアを用いた認証を含む多要素認証）などの認証レベルでもよい。また、認証要件は、ＩＤ（IDentifier）／パスワードの認証と端末装置による生体認証との組合せ（ＡＡＬ２相当）や、ＩＤ／パスワードの認証と所定のハードウェア認証デバイスによる認証との組合せ（ＡＡＬ３相当）などでもよい。ＡＡＬ３相当の認証で用いられるハードウェア認証デバイスの例には、ＹｕｂｉＫｅｙ（登録商標）が挙げられる。
　このように、認証要件は、認証の強度、すなわち、認証強度に対する要件であると言える。認証強度は、本人性の確認能力の高さである。認証強度が高い程、本人性の確認能力が高い。例えば、ＡＡＬの認証レベルで言えば、ＡＡＬ１，ＡＡＬ２，ＡＡＬ３のように、末尾の数値が大きい程、認証強度は高い。
　また、認証要件Ｌ１，Ｌ２，Ｌ３は、同じでもよいし、認証要件Ｌ１，Ｌ２，Ｌ３のうちの少なくとも２つの認証要件が互いに異なってもよい。処理部１２は、データ３０の属性および署名を行うユーザの属性の少なくとも一方に応じて、該当のユーザ、すなわち、署名者に対する認証要件を決定し得る。例えば、データ３０の属性は、データ３０に含まれる、請求者や契約書や申請書など文書の内容に応じて定められてもよい。ユーザの属性は、組織における該当のユーザが所属する部署や該当のユーザの役職などに応じて定められてもよい。
　データ３０の属性および署名を行うユーザの属性の少なくとも一方に応じた認証要件は、ユーザＡ，Ｂ，Ｃが属する組織内のポリシーや組織間で合意されたポリシーや法令などにより定められてもよい。記憶部１１は、当該ポリシーや法令などにより定められる、データ３０の属性および署名を行うユーザの属性の少なくとも一方に応じた認証要件を示す情報を予め記憶してもよい。その場合、処理部１２は、記憶部１１に記憶される当該情報に基づき、定義情報３１に対して要件情報３２を追加することができる。
　処理部１２は、データ３０ａに対するワークフローを制御する。処理部１２は、データ３０ａに含まれる定義情報３１に基づいて、署名者であるユーザＡ，Ｂ，Ｃの順に署名の付与を依頼する。署名の付与の依頼は、例えば、該当のユーザの電子メールアドレスに対する電子メールの送信により行われてもよいし、該当のユーザが利用するメッセージアプリケーション上でのメッセージの送信などの他の方法により行われてもよい。各ユーザは、自身が利用する端末装置を操作して、データ３０ａの内容を確認し、承認する場合、データ３０ａに自身の署名を付与する。処理部１２は、該当のユーザの署名がデータ３０ａに付与されると、次のユーザへ署名の付与を依頼する。
　処理部１２は、定義情報３１に従って署名者にデータへの署名の付与を依頼する際に、署名者に対して、定義情報３１に追加した要件情報３２に応じた認証を要求する。例えば、処理部１２は、要件情報３２に基づき、ユーザＡに対して、認証要件Ｌ１に応じた認証を要求する。より具体的には、処理部１２は、ユーザＡによる認証要件Ｌ１に応じた認証が行われた後で、データ３０ａに対するユーザＡの署名の付与が可能になるように制御してもよい。一例では、処理部１２は、ユーザＡによる認証要件Ｌ１に応じた認証を促す画面を端末装置２０に表示させ、当該画面に従ってユーザＡが認証要件Ｌ１を満たして認証された後に、データ３０ａの閲覧や編集を行う画面を端末装置２０に表示させてもよい。
　また、処理部１２は、データ３０ａに署名が付与される際にユーザＡが行った認証の方法を認証ログとして記憶部１１に記録し、データ３０ａへの署名時にユーザＡが認証要件Ｌ１を満たして認証されたか否かを事後的に検証可能にしてもよい。例えば、処理部１２は、ユーザＡの署名がデータ３０ａに付与された後、データ３０ａの正当性を検証するために、データ３０ａが適正なユーザＡにより署名されたか否かを検証してもよい。この場合、処理部１２は、記憶部１１に記憶される認証ログとデータ３０ａに含まれる要件情報３２とに基づいて、ユーザＡにより、要件情報３２で定められた認証要件Ｌ１を満たした認証が行われたか否かを検証することができる。ユーザＡに関して認証要件Ｌ１を満たした認証が行われていない場合、データ３０ａに付された当該ユーザの署名の信頼性は低下するため、データ３０ａは不正なデータとして扱われ得る。
　同様に、処理部１２は、要件情報３２に基づき、ユーザＢに対して認証要件Ｌ２に応じた認証を要求する。更に、処理部１２は、要件情報３２に基づき、ユーザＣに対して認証要件Ｌ３に応じた認証を要求する。
　このように、情報処理装置１０によれば、データが登録されたことが検出されると、データへの署名時に署名者に要求する認証に関する要件情報が、データに含まれるワークフローの定義情報に追加される。定義情報に従って署名者にデータへの署名の付与が依頼される際に、署名者に対して、定義情報に追加した要件情報に応じた認証が要求される。これにより、情報処理装置１０は、有効でない署名の付与を抑制できる。
　ここで、前述のように、データに署名を行う署名者の認証に関する要件は、組織内または組織間のポリシーや法令などに応じて定められることがある。この場合、署名者に対して一律の認証方法でしか認証を行えないと、署名者の本人性の確認が不十分な状態で行われた署名、すなわち、有効でない署名がデータに付与される可能性がある。
　そこで、情報処理装置１０は、ワークフローの定義情報に、署名者の認証に関する要件情報を追加することで、当該要件情報から該当のデータに対する各署名者の認証に関する要件を適切に特定でき、当該要件に従った認証を各署名者に要求できる。このため、情報処理装置１０は、データに対する署名者の本人性の確認に対する信頼性を向上できる。その結果、情報処理装置１０は、ポリシーや法令などの要件に違反する有効でない署名の付与を抑制できる。また、情報処理装置１０は、組織内や組織間で実行されるワークフローで扱われるデータに対する信頼性を向上できる。
　以下では、より具体的な例を用いて情報処理装置１０の機能を更に詳細に説明する。
　［第２の実施の形態］
　次に、第２の実施の形態を説明する。
　図２は、第２の実施の形態の情報処理システムの例を示す図である。
　第２の実施の形態の情報処理システムは、制御サーバ１００、クライアント装置２００，２００ａ，３００，３００ａおよびクラウドシステム４００を含む。制御サーバ１００およびクラウドシステム４００は、ネットワーク４０に接続される。ネットワーク４０は、例えばインターネットである。
　クラウドシステム４００は、ネットワーク４０を介して、クラウドサービスを提供する情報処理システムである。クラウドシステム４００は、複数の物理マシンやストレージを有し、物理マシンやストレージのリソースを、ネットワーク４０を介してクライアントコンピュータに提供する。例えば、クラウドシステム４００が実行するクラウドサービスは、クラウドベースのストレージサービスを含む。
　クライアント装置２００，２００ａは、組織Ｘが有するクライアントコンピュータである。組織Ｘは、例えば会社である。クライアント装置２００，２００ａは、組織Ｘに属するユーザにより使用される。クライアント装置２００，２００ａは、ネットワーク５０に接続されている。ネットワーク５０は、組織Ｘ内に敷設されたＬＡＮ（Local Area Network）である。ネットワーク５０は、ネットワーク４０に接続される。組織Ｘに属するユーザはクライアント装置２００，２００ａを操作して、クラウドシステム４００が提供するクラウドサービスを使用する。
　クライアント装置３００，３００ａは、組織Ｙが有するクライアントコンピュータである。組織Ｙは、例えば組織Ｘとは異なる会社である。クライアント装置３００，３００ａは、組織Ｙに属するユーザにより使用される。クライアント装置３００，３００ａは、ネットワーク６０に接続されている。ネットワーク６０は、組織Ｙ内に敷設されたＬＡＮである。ネットワーク６０は、ネットワーク４０に接続される。組織Ｙに属するユーザはクライアント装置３００，３００ａを操作して、クラウドシステム４００が提供するクラウドサービスを使用する。
　制御サーバ１００は、クラウドシステム４００を用いた複数の組織を跨ぐ、電子化された文書の承認のワークフロー（ＷＦ：WorkFlow）を制御するサーバコンピュータである。電子化された文書は、単に文書と言われる。電子化された文書は、文書データと言われてもよい。ユーザにより承認された文書には、ユーザの印鑑の画像およびユーザの電子署名が付与される。ユーザの印鑑の画像に代えて、ユーザの手書きのサイン画像が用いられてもよい。また、電子署名の付与や検証は、公開鍵基盤（ＰＫＩ：Public Key Infrastructure）に基づき、秘密鍵と公開鍵とのペアにより実現される。制御サーバ１００は、第１の実施の形態の情報処理装置１０の一例である。
　ここで、ＷＦによる文書の承認には、承認対象の文書に対する信頼性が保証されていることが重要となる。そこで、制御サーバ１００は、文書の信頼性に関する検証を可能としながら、組織を跨ぐ承認の手続を支援する機能を提供する。なお、データの信頼性の確保を支援するサービスは、ＴａａＳ（Trust as a Service）と呼ばれることがある。制御サーバ１００は、第１の実施の形態の情報処理装置１０の一例である。
　例えば、制御サーバ１００やクラウドシステム４００は、Ｗｅｂサーバとして機能する。また、クライアント装置２００，２００ａ，３００，３００ａは、Ｗｅｂブラウザとして機能する。例えば、クライアント装置２００，２００ａ，３００，３００ａのユーザは、Ｗｅｂブラウザを操作して、制御サーバ１００やクラウドシステム４００が実行するＷｅｂサーバにより提供されるＧＵＩ（Graphical User Interface）を利用可能である。例えば、ユーザは、当該ＧＵＩを用いて、自身に回送されたＷＦを承認する旨の入力やＷＦに関するその他の情報の入力などを制御サーバ１００に対して行える。
　図３は、制御サーバのハードウェア例を示す図である。
　制御サーバ１００は、ＣＰＵ１０１、ＲＡＭ１０２、ＨＤＤ１０３、ＧＰＵ（Graphics Processing Unit）１０４、入力インタフェース１０５、媒体リーダ１０６およびＮＩＣ（Network Interface Card）１０７を有する。なお、ＣＰＵ１０１は、第１の実施の形態の処理部１２の一例である。ＲＡＭ１０２またはＨＤＤ１０３は、第１の実施の形態の記憶部１１の一例である。
　ＣＰＵ１０１は、プログラムの命令を実行するプロセッサである。ＣＰＵ１０１は、ＨＤＤ１０３に記憶されたプログラムやデータの少なくとも一部をＲＡＭ１０２にロードし、プログラムを実行する。なお、ＣＰＵ１０１は複数のプロセッサコアを含んでもよい。また、制御サーバ１００は複数のプロセッサを有してもよい。以下で説明する処理は複数のプロセッサまたはプロセッサコアを用いて並列に実行されてもよい。また、複数のプロセッサの集合を「マルチプロセッサ」または単に「プロセッサ」と言うことがある。
　ＲＡＭ１０２は、ＣＰＵ１０１が実行するプログラムやＣＰＵ１０１が演算に用いるデータを一時的に記憶する揮発性の半導体メモリである。なお、制御サーバ１００は、ＲＡＭ以外の種類のメモリを備えてもよく、複数個のメモリを備えてもよい。
　ＨＤＤ１０３は、ＯＳ（Operating System）やミドルウェアやアプリケーションソフトウェアなどのソフトウェアのプログラム、および、データを記憶する不揮発性の記憶装置である。なお、制御サーバ１００は、フラッシュメモリやＳＳＤ（Solid State Drive）などの他の種類の記憶装置を備えてもよく、複数の不揮発性の記憶装置を備えてもよい。
　ＧＰＵ１０４は、ＣＰＵ１０１からの命令に従って、制御サーバ１００に接続されたディスプレイ４１に画像を出力する。ディスプレイ４１としては、ＣＲＴ（Cathode Ray Tube）ディスプレイ、液晶ディスプレイ（ＬＣＤ：Liquid Crystal Display）、プラズマディスプレイ、有機ＥＬ（ＯＥＬ：Organic Electro-Luminescence）ディスプレイなど、任意の種類のディスプレイを用いることができる。
　入力インタフェース１０５は、制御サーバ１００に接続された入力デバイス４２から入力信号を取得し、ＣＰＵ１０１に出力する。入力デバイス４２としては、マウス、タッチパネル、タッチパッド、トラックボールなどのポインティングデバイス、キーボード、リモートコントローラ、ボタンスイッチなどを用いることができる。また、制御サーバ１００に、複数の種類の入力デバイスが接続されていてもよい。
　媒体リーダ１０６は、記録媒体４３に記録されたプログラムやデータを読み取る読み取り装置である。記録媒体４３として、例えば、磁気ディスク、光ディスク、光磁気ディスク（ＭＯ：Magneto-Optical disk）、半導体メモリなどを使用できる。磁気ディスクには、フレキシブルディスク（ＦＤ：Flexible Disk）やＨＤＤが含まれる。光ディスクには、ＣＤ（Compact Disc）やＤＶＤ（Digital Versatile Disc）が含まれる。
　媒体リーダ１０６は、例えば、記録媒体４３から読み取ったプログラムやデータを、ＲＡＭ１０２やＨＤＤ１０３などの他の記録媒体にコピーする。読み取られたプログラムは、例えば、ＣＰＵ１０１によって実行される。なお、記録媒体４３は可搬型記録媒体であってもよく、プログラムやデータの配布に用いられることがある。また、記録媒体４３やＨＤＤ１０３を、コンピュータ読み取り可能な記録媒体と言うことがある。
　ＮＩＣ１０７は、ネットワーク４０に接続され、ネットワーク４０を介して他のコンピュータと通信を行うインタフェースである。ＮＩＣ１０７は、例えば、スイッチやルータなどの通信装置とケーブルで接続される。ＮＩＣ１０７は、無線通信インタフェースでもよい。
　なお、クライアント装置２００，２００ａ，３００，３００ａおよびクラウドシステム４００も、制御サーバ１００と同様のハードウェアにより実現される。
　図４は、制御サーバの機能例を示す図である。
　制御サーバ１００は、記憶部１１０および制御部１２０を有する。記憶部１１０には、ＲＡＭ１０２やＨＤＤ１０３の記憶領域が用いられる。制御部１２０は、ＲＡＭ１０２に記憶されたプログラムがＣＰＵ１０１により実行されることで実現される。
　記憶部１１０は、承認経路テンプレートテーブル１１１、認証ポリシーテーブル１１２、組織情報テーブル１１３および認証履歴テーブル１１４を記憶する。
　承認経路テンプレートテーブル１１１は、文書の属性に応じた承認経路のテンプレートを保持する。承認経路は、ＷＦにおける承認の経路、すなわち、ＷＦの回送先の順序を示す。承認経路のテンプレートは、回送先となるユーザの氏名などの個人情報は含んでおらず、回送先とする役職や部署と、その回送順を示す。例えば、請求書や契約書や申請書などの文書の属性に応じた承認経路のテンプレートが承認経路テンプレートテーブル１１１に予め登録される。
　認証ポリシーテーブル１１２は、文書の属性に応じたユーザの認証要件を保持する。認証要件は、該当のユーザに課すべきＦＩＤＯ２などの認証方法を示す。あるユーザがＷＦに従って該当の文書を承認し、署名を付与する場合、当該ユーザには、認証ポリシーテーブル１１２に登録された認証要件に基づく認証が要求される。認証ポリシーテーブル１１２に登録される認証要件は、組織Ｘ内のポリシーや組織Ｘ，Ｙ間で合意されたポリシーや法令などに基づいて予め定められる。また、文書ごとの認証要件は、該当の文書に設定される。
　組織情報テーブル１１３は、組織Ｘに所属するユーザの氏名、連絡先、および当該ユーザが所属する部署などの情報を保持する。図示を省略しているが、組織Ｙに関する組織情報テーブルも記憶部１１０に記憶される。
　認証履歴テーブル１１４は、ユーザの認証の履歴を保持する。ユーザの認証は、ユーザがＷＦに関する操作を行う前に実行される。ユーザは、認証成功後に、文書に対する署名を行える。認証履歴テーブル１１４には、該当のユーザが文書への署名時にどのような認証方法により認証されたかを示す認証ログが、当該文書の識別情報に対応付けて記録される。
　なお、記憶部１１０は、電子署名の付与に用いられる、各ユーザ、組織および制御サーバ１００の秘密鍵や、電子署名の検証に用いられる各ユーザ、組織および制御サーバ１００の公開鍵を記憶してもよい。公開鍵は、例えば所定の認証局による電子署名を含む電子証明書により配布される。なお、電子署名の付与に用いられる各ユーザの秘密鍵は、各ユーザが所持する所定のデバイスやクライアント装置に保持されてもよい。また、組織の秘密鍵は、該当の組織が保有する所定のサーバコンピュータなどにより保持されてもよい。組織の秘密鍵は、後述されるＥシールの付与に用いられる。また、組織の公開鍵は、Ｅシールの検証に用いられる。ここで、Ｅシールは、データの出所元の組織の正当性を保証するための情報であり、当該組織の電子署名に相当する。Ｅシールは、ｅシールとも表記される。
　制御部１２０は、組織Ｘ，Ｙを跨ぐＷＦの制御を行う。制御部１２０は、クレイム設定部１２１、個人名変換部１２２、ＷＦ管理部１２３、認証処理部１２４、検証部１２５および署名付与部１２６を有する。
　クレイム設定部１２１は、ＷＦによる承認対象の文書にクレイム情報を設定する。クレイム情報は、文書に署名を行うユーザの認証要件を示す。クレイム情報は、第１の実施の形態の要件情報３２の一例である。
　ここで、文書には、承認経路テンプレートテーブル１１１に基づいてＷＦによる回送先を定義した承認経路情報が付与される。クレイム設定部１２１は、認証ポリシーテーブル１１２に基づいて承認経路情報で定められる回送先に応じた認証要件を示すクレイム情報を、承認経路情報に追加する。承認経路情報は、第１の実施の形態の定義情報３１の一例である。
　個人名変換部１２２は、組織情報テーブル１１３に基づいて、文書に含まれる承認経路情報における回送先の情報を当該回送先に対応するユーザの個人名に変換する。また、個人名変換部１２２は、承認経路情報に、当該ユーザの電子メールアドレスなどの連絡先を追加する。
　ＷＦ管理部１２３は、組織Ｘ，ＹそれぞれのユーザによるＷＦの進行を管理する。ＷＦ管理部１２３は、文書に含まれる承認経路情報に従って、電子メールにより各ユーザに順番に文書の承認を依頼し、当該ユーザの承認に応じて、当該ユーザの印鑑の画像を文書に付与するとともに、当該ユーザの電子署名を文書に付与する。例えば、承認依頼の電子メールは、承認依頼のメッセージとともに、承認を行うための認証画面に遷移するためのＵＲＬ（Uniform Resource Locator）などを含んでもよい。当該認証画面は、クレイム情報で要求される認証要件に応じた認証を認証処理部１２４に実行させるための画面でもよい。
　認証処理部１２４は、ＷＦ管理部１２３による文書への承認の依頼に応じてユーザが制御サーバ１００にアクセスするための認証を行う。該当のユーザに対する認証方法は、上記のようにＷＦ管理部１２３により管理される。例えば、ＷＦ管理部１２３は、文書に含まれるクレイム情報において、該当のユーザに対して指定されている認証方法を、認証処理部１２４に実行させる。認証処理部１２４は、文書の識別情報に対応付けて、ユーザに対して実行された認証方法を示す認証ログを、認証履歴テーブル１１４に記録する。ここで、認証処理部１２４の認証に用いられる、各ユーザに対して予め登録されるＰＩＮ、ＩＤ／パスワードおよび生体情報などは、記憶部１１０に保持される。
　なお、認証処理部１２４の機能は、制御サーバ１００以外のサーバコンピュータにより実現されてもよい。その場合、ＷＦ管理部１２３は、認証処理を行うサーバコンピュータと、ネットワーク４０を介して通信し、認証の成功に応じて文書に対するユーザの署名の付与を許容するとともに、認証履歴テーブル１１４に認証ログを記録する。
　検証部１２５は、文書に対する各ユーザの署名が付与された後に、ＷＦが適正に実行されたか否かの検証を行う。例えば、検証部１２５は、組織Ｘ内でのＷＦが完了すると、文書に付与された組織Ｘの各ユーザの電子署名の検証を行う。検証部１２５は、組織Ｘの各ユーザの電子署名の検証に成功したか否かを、署名付与部１２６に通知する。
　また、検証部１２５は、文書に署名したユーザの認証が適正に行われたか否かの検証も行う。例えば、検証部１２５は、該当の文書に含まれるクレイム情報と、認証履歴テーブル１１４における当該文書に対する組織Ｘのユーザの認証ログとを照合して、認証ログで示される認証方法がクレイム情報の認証要件を満たしているか否かを判定する。そして、検証部１２５は、組織Ｘにおける各ユーザの認証ログが認証要件を満たしているか否かの判定結果を、署名付与部１２６に通知する。
　署名付与部１２６は、検証部１２５による検証結果に応じて、該当の文書に所定の電子署名を付与する。例えば、署名付与部１２６は、組織Ｘの各ユーザの電子署名の検証に成功したことが検証部１２５から通知されると、該当の文書に付与された各ユーザの電子署名を、組織ＸのＥシールに置換する。すなわち、署名付与部１２６は、組織Ｘの各ユーザの電子署名を文書から除去し、組織ＸのＥシールを当該文書に付与する。
　また、署名付与部１２６は、組織Ｘにおける各ユーザの認証ログが認証要件を満たしていることが検証部１２５から通知されると、該当の文書にＴａａＳ署名を付与する。ＴａａＳ署名は、文書に署名した各ユーザが、当該文書の認証ポリシーに従って適正に認証されたことが制御サーバ１００により確認済であることを示す、制御サーバ１００の電子署名である。
　このように、制御サーバ１００は、文書に対して組織ＸのＥシールだけでなく、ＴａａＳ署名を付与することで、組織ＸにおいてＷＦが実行されたこと、および、組織Ｘの適切なユーザにより承認が行われたことを保証することができる。例えば、組織Ｙのユーザは、ＷＦで回送された文書に付与されたＥシールにより、当該文書が組織ＸによるＷＦを経たものであることを検証できる。また、組織Ｙのユーザは、文書に付与されたＴａａＳ署名により、当該文書が組織Ｘの適正なユーザにより承認が行われたものであることを検証できる。なお、組織ＸのＥシールの検証には、組織Ｘの公開鍵が用いられる。また、ＴａａＳ署名の検証には、制御サーバ１００の公開鍵が用いられる。
　図５は、文書に対するワークフローの例を示す図である。
　例えば、制御サーバ１００は、組織Ｘ，Ｙの順に回送される文書５００がクラウドシステム４００に登録されたことを検出する。文書５００には、承認経路テンプレートテーブル１１１に基づく承認経路情報が付与されている。承認経路テンプレートテーブル１１１に基づく承認経路情報の付与は、制御サーバ１００により行われてもよい。例えば、文書５００の承認経路情報は、組織Ｘの部署Ｗの担当、課長、部長および組織Ｘの法務部をこの順に経由し、その後、組織Ｙへ至る承認経路を示す。本例では法務部での承認については、承認者の役職は問われないものとする。
　制御サーバ１００は、文書５００がクラウドシステム４００に登録されたことを検出すると、認証ポリシーテーブル１１２に基づいて文書５００の承認経路情報にクレイム情報Ｃ１を追加する。クレイム情報Ｃ１は、文書５００の属性に応じた、組織Ｘの部署Ｗの担当、課長、部長および法務部の各ユーザに対する認証要件を示す。また、制御サーバ１００は、組織情報テーブル１１３に基づいて、文書５００の承認経路情報に、組織Ｘの部署Ｗの担当Ａ、課長Ｂ、部長Ｃの氏名や連絡先、法務部の連絡先などの情報を追加する。担当Ａは、文書５００を起案したユーザとして制御サーバ１００により特定されてもよい。また、制御サーバ１００は、組織Ｘの次の回送先の組織Ｙの担当者の連絡先の情報を承認経路情報に追加してもよい。
　制御サーバ１００は、最初の回送先である担当Ａに文書５００の承認を依頼する。制御サーバ１００は、担当Ａが認証され、担当Ａの承認を受け付けると、文書５００に担当Ａの電子署名を付与した文書５０１を生成する。文書５０１には、文書５００に対する文書５０１の差分を示す情報が含まれる。
　次に、制御サーバ１００は、２番目の回送先である課長Ｂに文書５０１の承認を依頼する。制御サーバ１００は、課長Ｂが認証され、課長Ｂの承認を受け付けると、文書５０１に課長Ｂの電子署名を付与した文書５０２を生成する。文書５０２には、文書５０１に対する文書５０２の差分を示す情報が含まれる。
　次に、制御サーバ１００は、３番目の回送先である部長Ｃに文書５０２の承認を依頼する。制御サーバ１００は、部長Ｃが認証され、部長Ｃの承認を受け付けると、文書５０２に部長Ｃの電子署名を付与した文書５０３を生成する。文書５０３には、文書５０２に対する文書５０３の差分を示す情報が含まれる。
　次に、制御サーバ１００は、４番目の回送先である法務部に文書５０３の承認を依頼する。制御サーバ１００は、法務部の承認者Ｄが認証され、承認者Ｄの承認を受け付けると、文書５０３に承認者Ｄの電子署名を付与した文書５０４を生成する。文書５０４には、文書５０３に対する文書５０４の差分を示す情報が含まれる。
　こうして、組織Ｘ内でのＷＦが完了すると、制御サーバ１００は、文書５０４に付与されている４つの電子署名を検証する。例えば、各文書は、それより１つ前の段階の文書との差分を有する。このため、電子署名の検証のために、制御サーバ１００は、例えば、文書５０４から文書５０３を取得し、更に、文書５０３から文書５０２を取得するというように、文書のデータを遡って得ることができる。
　制御サーバ１００は、担当Ａ、課長Ｂ、部長Ｃおよび承認者Ｄそれぞれの電子署名の検証に成功すると、これらの電子署名をＥシールＭ１に置換する。また、制御サーバ１００は、担当Ａ、課長Ｂ、部長Ｃおよび承認者Ｄそれぞれの署名時の認証ログにより、各人に対して行われた認証がクレイム情報Ｃ１の認証要件を満たすと判定すると、文書５０４にＴａａＳ署名Ｎ１を付与する。文書６００は、文書５０４に対してＥシールＭ１が付与され、更にＴａａＳ署名Ｎ１が付与されたものである。
　そして、次に、制御サーバ１００は、組織Ｙの担当者である受信者Ｋに文書６００が組織Ｙに回送されたことを通知する。例えば、受信者Ｋは、クライアント装置３００を用いて文書６００を取得し、クライアント装置３００を用いてＥシールＭ１の検証やＴａａＳ署名Ｎ１の検証を行える。
　次に、上記のＷＦにおける制御サーバ１００の各部の処理を説明する。
　図６は、制御サーバの処理例を示す図である。
　まず、クラウドシステム４００に、文書５００ｐが登録される。文書５００ｐには承認経路テンプレートテーブル１１１に基づいて、文書５００ｐの属性に応じた承認経路のテンプレートである承認経路情報Ｔ１が設定されている。文書５００ｐに対する承認経路情報Ｔ１の設定は、制御サーバ１００により実行されてもよい。承認経路情報Ｔ１は、文書５００ｐの起案元の組織の部署における担当、課長、部長および法務部を順に回送することを示す。
　クレイム設定部１２１は、認証ポリシーテーブル１１２に基づいて、承認経路情報Ｔ１に対し、文書５００ｐの属性に応じたクレイム情報Ｃ１を追加する。クレイム情報Ｃ１は、担当、課長、部長および法務部の承認者それぞれの署名時における認証要件を示す。文書５００ｑは、文書５００ｐに対してクレイム情報Ｃ１が追加されたものである。
　個人名変換部１２２は、組織情報テーブル１１３に基づいて、文書５００ｑの承認経路情報Ｔ１に、起案元の組織Ｘの部署Ｗにおける担当Ａ、課長Ｂ、部長Ｃの氏名や電子メールアドレスおよび法務部の電子メールアドレス（メーリングリスト）などを設定する。これにより、承認経路情報Ｔ１は、承認経路情報Ｔ２に変換される。承認経路情報Ｔ２は、個人名変換部１２２により設定された回送先の各ユーザの氏名や電子メールアドレスなどの個人情報を含む。文書５００は、文書５００ｑにおける承認経路情報Ｔ１が承認経路情報Ｔ２に変換されたものである。
　ＷＦ管理部１２３は、図６で例示したように、文書５００に対する組織Ｘ内のＷＦを制御する。ＷＦ管理部１２３は、認証処理部１２４により該当のユーザの認証が行われた後に、文書５００に対する該当のユーザの承認や電子署名の付与を許容する。例えば、認証処理部１２４は、各ユーザに対して、ＦＩＤＯ２などの認証を行い、認証履歴テーブル１１４に認証ログを記録する。認証処理部１２４による該当のユーザに対する認証方法は、前述のようにＷＦ管理部１２３により管理され得る。例えば、ＷＦ管理部１２３は、クレイム情報Ｃ１において該当のユーザに対して指定された認証方法を実行するように、認証処理部１２４を制御する。
　文書５０４は、文書５００に対するＷＦの結果、担当Ａ、課長Ｂ、部長Ｃおよび法務部の承認者Ｄの電子署名が付与されたものである。検証部１２５は、文書５０４に付与された担当Ａ、課長Ｂ、部長Ｃおよび承認者Ｄそれぞれの電子署名を検証し、検証に成功したことを署名付与部１２６に通知する。また、検証部１２５は、担当Ａ、課長Ｂ、部長Ｃおよび法務部の承認者Ｄそれぞれの署名時の認証ログをクレイム情報Ｃ１の認証要件と照合し、担当Ａ、課長Ｂ、部長Ｃおよび法務部の承認者Ｄそれぞれの認証が認証要件を満たすことを署名付与部１２６に通知する。
　署名付与部１２６は、担当Ａ、課長Ｂ、部長Ｃおよび承認者Ｄそれぞれの電子署名の検証の成功に応じて、ＥシールＭ１を文書５０４に付与する。ただし、図６ではＥシールＭ１の図示は省略されている。署名付与部１２６は、文書５０４に対する署名時の担当Ａ、課長Ｂ、部長Ｃおよび法務部の承認者Ｄそれぞれの認証が認証要件を満たすため、ＴａａＳ署名Ｎ１を文書５０４に付与する。前述のように、文書６００は、文書５０４に対してＴａａＳ署名Ｎ１が付与されたものである。
　その後、組織Ｙの受信者Ｋは、クライアント装置３００を用いて文書６００を取得し、クライアント装置３００を用いてＴａａＳ署名Ｎ１の検証やＥシールＭ１の検証を行える。
　図７は、文書のデータ構造例を示す図である。
　図７（Ａ）は、ＯｐｅｎＸＭＬ（eXtensible Markup Language）ファイルである文書５００を例示する。文書５００は、表示データ領域５１０および非表示データ領域５２０を有する。
　表示データ領域５１０は、クライアント装置３００などのブラウザによりディスプレイに表示される本文が格納される領域である。例えば、文書５００を承認したユーザの印鑑の画像は、表示データ領域５１０に格納される。
　非表示データ領域５２０は、ディスプレイに表示されないメタ情報が格納される領域である。非表示データ領域５２０は、例えば、制御サーバ１００が保持する暗号鍵で暗号化されている。このため、非表示データ領域５２０に格納されるメタ情報は、制御サーバ１００でなければ編集を行えない。例えば、承認経路情報Ｔ２およびクレイム情報Ｃ１は、非表示データ領域５２０に格納される。クレイム情報Ｃ１は、例えばＪＳＯＮ（JavaScript Object Notation）形式で記述され、格納先に応じてＢＡＳＥ６４などに変換されて管理される。ＪａｖａＳｃｒｉｐｔは登録商標である。なお、非表示データ領域５２０には、前の文書に対する差分の履歴や、文書５００に付与される電子署名の情報も格納される。
　図７（Ｂ）は、ＰＤＦ（Portable Document Format）ファイルである文書５００ａを例示する。文書５００ａは、表示データ領域５１０ａおよび非表示データ領域５２０ａを有する。表示データ領域５１０ａは、表示データ領域５１０に対応する。非表示データ領域５２０ａは、非表示データ領域５２０に対応する。非表示データ領域５２０ａには、承認経路情報Ｔ２ａやクレイム情報Ｃ１ａが含まれる。
　図７（Ｃ）は、ＡＳＩＣ（Associated Signature Containers）ファイル（ＺＩＰファイル）である文書５００ｂを例示する。文書５００ｂは、ファイル／フォルダ５１０ｂおよび．ＭＥＴＡ－ＩＮＦフォルダ５２０ｂを有する。ファイル／フォルダ５１０ｂは、表示データ領域５１０に対応し、ユーザが閲覧可能な文書５００ｂの本文が格納される領域である。．ＭＥＴＡ－ＩＮＦフォルダ５２０ｂは、非表示データ領域５２０に対応し、承認経路情報Ｔ２ｂやクレイム情報Ｃ１ｂが格納される領域である。
　このように、ＷＦによる承認対象の文書は、ＯｐｅｎＸＭＬ形式、ＰＤＦ形式およびＡＳＩＣ形式（ＺＩＰ形式）などの種々のデータ形式とすることができる。図７におけるデータ形式は一例であり、文書のデータ形式として他の種類のデータ形式が用いられてもよい。
　図８は、クレイム情報の生成例を示す図である。
　例えば、文書５００ｐの属性は、「契約書」である。文書５００ｐは、承認経路情報Ｔ１に対応する印鑑枠５１１，５１２，５１３，５１４を有する。印鑑枠５１１，５１２，５１３，５１４は、それぞれ文書５００ｐの起案元の文書の担当、課長、部長および組織Ｘの法務部の承認者に対応する印鑑の画像を付与するための枠である。印鑑枠５１１，５１２，５１３，５１４は、例えば、表示データ領域５１０において、ＷＦの回送順に従って記述される。クレイム設定部１２１は、承認経路情報Ｔ１または印鑑枠５１１，５１２，５１３，５１４の記述を解析することで、承認経路における回送先の役職や部署を特定する。例えば、ＯｐｅｎＸＭＬでは、署名枠はＳｉｇｎａｔｕｒｅｌｉｎｅ書式を用いて記述される。
　また、クレイム設定部１２１は、認証ポリシーテーブル１１２に基づいて、文書５００ｐの属性「契約書」に応じた認証要件を取得する。例えば、認証ポリシーテーブル１１２は、文書の属性、すなわち、文書属性「契約書」に対する認証要件「ＦＩＤＯ２」のレコードを有する。このレコードは、文書属性「契約書」の文書に対する署名には、ＦＩＤＯ２によるユーザの認証を要することを示す。
　なお、認証ポリシーテーブル１１２には、認証要件として、前述のように、ＡＡＬ１，ＡＡＬ２，ＡＡＬ３などの認証レベルが定められてもよい。例えば、文書の属性に応じて、比較的簡易な申請書類の場合はＡＡＬ２を認証要件とし、金銭や契約に関わる書類など、経済的影響や組織の資産や運用への影響などが比較的大きい書類の場合はＡＡＬ３を認証要件とすることが考えられる。
　また、認証要件として、ＰＩＮ（Personal Identification Number）やＩＤ／パスワードによる認証と生体認証との組合せ（ＡＡＬ２相当）や、ＰＩＮやＩＤ／パスワードによる認証とＹｕｂｉＫｅｙなどの認証専用デバイスによる認証との組合せ（ＡＡＬ３相当）などの認証方法が定められてもよい。
　クレイム設定部１２１は、文書５００ｐにおける承認経路の解析結果と、認証ポリシーテーブル１１２から取得した認証要件とに基づいて、クレイム情報Ｃ１を生成する。クレイム情報Ｃ１は、例えばＪＳＯＮ形式で記述される。例えば、クレイム情報Ｃ１では、各ユーザの認証要件は、配列ｖｅｒｉｆｉｅｒの要素として記述される。
　例えば、クレイム情報Ｃ１の３行目～５行目で示される１つ目の要素は、文書５００ｐの起案者の印鑑枠５１１に対応する。配列ｖｅｒｉｆｉｅｒの要素における「“ＦＩＤＯ２”：｛“ｕｖ”：“ｒｅｑｕｉｒｅｄ”｝」の記述は、署名時にＦＩＤＯ２によるユーザ認証が必要であることを示す。ここで、ｕｖは、user verificationの略である。図８の例では、認証方法として、“ＦＩＤＯ２”の記述に対する特定の認証方法（例えば、ＩＤ／パスワードの認証と端末装置による生体認証との組合せなど）が予め定められている場合を例示する。ただし、前述のように、配列ｖｅｒｉｆｉｅｒの要素として、ＦＩＤＯ２による他の認証方法を指定可能にしてもよい。また、配列ｖｅｒｉｆｉｅｒの要素として“ｕｖ”（ユーザ認証）の他にも、ＹｕｂｉＫｅｙなどの所定のデバイスのボタンを該当のユーザにタッチさせることによるユーザの存在性（ｕｐ：user presence）の確認を課すことを設定することもできる。
　なお、認証要件として、ＡＡＬの認証レベルを指定する場合、例えば、配列ｖｅｒｉｆｉｅｒの認証要件に係る要素として、例えば、「“ＳＰ８００”：“ＡＡＬ２”」のような記述を設定すればよい。この場合、ＷＦ管理部１２３は、ＡＡＬ２に対応する、予め定められた認証方法をユーザに要求する。
　クレイム情報Ｃ１の６～９行目で示される２つ目の要素は、印鑑枠５１２に対応する。「“ｒｏｌｅ”：“ｌｅｖｅｌ１”」の記述は、役職を示す。例えば、オブジェクトｒｏｌｅに対する値ｌｅｖｅｌ１は、第１段階の幹部社員の役職（例えば、課長、マネージャ、主任など）を示す。ここで、役職の段階が上がるほど、上位の役職となる。
　クレイム情報Ｃ１の１０～１３行目で示される３つ目の要素は、印鑑枠５１３に対応する。例えば、オブジェクトｒｏｌｅに対する値ｌｅｖｅｌ２は、第２段階の幹部社員の役職（例えば、部長やプロデューサーなど）を示す。
　クレイム情報Ｃ１の１４～１７行目で示される４つ目の要素は、印鑑枠５１４に対応する。「“ｄｅｐｔ”：“ｌａｗｄｅｐｔ”」の記述は、部署を示す。例えば、オブジェクトｄｅｐｔに対する値ｌａｗｄｅｐｔは、法務部を示す。その他にも、例えば、オブジェクトｄｅｐｔに対する値ａｃｃｄｅｐｔは、経理部を示す。また、オブジェクトｄｅｐｔに対する値ｈｒｄｅｐｔは、総務部を示す。
　こうして、文書５００ｐにクレイム情報Ｃ１が追加されることで、文書５００ｑが生成される。また、組織情報テーブル１１３を基に文書５００ｑの承認経路情報Ｔ１が承認経路情報Ｔ２に変換されることで、文書５００が生成される。このとき、クレイム設定部１２１は、組織情報テーブル１１３に基づいて、文書５００のクレイム情報Ｃ１に、ユーザの識別情報を追加する。
　なお、配列ｖｅｒｉｆｉｅｒの要素として記述されるオブジェクトには、後述されるように、電子メールを示す「ｅｍａｉｌ」が含まれる。また、オブジェクトｒｏｌｅの値には、上記以外にも「ｌｅｖｅｌ３」や「ｃｓｕｉｔｅ」なども考えられる。オブジェクトｒｏｌｅの値ｌｅｖｅｌ３は、第３段階の幹部社員の役職（例えば、統括部長やフェローなど）を示す。オブジェクトｒｏｌｅの値ｃｓｕｉｔｅは、最高レベルの幹部社員の役職（例えば、最高技術責任者（ＣＴＯ：Chief Technical Officer）や最高ＤＸ責任者（ＣＤＸＯ：Chief Digital Transformation Officer）など）を示す。
　図９は、クレイム情報に基づく処理例（その１）を示す図である。
　例えば、クレイム設定部１２１は、文書５００の起案者である部署Ｗの担当Ａを特定すると、組織情報テーブル１１３から担当Ａの識別情報を取得する。ここで、組織情報テーブル１１３には、組織Ｘのメンバの識別情報ごとに、所属する部署と役職と上司の識別情報とが対応付けて保持される。メンバの識別情報には、例えば電子メールアドレスが用いられる。例えば、文書５００の起案者である担当Ａは、クラウドシステム４００に文書５００ｑの登録を行ったときに使用されたアカウント情報などから特定され得る。
　組織情報テーブル１１３によれば、部署Ｗの担当Ａの識別情報、すなわち、電子メールアドレスは、「ｔａｒｏ＠ｘｘｘ．ｚｚｚ」である。したがって、クレイム設定部１２１は、クレイム情報Ｃ１における配列ｖｅｒｉｆｉｅｒの１つ目の要素に、「“ｅｍａｉｌ”：“ｔａｒｏ＠ｘｘｘ．ｚｚｚ”」を追加する。
　また、クレイム設定部１２１は、担当Ａの上司である課長Ｂの電子メールアドレス「ｋａｃｏｕ＠ｘｘｘ．ｚｚｚ」を組織情報テーブル１１３から特定し、クレイム情報Ｃ１に追加する。更に、クレイム設定部１２１は、部長Ｃの電子メールアドレス「ｂｕｃｈｏｕ＠ｘｘｘ．ｚｚｚ」を組織情報テーブル１１３から特定し、クレイム情報Ｃ１に追加する。
　そして、認証処理部１２４は、例えば、各ユーザによる文書５００への署名時の認証が行われると、文書５００の文書ＩＤに対応付けて、当該ユーザの識別情報と認証時の認証方法とを認証履歴テーブル１１４に記録する。ここで、文書５００の文書ＩＤは、「ｉｄ１」であるとする。文書５００ｐ，５００ｑ，５００～５０４，６００は、何れも文書ＩＤ「ｉｄ１」を有する。例えば、認証処理部１２４は、クレイム情報Ｃ１に基づき担当ＡをＦＩＤＯ２の認証方法で認証した場合、文書ＩＤ「ｉｄ１」に対応付けて、認証履歴「ｔａｒｏ＠ｘｘｘ．ｚｚｚ：ＦＩＤＯ２」の認証ログを示すレコードを認証履歴テーブル１１４に追加する。
　図１０は、クレイム情報に基づく処理例（その２）を示す図である。
　認証処理部１２４は、課長Ｂの認証や部長Ｃの認証が行われた場合も、担当Ａの認証の場合と同様に、課長Ｂや部長Ｃに対する認証ログを認証履歴テーブル１１４に記録する。
　図１１は、クレイム情報に基づく処理例（その３）を示す図である。
　また、クレイム情報Ｃ１では、回送先として、法務部などの部署のみが設定されてもよい。この場合、例えば、クレイム設定部１２１は、法務部に所属する承認者Ｄの認証が行われた場合に、承認者Ｄの電子メールアドレス「ｈａｎａｋｏ＠ｘｘｘ．ｚｚｚ」をクレイム情報Ｃ１に設定してもよい。
　なお、クレイム情報Ｃ１の回送先に法務部などの部署のみが設定される場合、ＷＦ管理部１２３は、当該法務部に対応するメーリングリスト宛に、ＷＦの承認依頼を送信する。この場合、ＷＦ管理部１２３は、当該法務部に所属する承認者Ｄが承認依頼に応じて署名を行う際に、クレイム情報Ｃ１で指定される認証要件に従った認証を要求する。
　そして、認証処理部１２４は、承認者Ｄの認証が行われると、承認者Ｄに対する認証ログを認証履歴テーブル１１４に記録する。
　次に、検証部１２５によるクレイム情報の検証例を説明する。
　図１２は、クレイム情報の検証例を示す図である。
　検証部１２５は、ＷＦ管理部１２３により組織Ｘ内でのＷＦが完了した文書５０４が生成されたことを検出する。すると、検証部１２５は、組織情報テーブル１１３および認証履歴テーブル１１４に基づいて文書５０４のクレイム情報Ｃ１における要件が満たされているか否かを検証する。
　具体的には、検証部１２５は、認証履歴テーブル１１４における文書ＩＤ「ｉｄ１」の認証履歴を、クレイム情報Ｃ１における各ユーザの認証要件と照合し、各ユーザがクレイム情報Ｃ１の認証要件を満たして認証されたか否かを判定する。
　また、検証部１２５は、組織情報テーブル１１３に基づいて、認証された各ユーザの役職や所属部署が、クレイム情報Ｃ１で定められた役職（「ｒｏｌｅ」）や部署（「ｄｅｐｔ」）に関する要件を満たすか否かを判定する。ここで、ユーザの役職や所属する部署に関する要件は、ユーザ属性要件と言われる。
　そして、検証部１２５は、担当Ａ、課長Ｂ、部長Ｃおよび承認者Ｄについて、クレイム情報Ｃ１に記述された認証要件およびユーザ属性要件が全て満たされている場合、文書５０４にＴａａＳ署名Ｎ１を付与する。
　なお、ＥシールＭ１は、文書５０４の表示データ領域５１０の情報のハッシュ値を組織Ｘの秘密鍵で暗号化したものである。これに対し、ＴａａＳ署名Ｎ１は、例えばＥシールＭ１を含む文書５０４の全体のハッシュ値を制御サーバ１００の秘密鍵で暗号化したものである。
　ここで、クレイム情報Ｃ１において、オブジェクト「ｒｏｌｅ」の値が示す役職やオブジェクト「ｄｅｐｔ」の値が示す部署は、組織ごとに異なる可能性がある。このため、記憶部１１０は、オブジェクト「ｒｏｌｅ」の値やオブジェクト「ｄｅｐｔ」の値による抽象的な記述を各組織の役職や部署の名称に変換するルールである抽象化定義ルールを予め保持してもよい。
　図１３は、抽象化定義ルールの例を示す図である。
　抽象化定義ルール１１５は、記憶部１１０に予め記憶される。抽象化定義ルール１１５は、抽象化定義、組織Ｘおよび組織Ｙの項目を含む。抽象化定義の項目には、オブジェクト「ｒｏｌｅ」の値またはオブジェクト「ｄｅｐｔ」の値が登録される。組織Ｘの項目には、抽象化定義に対応する組織Ｘの役職または部署の名称が登録される。組織Ｙの項目には、抽象化定義に対応する組織Ｙの役職または部署の名称が登録される。
　例えば、抽象化定義ルール１１５には、抽象化定義「ｌｅｖｅｌ１」、組織Ｘ「課長」、組織Ｙ「マネージャ」のレコードを有する。このレコードは、オブジェクト「ｒｏｌｅ」の値「ｌｅｖｅｌ１」が、組織Ｘでは役職「課長」に相当し、組織Ｙでは役職「マネージャ」に相当することを示す。
　また、抽象化定義ルール１１５には、抽象化定義「ｌｅｖｅｌ２」、組織Ｘ「部長」、組織Ｙ「ディレクター」のレコードを有する。このレコードは、オブジェクト「ｒｏｌｅ」の値「ｌｅｖｅｌ２」が、組織Ｘでは役職「部長」に相当し、組織Ｙでは役職「ディレクター」に相当することを示す。
　更に、抽象化定義ルール１１５には、抽象化定義「ｌａｗｄｅｐｔ」、組織Ｘ「法務部」、組織Ｙ「法務部」のレコードを有する。このレコードは、オブジェクト「ｄｅｐｔ」の値「ｌａｗｄｅｐｔ」が、組織Ｘ，Ｙの何れも部署「法務部」に相当することを示す。
　検証部１２５は、抽象化定義ルール１１５に基づいてクレイム情報Ｃ１におけるオブジェクト「ｒｏｌｅ」の値やオブジェクト「ｄｅｐｔ」の値を該当の組織の役職に変換し、組織情報テーブル１１３における各ユーザの役職と照合できる。
　図１４は、クレイム情報の検証結果に応じたＴａａＳ署名の付与例を示す図である。
　図１４（Ａ）は、クレイム情報Ｃ１の検証結果が正常の場合を示す。例えば、文書５０４におけるクレイム情報Ｃ１の検証結果が正常の場合とは、承認経路情報Ｔ２の各ユーザについて、クレイム情報Ｃ１に記述された認証要件およびユーザ属性要件の全部が満たされている場合である。
　署名付与部１２６は、クレイム情報Ｃ１の検証結果が正常の場合、文書５０４にＴａａＳ署名Ｎ１を付与することで、文書６００を生成する。ＴａａＳ署名Ｎ１は、文書５０４のハッシュ値を、制御サーバ１００の秘密鍵で暗号化した有効なＴａａＳ署名である。ＴａａＳ署名Ｎ１は、文書５０４にＥシールＭ１を付与した文書のハッシュ値を当該秘密鍵で暗号化したものでもよい。
　図１４（Ｂ）は、クレイム情報Ｃ１の検証結果が異常の場合を示す。例えば、文書５０４ａにおけるクレイム情報Ｃ１の検証結果が異常の場合とは、承認経路情報Ｔ２ａの各ユーザについて、クレイム情報Ｃ１に記述された認証要件およびユーザ属性要件の少なくとも一部が満たされていない場合である。
　図１４（Ｂ）では、一例として、文書属性が契約書である文書５０４ａの承認経路情報Ｔ２ａで示される承認者Ｅの所属部署が、組織情報テーブル１１３から総務部であると特定される場合を示す。例えば、承認経路情報Ｔ２ａは、本来の承認経路情報Ｔ２から改ざんされたものである。この場合、クレイム情報Ｃ１に、署名時に認証された承認者Ｅの電子メールアドレスが設定されている。一方、文書５０４ａのクレイム情報Ｃ１では、ＷＦにおける組織Ｘの最後の回送先として法務部が指定されている。したがって、検証部１２５は、承認者Ｅがクレイム情報Ｃ１に記述されているユーザ属性要件を満たさないと判定する。この場合、署名付与部１２６は、文書５０４ａに無効なＴａａＳ署名Ｐ１を付与することで、文書６００ａを生成する。ＴａａＳ署名Ｐ１は、文書５０４ａまたは文書５０４ａにＥシールを付与した文書のハッシュ値とは異なるハッシュ値を、制御サーバ１００の秘密鍵で暗号化した無効なＴａａＳ署名である。ＴａａＳ署名Ｐ１は、文書５０４ａにＥシールＭ１を付与した文書のハッシュ値とは異なるハッシュ値を当該秘密鍵で暗号化したものでもよい。
　例えば、組織Ｙの受信者Ｋがクライアント装置３００を用いて文書６００ａのＴａａＳ署名Ｐ１を検証する場合、当該検証に必ず失敗する。これにより、受信者Ｋは、文書６００ａが組織Ｘにおいて適正なＷＦを経ていない不正な文書であることを認識できる。
　なお、検証部１２５によりクレイム情報Ｃ１に記述された認証要件の検証で異常が検出される場合も、署名付与部１２６は、無効なＴａａＳ署名を該当の文書に付与する。
　図１５は、ＴａａＳ署名の検証結果に応じた処理例を示す図である。
　図１５（Ａ）は、正常なＴａａＳ署名Ｎ１の場合を示す。クライアント装置３００は、文書６００を受信すると、文書６００に付与されたＴａａＳ署名Ｎ１を検証する。例えば、クライアント装置３００は、制御サーバ１００の公開鍵を用いてＴａａＳ署名Ｎ１を復号することでハッシュ値を取得し、文書６００のＴａａＳ署名Ｎ１以外の部分のハッシュ値と比較する。ＴａａＳ署名Ｎ１は正常な電子署名であるため、両ハッシュ値は一致する。このため、クライアント装置３００はＴａａＳ署名Ｎ１の検証に成功する。そして、クライアント装置３００は、文書６００に対する組織Ｙ内でのＷＦに関する次の処理に移る。
　図１５（Ｂ）は、異常なＴａａＳ署名Ｐ１の場合を示す。クライアント装置３００は、文書６００ａを受信すると、文書６００ａに付与されたＴａａＳ署名Ｐ１を検証する。例えば、クライアント装置３００は、制御サーバ１００の公開鍵を用いてＴａａＳ署名Ｐ１を復号することでハッシュ値を取得し、文書６００ａのＴａａＳ署名Ｐ１以外の部分のハッシュ値と比較する。ＴａａＳ署名Ｐ１を復号して得られるハッシュ値は異常なハッシュ値であるため、両ハッシュ値は一致しない。このため、クライアント装置３００はＴａａＳ署名Ｐ１の検証に失敗する。すると、クライアント装置３００は、文書６００ａのクレイム情報Ｃ１などに基づいて、文書６００ａの送信者（例えば、担当者Ａ）に、文書６００ａが不正であることを通知する電子メール（通知メール）を送信する。また、クライアント装置３００は、組織Ｙ内で予め定められている所定の管理者の電子メールアドレスにも当該通知メールを送信する。
　このように、組織ＹではＴａａＳ署名の検証結果に応じて、送信された文書の正当性を検証し、組織Ｙ内でのＷＦを進めるか否かを決定することができる。例えば、図１５におけるＴａａＳ署名の検証は、該当の文書が組織Ｙにおける既存のＷＦシステムにより処理される場合、当該ＷＦシステムにおけるＴａａＳ署名用の追加検証モジュールにより実行されてもよい。
　図１６は、ＴａａＳ署名の検証結果の表示例を示す図である。
　ＴａａＳ署名Ｎ１の検証結果は、例えば、クライアント装置３００により表示される検証結果通知画面７００により、組織Ｙの受信者Ｋに提示されてもよい。図１６では、ＴａａＳ署名Ｎ１の検証結果が正常であることや、組織Ｘにおいてクレイム情報Ｃ１に記述された認証要件を満たすユーザによる承認が行われたことを示すメッセージが検証結果通知画面７００に表示される例を示している。
　例えば、制御部１２０は、クライアント装置３００のメーラに対して、署名検証用のプラグインやアドインを予め提供しておく。そして、ＷＦ管理部１２３は、受信者Ｋ宛の電子メールに、文書６００を添付して送信する。すると、クライアント装置３００のメーラで受信された文書６００が当該プラグインなどにより自動的に検証され、検証結果通知画面７００がクライアント装置３００に表示される。
　なお、クライアント装置３００は、添付ファイルとして無効なＴａａＳ署名が付された文書が存在する場合、当該プラグインの機能により添付ファイルを削除し、その旨を通知するメッセージを検証結果通知画面７００に表示してもよい。
　図１７は、クレイム情報に対応するメッセージの表示例を示す図である。
　ＷＦ管理部１２３は、文書６００を受信したクライアント装置３００により、クレイム情報Ｃ１をそのまま表示可能にしてもよい。ＷＦ管理部１２３は、クレイム情報Ｃ１の記述をクライアント装置３００で用いられるＵＩ（User Interface）の自然言語に変換したメッセージを表示可能にしてもよい。
　例えば、クレイム情報Ｃ１における「“ｄｅｐｔ”：“ｌａｗｄｅｐｔ”」の記述は、日本語ＵＩの場合、法務部により確認済であることを日本語で示すメッセージに変換されて検証結果通知画面７００に表示される。また、クレイム情報Ｃ１における「“ｄｅｐｔ”：“ｌａｗｄｅｐｔ”」の記述は、英語ＵＩの場合、「Ｖｅｒｉｆｉｅｄ　ｂｙ　ｌａｗ　ｄｅｐｔ．」のようなメッセージに変換されて検証結果通知画面７００に表示される。クレイム情報Ｃ１は、その他の言語のＵＩが用いられる場合、当該言語のメッセージに変換される。
　ＴａａＳ署名の検証結果は、クライアント装置３００において文書の内容を表示する文書表示画面の中に表示されてもよい。次にＴａａＳ署名の検証結果を含む文書表示画面の例を説明する。
　図１８は、文書表示画面の例を示す図である。
　図１８（Ａ）は、文書６００に対する文書表示画面８００を例示する。文書表示画面８００は、クライアント装置３００に表示される。文書表示画面８００は、本文表示領域８０１と署名表示領域８０２とを有する。本文表示領域８０１は、文書６００の本文の内容が表示される領域である。本文表示領域８０１には、文書６００の本文に加えて、承認経路に対応する印鑑枠や各印鑑枠に付された担当Ａや課長Ｂなどの印鑑の画像も表示される。
　署名表示領域８０２は、文書６００に付与されているＴａａＳ署名Ｎ１の検証結果が表示される領域である。署名表示領域８０２には、担当Ａや課長Ｂなどの電子署名やＥシールＭ１の検証結果が表示されてもよい。ただし、文書６００から担当Ａや課長Ｂなどの組織Ｘにおけるユーザ個人の電子署名がＥシールＭ１に置換されている場合、ユーザ個人の電子署名は表示されない。なお、ユーザ個人の電子署名がＥシールＭ１に置換されている場合、本文表示領域８０１には、ユーザ個人の印鑑の画像に代えて、組織Ｘの印鑑の画像が表示される。クライアント装置３００は、文書６００に付与されたＴａａＳ署名Ｎ１の検証に成功する。このため、署名表示領域８０２には、ＴａａＳ署名Ｎ１が有効であることが表示される。
　図１８（Ｂ）は、文書６００ａに対して文書表示画面８００ａを例示する。文書表示画面８００ａは、クライアント装置３００に表示される。文書表示画面８００ａは、本文表示領域８０１ａと署名表示領域８０２ａとを有する。本文表示領域８０１ａは、本文表示領域８０１に対応する。署名表示領域８０２ａは、署名表示領域８０２に対応する。
　クライアント装置３００は、文書６００ａに付与されたＴａａＳ署名Ｐ１の検証に失敗する。このため、署名表示領域８０２ａには、ＴａａＳ署名Ｐ１が無効であることが表示される。
　このように、組織Ｙの受信者Ｋは、文書表示画面８００，８００ａにより、ＴａａＳ署名Ｎ１，Ｐ１の有効性を確認することで、受信した文書６００，６００ａの正当性を容易に確認することができる。
　次に、制御サーバ１００の処理手順を説明する。
　図１９は、ＴａａＳ署名付き文書の送信例を示すフローチャートである。
　（Ｓ１０）クレイム設定部１２１は、文書テンプレートの入力を受け付ける。例えば、クレイム設定部１２１は、クラウドシステム４００への文書テンプレート、すなわち、文書５００ｐが登録されたことを検出すると、クラウドシステム４００から文書５００ｐを取得する。文書５００ｐは、担当Ａにより起案された本文や文書５００ｐの属性に応じて、承認経路テンプレートテーブル１１１を基に設定された承認経路情報Ｔ１に対応する印鑑枠を含む。
　（Ｓ１１）クレイム設定部１２１は、文書５００ｐの印鑑枠から承認経路を特定し、当該承認経路に基づいてクレイム情報Ｃ１を生成し、文書５００ｐに付与する。その結果、文書５００ｐからクレイム情報Ｃ１を含む文書５００ｑが生成される。なお、クレイム設定部１２１は、印鑑枠から承認経路を特定してもよいし、承認経路情報Ｔ１から承認経路を特定してもよい。このとき、クレイム設定部１２１は、認証ポリシーテーブル１１２に基づいて、文書５００ｐの属性に応じた認証要件をクレイム情報Ｃ１に設定する。更に、個人名変換部１２２は、組織情報テーブル１１３に基づいて、文書５００ｑの承認経路情報Ｔ１を、個人名などの情報を追加した承認経路情報Ｔ２に変換する。その結果、文書５００ｑから承認経路情報Ｔ２を含む文書５００が生成される。また、前述のように、クレイム設定部１２１は、組織情報テーブル１１３に基づいて、クレイム情報Ｃ１に回送先のユーザの電子メールアドレスなどの識別情報を付与する。
　（Ｓ１２）ＷＦ管理部１２３は、文書５００の承認経路情報Ｔ２に基づいて、文書５００に対する組織Ｘ内でのＷＦの実行を開始する。
　（Ｓ１３）ＷＦ管理部１２３は、承認経路情報Ｔ２で示される承認経路に従って、ユーザの電子メールアドレス宛に承認依頼を送信する。認証処理部１２４は、承認依頼に応じたユーザによる承認を受け付ける前に、クレイム情報Ｃ１に定められた認証要件を満たす認証方法によりユーザを認証する。認証処理部１２４は、当該ユーザの認証ログを、文書５００の文書ＩＤに対応付けて認証履歴テーブル１１４に記録する。ＷＦ管理部１２３は、ユーザによる承認に応じて、当該ユーザの印鑑の画像と電子署名とを文書５００に付与する。その結果、文書５００から文書５０４が生成される。文書５０４は、文書５００に対し、承認経路に従って組織Ｘ内の各ユーザにより順番に承認が行われた結果である。
　（Ｓ１４）検証部１２５は、文書５０４に含まれる組織Ｘの各ユーザの電子署名を検証する。そして、検証部１２５が組織Ｘの全てのユーザの電子署名の検証に成功すると、署名付与部１２６は、文書５０４に組織ＸのＥシールＭ１を付与する。このとき、署名付与部１２６は、文書５０４に含まれる組織Ｘの各ユーザの電子署名や承認経路情報Ｔ２を文書５０４から削除してもよい。なお、ステップＳ１４の検証が失敗する場合、文書５０４は、不正なユーザにより改ざんされている可能性があるため、ＷＦは続行不能となる。
　（Ｓ１５）検証部１２５は、文書５０４のクレイム情報Ｃ１の検証を行う。具体的には、検証部１２５は、図１２で説明したように、認証履歴テーブル１１４とクレイム情報Ｃ１との照合による認証要件の確認や組織情報テーブル１１３とクレイム情報Ｃ１との照合によるユーザ属性要件の確認を行う。
　（Ｓ１６）署名付与部１２６は、ステップＳ１５の検証結果に応じて、ＥシールＭ１の付与後の文書５０４にＴａａＳ署名を付与する。具体的には、ステップＳ１５の検証結果が正常の場合、署名付与部１２６は、文書５０４に有効なＴａａＳ署名Ｎ１を付与することで文書６００を生成する。一方、ステップＳ１５の検証結果が異常の場合、署名付与部１２６は、文書５０４に無効なＴａａＳ署名Ｐ１を付与することで文書６００ａを生成する。
　（Ｓ１７）ＷＦ管理部１２３は、ＴａａＳ署名付きの文書を、ＷＦの次の回送先の組織Ｙの所定のユーザ（例えば、受信者Ｋ）の電子メールアドレス宛に送信する。受信者Ｋの電子メールアドレスは、文書５００ｐや文書５００の段階などで組織Ｘのユーザ（例えば、担当Ａ）により予め指定されてもよいし、ステップＳ１７の段階で指定されてもよい。そして、ＴａａＳ署名付き文書の送信時の処理が終了する。
　次に、文書６００を受信するクライアント装置３００の処理手順を説明する。
　図２０は、ＴａａＳ署名付き文書の受信例を示すフローチャートである。
　（Ｓ２０）クライアント装置３００は、ＴａａＳ署名付きの文書を制御サーバ１００から受信する。
　（Ｓ２１）クライアント装置３００は、受信した文書に付与されているＥシールを検証する。クライアント装置３００は、Ｅシールの検証に成功する場合、該当の文書の本文が組織Ｘにより作成された真正なものであると判断する。クライアント装置３００は、Ｅシールの検証に失敗する場合、該当の文書の本文が組織Ｘ以外の第三者により改ざんされた不正なものであることをユーザ（例えば、受信者Ｋや管理者など）に通知する。
　（Ｓ２２）クライアント装置３００は、受信した文書に付与されているＴａａＳ署名を検証する。クライアント装置３００は、ＴａａＳ署名の検証に成功する場合、該当の文書が組織Ｘにおける適正なユーザにより署名されたものであると判断する。クライアント装置３００は、ＴａａＳ署名の検証に失敗する場合、該当の文書が組織Ｘにおける不適切なユーザによる署名を含む不正なものであることをユーザ（例えば、受信者Ｋや管理者など）に通知する。
　（Ｓ２３）クライアント装置３００は、ステップＳ２１，Ｓ２２の各検証に成功すると、受信した文書に対する組織ＹにおけるＷＦの実行を開始する。そして、ＴａａＳ署名付き文書の受信時の処理が終了する。例えば、制御サーバ１００は、クライアント装置３００からの要求に応じて該当の文書の組織ＹにおけるＷＦの実行を制御してもよい。あるいは、組織ＹにおけるＷＦの実行は、組織Ｙが有する所定のＷＦシステムにより実行されてもよい。制御サーバ１００は、組織ＹでのＷＦの実行時にも、組織Ｘと同様に、該当の部署の属性に応じた承認経路やクレイム情報の設定、および、ＥシールやＴａａＳ署名の付与を行える。
　なお、ステップＳ１１において、クラウドシステム４００に登録された文書の属性に対する認証要件が認証ポリシーテーブル１１２に登録されていないこともある。その場合、クレイム設定部１２１は、ＷＦの実行に伴って実際にユーザに対して実行した認証方法をクレイム情報Ｃ１に追加してもよい。この場合、ステップＳ１５の検証では、ユーザ属性要件のみが確認されることになる。また、組織Ｙの受信者Ｋは、受信した文書６００に含まれるクレイム情報Ｃ１に基づいて組織Ｘの各ユーザに対して実行された認証方法を確認できる。
　ここで、第２の実施の形態では、制御サーバ１００により組織Ｘ，Ｙを跨ぐＷＦの実行を制御する例を説明した。この場合、制御サーバ１００を提供するプロバイダは、組織Ｘ，Ｙとは異なる組織である。したがって、制御サーバ１００の電子証明書のトラストアンカーは、制御サーバ１００を提供するプロバイダよりも上位の認証局となる。例えば、組織Ｘ，Ｙが属する国や地域の行政府が、信頼済のトラストアンカーのリスト（トラストリスト）を提供することもある。
　ただし、制御サーバ１００は、単一の組織内のＷＦ、例えば組織Ｘ内だけのＷＦの制御に用いられてもよい。この場合、制御サーバ１００は、組織Ｘの社内システムとして管理されていればよい。このため、制御サーバ１００の電子証明書のトラストアンカーは組織Ｘの社内の認証局でもよい。
　また、図８の認証ポリシーテーブル１１２の例では、文書の属性に対して認証要件が定められている場合を説明したが、認証要件はユーザの役職や所属部署などのユーザの属性に対して定められてもよい。
　図２１は、認証ポリシーテーブルの例を示す図である。
　例えば、記憶部１１０は、認証ポリシーテーブル１１２に代えて、認証ポリシーテーブル１１２ａを予め保持してもよい。認証ポリシーテーブル１１２ａは、文書属性およびユーザ属性に対応付けて、認証要件および認証要件に対応する認証レベルを保持する。
　例えば、認証ポリシーテーブル１１２ａは、文書属性「契約書」、ユーザ属性「担当」に対して、認証要件「ＩＤ／Ｐａｓｓ認証およびＨＷ（HardWare）認証デバイスへのタッチ」、認証レベル「ＡＡＬ１」のレコードを有する。このレコードは、文書属性が「契約書」で、署名するユーザの役職が「担当」の場合に、ＩＤ／パスワードによる認証と、ＹｕｂｉＫｅｙなどのＨＷ認証デバイスへのタッチとを認証要件として要求することを示す。また、当該認証要件に対応する認証レベルがＡＡＬ１であることを示す。
　また、認証ポリシーテーブル１１２ａは、文書属性「契約書」、ユーザ属性「部長」に対して、認証要件「ＩＤ／Ｐａｓｓ認証およびＨＷ認証デバイスを用いた生体認証」、認証レベル「ＡＡＬ３」のレコードを有する。このレコードは、文書属性が「契約書」で、署名するユーザの役職が「部長」の場合に、ＩＤ／パスワードによる認証と、ＹｕｂｉＫｅｙなどのＨＷ認証デバイスによる生体認証とを認証要件として要求することを示す。また、当該認証要件に対応する認証レベルがＡＡＬ３であることを示す。
　更に、認証ポリシーテーブル１１２ａは、文書属性「ＸＸ申請書」、ユーザ属性「－」（設定なし）に対して、認証要件「ＩＤ／Ｐａｓｓ認証およびＨＷ認証デバイスへのタッチ」、認証レベル「ＡＡＬ１」のレコードを有する。このレコードは、文書属性が「ＸＸ申請書」の場合、ユーザ属性に関わらず、ＩＤ／パスワードによる認証と、ＹｕｂｉＫｅｙなどのＨＷ認証デバイスへのタッチとを認証要件として要求することを示す。また、当該認証要件に対応する認証レベルがＡＡＬ１であることを示す。
　また、認証ポリシーテーブル１１２ａは、文書属性に関わらず、ユーザ属性のみに応じた認証要件を示すレコードを有してもよい。
　このように、認証ポリシーテーブル１１２ａは、文書属性およびユーザ属性の少なくとも一方に応じた認証要件を含み得る。クレイム設定部１２１は、認証ポリシーテーブル１１２ａに基づいて、該当の文書の属性や承認経路情報に含まれるユーザの属性に応じた認証要件を示すクレイム情報を生成し、承認経路情報に対して追加することができる。
　ところで、前述のように、文書に署名を行う署名者の認証に関する要件は、組織内または組織間のポリシーや法令などに応じて定められることがある。この場合、署名者に対して一律の認証方法でしか認証を行えないと、署名者の本人性の確認が不十分な状態で行われた署名、すなわち、有効でない署名が文書に付与される可能性がある。
　そこで、制御サーバ１００は、文書に含まれる承認経路情報に対し、署名者の認証要件を示すクレイム情報を追加することで、クレイム情報から該当の文書に対する各署名者の認証要件を適切に特定でき、当該認証要件に従った認証を各署名者に要求できる。このため、制御サーバ１００は、文書に対する署名者の本人性の確認に対する信頼性を向上できる。その結果、制御サーバ１００は、ポリシーや法令などの要件に違反する有効でない署名の付与を抑制できる。また、制御サーバ１００は、組織内や組織間で実行されるＷＦで扱われるデータに対する信頼性を向上できる。
　以上説明したように、制御サーバ１００は次の処理を実行する。
　制御部１２０は、データへの署名を伴うワークフローを制御する。制御部１２０は、ワークフロー対象のデータがクラウドシステム４００などに登録されたことを検出する。すると、制御部１２０は、データへの署名時に署名者に要求する認証に関する要件情報を、当該データに含まれるワークフローの定義情報に追加する。制御部１２０は、定義情報に従って署名者にデータへの署名の付与を依頼する際に、署名者に対して、定義情報に追加した要件情報に応じた認証を要求する。
　これにより、制御サーバ１００は、要件情報を基に各署名者を適切に認証し、データへの署名を付与させることができる。このため、該当の署名者本人以外の人物が行うような有効でない署名の付与を抑制できる。なお、承認経路情報Ｔ１，Ｔ２は、ワークフローの定義情報の一例である。クレイム情報Ｃ１は、要件情報の一例である。また、文書は、ワークフローの対象となるデータの一例である。
　例えば、制御部１２０は、データに対する署名の付与時に行われた認証に関する履歴情報を取得してもよい。制御部１２０は、取得した履歴情報が要件情報に対応しているか否か、すなわち、履歴情報における認証の方法が要件情報の認証の方法に一致しているか否かを検証してもよい。制御部１２０は、検証結果が肯定的である場合、すなわち、履歴情報の認証の方法が要件情報の認証の方法に一致している場合に、要件情報が満たされていると判断して、データに電子署名を付与してもよい。
　これにより、制御サーバ１００は、データに付与した電子署名により、各署名者の認証が適正に行われたことの事後的な検証を可能にすることができる。ＴａａＳ署名Ｎ１は、当該電子署名の一例である。また、認証履歴テーブル１１４は、認証に関する履歴情報の一例である。例えば、制御部１２０は、複数の署名者についての履歴情報が各署名者に対する要件情報を全て満たす場合に、データに電子署名を付与してもよい。また、制御部１２０は、検証結果が否定的である場合には、当該データを、署名付与時における署名者の認証が適切に行われていない無効なデータとして扱い、電子署名（ＴａａＳ署名）を付与しなくてもよい。
　また、制御部１２０は、データの属性および定義情報に含まれる署名者の属性の少なくとも一方に応じた認証要件を示すポリシー情報に基づいて、当該データに応じた要件情報を生成してもよい。
　これにより、制御サーバ１００は、データの属性や署名者の属性に応じた適切な認証要件を要件情報として設定できる。認証ポリシーテーブル１１２，１１２ａは、ポリシー情報の一例である。
　また、要件情報は、定義情報に含まれる署名者に要求する単要素認証または多要素認証による認証方法を指定する情報を含んでもよい。また、要件情報は、定義情報に含まれる複数の署名者それぞれに要求する単要素認証または多要素認証による認証方法を、署名者ごとに指定する情報を含んでもよい。
　これにより、制御サーバ１００は、署名者に対して単要素認証や多要素認証により認証を課すことができる。なお、単要素認証または多要素認証による認証方法は、例えば、ＡＡＬなどの認証レベルにより指定されてもよい。
　また、要件情報は、署名者が所属する組織における署名者の属性に関するユーザ属性要件を含んでもよい。この場合、制御部１２０は、認証が行われた署名者の識別情報を要件情報に追加してもよい。そして、制御部１２０は、電子署名（ＴａａＳ署名）の付与の際に、組織に属する複数のユーザそれぞれの識別情報に対応するユーザの属性を示す組織情報に基づいて、要件情報に含まれる署名者の識別情報に対応する属性がユーザ属性要件を満たすか否かを判定してもよい。制御部１２０は、署名者の識別情報に対応する属性がユーザ属性要件を満たす場合に、当該データに電子署名（ＴａａＳ署名）を付与してもよい。
　このように、制御サーバ１００は、認証要件だけでなく、ユーザの役職や所属などのユーザ属性要件を更に検証して電子署名（ＴａａＳ署名）を付与することで、データに対して適切なユーザが署名したことをより強固に保証できる。なお、組織情報テーブル１１３は、組織情報の一例である。
　また、制御部１２０は、前述のように、データに対する署名の付与時に行われた認証に関する履歴情報を取得し、取得した履歴情報が要件情報に対応しているか否かを検証してもよい。そして、制御部１２０は、検証結果が肯定的である場合に、有効な電子署名（有効なＴａａＳ署名Ｎ１）をデータに付与してもよい。また、制御部１２０は、検証結果が否定的である場合に、無効な電子署名（無効なＴａａＳ署名Ｐ１）をデータに付与してもよい。
　これにより、制御サーバ１００は、データに付与された電子署名（ＴａａＳ署名）により、当該データの署名時に各署名者の認証が適正に行われたことの事後的な検証を可能にすることができる。
　なお、第１の実施の形態の情報処理は、処理部１２にプログラムを実行させることで実現できる。また、第２の実施の形態の情報処理は、ＣＰＵ１０１にプログラムを実行させることで実現できる。プログラムは、コンピュータ読み取り可能な記録媒体４３に記録できる。
　例えば、プログラムを記録した記録媒体４３を配布することで、プログラムを流通させることができる。また、プログラムを他のコンピュータに格納しておき、ネットワーク経由でプログラムを配布してもよい。コンピュータは、例えば、記録媒体４３に記録されたプログラムまたは他のコンピュータから受信したプログラムを、ＲＡＭ１０２やＨＤＤ１０３などの記憶装置に格納し（インストールし）、当該記憶装置からプログラムを読み込んで実行してもよい。
　上記については単に本発明の原理を示すものである。更に、多数の変形や変更が当業者にとって可能であり、本発明は上記に示し、説明した正確な構成および応用例に限定されるものではなく、対応する全ての変形例および均等物は、添付の請求項およびその均等物による本発明の範囲とみなされる。
　１０　情報処理装置
　１１　記憶部
　１２　処理部
　２０，２０ａ，２０ｂ　端末装置
　３０，３０ａ　データ
　３１　定義情報
　３２　要件情報

Claims (9)

  1. 　データへの署名を伴うワークフローを制御するワークフロー制御方法において、
    　コンピュータが、
    　前記データが登録されたことを検出すると、前記データへの署名時に署名者に要求する認証に関する要件情報を、前記データに含まれる前記ワークフローの定義情報に追加し、
    　前記定義情報に従って前記署名者に前記データへの署名の付与を依頼する際に、前記署名者に対して、前記定義情報に追加した前記要件情報に応じた認証を要求する、
    　ワークフロー制御方法。
  2. 　前記コンピュータが更に、前記データに対する前記署名の付与時に行われた前記認証に関する履歴情報を取得し、取得した前記履歴情報が前記要件情報に対応しているか否かを検証し、検証結果が肯定的である場合に、前記データに電子署名を付与する、
    　請求項１記載のワークフロー制御方法。
  3. 　前記コンピュータが更に、前記データの属性および前記定義情報に含まれる前記署名者の属性の少なくとも一方に応じた認証要件を示すポリシー情報に基づいて、前記データに応じた前記要件情報を生成する、
    　請求項１記載のワークフロー制御方法。
  4. 　前記要件情報は、前記定義情報に含まれる前記署名者に要求する単要素認証または多要素認証による認証方法を指定する情報を含む、
    　請求項１記載のワークフロー制御方法。
  5. 　前記要件情報は、前記定義情報に含まれる複数の署名者それぞれに要求する単要素認証または多要素認証による認証方法を、前記署名者ごとに指定する情報を含む、
    　請求項１記載のワークフロー制御方法。
  6. 　前記要件情報は、前記署名者が所属する組織における前記署名者の属性に関するユーザ属性要件を含み、
    　前記コンピュータが更に、
    　前記認証が行われた前記署名者の識別情報を前記要件情報に追加し、
    　前記電子署名の付与の際に、前記組織に属する複数のユーザそれぞれの識別情報に対応するユーザの属性を示す組織情報に基づいて、前記要件情報に含まれる前記署名者の識別情報に対応する属性が前記ユーザ属性要件を満たすか否かを判定し、前記署名者の識別情報に対応する属性が前記ユーザ属性要件を満たす場合に、前記データに前記電子署名を付与する、
    　請求項２記載のワークフロー制御方法。
  7. 　前記コンピュータが更に、
    　前記データに対する前記署名の付与時に行われた前記認証に関する履歴情報を取得し、取得した前記履歴情報が前記要件情報に対応しているか否かを検証し、
    　検証結果が肯定的である場合に、有効な電子署名を前記データに付与し、
    　前記検証結果が否定的である場合に、無効な電子署名を前記データに付与する、
    　請求項１記載のワークフロー制御方法。
  8. 　データへの署名を伴うワークフローを制御するワークフロー制御プログラムにおいて、
    　コンピュータに、
    　前記データが登録されたことを検出すると、前記データへの署名時に署名者に要求する認証に関する要件情報を、前記データに含まれる前記ワークフローの定義情報に追加し、
    　前記定義情報に従って前記署名者に前記データへの署名の付与を依頼する際に、前記署名者に対して、前記定義情報に追加した前記要件情報に応じた認証を要求する、
    　処理を実行させるワークフロー制御プログラム。
  9. 　データへの署名を伴うワークフローを制御する情報処理装置において、
    　前記データを記憶する記憶部と、
    　前記データが登録されたことを検出すると、前記データへの署名時に署名者に要求する認証に関する要件情報を、前記データに含まれる前記ワークフローの定義情報に追加し、前記定義情報に従って前記署名者に前記データへの署名の付与を依頼する際に、前記署名者に対して、前記定義情報に追加した前記要件情報に応じた認証を要求する処理部と、
    　を有する情報処理装置。
PCT/JP2022/022645 2022-06-03 2022-06-03 ワークフロー制御方法、ワークフロー制御プログラムおよび情報処理装置 WO2023233658A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/JP2022/022645 WO2023233658A1 (ja) 2022-06-03 2022-06-03 ワークフロー制御方法、ワークフロー制御プログラムおよび情報処理装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2022/022645 WO2023233658A1 (ja) 2022-06-03 2022-06-03 ワークフロー制御方法、ワークフロー制御プログラムおよび情報処理装置

Publications (1)

Publication Number Publication Date
WO2023233658A1 true WO2023233658A1 (ja) 2023-12-07

Family

ID=89026240

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2022/022645 WO2023233658A1 (ja) 2022-06-03 2022-06-03 ワークフロー制御方法、ワークフロー制御プログラムおよび情報処理装置

Country Status (1)

Country Link
WO (1) WO2023233658A1 (ja)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004355112A (ja) * 2003-05-27 2004-12-16 Aruze Corp 申請処理システム
JP2009289060A (ja) * 2008-05-29 2009-12-10 Hitachi Ltd ワークフローサーバ、ワークフロー管理方法、プログラムおよび記録媒体
WO2022070414A1 (ja) * 2020-10-02 2022-04-07 富士通株式会社 制御方法、制御プログラムおよび情報処理装置

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004355112A (ja) * 2003-05-27 2004-12-16 Aruze Corp 申請処理システム
JP2009289060A (ja) * 2008-05-29 2009-12-10 Hitachi Ltd ワークフローサーバ、ワークフロー管理方法、プログラムおよび記録媒体
WO2022070414A1 (ja) * 2020-10-02 2022-04-07 富士通株式会社 制御方法、制御プログラムおよび情報処理装置

Similar Documents

Publication Publication Date Title
US11025435B2 (en) System and method for blockchain-based cross-entity authentication
Nizamuddin et al. IPFS-blockchain-based authenticity of online publications
US10715334B2 (en) Methods and apparatus for validating a digital signature
US20190123895A1 (en) Methods and apparatus for verifying a user transaction
US6959382B1 (en) Digital signature service
EP1878190B1 (en) Method and device of enabling a user of an internet application access to protected information
US9130926B2 (en) Authorization messaging with integral delegation data
JP2021519531A (ja) ブロックチェーン・ネットワークに対するドキュメント・アクセス
US20140019761A1 (en) Self-contained electronic signature
US20020038290A1 (en) Digital notary system and method
CN112199721A (zh) 认证信息处理方法、装置、设备及存储介质
EP3864551A1 (en) Distributed ledger-based profile verification
US8479006B2 (en) Digitally signing documents using identity context information
JP2017033339A (ja) サービス提供システム、情報処理装置、プログラム及びサービス利用情報作成方法
US20100275030A1 (en) Method for ensuring the validity of recovered electronic documents from remote storage
JP2014153805A (ja) 情報処理システム、情報処理装置、認証方法及びプログラム
US20230186241A1 (en) Generation method, storage medium, and information processing device
JP2024507908A (ja) Ｓｓｉを用いたブロックチェーンネットワークアイデンティティ管理
US20230185616A1 (en) Control method, storage medium, and information processing device
WO2023233658A1 (ja) ワークフロー制御方法、ワークフロー制御プログラムおよび情報処理装置
JP2008027089A (ja) 電子データの開示方法およびシステム
US20230214502A1 (en) Systems and methods for electronic document execution, authentication, and forensic review
JP7190477B2 (ja) 電子文書管理装置、及び電子文書管理プログラム
CN114626099A (zh) 计算机可读记录介质以及信息处理方法、设备和系统
JP2004046590A (ja) 契約書保管装置、システム及びその方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22944938

Country of ref document: EP

Kind code of ref document: A1