Patent Application
20200226596
This application is based upon and claims the benefit of priority of the prior Japanese Patent Application No. 2019-3858, filed on Jan. 11, 2019, the entire contents of which are incorporated herein by reference.
The embodiments discussed herein are related to a signature server, a signature method, and a computer-readable recording medium having stored therein a signature program capable of performing a process for digital signature issue.
A blockchain is used as a management system for a virtual currency, and requires a safe operation. Types of the virtual currency or the blockchain are explosively increased, and linking between different virtual currencies and blockchains is increasingly required. When linking different virtual currencies and blockchains, different authentication information is required for transaction execution. It is difficult for a general user of this service to keep such authentication information himself or herself, and issue a digital signature and execute a transaction. Therefore, a web application which manages authentication information, issues a digital signature and executes the transaction on behalf of the user with permission is required.
Related art is disclosed in Japanese Laid-open Patent Publication No. 2018-139067, Japanese National Publication of International Patent Application No. 2018-521437 and Japanese Laid-open Patent Publication No. 2018-136657.
According to an aspect of the embodiments, an information processing apparatus includes: a memory; and a processor coupled to the memory and configured to: generate, in response to reception of a token issue request including transaction information from a user, a permission rule for determining a permission range of transaction contents based on the transaction information; transmit a token corresponding to the permission rule to a web application which processes a proxy transaction for the user, and determine, in response to reception of a signature issue request based on a transaction request by the user including the token from the web application, whether or not to issue a digital signature corresponding to the signature issue request, based on whether or not the transaction contents included in the transaction request are within the permission range determined by the permission rule corresponding to the token included in the signature issue request.
The object and advantages of the invention will be realized and attained by means of the elements and combinations particularly pointed out in the claims.
It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory and are not restrictive of the invention.
For example, as a technology related to management of a blockchain and a virtual currency, a technology may be provided for executing an account operation interlocked with transaction using the blockchain and determining success or failure of the transaction by matching execution results. There may be provided a technology in which an encryption wallet accessible to a node in which a distributed blockchain ledger is managed by a virtual data token is provided to a user and a security is transferred between users. There may be provided a technology in which a virtual currency management device transmits an exchange request including an exchange rate between a virtual currency and a legal currency to a server in which a blockchain is stored so as to add a block to the blockchain, and receive an exchange rate after an exchange between the virtual currency and the legal currency.
Regarding the requirement of the web application, when authentication information is managed in a server of the web application accessed by many users, there is a risk that the authentication information will be leaked to the outside. For this reason, an operation mode in which a signature server which performs a process according to digital signature issue is separately prepared and the signature server permits only access of the web application is considered. At this time, the signature server is permitted to issue a signature only for a specific transaction content by a request from a user via the web application, and issues a digital signature when receiving a request for a transaction permitted in advance from the web application. The web application issues a transaction in the blockchain using the digital signature received from the signature server.
When performing the operation, for example, in an exchange of the virtual currency, a currency exchange rate fluctuates in a short time, so there may be a situation in which the transaction amount differs between when the user permits the transaction signature and when the user actually performs a remittance. In this case, in the related art, it is impossible to collate the permission content intended by the user with the actual transaction content.
In one aspect, permission contents may be collated with transaction contents of a user.
Hereinafter, embodiments of a signature server, a signature method, and a signature program according to the present disclosure are described in detail with reference to the drawings.
The disclosed technology may be applied to, for example, a proxy transaction by a blockchain and a signature server which performs a process related to digital signature issue. In this case, in advance, the signature server calculates a permission range of a parameter (for example, a permission range of the remittance amount) in the transaction process based on transaction information of a user, and sets a permission rule to which information on the permission range is given. In the disclosed technology, the signature server keeps and holds authentication information (a secret key) of the user.
For example, at a time of requesting issue of an access token of the user, the signature server sets a permission rule including a permission range of the remittance amount as a permission range of a parameter in the transaction process. After then, when the user actually performs a remittance request after a time elapses, the signature server determines whether or not the remittance amount of the remittance request is within the permission range of the set remittance amount. Therefore, when the remittance amount of the remittance request is within the permission range of the set remittance amount, the signature server issues a digital signature and executes a remittance transaction in the web application (web app). The web application includes, for example, a server and client type web application, a smart contract in a blockchain, a program in the blockchain, and the like. In the proxy transaction, for example, user authority is transferred to the web application, and the web application executes transaction on behalf of the user himself or herself.
Since a currency exchange rate fluctuates in a short time in a case of a virtual currency or the like, there may be a situation in which the transaction amount differs between when the user permits transaction (for example, at a time of issuing an access token) and when the user actually issues a remittance request via the web application. In this case, in the embodiment, the signature server may collate permission contents with the transaction contents of the user at the time of the proxy transaction. At the time of the remittance request when the user actually performs remittance, in a case where the remittance amount is within the permission range even when the currency exchange rate fluctuates, the signature server issues a digital signature, and the user may perform a remittance transaction. When the remittance amount is outside the permission range, the signature server does not permit the remittance transaction and the user may not perform the remittance transaction. Therefore, the user may perform remittance within the permission range of the remittance amount set in the signature server.
A flow of the transaction process will be described. First, the user L transmits an access token issue request to the signature server A (100) (step S1). Therefore, transaction information is registered in the signature server A (100).
The signature server A (100) includes each of functions of a request reception and response unit 101, a permission range calculation unit 102, a permission rule registration unit 103, an access token creation unit 104, a permission rule determination unit 105, and a digital signature creation unit 106.
The request reception and response unit 101 respectively receives an access token issue request and a signature issue request. The signature issue request includes an access token and transaction information.
Based on the transaction information of the access token issue request, the permission range calculation unit 102 calculates a permission range of a permission rule (a permission range of the remittance amount) (step S2). The permission rule registration unit 103 records the permission range of the permission rule (the permission range of the remittance amount) calculated by the permission range calculation unit 102 in a recording unit (step S3).
The access token creation unit 104 records the access token in association with (associated with) the transaction information (the remittance amount) and the permission rule in the recording unit (step S4). At this time, the request reception and response unit 101 issues an access token to the web application 160 (step S5).
Next, the user L actually transmits a remittance transaction request to the web application 160 (step S6). Therefore, the web application 160 transmits a signature issue request (to which the access token and the transaction information (the remittance amount) are attached) to the signature server A (100) (step S7).
The permission rule determination unit 105 determines whether or not the transaction information (the remittance amount) sent from the web application 160 satisfies the permission rule recorded in the recording unit (step S8). As described below, the permission rule determination unit 105 generates a digital signature and sends the digital signature to the web application 160 only when the transaction information (the remittance amount) satisfies the permission rule recorded in the recording unit.
The digital signature creation unit 106 creates a digital signature of a transaction corresponding to the access token in the signature issue request (step S9). At this time, the digital signature creation unit 106 creates the digital signature by using a secret key 110 held inside the signature server A (100). The secret key 110 corresponds to authentication information for authenticating an account of the user L for a transaction process.
The request reception and response unit 101 of the signature server A (100) sends the digital signature of the transaction corresponding to the access token to the web application 160 (step S10). The web application 160 issues a remittance transaction to which the digital signature sent from the signature server A (100) is attached to the blockchain BC (step S11).
It is assumed that the user L has an account a in the blockchain BC, and the user S also has an account b in the blockchain BC. It is assumed that the user L remits a virtual currency in the account a to the account b of the user S via the web application 160 linked to the blockchain BC. The web application 160 illustrated in
Hereinafter, based on the description of
1. The user L permits the signature server A (100) to issue a signature on behalf of the user L only for a specific remittance request (step S201).
2. The signature server A (100) creates a permission rule obtained by calculating a permission range of the remittance amount based on transaction information of the user L, and associates an access token with the permission rule and registers the permission rule in the recording unit (step S202).
3. The signature server A (100) issues an access token to the web application 160 (step S203).
4. The user L sends the remittance request including information on the remittance amount to the web application 160 (step S204).
5. The web application 160 sends the sent access token and a signature issue request including the transaction information such as the remittance amount to the signature server A (100) (step S205).
6. The signature server A (100) determines whether or not the transaction information including the received remittance amount satisfies the permission rule (the permission range of the remittance amount) associated with the received access token. In a case where the determination result satisfies the permission rule, the signature server A (100) creates a digital signature of the transaction information corresponding to the received access token (step S206).
7. The signature server A (100) sends the created digital signature to the web application 160 (step S207).
8. The web application 160 attaches the received digital signature to a remittance transaction and issues the remittance transaction in the blockchain BC.
For example, the signature server A (100) includes a central processing unit (CPU) 301, a memory 302, a network interface (IF) 303, a recording medium IF 304, and a recording medium 305. 300 is a bus which couples each unit.
The CPU 301 is an arithmetic processing device which functions as a processing unit which controls the entire process of the signature server 100. The memory 302 includes non-volatile memory and volatile memory. The non-volatile memory is, for example, a read-only memory (ROM) which stores a program of the CPU 301. The volatile memory is, for example, dynamic random-access memory (DRAM), static random-access memory (SRAM), or the like used as a work area of the CPU 301.
The network IF 303 is communicatively coupled to an external terminal (such as a PC, a smartphone, or the like of the user) via a network 310 such as a local area network (LAN), a wide area network (WAN), the Internet, or the like.
The recording medium IF 304 is an interface for reading and writing information processed by the CPU 301 from and to the recording medium 305. The recording medium 305 is a recording device which assists the memory 302. As the recording medium 305, for example, a hard disk drive (HDD), a solid state drive (SSD), a Universal Serial Bus (USB) flash drive, or the like may be used.
The CPU 301 executes a program recorded in the memory 302 or the recording medium 305 so as to realize each function of the signature server A (100) illustrated in
The hardware configuration illustrated in
Meanwhile, the following steps S405 and S406 are sub-processes for verifying a permission rule for the user L. When the permission rule verification of the user L is not required, the signature server A (100) may execute step S407 after the process in step S404.
In the process of the registration phases for the permission rule illustrated in
The user L attaches transaction information for designating a remittance source (the account a), a remittance destination (the account b), and the remittance amount, to an access token issue request and sends the access token issue request to the signature server A (step S402).
Therefore, based on the transaction information of the issue request, the signature server A (100) calculates a permission range of a permission rule (step S403). The signature server A (100) sends the permission rule attached to the permission range (the permission range of the remittance amount) to the user L (step S404).
The signature server A (100) determines a response (permission or rejection) of the user L for the permission rule (step S405). When the response of the user L is permission (Yes in step S405), the signature server A (100) proceeds to the process in step S407. On the other hand, when the response of the user L is rejection (No in step S405), based on the parameter permission range (the permission range of the remittance amount) by the user L, a permission rule with a permission range is generated (step S406), and the process proceeds in step S407.
Next, the signature server A (100) registers the permission rule with the permission range to which the generated parameter permission range is given inside the signature server A (step S407). The signature server A (100) creates a new access token and registers the access token inside the signature server A in association with the transaction information received in step S402 and the registered permission rule (step S408). The signature server A (100) issues the created new access token to the web application 160 (step S409). The signature server A (100) terminates series of processes related to the registration phases of the permission rule.
Next, in the process of the remittance phases illustrated in
Therefore, the signature server A (100) determines whether or not the transaction information including the remittance amount satisfies the permission rule with the permission range (the permission range of the remittance amount) associated with the access token (step S412). When the determination result satisfies the permission rule (the remittance amount is within the permission range) (Yes in step S413), the signature server A (100) proceeds to the process in step S414. On the other hand, when the determination result does not satisfy the permission rule (the remittance amount is outside the permission range) (No in step S413), the signature server A (100) proceeds to the process in step S417.
In the process in step S414, the signature server A (100) creates a digital signature of the transaction information corresponding to the received access token (step S414). Next, the signature server A (100) sends the created digital signature to the web application 160 (step S415).
Therefore, the web application 160 attaches the received digital signature to a remittance transaction and issues the remittance transaction in the blockchain BC (step S416). In step S417, the signature server A (100) replies that a digital signature is not issued to the web application 160 (step S417). After the processes in step S416 or step S417, the signature server A (100) terminates series of processes related to the remittance phases.
Next, a specific example of remittance will be described for the transaction process described with reference to
In step S402, in a case of an access token issue request by the user L, a virtual currency in the account a of the user L is remitted to the account b of the user S. As compared with the virtual currency, a legal currency (for example, dollar $, yen ¥, or the like) is generally more stable in value, and it is considered to construct a signature issue rule based on a value in the legal currency. In the following description, dollar $ is treated as the legal currency.
Next, in step S403, the signature server A (100) creates a permission range according to the following procedure. When the remittance amount included in transaction information at a time of setting a permission rule is X, a permission range described in the following equation (1) is calculated for a remittance amount Y included in a remittance request.
X*(1−K)Y X*(1+K) . . . (1)
(K is a constant satisfying 0<K<1)
At this time, for example, when the signature server A (100) sets K=0.3 in advance and the remittance amount included in the transaction information at the time of creating a permission rule is virtual currency 100 points, the signature server A (100) creates the permission rule described in the following equation (2) as the permission range of the remittance amount Y included in the remittance request.
70≤Y≤130 . . . (2)
For example, when K=0.3 and the signature server A (100) receives a transaction of the transaction information 500 illustrated in
In the process in step S408, the signature server A (100) creates an appropriate character string (for example, “P8mOcv+6SW”) as a new access token. The signature server A (100) associates the permission rule (or the permission rule generated by the user L in step S407) created in step S404 with the access token and adds the permission rule as a new permission rule to the recording unit (a table) inside the signature server A (100).
Next, in the process in step S409, the signature server A (100) issues the new access token of “P8mOcv+6SW” to the web application 160.
In step S413, the signature server A (100) determines whether the remittance amount of the received remittance request 900 satisfies the extracted permission rule 1000. For example, in the case of the remittance request 900, it is assumed that a virtual currency rate fluctuates from 3.0 when a signature is permitted to 3.2 [dollar/virtual currency]. At this time, although the remittance amount is 640 dollars by dollar exchange (since the rate is 3.2 [dollar/virtual currency]), the remittance amount is within a range of the remittance amount of the permission rule 1000 (see
On the other hand, for example, in the case of the remittance request 900, it is assumed that a virtual currency rate largely fluctuates from 3.0 when the signature is permitted to 2.0 [dollar/virtual currency]. In this case, since a value of the remittance amount in dollars is 400 dollars and outside the range of the remittance amount of the permission rule 1000, the signature server A (100) determines that “the permission rule is not satisfied” (No in step S413). In this case, according to the process in step S417, the signature server A (100) replies that a signature is not issued to the web application 160.
Next, in step S414, the signature server A (100) creates a digital signature corresponding to transaction information only when it is determined that “the permission rule is satisfied (Yes in step S413)” in step S413. Next, in step S415, the signature server A (100) sends the created digital signature to the web application 160.
In step S416, the web application 160 attaches the received digital signature to a remittance transaction and issues the remittance transaction in the blockchain BC.
According to Embodiment 1, one blockchain (BC) and one signature server A (100) are provided, and as a currency rate fluctuates in a case of performing remittance as a transaction process from the user L to the user S, it is possible to collate permission contents of the transaction of the user L with transaction contents at a time of performing an actual remittance. When issuing the access token at a time of permitting the transaction, the signature server A (100) calculates a permission range of the remittance amount, and issues a digital signature only in a case where the remittance amount at the time of the actual remittance is within the permission range. A transaction process of the remittance is permitted.
Therefore, the user L who performs a remittance operation of a virtual currency in the blockchain BC may verify whether or not the remittance amount is within an intended permission content even in a case where there is a time difference or a difference situation between when the transaction is permitted and when a transaction request is actually sent. Since the secret key 110 of the user L is held in the signature server A (100) without being deposited in the web application 160, a proxy transaction may be safely executed.
In Embodiment 2, it is assumed that the user L has respectively the accounts a and b in a blockchain A (a virtual currency A) and a blockchain B (a virtual currency B). An example in which the user L exchanges the virtual currency A in the account a for the virtual currency B in the account b via the web application 160 linked with the blockchains will be described.
The secret key 110 of the account a is managed by the signature server A (100) for the blockchain A. The secret key 110 of the account b is managed by a signature server B (100) for the blockchain B. In the transaction process to be described below, the virtual currency A is exchanged for the virtual currency B, and the signature server A (100) performs the process. In a case where the virtual currency B is exchanged for the virtual currency A, the signature server B for the blockchain B as a payment source is required.
Hereinafter, based on the description of
1. The user L permits the signature server A (100) to issue a signature on behalf of the user L only for a specific remittance request (step S1101).
2. The signature server A (100) creates a permission rule obtained by calculating a permission range of the remittance amount based on transaction information of the user L, and associates an access token with the permission rule and registers the permission rule in the recording unit (step S1102).
3. The signature server A (100) issues an access token to the web application 160 (step S1103).
4. The user L sends the remittance request including information on the remittance amount to the web application 160 (step S1104).
5. The web application 160 sends the sent access token and a signature issue request including the transaction information such as the remittance amount to the signature server A (100) (step S1105).
6. The signature server A (100) determines whether or not the transaction information including the received remittance amount satisfies the permission rule (the permission range of the remittance amount) associated with the received access token. In a case where the determination result satisfies the permission rule, the signature server A (100) creates a digital signature of the transaction information corresponding to the received access token (step S1106).
7. The signature server A (100) sends the created digital signature to the web application 160 (step S1107).
8. The web application 160 attaches the received digital signature to a remittance transaction and issues the remittance transaction in the blockchains A and B (step S1108).
Meanwhile, the following steps S1205 and S1206 are sub-processes for verifying a permission rule for the user L. When the permission rule verification of the user L is not required, the signature server A (100) may execute step S1207 after the process in step S1204.
In the process of the registration phases for the permission rule illustrated in
The user L attaches transaction information for designating a remittance source (the account a), a remittance destination (the account b), and the remittance amount, to an access token issue request and sends the access token issue request to the signature server A (step S1202).
Therefore, based on the transaction information of the issue request, the signature server A (100) calculates a permission range of a permission rule (step S1203). The signature server A (100) sends the permission rule attached to the permission range (the permission range of the remittance amount) to the user L (step S1204).
The signature server A (100) determines a response (permission or rejection) of the user L for the permission rule (step S1205). When the response of the user L is permission (Yes in step S1205), the signature server A (100) proceeds to the process in step S1207. On the other hand, when the response of the user L is rejection (No in step S1205), based on the parameter permission range (the permission range of the remittance amount) by the user L, a permission rule with a permission range is generated (step S1206), and the process proceeds in step S1207.
Next, the signature server A (100) registers the permission rule with the permission range to which the generated parameter permission range is given inside the signature server A (step S1207). The signature server A (100) creates a new access token and registers the access token inside the signature server A in association with the transaction information received in step S1202 and the registered permission rule (step S1208). The signature server A (100) issues the created new access token to the web application 160 (step S1209). The signature server A (100) terminates series of processes related to the registration phases of the permission rule.
Next, in the process of the remittance phases illustrated in
Therefore, the signature server A (100) determines whether or not the transaction information including the remittance amount satisfies the permission rule with the permission range (the permission range of the remittance amount) associated with the access token (step S1212). When the determination result satisfies the permission rule (the remittance amount is within the permission range) (Yes in step S1213), the signature server A (100) proceeds to the process in step S1214. On the other hand, when the determination result does not satisfy the permission rule (the remittance amount is outside the permission range) (No in step S1213), the signature server A (100) proceeds to the process in step S1217.
In the process in step S1214, the signature server A (100) creates a digital signature of the transaction information corresponding to the received access token (step S1214). Next, the signature server A (100) sends the created digital signature to the web application 160 (step S1215).
Therefore, the web application 160 attaches the received digital signature to a remittance transaction and issues the remittance transaction in the blockchains A and B (step S1216). In step S1217, the signature server A (100) replies that a digital signature is not issued to the web application 160 (step S1217). After the processes in step S1216 or step S1217, the signature server A (100) terminates series of processes related to the remittance phases.
Next, a specific example of remittance will be described for the transaction process described with reference to
In step S1202, the user L exchanges the virtual currency A in the account a for the virtual currency B in the account b. As compared with the virtual currency A, the virtual currency B is more stable in value, and it is considered to construct a signature issue rule based on a value in the legal currency B. In this example, since a remittance source is the virtual currency A and the secret key is managed by the signature server A (100), it is assumed that the signature server A (100) sets a permission rule for a transaction.
Next, in step S1203, the signature server A (100) creates a permission range according to the following procedure. When the remittance amount included in transaction information at a time of setting a permission rule is X, a permission range described in the following equation (3) is calculated for the remittance amount Y included in a remittance request.
X*(1−K)≤Y≤X*(1+K) . . . (3)
(K is a constant satisfying 0<K<1)
At this time, when the signature server A (100) sets K=0.3 in advance and the remittance amount included in the transaction information at the time of creating a permission rule is virtual currency 100 points, the signature server A (100) creates the permission rule described in the following equation (4) as the permission range of the remittance amount Y included in the remittance request.
70≤Y≤130 . . . (4)
For example, when K=0.3 and the signature server A (100) receives a transaction of the transaction information 1300 illustrated in
In the process in step S1208, the signature server A (100) creates an appropriate character string (for example, “P8mOcv+6SW”) as a new access token. The signature server A (100) associates the permission rule (or the permission rule generated by the user L in step S1207) created in step S1204 with the access token and adds the permission rule as a new permission rule to the recording unit (a table) inside the signature server A (100).
Next, in the process in step S1209, the signature server A (100) issues the new access token of “P8mOcv+6SW” to the web application 160.
In step S1213, the signature server A (100) determines whether the remittance amount of the received remittance request 1700 satisfies the extracted permission rule 1800. For example, in the case of the remittance request 1700, it is assumed that a virtual currency rate fluctuates from 3.0 when a signature is permitted to 3.2 [virtual currency B/virtual currency A]. At this time, the remittance amount is 640 points by virtual currency B exchange (since the rate is 3.2 [virtual currency B/virtual currency A]). Since the remittance amount of 640 points is within a range of the remittance amount of the permission rule 1800 (see
On the other hand, for example, in the case of the remittance request 1700, it is assumed that a virtual currency rate largely fluctuates from 3.0 when the signature is permitted to 2.0 [virtual currency B/virtual currency A]. In this case, since a value of the remittance amount in virtual currency B is 400 points and outside the range of the remittance amount of the permission rule 1800, the signature server A (100) determines that “the permission rule is not satisfied” (No in step S1213). In this case, according to the process in step S1217, the signature server A (100) replies that a signature is not issued to the web application 160.
Next, in step S1214, the signature server A (100) creates a digital signature corresponding to transaction information only when it is determined that “the permission rule is satisfied (Yes in step S1213)” in step S1213. Next, in step S1215, the signature server A (100) sends the created digital signature to the web application 160.
In step S1216, the web application 160 attaches the received digital signature to a remittance transaction and issues the remittance transaction in the blockchains A and B.
According to Embodiment 2, as a currency rate fluctuates in a case where the user L performs remittance of exchanging between the virtual currencies A and B in the two blockchains A and B, it is possible to collate permission contents of the transaction of the user L with transaction contents at a time of performing an actual remittance. When issuing the access token at a time of permitting the transaction, the signature server A (100) calculates a permission range of the remittance amount, and issues a digital signature only in a case where the remittance amount at the time of the actual remittance is within the permission range. A transaction process of the remittance is permitted.
Therefore, the user L who performs a remittance operation of the virtual currency A in the blockchain A may verify whether or not the remittance amount is within an intended permission content even in a case where there is a time difference or a difference situation between when the transaction is permitted and when a transaction request is actually sent. Since the secret key 110 of the user L is held in the signature server A (100) without being deposited in the web application 160, a proxy transaction may be safely executed.
In Embodiment 3, an example in which a transaction permission rule is determined based on a past transaction of the user L will be described. Another example in which the signature server A (100) described in Embodiments 1 and 2 calculates a permission range of the remittance amount (corresponding to step S403 and step S1203) will be described.
When the remittance amount included in transaction information (500 and 1300) at a time of setting a permission rule is X, the signature server A (100) calculates a permission range described in the following equation (5) for the remittance amount Y included in the remittance request (900 and 1700).
X*(M/U)≤Y≤X*(M/L) . . . (5)
(M is an average of currency exchange rates for a most recent certain period, L is a lower limit of a 95% confidence interval of the currency exchange rate for the most recent certain period, and U is an upper limit of a 95% confidence interval of the currency exchange rate for the most recent certain period.)
The processing unit (the CPU 301) of the signature server A (100) records the currency exchange rate for the most recent certain period and the lower and upper limits of the confidence interval in a recording unit (such as the recording medium 305 or the like).
The currency exchange rate uses a rate of [virtual currency/base currency] after determining a base currency (a currency which is a center of a currency exchange). When calculating the upper and lower limits of the confidence interval, distribution of the value of the currency exchange rate is assumed to be normal distribution.
According to Embodiment 3, it is possible to calculate the permission range of the remittance amount based on a currency exchange rate of transactions performed for the past certain period. Therefore, based on information on a transaction process actually performed by the user L, it is possible to create the permission rule along an intended transaction of the user L. In the example described above, the permission range of the remittance amount is calculated based on the transactions performed by the user L for the past certain period, but the permission range of the remittance amount may be calculated based on transactions performed by another user for the past certain period without being limited thereto. For example, in a case or the like in which the user L does not perform a transaction in the past certain period, the user L may use the permission range of the remittance amount calculated based on transactions performed by the other user for the past certain period, and even a user with a small number of transactions may perform an appropriate remittance.
In Embodiment 4, variations of a smart contract (an application example to various systems) will be described. In each of the embodiments described above, the application example to the proxy authentication system for remittance of the virtual currency is described. Without being limited thereto, the same may be applied to a proxy authentication function of the web application 160 for issuing and operating a smart contract in a blockchain.
When the signature server A (100) verifies a request of issuing a digital signature from the web application 160, in a case of a transaction of executing a smart contract, a permission rule with a permission range may be set for an argument value. In this regard, in each of the embodiments described above, at the time of a remittance request, the signature server A (100) calculates the permission range of the remittance amount so as to create a permission rule.
As an application example to various systems, there is a smart contract of a side dish section in a supermarket, for example. The user gives surveying instrument an authority to “pay for 300 grams of side dish with one point of virtual currency” in advance. When the surveying instrument measures the side dish within a range of 250 to 350 grams, a smart contract interlocked with the surveying instrument may perform payment with the virtual currency on behalf of the user.
Without being limited to the virtual currency, a parameter (a setting value or a condition of the permission range) of a smart contract in various transaction processes including a transaction with a point card may be set in the same manner as in the embodiment described above. Therefore, it becomes possible to collate permission contents of the transaction of the user with transaction contents when using the actual system. The user of the web application may execute the transaction process with the remittance amount or the like along an intended permission content even in a case where there is a time difference or a difference situation between when the transaction is permitted and when a transaction request is actually sent.
Difference between Related Art and Embodiment
A difference between the related art and the embodiment will be described. In the related art, for example, an OAuth 2.0 technology is widely known as a mechanism for transferring an authority of a user to another application. This technology includes a mechanism in which an access authority of the user is partly transferred to a web application by using an access token so that the web application performs a process on behalf of the user. As described above, the access token is a symbol (a character string) indicating that only a specific operation is permitted on behalf of the user.
It is assumed that the user L posts a video to the video posting site 2010 (step S2003). In this case, the video posting site 2010 attaches the access token to the SNS site 2020 on behalf of the user L and posts the video (step S2004). In this manner, in a case where the user L registers a video in the video posting site 2010, by using an access token registered in advance, it is possible to perform proxy authentication when the video posting site 2010 automatically posts the video or the like to the SNS site 2020 with authority of the user L.
In order to sequentially describe a flow of proxy authentication in the system configuration illustrated in
After then, when there is a remittance request by the user L (step S2104), the web application 2160 requests the signature servers A and B (2101) to issue a digital signature (step S2105). The signature servers A and B (2101) use mechanism of the access token so as to verify whether transaction contents coincide with permission contents of the user L (step S2106), and issue a signature to the web application 2160 when the transaction contents coincide with the permission contents (step S2107). Therefore, the web application 2160 issues a transaction in the blockchains A and B as a proxy transaction of the user L by using the signature received from the signature servers A and B (2101) (step S2108).
In the system configuration in the related art, it is difficult to collate permission content intended by a user with actual transaction contents. For example, in an exchange of a virtual currency, a currency exchange rate fluctuates in a short time. For this reason, the transaction amount differs between when the user L permits the signature (at a time of issuing an access token in step S2101) and when the user actually performs remittance via the web application 2160 (at a time of issuing a remittance request in step S2104).
For description using a specific example, in a transaction system of a virtual currency, it is assumed that a rate of the virtual currency to a base currency (for example, US dollar) fluctuates, and a permission rule of the signature servers A and B (2101) is configured based on a value of the base currency. When a signature is permitted (“use date: September 14, 2018, 15:00”, in step S2101), it is assumed that “a rate of US dollar to virtual currency A is 2.0 USD/virtual currency A”. In this case, when 100 points of the virtual currency A are transferred, a value in US dollars is 200 USD. The signature servers A and B (2101) set a signature issue rule as “pass a signature when a user sends a transaction corresponding to 200 USD to a designated destination”.
Meanwhile, it is assumed that the rate of the virtual currency fluctuates until the remittance is actually permitted (“use date: September 14, 2018, 15:30”, in step S2104) and “a rate of US dollar to the virtual currency A is 1.8 USD/virtual currency A”. In this case, even in a transaction for transferring 100 points of the same virtual currency A, a value in US dollar is 180 USD, and the signature servers A and B (2101) may not issue a signature in step S2107 for this transaction.
In this manner, in the related art, in the virtual currency transaction system with proxy authentication to which the OAuth 2.0 technology is simply applied to, there is a time difference or a difference situation between when the user L permits a transaction and when a transaction request is actually sent, so it is not possible to collate permission contents with transaction contents. In this case, for example, the user may not verify whether or not the remittance amount is within an intended permission range of the remittance amount. In a case where the signature server does not issue a signature, the transaction itself may not be performed.
In the related art, the web application held the secret key of the user and exchanges information with the blockchain during the transaction process. Since the secret key is held by the web application, there is also a concern that proxy transactions may not be safely executed.
On the other hand, in the embodiment described above, the signature server sets a permission rule obtained by calculating a permission range of the remittance amount based on transaction information of the user, and determines whether or not a remittance request of the user is within the permission rule. Therefore, even when a currency exchange rate fluctuates due to a time difference or a difference situation between when the user of the web application permits the transaction and when the remittance request is actually sent, the signature server may verify whether the remittance amount of the user is within the intended permission range based on the permission rule. In addition, the user may perform remittance within the permission range of the remittance amount, and may reduce unintentional under or over the remittance amount.
In the embodiment, since the signature server holds the secret key of the user, a proxy transaction may be safely performed as compared with the related art. Even when linking a plurality of blockchain, the corresponding plurality of signature server respectively and distributively hold secret keys of the user, so that the proxy transaction may be safely executed even when linking the plurality of blockchain.
According to the embodiment described above, in response to reception of a token issue request including transaction information from a user, the signature server generates a permission rule for determining a permission range of transaction contents based on the transaction information, and transmits a token corresponding to the permission rule to the web application which processes a proxy transaction of the user. According to receiving a signature issue request based on a transaction request by the user including the token from the web application, whether or not to issue a digital signature corresponding to the signature issue request is determined, based on whether or not the transaction contents included in the transaction request are within the permission range determined by the permission rule corresponding to the token included in the signature issue request. Therefore, collation between permission contents of the transaction at the time of the token issue request and actual transaction contents is performed. For example, it is possible to verify whether or not the remittance amount of the user is within the permission range of the intended remittance amount. The signature server determines whether or not the actual transaction contents satisfy the permission range of the permission rule, and when the actual transaction contents satisfy the permission range, the signature server issues a digital signature and causes the web application (the Web app) to execute the remittance transaction. The transaction process performed in the embodiment may be applied to a proxy transaction by a blockchain and a signature server.
In a case where a transaction is remittance of an amount of money or points with currency values by a user, at a time of a token issue request from the user, the signature server determines a permission range of the remittance amount for a permission rule. At the time of an actual remittance request by the user, it is determined whether or not the remittance amount included in the remittance request is within the permission range in the permission rule. Therefore, it becomes possible to collate permission contents of the user at the time of the proxy transaction with actual transaction contents by applying to the remittance in the virtual currency or the like. Since a currency exchange rate fluctuates in a short time in the virtual currency or the like, there may be a situation in which even in a case of the same remittance amount, the transaction amount differs between when being permitted by the user (at a time of issuing an access token) and when the user actually issues a remittance request via the web application due to a change of the currency exchange rate. In this case, it is possible to verify whether or not the remittance amount is within the permission range, and even when the remittance amount fluctuates at the currency exchange rate at the time of actual remittance, in a case where the remittance amount is within the permission range, a digital signature is issued and a proxy transactions by the web application may be appropriately performed.
Only in a case where the remittance amount included in the remittance request is within the permission range in the permission rule, the signature server may determine that issue of a digital signature of the transaction information to the web application is permitted and issue the digital signature to the web application. Therefore, at the time of the remittance request when the user actually performs remittance, in a case where the remittance amount is within the permission range, the signature server issues a digital signature, and the user may perform a remittance transaction. On the other hand, when the remittance amount is outside the permission range, the remittance transaction is not permitted. The user may perform the remittance within the permission range of the remittance amount set in the signature server.
The signature server may hold authentication information for authenticating the transaction process by the user, and create a digital signature by using the authentication information. By keeping and holding the authentication information (a secret key) of the user in the signature server, it is not required for the web application to hold the secret key in the related art, and a proxy transaction may be safely executed.
For each token issue request including transaction information from the user, the signature server additionally creates information in which a remittance source, a remittance destination, a permission range of the remittance amount, and a token for each user are associated with each other in a table, as information of the permission rule. At the time of the actual remittance request by the user, a permission rule corresponding to the remittance request may be extracted by referring to the permission rule of the table, and it may be determined whether or not the remittance amount of the extracted permission rule is within the permission range of the remittance amount. Therefore, each time the user performs a transaction, a history of the transaction contents may be tabulated and accumulated, and a permission rule appropriate to each user may be created and remittance may be appropriately processed based on the appropriate permission rule for each user.
The signature server may calculate a value obtained by multiplying the remittance amount included in the transaction information at the time of creating the permission rule by a predetermined coefficient as a maximum value and a minimum value defining the permission range of the remittance amount. Therefore, the permission range of the remittance amount may be appropriately set, and an actual remittance process may be appropriately executed by using the permission range.
The signature server may calculate the permission range of the remittance amount by using the currency exchange rate included in the current or past transaction information of the user or another user. Therefore, it becomes possible to appropriately set the permission range of the remittance amount according to a transaction status of the user, and it becomes possible to appropriately process the remittance based on the permission rule appropriate to each user. Even a user with a small number of transactions may perform appropriate remittance by using transaction information of the other user.
The signature server may notify the user of the calculated permission rule, perform a determination using the permission rule by permission of the user, and perform the determination using a permission rule created by the user when being rejected by the user. Therefore, according to the permission rule created by the signature server, the remittance may be appropriately performed based on the permission of the user. Since the remittance may be performed by using the permission rule created by the user when the user rejects the permission rule created by the signature server, a transaction of the remittance according to the intention of the user may be performed.
The transaction may be a smart contract using one or a plurality of blockchain accounts, and at the time of a transaction when the smart contract is executed, a determination is performed by using a permission rule for a request for issuing a digital signature from the web application. Therefore, the transaction process described in the embodiment may be applied to various systems, and the transaction process in the applied various systems may be appropriately executed by using the permission rule.
The signature method described in the embodiment of the present disclosure may be enabled by causing a processor such as a server or the like to execute a program prepared in advance. The present signature method is recorded in a computer-readable recording medium such as a hard disk, a compact disc-read only memory (CD-ROM), a flash memory, or the like, and executed by being read from the recording medium by the computer. The present signing method may be distributed via a network such as the Internet.
All examples and conditional language provided herein are intended for the pedagogical purposes of aiding the reader in understanding the invention and the concepts contributed by the inventor to further the art, and are not to be construed as limitations to such specifically recited examples and conditions, nor does the organization of such examples in the specification relate to a showing of the superiority and inferiority of the invention. Although one or more embodiments of the present invention have been described in detail, it should be understood that the various changes, substitutions, and alterations could be made hereto without departing from the spirit and scope of the invention.
| Number | Date | Country | Kind |
|---|---|---|---|
| 2019-003858 | Jan 2019 | JP | national |
