Authorization system and authorization method

Abstract

To prevent impersonation that uses an invalid verifiable certificate.SOLUTION: When receiving a verifiable request from an authorization request device, a structure analysis unit determines that the verifiable request including a third verifiable certificate is authentic when attribute information about a delegator included in a second verifiable certificate is not inconsistent with attribute information about a delegator included in a first verifiable certificate, and the attribute information about a delegatee in the third verifiable certificate is not inconsistent with attribute information about the delegator in the first verifiable certificate and the attribute information about the delegator and a delegatee in the second verifiable certificate.SELECTED DRAWING: Figure 6

Description

Technical Field

[0001] The present invention relates to an authorization system and an authorization method, and is suitable for application to an authorization system related to a technique for preventing forgery when using, for example, Verifiable Credentials.

Background Art

[0002] In recent years, from the viewpoints of privacy protection and usability, there exists an authorization system that utilizes Verifiable Credentials as an example of verifiable certificates. In Non-Patent Document 1, an authorization system using VC (Verifiable Credential) is defined, and the basic functions of Issuer, Holder, Verifier, and VDR (Verifiable Data Registry), which are components of the authorization system, are disclosed. The VC describes the attribute information of the Holder who requests authorization from the Verifier. When the Verifier receives a VP (Verifiable Presentation) consisting of a plurality of VCs from the Holder, authorization is performed based on the attribute information described in each VC included in the VP.

Prior Art Documents

Non-Patent Documents

[0003]

Non-Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] However, when a malicious Holder includes a VC issued to a third party in a VP and requests authorization from the Verifier, there is a problem that the Verifier cannot detect the invalid VC even though the VC issued to the third party is invalid in verification.

[0005] The present invention has been made in consideration of the above points, and proposes an authorization system and an authorization method capable of preventing forgery using an invalid verifiable certificate.

Means for Solving the Problems

[0006] In order to solve such problems, in the present invention, an issuer device that issues a first verifiable certificate including the attribute information of the entruster and issues a second verifiable certificate including the attribute information of the entruster as entrustment information for the trustee as the entruster, and when the trustee receives the second verifiable certificate and the first verifiable certificate, an authorization request device that issues a verifiable request request configured by adding a third verifiable certificate including the attribute information of the trustee to the first verifiable certificate and the second verifiable certificate, and an authorization device that authorizes whether the verifiable request request received from the authorization request device is genuine. The authorization device, when receiving the verifiable request request from the authorization request device, can trace the attribute information of the entruster included in the second verifiable certificate without inconsistency with the attribute information of the entruster included in the first verifiable certificate, and the attribute information of the trustee in the third verifiable certificate can be traced without inconsistency with the attribute information of the entruster in the first verifiable certificate and the attribute information of the entruster and the trustee in the second verifiable certificate. In this case, it has a structure analysis unit that determines that the verifiable request request including the third verifiable certificate is genuine.

[0007] In the present invention, a first issuing step in which an issuer device issues a first verifiable certificate including the attribute information of the entruster, a second issuing step in which the issuer device issues a second verifiable certificate including the attribute information of the entruster as entrustment information for the trustee as the entruster, and when the authorization request device receives the second verifiable certificate and the first verifiable certificate by the trustee, a second issuing step of issuing a verifiable request request configured by adding a third verifiable certificate including the attribute information of the trustee to the first verifiable certificate and the second verifiable certificate, and when the structure analysis unit of the authorization device receives the verifiable request request from the authorization request device, the attribute information of the entruster included in the second verifiable certificate can be traced without inconsistency with the attribute information of the entruster included in the first verifiable certificate, and the attribute information of the trustee in the third verifiable certificate can be traced without inconsistency with the attribute information of the entruster in the first verifiable certificate and the attribute information of the entruster and the trustee in the second verifiable certificate. A verifiable request verification step of determining that the verifiable request request including the third verifiable certificate is genuine is provided.

Effect of the Invention

[0008] According to the present invention, it is possible to prevent forgery using an invalid verifiable certificate.

Brief Description of the Drawings

[0009]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Figure 16

Figure 17

Figure 18

Figure 19

Figure 20

Figure 21

Mode for Carrying Out the Invention

[0010] Hereinafter, based on the drawings, one embodiment of the present invention will be described in detail. (1) First Embodiment FIG. 1 is a system configuration diagram showing a configuration example of an authorization system 1000 according to the first embodiment. The authorization system 1000 includes, as its components, for example, an Issuer, a Holder, a Verifier, a Verifier server 300, and a Verifiable Data Registry (hereinafter abbreviated as "VDR"). The authorization system 1000 performs authorization using, for example, Verifiable Credential (VC).

[0011] In this embodiment, each term is used as follows. "Issuer" has a function of issuing a VC in response to a request from a requester. "Holder" has a function of holding the issued VC. "Verifier" has a function of performing verification authorization on the issued VC and determining whether to authorize the provision of a predetermined service according to the result of the verification authorization. "Entrustor" has a function of entrusting a predetermined request to an entrusted person. "Entrusted person" has a function of receiving a predetermined request from the entrustor. "Issuance target" indicates the target to which the VC is issued. In this embodiment, "Issuer", "Holder", "Verifier", "Entrustor", "Entrusted person", and "Issuance target" are each also referred to as an entity and are, for example, any of a terminal, a device, and a system.

[0012] The Issuer issues a VC including the attribute information of the entrustor in response to a request from the entrustor who is the requester, or issues a VC including the attribute information of the entrusted person in response to a request from the entrusted person who is the requester. The Holder holds the issued VC. When the Holder makes a verifiable request to the Verifier, the Holder passes a plurality of held VCs as a Verifiable Presentation (VP) to the Verifier.

[0013] The Verifier performs verification authorization in response to a verifiable request using the received Verifiable Presentation (VP), and can provide a predetermined service after authorization according to the verification authorization result.

[0014] The authorization system 1000 includes, for example, an Issuer server 100, a Holder terminal 200, a VDR 400, and a network 500. The Issuer server 100, the Holder terminal 200, the Verifier server 300, and the VDR 400 are connected to each other via the network 500 and can exchange data and the like.

[0015] The Issuer server 100 is at least one computer that functions as an Issuer, creates a VC (Verifiable Credential) including the attribute information of the requester, and issues it to the Holder. Details of the Issuer server 100 will be described later.

[0016] The Holder terminal 200 is a terminal device that functions as a Holder, creates a VP by adding its own attribute information to the VC received from the Issuer server 100, and issues it to the Verifier server 300 as a Verifier. Details of the Holder terminal 200 will be described later.

[0017] The Verifier server 300 is at least one computer that functions as a verifier, performs verification authorization in response to a verifiable request using, for example, a VP, and provides a predetermined service after authorization according to the verification authorization result. The Verifier server 300 performs verification authorization based on the content of the VP received from the Holder terminal 200 along with the verifiable request, and when the provision of a specific service is authorized according to the verification authorization result, provides the specific service to the requester of the verifiable request. Details of the Verifier server 300 will be described later.

[0018] FIG. 2 is a block diagram showing an example of the hardware configuration of the Issuer server 100 shown in FIG. 1. Note that since the Holder terminal 200, the Verifier server 300, and the VDR 400 have substantially the same configuration as the Issuer server 100 except for some differences in configuration and processing speed, the description thereof is omitted.

[0019] The Issuer server 100 is at least one computer, and includes a processor 1, a main storage device 2, an auxiliary storage device 3, an input device 4, an output device 5, and a communication I / F 6. The processor 1 is a so-called CPU (Central Processing Unit) and executes a program, for example. The main storage device 2 is a memory having a storage area capable of storing a program and data executed by the processor 1, for example. The auxiliary storage device 3 is a so-called cache and has a storage area in which programs and data stored in the main storage device 2 are temporarily stored. The input device 4 is a mouse or a keyboard that receives operations from the outside. The output device 5 is a so-called display. The communication I / F 6 performs data transfer and the like with the outside via the network 500.

[0020] FIG. 3 is a diagram showing an example of a VP. In the present embodiment, the VP includes, for example, n VCs (VC1 to VC n ), ID Holder , and an electronic signature Holder . The ID Holder indicates the ID (Identifier) of the owner (Holder) who creates and holds the VP. The electronic signature Holder indicates the electronic signature of the Holder of the VP. The electronic signature is, for example, an electronic signature using a public key, and this electronic signature prevents the VP from being forged.

[0021] VC1 to VC n each have an ID 発行対象者 , an ID Issuer , two pieces of attribute information, an expiration date, an ID, and an electronic signature. The number of attributes included in the VC is not limited to two, and any number may be included.

[0022] The ID 発行対象者 indicates the issuer of the VC. For example, the ID 発行対象者a indicates that the issuer is "Issuer a".

[0023] IDIssuer indicates the ID of the Issuer. For example, ID IssuerA indicates that the Issuer is "IssuerA".

[0024] The two pieces of attribute information respectively indicate the attribute information of the entity to which the VC is issued. The expiration date indicates the expiration date of the VC. In this embodiment, a VC that has passed the expiration date is treated as invalid, for example. ID indicates the identifier of the VC. For example, ID VC1 indicates the identifier of the VC1. The electronic signature indicates the electronic signature attached to the VC. For example, electronic signature IssuerA indicates that it is the electronic signature of IssuerA. The electronic signature is, for example, an electronic signature using a public-key cryptosystem, and the presence or absence of forgery of the VC can be determined by this electronic signature.

[0025] FIG. 4 is a block diagram showing an example of the software configuration of the Issuer server 300 shown in FIG. 1. The Issuer server 300 includes a VC issuance reception unit 101, a VC issuance unit 102, a VC invalidation information registration unit 103, and a public key registration unit 104.

[0026] The VC issuance reception unit 101 receives the issuance of a VC in response to a request from the requester. Here, the requester is at least one of the principal and the agent. The request may or may not include the attribute information of the requester.

[0027] The VC issuance unit 102 issues a VC including the attribute information of the requester. At this time, the attribute information included in the VC issuance request may be included in the VC, or the attribute information of the requester managed by the Issuer may be included in the VC. The VC invalidation information registration unit 103 registers the invalidation information of the invalid VC in the VDR 400. The public key registration unit 104 registers the public key corresponding to the private key used when creating the electronic signature in the VDR 400.

[0028] FIG. 5 is a block diagram showing an example of the software configuration of the Holder terminal 200 shown in FIG. 1. The Holder terminal 200 includes a VC issuance request unit 201, a VC management unit 202, a VP creation unit 203, a VP presentation unit 204, a VC management store 205, and a public key information registration unit 206 capable of registering information related to a public key.

[0029] The VC issuance request unit 201 issues a request for the issuance of a VC to the Issuer server 100 as a request source. Here, the request source refers to at least one of the principal and the agent. The request may or may not include the attribute information of the request source.

[0030] The VC management unit 202 stores and manages the VC issued by the Issuer server 100 in a storage area (not shown).

[0031] The VP creation unit 203 creates a VP including at least one VC and issues it to the Verifier server 300. The VP presentation unit 204 presents the created VP to the Verifier server 300. The VC management store 205 stores and manages the VC. The public key information registration unit 206 registers the public key corresponding to the private key used to create the electronic signature in the VDR 400.

[0032] FIG. 6 is a block diagram showing an example of the software configuration of the Verifier server 300 shown in FIG. 1. The Verifier server 300 includes an interface 310, a VP structure analysis unit 320, a VP verification unit 330, a VC verification unit 340, an authorization policy verification unit 350, a VP structure data storage unit 360, an expiration information cache unit 370, a public key cache unit 380, and an authorization policy storage unit 390. The authorization policy storage unit 390 stores an authorization policy indicating criteria for determining whether to authorize the provision of a predetermined service. For example, it stores an authorization policy describing conditions related to the trust of the Issuer and conditions related to attribute information (including conditions).

[0033] The interface 310 has a VP reception unit 311 and an authorization determination result return unit 312. The VP reception unit 311 receives a VP. The authorization determination result return unit 312 returns an authorization determination result based on the authorization verification result by the Verifier server 300 to the requester.

[0034] The VP structure analysis unit 320 includes an Issuer-based structure analysis unit 321, an issue target person-based structure analysis unit 322, and an expired VC analysis unit 323.

[0035] The Issuer-based structure analysis unit 321 performs a structure analysis on the VP based on the Issuer and generates Issuer-based VP structured data. The issue target person-based structure analysis unit 322 performs a structure analysis on the VP based on the issue target person and generates issue target person-based VP structured data. In this embodiment, the structured data is data that structures the relationships of a plurality of VCs such as Issuer, Holder, principal, and agent.

[0036] The expired VC analysis unit 323 discriminates valid VCs from the Issuer-based VP structured data, the issue target person-based VP structured data, and the information on invalid VCs in the expired information cache unit 370, and creates Issuer-based valid VP structured data and issue target person-based valid VP structured data. At this time, the expired VC analysis unit 323 also detects forgery. When forgery is detected, the invalid VCs are deleted from each valid VP structured data. Each valid VP structured data is stored in the VP structure data storage unit 360.

[0037] The VP verification unit 330 is an example of a verifiable request verification unit and includes a Holder expired information acquisition unit 331, a Holder validity verification unit 332, a Holder public key acquisition unit 333, and a Holder signature verification unit 334.

[0038] The Holder expired information acquisition unit 331 is the ID described in the VP HolderUse Holder to search the revocation information cache unit 370 to determine whether the revocation information of the Holder is stored therein. Here, in the revocation information cache unit 370, when the Holder has been revoked, the revocation information of the Holder may be stored. If the revocation information of the Holder is stored in the revocation information cache unit 370, the Holder revocation information acquisition unit 331 acquires the revocation information of the corresponding Holder. On the other hand, if the revocation information of the Holder is not stored, the ID Holder is used to request the revocation information of the Holder from the VDR 400. When the corresponding revocation information is stored in the VDR 400, the revocation information of the Holder is acquired from the VDR 400. The Holder revocation information acquisition unit 331 stores this revocation information in the revocation information cache unit 370.

[0039] The Holder validity verification unit 332 determines whether the Holder has been revoked based on the revocation information of the Holder.

[0040] The Holder public key acquisition unit 333 uses the ID Holder to search the public key cache unit 380 to determine whether the public key of the Holder is stored therein. Here, the public key of the Holder may be stored in the public key cache unit 380. If the public key of the Holder is stored in the public key cache unit 380, the Holder validity verification unit 332 acquires the public key. On the other hand, if the public key of the Holder is not stored, the ID Holder is used to request the public key of the Holder from the VDR 400. When the corresponding public key is stored in the VDR 400, the public key of the Holder is acquired from the VDR 400. The Holder validity verification unit 332 stores this public key in the public key cache unit 380.

[0041] The Holder signature verification unit 334 verifies the electronic signature of the Holder using the hash value of the VP, the electronic signature by the Holder, and the public key of the Holder. Thereby, it is possible to determine whether the VP has been forged.

[0042] The VC verification unit 340 includes an issuance target invalidation information acquisition unit 341, an issuance target validity verification unit 342, an Issuer invalidation information acquisition unit 343, an Issuer validity verification unit 344, a VC invalidation information acquisition unit 345, a VC validity verification unit 346, an Issuer public key acquisition unit 347, and an Issuer signature verification unit 348.

[0043] The issuance target invalidation information acquisition unit 341 uses the ID 発行対象者 described in each VC included in the Issuer-based valid VP structured data to search the invalidation information cache unit 370 for whether the invalidation information of each issuance target is stored. At this time, each VC included in the issuance target-based valid VP structured data may also be used. When the invalidation information of each issuance target is stored, the issuance target invalidation information acquisition unit 341 acquires the invalidation information. On the other hand, when the issuance target invalidation information acquisition unit 341 is not stored, it uses the ID 発行対象者 to request the invalidation information of the issuance target from the VDR 400, and when the corresponding invalidation information is stored in the VDR 400, it acquires the invalidation information of the issuance target from the VDR 400. In addition, the issuance target invalidation information acquisition unit 341 stores this invalidation information in the invalidation information cache unit 370. Also, this invalidation information is passed to the invalid VC analysis unit 323 for invalid VC analysis.

[0044] The issuance target validity verification unit 342 determines the invalidation status of each Issuer from the invalidation information of each Issuer.

[0045] The Issuer invalidation information acquisition unit 343 uses the ID Issuer to search the invalidation information cache unit 370 for whether the invalidation information of each Issuer is stored for each Issuer of each VC included in the Issuer-based valid VP structured data. When the Issuer invalidation information acquisition unit 343 is stored, it acquires the invalidation information. On the other hand, when the Issuer invalidation information acquisition unit 343 is not stored, it uses the ID IssuerUse it to request the Issuer's invalidation information from the VDR400, and when the corresponding invalidation information is stored in the VDR400, obtain the Issuer's invalidation information from the VDR400. Also, the Issuer invalidation information acquisition unit 343 stores this invalidation information in the invalidation information cache unit 370.

[0046] The Issuer validity verification unit 344 determines the presence or absence of invalidation of each Issuer from the invalidation information of each Issuer. The VC invalidation information acquisition unit 345 requests the invalidation information of each VC from the VDR400 for each VC included in the issuance target person-based valid VP structured data (which may be the Issuer-based valid VP structured data), and obtains the invalidation information of each VC from the VDR400.

[0047] The VC validity verification unit 346 determines the presence or absence of invalidation from the invalidation information of each VC for each VC included in the issuance target person-based valid VP structured data (which may be the Issuer-based valid VP structured data). The Issuer public key acquisition unit 347 searches the public key cache unit 380 for the Issuer's public key using the ID Issuer If the public key is stored, the Issuer public key acquisition unit 347 obtains the public key. On the other hand, if the public key is not stored, the Issuer public key acquisition unit 347 requests the Issuer's public key from the VDR400 using the ID Issuer When the corresponding public key is stored in the VDR400, obtain the Issuer's public key from the VDR400. Also, the Issuer public key acquisition unit 347 stores this public key in the public key cache unit 380. Also, pass this invalidation information to the invalid VC analysis unit 323 to perform invalid VC analysis.

[0048] The Issuer signature verification unit 348 verifies the electronic signature of the Issuer for each VC included in the issuance target-based valid VP structured data (which may also be Issuer-based) using the hash value of the VC, the electronic signature by the Issuer, and the public key of the Issuer. When there is a VC for which the verification fails, it is considered that the corresponding VC is invalid, and this invalidation information is passed to the invalid VC analysis unit 323 for invalid VC analysis.

[0049] The authorization policy verification unit 350 includes an authorization policy acquisition unit 351, an attribute information verification unit 352, and an Issuer trust verification unit 353.

[0050] The authorization policy acquisition unit 351 acquires the authorization policy from the authorization policy storage unit 390. The attribute information verification unit 352 verifies whether the VC included in the conditions of the attribute information described in the authorization policy and the issuance target-based valid VP structured data (which may also be Issuer-based valid VP structured data) satisfies the authorization policy from the attribute information of each VC.

[0051] The Issuer trust verification unit 353 is an example of a trust verification unit. It acquires the Issuer trust information (issuer's trust information) described later from the VDR 400, and verifies whether the authorization policy is satisfied from this Issuer trust information (issuer's trust information), the conditions regarding the trust of the Issuer described in the authorization policy, and the information of the Issuer included in the Issuer-based valid VP structured data. When the attribute information verification unit 352 and the Issuer trust verification unit 353 satisfy the authorization policy, they authorize the provision of a predetermined service, while when they do not satisfy the authorization policy, they do not authorize the provision of a predetermined service.

[0052] FIG. 7 is a diagram showing an example of the issuance target-based VP structured data. In the illustrated example, the VCs related to the issuance target are structured, for example, as a tree structure. The issuance target-based VP structured data is such that, for example, issuance target a acts as an Issuer towards issuance target b who is a Holder, and issues VC3 as an example of a verifiable certificate. Issuance target a has, for example, VC1 and VC2, and issuance target b has, for example, VC3, VC4, and VC5 as examples of verifiable certificates.

[0053] In this embodiment, by taking advantage of the characteristics of VP and VC and performing the following processes, the relationships between issuance targets are extracted. For example, each ID included in each VC is used for the extraction of relationships. Procedure 1. Identify the entity that is both an Issuer and an issuance target from the information of each VC (issuance target a in the figure). As an example, the case where VC3 is issued by issuance target a will be described. Procedure 2. Identify the issuance target (issuance target b) for the VC (VC3) for which the entity identified in Procedure 1 is the Issuer. Procedure 3. Regarding the relationship between the issuance targets from Procedures 1 and 2, assume that there is a relationship between the entities identified in Procedures 1 and 2. Also, assume that the entrusting party has a higher-level relationship than the entrusted party. In this example, it is determined that issuance target a has a higher-level relationship than issuance target b. Procedure 4. Identify the issuance target that is the same as the Holder.

[0054] Figure 8 is a diagram showing a specific example of Issuer-based VP structured data. In the illustrated example, the VCs associated with the Issuer are structured, for example, as a tree structure. The Issuer-based VP structured data is such that IssuerA has, for example, VC1 and VC4, IssuerB has, for example, VC2 and VC5, and IssuerC has, for example, VC3. For the premise of the illustrated example, assume that for VC3, IssuerC = issuance target a. For example, the entrusting party is issuance target a and the entrusted party is issuance target b.

[0055] FIG. 9 is a block diagram showing a configuration example of the VDR400. The VDR400 includes ID invalidation information 401, VC invalidation information 402, a public key 403, and Issuer trust information 404.

[0056] The ID invalidation information 401 is managed, for example, in the form of (ID Issuer1 , invalidation information Issuer1 ) if the Issuer is Issuer1. The VC invalidation information 402 is managed, for example, in the form of (ID VC1 , invalidation information VC1 ) if the VC is VC1. The public key 403 is managed, for example, in the form of (ID Issuer1 , pk Issuer1 ) if the Issuer is Issuer1. Note that pk indicates the public key. The Issuer trust information 404 is information indicating the degree of reliability regarding the Issuer.

[0057] FIG. 10 is a diagram showing an overview of the VP approval process. When receiving a VP, the VP verification unit 330 delivers the VP to the VP structure analysis unit 320. The VP structure analysis unit 320 performs a predetermined structure analysis on the VP to create structured data. The structured data here is, for example, at least one of the above-described issuance target person-based valid VP structured data and Issuer-based valid VC structured data, and when there is no need to particularly distinguish between the two in this embodiment, it is simply collectively referred to as "structured data".

[0058] The VC verification unit 340 is an example of a verifiable certificate verification unit. When it determines that some VCs in the structured data received from the VP structure analysis unit 320 are invalid, it delivers the invalidation information about the structured data to the VP structure analysis unit 320. In response, the VP structure analysis unit 320 registers the invalidation for the structured data and deletes the some VCs from the structured data. As a result, thereafter, the VC verification unit 340 targets the remaining structured data with the some VCs deleted from the structured data for verification. By deleting the invalidated structured data in this way, it becomes unnecessary to refer to the some VCs thereafter, and thus the processing cost can be reduced.

[0059] When the authorization policy verification unit 350 determines that some VCs of the structured data received from the VP structure analysis unit 320 have expired, it transfers the expiration information about the structured data to the VP structure analysis unit 320. In response, the VP structure analysis unit 320 registers the expiration of the some VCs for the structured data and deletes the some VCs from the structured data. As a result, thereafter, the authorization policy verification unit 350 does not need to verify the some VCs, and it suffices to verify the remaining structured data from which the some verifiable certificates have been deleted from the structured data, so that the processing cost can be reduced.

[0060] When the authorization policy verification unit 350 determines that the structured data received from the VP structure analysis unit 320 has not expired, it determines whether the structured data violates the authorization policy, and outputs an authorization determination result regarding whether it can be authorized. The authorization policy verification unit 350 authorizes the structured data when it does not violate the authorization policy, while it does not authorize the structured data when it violates the authorization policy.

[0061] (VP Structure Analysis Process (First Time)) FIG. 11 is a flowchart showing an example of the procedure of the VP structure analysis process (first time). The VP structure analysis process shown in FIG. 11 is the VP structure analysis process executed for the first time by the VP structure analysis unit 320.

[0062] In step S101, the issuance target person-based structure analysis unit 322 acquires a VP from the VP reception unit 311 and creates issuance target person-based VP structured data.

[0063] In step S102, the issuance target person-based structure analysis unit 322 acquires a VP from the VP reception unit 311 and creates Issuer-based VP structured data.

[0064] In step S103, the invalid VC analysis unit 323 detects at least one piece of structured data (hereinafter also referred to as "structured data group") that cannot be traced from the Holder among the issuer-targeted VP structured data. In the present embodiment, "traceable" means that there is no inconsistency in the attribute information included in the VC or VP, and it is not recognized as forgery, for example, in the relationship between the principal and the agent.

[0065] In step S104, the invalid VC analysis unit 323 determines whether there is a structured data group that cannot be traced from the Holder.

[0066] If there is no structured data group that cannot be traced from the Holder, the invalid VC analysis unit 323 executes step S105. In step S105, the invalid VC analysis unit 323 sets the issuer-targeted VP structured data as the issuer-targeted valid VP structured data. In step S106, the invalid VC analysis unit 323 sets the Issuer-based VP structured data as the Issuer-based valid VP structured data.

[0067] On the other hand, if there is a structured data group that cannot be traced from the Holder, the invalid VC analysis unit 323 executes step S107. In step S107, the invalid VC analysis unit 323 sets, as the issuer-targeted valid VP structured data, all of the issuers included in the structured data group that cannot be traced from the Holder and the VCs hanging from the issuers after deletion. In this way, it is possible to detect that the VCs that cannot be traced from the Holder are forged VCs. By detecting and deleting the VCs used for forgery, only valid VCs that are not forgeries can be used for subsequent verification. Also, by not using the invalid VCs due to forgery in subsequent verification, the processing cost can be reduced.

[0068] Next, in step S108, the invalid VC analysis unit 323 deletes the deleted VC from the Issuer-based VP structured data to obtain the Issuer-based valid VP structured data.

[0069] Furthermore, in step S109, the expiration VC analysis unit 323 passes the issuance target person-based valid VP structured data and the Issuer-based valid VP structured data to the VC verification unit 340.

[0070] FIG. 12 is a sequence chart showing an example of the procedure of the VP verification process. The VP verification process is executed by the VP verification unit 330. In step S201, the Holder expiration information acquisition unit 331 searches the expiration information cache unit 370 based on the ID Holder In step S202, if there is expiration information Holder corresponding to the ID Holder the Holder expiration information acquisition unit 331 acquires the expiration information Holder from the expiration information cache unit 370. On the other hand, if there is no expiration information Holder corresponding to the ID Holder the Holder expiration information acquisition unit 331 executes step S203.

[0071] In step S203, the Holder expiration information acquisition unit 331 searches the VDR 400 based on the ID Holder In step S204, if there is expiration information Holder corresponding to the ID Holder the Holder expiration information acquisition unit 331 acquires the expiration information Holder from the VDR 400.

[0072] If there is expiration information Holder corresponding to the ID Holder in step S205, the Holder expiration information acquisition unit 331 stores the expiration information Holder in the expiration information cache unit 370. On the other hand, if the expiration information Holder corresponding to the ID Holder cannot be obtained, the Holder expiration information acquisition unit 331 does not access the expiration information cache unit 370.

[0073] Next, in step S206, the Holder validity verification unit 332 verifies the validity of the Holder.

[0074] In step S207, the Holder public key acquisition unit 333 searches the public key cache unit 380 based on the ID Holder . In step S202, if there is a public key Holder corresponding to the ID Holder , the Holder public key acquisition unit 333 acquires the public key Holder from the public key cache unit 380.

[0075] On the other hand, if there is no public key Holder corresponding to the ID Holder , in step S209, the Holder public key acquisition unit 333 searches the VDR 400 based on the ID Holder . In step S210, if there is a public key Holder corresponding to the ID Holder , the Holder public key acquisition unit 333 acquires the public key Holder from the VDR 400. In step S210, the Holder public key acquisition unit 333 stores the public key Holder in the public key cache unit 380.

[0076] Next, in step S212, the Holder signature verification unit 334 verifies the signature attached to the VP.

[0077] FIG. 13 is a diagram showing an example of detecting forgery using issuer-based VP structured data. This detection of forgery is executed by the VP structure analysis unit 320. In the illustrated issuer-based VP structured data regarding a certain VP, the left part is the same as the issuer-based VP structured data shown in FIG. 7 described above, and it is determined that there is no forgery. However, in the right part, VC6 and VC7 are hanging on the issuer d, and since these VC6 and VC7 are not included in the VCs of the right issuer-based VP structured data, it is determined that they cannot be traced, and it is detected that there is forgery.

[0078] FIG. 14 is a diagram showing a specific example of detecting impersonation. First, the authorization system 1000 according to the present embodiment will be described.

[0079] The principal issues a request to the Issuer server 100 and receives the issuance of a VC (hereinafter also referred to as "VC1") including the principal's own attribute information from the Issuer server 100, and becomes the Holder of the VC1. The principal who has received the issuance of the VC1 thus corresponds to the Holder of the VC1 (hereinafter also referred to as "Holder1") and corresponds to the Holder terminal 200. For example, when the principal commissions the Verifier server 300 to issue a request for providing a predetermined service (service provision request) and commissions the recipient as the principal, the principal passes two types of VCs to the recipient as follows.

[0080] That is, first, the principal passes a VC (hereinafter also referred to as "VC1") including the principal's own attribute information as the principal of the request to the recipient. Second, as described above, although the principal is the Holder, as the Issuer for the recipient, in order to commission the recipient, the principal (Holder1) issues a VC (hereinafter also referred to as "VC2") including the principal's (Holder1) attribute information as the commission information from the principal (Holder1) to the recipient. At this time, VC1 and VC2 may be passed together as a VP, or may be passed separately. The recipient becomes the Holder of the issued VC2 (hereinafter also referred to as "Holder2") and corresponds to the Holder terminal 200. That is, the principal may be the Holder of the VC2 and also become the Issuer of the VC2 for the recipient.

[0081] Furthermore, the assignee (Holder2) issues a request to the Issuer server 100 to receive the issuance of a VC (hereinafter also referred to as "VC3") including its own attribute information as the assignee from the Issuer server 100, and becomes the Holder of the VC3. This assignee creates a VP (a verifiable request for receiving a predetermined service) by adding VC3 to the received VC1 and VC2, and issues it to the Verifier.

[0082] The Vefifier server 300 performs verification and authorization in response to the verifiable request using the received VP, and can provide a predetermined service after authorization according to the verification and authorization result. Based on the content of the VP, the Vefifier server 300 determines, for example, whether Holder1 is the principal in the relationship with Holder2 and Holder2 is the assignee in the relationship with Holder1 from the attribute information of the principal in VC2 and the attribute information in VC1 (also referred to as the "authorization condition"). If the authorization condition is met, it is determined that the VP is genuine, while if the authorization condition is not met, it is determined that the VP is not genuine.

[0083] The authorization system 1000 according to this embodiment includes an Issuer server 100 as an example of an issuer device that issues a VC1 including the attribute information of the authorizer, and issues a VC2 including the attribute information of the authorizer as authorization information for the trustee as the authorizer; a Holder terminal 200 as an example of an authorization request device that, when the trustee receives the VC2 and VC1, issues a VP configured by adding a VC3 including the attribute information of the trustee to the VC1 and VC2; and a Verifier server 300 as an example of an authorization device that authorizes whether the VP received from the Holder terminal 200 is genuine. This Verifier server 300 includes a VP structure analysis unit 320 as follows. That is, when receiving a VP from the Holder terminal 200, this VP structure analysis unit 320 determines that the VP including the VC3 is genuine if the attribute information of the authorizer included in the VC2 can be traced without inconsistency with the attribute information of the authorizer included in the VC1, and the attribute information of the trustee in the VC3 can be traced without inconsistency with the attribute information of the authorizer in the VC1 and the attribute information of the authorizer and the trustee in the VC2.

[0084] The authorization method according to this embodiment includes: a first issuance step in which the Issuer server 100 issues a VC1 including the attribute information of the authorizer; a second issuance step in which the Issuer server 100 issues a VC2 including the attribute information of the authorizer as authorization information for the trustee as the authorizer; a second issuance step in which the Holder terminal 200 issues a VP configured by adding a VC3 including the attribute information of the trustee to the VC1 and VC2 when the trustee receives the VC2 and VC1; and a verifiable request verification step in which the VP structure analysis unit 320 of the Verifier server 300 determines that the VP including the VC3 is genuine if the attribute information of the authorizer included in the VC2 can be traced without inconsistency with the attribute information of the said authorizer included in the VC1, and the attribute information of the trustee in the VC3 can be traced without inconsistency with the attribute information of the authorizer in the VC1 and the attribute information of the authorizer and the trustee in the VC2.

[0085] In this embodiment, when the VP structure analysis unit 320 cannot be traced without inconsistency as described above, it is excluded from the subsequent verification targets.

[0086] FIGS. 15 and 16 are sequence charts showing an example of the procedure of the VC verification process. The sequence chart shown in FIG. 16 is continuous with the sequence chart shown in FIG. 15. The VC verification process is executed by the VC verification unit 340 of the Verifier server 300.

[0087] In step S301 shown in FIG. 15, the issuance target person invalidation information acquisition unit 341 searches the invalidation information cache unit 370 based on the ID 発行対象者 In step S302, if there is invalidation information 発行対象者 corresponding to the ID 発行対象者 the issuance target person invalidation information acquisition unit 341 acquires the invalidation information 発行対象者 from the invalidation information cache unit 370.

[0088] On the other hand, if there is no invalidation information 発行対象者 corresponding to the ID 発行対象者 in step S303, the issuance target person invalidation information acquisition unit 341 searches the VDR 400 based on the ID 発行対象者 In step S304, if there is invalidation information 発行対象者 corresponding to the ID 発行対象者 the issuance target person invalidation information acquisition unit 341 acquires the invalidation information 発行対象者 from the VDR 400.

[0089] If there is invalidation information 発行対象者 corresponding to the ID 発行対象者 in step S305, the issuance target person invalidation information acquisition unit 341 stores the invalidation information 発行対象者 in the invalidation information cache unit 370. On the other hand, if the invalidation information Holder corresponding to the ID Holder cannot be obtained, the issuance target person invalidation information acquisition unit 341 does not access the invalidation information cache unit 370.

[0090] In step S306, the issuance target validity verification unit 342 verifies the validity of the issuance target. Next, in step S307, the expiration VC analysis unit 323 verifies the validity of the VC. In step S308, the Issuer expiration information acquisition unit 343 searches the expiration information cache unit 370 based on the ID Issuer . In step S309, if there is expiration information Issuer corresponding to the ID Issuer , the Issuer expiration information acquisition unit 343 acquires the expiration information Issuer from the expiration information cache unit 370.

[0091] On the other hand, if there is no expiration information Issuer corresponding to the ID Issuer , in step S310, the Issuer expiration information acquisition unit 343 searches the VDR 400 based on the ID Issuer . In step S311, if there is expiration information Issuer corresponding to the ID Issuer , the Issuer expiration information acquisition unit 343 acquires the expiration information Issuer from the VDR 400. If there is expiration information Issuer corresponding to the ID Issuer , in step S312, the Issuer expiration information acquisition unit 343 stores the expiration information Issuer in the expiration information cache unit 370. On the other hand, if the expiration information Issuer corresponding to the ID Issuer cannot be acquired, the Issuer expiration information acquisition unit 343 does not access the expiration information cache unit 370.

[0092] In step S313, the Issuer validity verification unit 344 verifies the validity of the Issuer. Next, in step S314, the expiration VC analysis unit 323 verifies the validity of the VC in the same manner as in step S307 described above.

[0093] In step S315 shown in FIG. 16, the VC expiration information acquisition unit 345 searches the expiration information cache unit 370 based on the ID VC . In step S316, for the ID VCInvalidation information corresponding thereto VC If there is, the VC invalidation information acquisition unit 345 acquires the invalidation information VC from the invalidation information cache unit 370. On the other hand, for the ID VC if there is no corresponding invalidation information VC the VC invalidation information acquisition unit 345 executes step S317.

[0094] In step S317, the VC invalidation information acquisition unit 345 searches the VDR 400 based on the ID VC In step S204, if there is invalidation information VC corresponding to the ID VC the VC invalidation information acquisition unit 345 acquires the invalidation information VC from the VDR 400. If there is invalidation information VC corresponding to the ID VC in step S205, the VC invalidation information acquisition unit 345 stores the invalidation information VC in the invalidation information cache unit 370. On the other hand, if the invalidation information VC corresponding to the ID VC cannot be obtained, the VC invalidation information acquisition unit 345 does not access the invalidation information cache unit 370.

[0095] In step S320, the VC validity verification unit 346 verifies the validity of the VC. Next, in step S321, the invalid VC analysis unit 323 verifies the validity of the VC in the same manner as step S307 described above.

[0096] If the VC is valid, in step S322, the Issuer public key acquisition unit 347 searches the public key cache unit 380 based on the ID Issuer In step S323, if there is a public key Issuer corresponding to the ID Issuer the Issuer public key acquisition unit 347 acquires the public key Issuer from the public key cache unit 380.

[0097] In step S324, the Issuer public key acquisition unit 347 uses the ID IssuerSearch for the VDR400 based on this. In step S325, for the ID Issuer if there is a corresponding public key Issuer the Issuer public key acquisition unit 347 acquires the public key Issuer from the VDR400. In step S326, the Issuer public key acquisition unit 347 stores the public key Issuer in the public key cache unit 380.

[0098] In step S227, the Issuer signature verification unit 348 verifies the electronic signature. Next, in step S328, the expired VC analysis unit 323 verifies the validity of the VC in the same manner as in step S307 described above.

[0099] Figures 17 and 18 show an example of the case where the VC becomes invalid due to expiration. Figure 17 is an example of the case where the VC becomes invalid due to the expiration of the subject of issuance, and Figure 18 shows an example of the case where the VC becomes invalid due to the expiration of the Issuer.

[0100] In the subject of issuance-based VP structured data shown in Figure 17, the subject of issuance a has expired, and the VCs VC1 and VC2 attached to the subject of issuance a have become invalid. Therefore, the VC3 including these VCs VC1 and VC2 is treated as invalid.

[0101] On the other hand, in the Issuer-based VP structured data shown in Figure 18, the Issuer A has expired, and the VCs VC1 and VC4 attached to the Issuer A have become invalid. Therefore, the Issuer A, VC1, and VC4 are treated as invalid.

[0102] (VP structure analysis process (after the second time)) Figure 19 is a flowchart showing an example of the procedure of the VP structure analysis process (after the second time). The VP structure analysis process shown in Figure 19 is the VP structure analysis process executed by the VP structure analysis unit 320 after the second time. That is, the VP structure analysis process shown in Figure 19 is executed after the first VP structure analysis process shown in Figure 11 is executed.

[0103] In step S121, the expired VC analysis unit 323 receives the expiration information. In step S122, the expired VC analysis unit 323 determines whether the issuance target has expired.

[0104] If the expiration VC analysis unit 323 determines that the issuance target has not expired, it executes step S123. In step S123, the expiration VC analysis unit 323 determines whether it has expired. If the Issuer has not expired, the expiration VC analysis unit 323 executes step S124. In step S124, the expiration VC analysis unit 323 uses, as the new Issuer-based valid VP structured data, the Issuer-based valid VP structured data with all expired VCs deleted. Note that step S124 is executed when the VC has expired, and there are mainly two cases where the VC has expired. First, it is the case where it has expired in the VC validity verification, and second, it is the case where the verification has failed in the Issuer's signature verification. Next, in step S125, the expiration VC analysis unit 323 uses, as the new issuance target-based valid VP structured data, the issuance target-based valid VP structured data with all expired VCs deleted.

[0105] On the other hand, if the Issuer has expired, the expiration VC analysis unit 323 executes step S126.

[0106] In step S126, the expiration VC analysis unit 323 uses, as the new Issuer-based valid VP structured data, the Issuer-based valid VP structured data with all expired Issuers and the VCs hanging from those Issuers deleted. Next, in step S127, the expiration VC analysis unit 323 deletes the deleted VCs from the issuance target-based valid VP structured data to obtain the new issuance target-based valid VP structured data.

[0107] On the other hand, when the issuing target has expired, the expired VC analysis unit 323 executes step S128. In step S128, the expired VC analysis unit 323 deletes all the expired issuing targets and the VCs hanging from the issuing targets in the issuing target-based valid VP structured data, and uses the result as the new issuing target-based valid VP structured data. In step S129, the expired VC analysis unit 323 deletes the deleted VCs from the Issuer-based valid VP structured data to obtain new Issuer-based valid VP structured data.

[0108] Figure 20 is a sequence chart showing an example of the procedure of the authorization policy verification process. The authorization policy verification process is executed by the authorization policy verification unit 350. The authorization policy verification process determines whether to authorize the provision of a service based on each VC included in the Issuer-based valid VP structured data or the VCs included in the issuing target-based valid VP structured data.

[0109] First, in step S401, the authorization policy acquisition unit 351 issues an authorization policy request. In step S402, if there is an authorization policy corresponding to the authorization policy request, the authorization policy is acquired (step S402).

[0110] Next, in step S403, the attribute information verification unit 352 verifies the attribute information included in the VP. The VP includes VC1 containing the attribute information of the principal (Holder1), VC2 containing the attribute information from the principal to the assignee (Holder2), and VC3 containing the attribute information of the trustee (Holder2).

[0111] Next, in step S403, the attribute information verification unit 352 verifies whether the relationships of these attribute information can be traced.

[0112] In step S404, the Issuer trust verification unit 353 issues a trust information request for the Issuer to the VDR 400. In step S405, if there is corresponding trust information in the VDP 400, the Issuer trust verification unit 353 acquires the Issuer trust information as the trust information.

[0113] The authorization system 1000 according to this embodiment issues a VC1 as an example of a first verifiable certificate including the attribute information of the entruster, and issues a VC2 as an example of a second verifiable certificate including the attribute information of the entruster (for example, including the signature of the entruster and ID_entruster) as entrustment information from the entruster to the trustee. An Issuer server 100 as an example of an issuer device, when the trustee receives the VC2 and VC1, a Holder terminal 200 as an example of an authorization request device that issues a VP configured by adding a VC3 as an example of a third verifiable certificate including the attribute information of the trustee to the VC1 and VC2, and a Verifier server 300 as an example of an authorization device that authorizes whether the VP received from the Holder terminal 200 is genuine. When receiving the VP from the Holder terminal 200, this Verifier server 300 has a VP structure analysis unit 320 that determines that the VP including the VC3 is genuine if the attribute information of the entruster included in the VC2 can be traced without inconsistency with the attribute information of the entruster included in the VC1, and the attribute information of the trustee in the VC3 can be traced without inconsistency with the attribute information of the entruster in the VC1 and the attribute information of the entruster and trustee in the VC2.

[0114] The authorization method according to this embodiment includes: a first issuance step in which the Issuer server 100 issues VC1 including the attribute information of the authorizer; a second issuance step in which the Issuer server 100 issues VC2 including the attribute information of the authorizer as the authorization information for the assignee as the authorizer; a second issuance step in which the Holder terminal 200 issues a VP configured by adding VC3 including the attribute information of the assignee to VC1 and VC2 when the assignee receives VC2 and VC1; and a verifiable request verification step in which the VP structure analysis unit 320 of the Verifier server 300 determines that the VP including VC3 is genuine when the attribute information of the authorizer included in VC2 can be traced without inconsistency with the attribute information of the authorizer included in VC1, and the attribute information of the assignee in VC3 can be traced without inconsistency with the attribute information of the authorizer in VC1 and the attribute information of the authorizer and the assignee in VC2. By doing so, for example, it is possible to prevent forgery using invalid VCs by the assignee.

[0115] In this embodiment, when the VP structure analysis unit 320 cannot be traced without inconsistency as described above, it is excluded from the verification target of the subsequent verification process. By doing so, the processing cost can be suppressed because the VC verification unit 340 does not need to verify the part of the VC.

[0116] In this embodiment, when the Verifier 300 as an example of the authorization device determines that a part of the VCs in the structured data, which is the structured data structuring the relationships of the plurality of VCs, has expired, the Verifier 300 includes a VC verification unit 340 that targets the remaining structured data obtained by deleting the part of the VDs from the structured data for verification. By doing so, the processing cost can be suppressed because the VC verification unit 340 does not need to verify the part of the VCs.

[0117] In this embodiment, when Verifier 300 determines that some of the VCs in the structured data, which is the data structuring the relationships of a plurality of VCs, are invalidated, it includes an authorization policy verification unit 350 that verifies the remaining structured data obtained by deleting some of the verifiable certificates from the structured data. By doing so, the processing cost can be suppressed because the authorization policy verification unit 350 does not need to verify the relevant some of the VCs.

[0118] The authorization system 1000 according to this embodiment includes an authorization policy storage unit 390 (see FIG. 6) that stores an authorization policy indicating criteria for determining whether to authorize the provision of a predetermined service. The authorization policy verification unit 350 authorizes the provision of the service when the structured data, which is the data structuring the relationships of a plurality of VCs, does not violate the authorization policy, while does not authorize the provision of the service when the structured data violates the authorization policy. By doing so, if an appropriate authorization policy is set in the authorization policy storage unit 390, the authorization policy verification unit 350 can accurately select the party to whom the service should be provided.

[0119] The authorization system 1000 according to this embodiment includes a trust verification unit that verifies whether the authorization policy is satisfied based on the Issuer trust information, the conditions regarding Issuer trust described in the authorization policy, and the information of the issuer included in the Issuer-based valid VP structured data.

[0120] The authorization system 1000 according to this embodiment includes a public key cache unit 380 that stores the public keys used for authentication of electronic signatures. By doing so, forgery of electronic signatures can be detected.

[0121] The authorization system 1000 according to this embodiment includes an invalidation information cache unit 370 that stores the invalidation information of the verification targets (for example, VC1, VC2, VC3, VP). By doing so, when any of VC1, VC2, VC3, VP for which the invalidation information is stored in the invalidation information cache unit 370 becomes the verification target, it can be recognized that it is illegal.

[0122] In this embodiment, the verifiable certificate is, for example, VC (Verifiable Credential), and the verifiable request is, for example, VP (Verifiable Presentation).

[0123] (2) Second Embodiment The authorization system according to the second embodiment has substantially the same configuration and operation as the authorization system 1000 according to the first embodiment. Therefore, the differences will be mainly described below. FIG. 21 is a block diagram illustrating the configuration of the authorization system according to the second embodiment. In FIG. 21, the detailed configurations corresponding to each configuration in FIG. 6 are omitted.

[0124] In the authorization system according to the second embodiment, the VP structure analysis unit 320, VP verification unit 330, VC verification unit 340, authorization policy verification unit 350, VP structure data storage unit 360, revocation information cache unit 370, public key cache unit 380, authorization policy storage unit 390, and the above-mentioned Verifier 397, which were all installed on the Verifier server 300 in the authorization system 1000 according to the first embodiment, are separated.

[0125] Specifically, in the authorization system according to the second embodiment, the VP structure analysis unit 320, VP verification unit 330, VC verification unit 340, authorization policy verification unit 350, VP structure data storage unit 360, revocation information cache unit 370, public key cache unit 380, and authorization policy storage unit 390 are installed on the VP verification server 399. The VP verification server 399 is separate from the Verifier having the interface 398 for communicating with the entruster, trustee, etc. (such as the Issuer server 100, Holder terminal 200, and VDR 400, etc.) and the VC.

[0126] The VP verification server 399 and the Verifier 397 are connected by a network (not shown). When the VP verification server 399 receives a VP from the Verifier 397, similar to the first embodiment, the VP structure analysis unit 320, the VP verification unit 330, the VC verification unit 340, and the authorization policy verification unit 350 perform authorization using the VP structure data storage unit 360, the revocation information cache unit 370, the public key cache unit 380, and the authorization policy storage unit 390, and return the authorization determination result to the Verifier 397 (its interface 398). The interface 398 returns this response content to the outside (such as the trustee).

[0127] In this embodiment, the interface 398 that communicates with the principal and the trustee is separate from the VP verification server 399 as an example of a verifiable request authorization server having at least the VP structure analysis unit 320, the VP verification unit 330, the VC verification unit 340, and the authorization policy verification unit 350. By using the VP verification server 399 in this way, since each process can be distributed, the processing load on the VP verification server 399 is suppressed, so that the processing cost can be reduced, and there is no need to use a high-speed and expensive device, so that the cost of the entire system can be suppressed.

[0128] Note that the present invention is not limited to the above-described embodiments, and includes various modifications and equivalent configurations within the scope of the appended claims. For example, the above-described embodiments have been described in detail for easy understanding of the present invention, and the present invention is not necessarily limited to those having all the configurations described. Also, each element described in parallel in this embodiment may be in a mode in which at least one of each element is connected in series to another element.

Industrial Applicability

[0129] The present invention can be applied to an authorization system related to a technique for preventing forgery when using, for example, Verifiable Credentials.

Explanation of Signs

[0130] 100... Issuer server, 200... Holder terminal, 300... Verifier server, 320... VP structure analysis unit, 330... VP verification unit, 340... VC verification unit, 350... Permission policy verification unit, 399... VP verification server, 1000... Approval system

Claims

1. An issuer device that issues a first verifiable certificate including the attribute information of the entruster, and issues a second verifiable certificate including the attribute information of the entruster as entrustment information to the trustee as the entruster; When the trustee receives the second verifiable certificate and the first verifiable certificate, an authorization request device that issues a verifiable request request configured by adding a third verifiable certificate including the attribute information of the trustee to the first verifiable certificate and the second verifiable certificate; An authorization device that authorizes whether the verifiable request request received from the authorization request device is genuine, comprising: The authorization device, When receiving the verifiable request request from the authorization request device, the attribute information of the entruster included in the second verifiable certificate can be traced without inconsistency with the attribute information of the entruster included in the first verifiable certificate, and the trustee in the third verifiable certificate When the attribute information of is traceable without inconsistency with the attribute information of the entruster in the first verifiable certificate and the entruster and the trustee in the second verifiable certificate, it has a structure analysis unit that determines that the verifiable request request including the third verifiable certificate is genuine An authorization system characterized by the above.

2. The structure analysis unit, If it cannot be traced without inconsistency, it will be excluded from the verification target hereafter The authorization system according to claim 1, characterized by the above.

3. The authorization device, When it is determined that some of the verifiable certificates in the structured data, which is the structured relationship of a plurality of verifiable certificates, are invalid, it has a verifiable certificate verification unit that verifies the remaining structured data obtained by deleting the some verifiable certificates from the structured data The authorization system according to claim 1, characterized by the above.

4. The authorization device, If it is determined that some of the verifiable certificates in the structured data, which is the structured data that structures the relationships of multiple verifiable certificates, are invalidated, an authorization policy verification unit that targets the remaining structured data obtained by deleting the some of the verifiable certificates from the structured data for verification is provided. The authorization system according to claim 1, characterized in that.

5. An authorization policy storage unit that stores an authorization policy indicating criteria for determining whether to authorize the provision of a predetermined service is provided. The authorization policy verification unit If the structured data, which is the structured data that structures the relationships of multiple verifiable certificates, does not violate the authorization policy, authorizes the provision of the service, while if the structured data violates the authorization policy, does not authorize the provision of the service. The authorization system according to claim 4, characterized in that.

6. A trust verification unit that verifies whether the trust information of the issuer, the conditions regarding the trust of the issuer described in the authorization policy, and the information of the issuer included in the structured data of the issuer satisfy the authorization policy is provided. The authorization system according to claim 4, characterized in that.

7. A public key cache unit that stores the public key used for the authentication of the electronic signature is provided. The authorization system according to claim 1, characterized in that.

8. An invalidation information cache unit that stores the invalidation information of the verification target is provided. The authorization system according to claim 1, characterized in that.

9. The first to third verifiable certificates are Verifiable Credential, and the verifiable request is Verifiable Presentation. The authorization system according to claim 1, characterized in that.

10. An interface for communicating with the principal and the agent, A verifiable request authorization server having at least the structure analysis unit, the verifiable request verification unit, the verifiable certificate verification unit, and the authorization policy verification unit, which are separate entities The authorization system according to claims 3 and 4, characterized in that.

11. A first issuing step in which an issuer device issues a first verifiable certificate including the principal's attribute information, A second issuing step in which the issuer device issues a second verifiable certificate including the principal's attribute information as delegation information to the agent as the principal, A second issuing step in which, when the authorization request device receives the second verifiable certificate and the first verifiable certificate by the agent, the authorization request device issues a verifiable request request configured by adding a third verifiable certificate including the agent's attribute information to the first verifiable certificate and the second verifiable certificate, When the structure analysis unit of the authorization device receives the verifiable request request from the authorization request device, the principal's attribute information included in the second verifiable certificate can be traced without inconsistency with the principal's attribute information included in the first verifiable certificate, and the agent's attribute information in the third verifiable certificate can be traced without inconsistency with the principal in the first verifiable certificate, and the principal and the agent in the second verifiable certificate. A verifiable request request verification step of determining that the verifiable request request including the third verifiable certificate is genuine when the attribute information of the agent can be traced without inconsistency, An authorization method characterized by having.

Images