Authorization system and authorization method

Abstract

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 the attribute information about a delegator included in a second verifiable certificate is not inconsistent with the 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 the 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.

Description

Authorization system and authorization method

[0001] The present invention relates to an authorization system and an authorization method, and is suitable for application to an authorization system relating to a technology for preventing spoofing when utilizing verifiable credentials, for example.

[0002] In recent years, from the viewpoints of privacy protection and availability, there have been authorization systems that utilize Verifiable Credentials as an example of verifiable certificates. Non-Patent Document 1 defines an authorization system that uses VCs (Verifiable Credentials) and discloses basic functions of the components of the authorization system: Issuer, Holder, Verifier, and Verifiable Data Registry (VDR). Attribute information of a Holder requesting authorization from a Verifier is described in a VC, and when the Verifier receives a VP (Verifiable Presentation) consisting of multiple VCs from the Holder, authorization is performed based on the attribute information described in each VC included in the VP.

[0003] https: / / www.w3.org / TR / VC-data-model-2.0 /

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

[0005] The present invention has been made in consideration of the above points, and aims to propose an authorization system and authorization method that can prevent spoofing using invalid verifiable certificates.

[0006] In order to solve the above problem, the present invention provides an issuer device that issues a first verifiable certificate including attribute information of a principal and issues a second verifiable certificate including attribute information of the principal as delegation information to an agent as the principal; an authorization request device that, when the agent receives the second verifiable certificate and the first verifiable certificate, issues a verifiable request request configured by adding a third verifiable certificate including attribute information of the agent to the first verifiable certificate and the second verifiable certificate; and an authorization server that verifies whether the verifiable request request received from the authorization request device is genuine. and an authorization device that can verify the verifiable request request from the authorization request device, wherein the authorization device has a structural analysis unit that, upon receiving the verifiable request request from the authorization request device, determines that the verifiable request request including the third verifiable certificate is genuine if attribute information of the principal included in the second verifiable certificate can be traced back without inconsistency to attribute information of the principal included in the first verifiable certificate and attribute information of the agent in the third verifiable certificate can be traced back without inconsistency to attribute information of the principal in the first verifiable certificate and the principal and the agent in the second verifiable certificate.

[0007] Furthermore, in the present invention, there are provided a first issuing step in which an issuer device issues a first verifiable certificate including attribute information of a delegator; a second issuing step in which the issuer device issues a second verifiable certificate including attribute information of the delegator as delegation information for an agent as the delegator; a second issuing step in which an authorization request device issues a verifiable request request configured by adding a third verifiable certificate including attribute information of the agent to the first verifiable certificate and the second verifiable certificate when the agent receives the second verifiable certificate and the first verifiable certificate; and a configuration of an authorization device. and a verifiable request request verification step in which, when the authentication analysis unit receives the verifiable request request from the authorization request device, if the attribute information of the principal included in the second verifiable certificate can be traced back without inconsistency to the attribute information of the principal included in the first verifiable certificate and the attribute information of the agent in the third verifiable certificate can be traced back without inconsistency to the attribute information of the principal in the first verifiable certificate and the attribute information of the principal and the agent in the second verifiable certificate, the authentication analysis unit determines that the verifiable request request including the third verifiable certificate is genuine.

[0008] According to the present invention, it is possible to prevent spoofing using invalid verifiable certificates.

[0009] 1 is a system configuration diagram showing an example of the configuration of an authorization system according to a first embodiment.

[0023] FIG. 1 is a block diagram showing an example of the hardware configuration of the Issuer server shown in FIG. 1.

[0024] FIG. 2 is a block diagram showing an example of the software configuration of the Issuer server shown in FIG. 1.

[0025] FIG. 3 is a block diagram showing an example of the software configuration of the Holder terminal shown in FIG. 1.

[0026] FIG. 4 is a block diagram showing an example of the software configuration of the Verifier server shown in FIG. 1.

[0027] FIG. 5 is a diagram showing an example of issuer-based VP structured data.

[0028] FIG. 6 is a block diagram showing an example of the configuration of a VDR.

[0029] FIG. 7 is a flowchart showing an example of the procedure of a VP structure analysis process (first time).

[0030] FIG. 8 is a sequence chart showing an example of the procedure of a VP verification process.

[0031] FIG. 9 is a diagram showing an example of detecting spoofing using issuer-based VP structured data.

[0032] FIG. 10 is a sequence chart showing an example of the procedure of a VC verification process.

[0033] FIG. 11 is a sequence chart showing an example of the procedure of a VC verification process.

[0034] FIG. 12 is a diagram showing an example of a case where a VC becomes invalid due to revocation.

[0035] It is a flowchart showing an example of the procedure of the VP structure analysis process (second time and thereafter).It is a sequence chart showing an example of the procedure of the authorization policy verification process.It is a block diagram showing an example of the configuration of the authorization system according to the second embodiment.

[0010] An embodiment of the present invention will be described in detail below with reference to the drawings. (1) First Embodiment Fig. 1 is a system configuration diagram showing an example of the configuration of an authorization system 1000 according to a first embodiment. The authorization system 1000 has, 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, a verifiable credential (VC).

[0011] In this embodiment, the terms are used as follows: An "Issuer" has the function of issuing a VC in response to a request from a requester. A "Holder" has the function of holding an issued VC. A "Verifier" has the function of verifying and approving an issued VC, and determining whether or not to approve the provision of a specified service based on the results of that verification and approval. A "Delegator" has the function of delegating a specified request to an agent. An "Agent" has the function of accepting a specified request from a delegator. An "Issuing target" refers to a target to whom a VC is issued. In this embodiment, the "Issuer", "Holder", "Verifier", "Delegator", "Agent" and "Issuing target" are each also referred to as entities, and are, for example, a terminal, a device or a system.

[0012] For example, the Issuer issues a VC including attribute information of a requesting delegator in response to a request from the requesting delegate, or issues a VC including attribute information of the requesting delegate in response to a request from the requesting delegate. The Holder holds the issued VC. When the Holder makes a verifiable request request to the Verifier, it passes multiple VCs it holds to the Verifier as VPs (Verifiable Presentations).

[0013] The Verifier performs verification and authorization in response to a verifiable request using the received VP (Verifiable Presentation), and can provide a predetermined service after authorization according to the verification and 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 one another 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 verifiable credential (VC) including attribute information of the requester, and issues the VC to a holder. Details of the issuer server 100 will be described later.

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

[0017] The Verifier server 300 is at least one computer that functions as a verifier, and performs verification and authorization in response to a verifiable request request using a VP, for example, and can provide a predetermined service after authorization according to the verification and authorization result. The Verifier server 300 performs verification and authorization based on the contents of the VP received from the Holder terminal 200 along with the verifiable request request, and if the provision of a specific service is authorized according to the verification and authorization result, the Verifier server 300 provides the specific service to the requester of the verifiable request 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 the Holder terminal 200, the Verifier server 300, and the VDR 400 have almost the same configuration as the issuer server 100 except for some differences in configuration and processing speed, and therefore their explanations are omitted.

[0019] The issuer server 100 is at least one computer, and includes a processor 1, a main memory device 2, an auxiliary memory 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, for example, a program. The main memory device 2 is, for example, a memory having a storage area capable of storing programs and data executed by the processor 1. The auxiliary memory device 3 is a so-called cache and has a storage area in which programs and data stored in the main memory device 2 are temporarily stored. The input device 4 is a mouse and keyboard that accept operations from outside. The output device 5 is a so-called display. The communication I / F 6 exchanges data and the like with the outside via a network 500.

[0020] 3 is a diagram showing an example of a VP. In this embodiment, the VP is, for example, n VCs (VCs １ ~VC ｎ ), I.D. Ｈｏｌｄｅｒ , electronic signature Ｈｏｌｄｅｒ Contains ID Ｈｏｌｄｅｒ indicates the ID (identifier) ​​of the owner (Holder) who created and holds the VP. Ｈｏｌｄｅｒ 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 tampering with the VP.

[0021] VC １ ~VC ｎ are IDs, respectively. 発行対象者 , ID Ｉｓｓｕｅｒ , and two attribute information items, a validity period, an ID, and a digital signature. The number of attributes included in a VC is not limited to two, and any number of attributes may be included.

[0022] ID 発行対象者 indicates the person who issued the VC, for example, ID 発行対象者ａ indicates that the person to whom the certificate is issued is "person to whom the certificate is issued a."

[0023] ID Ｉｓｓｕｅｒ indicates the ID of the issuer, for example, ID ＩｓｓｕｅｒＡindicates that the issuer is "Issuer A."

[0024] The two pieces of attribute information indicate the attribute information of the entity to which the VC is issued. The validity period indicates the validity period of the VC. In this embodiment, a VC that has passed its validity period is treated as invalid, for example. The ID indicates the identifier of the VC, for example, ID ＶＣ１ is the VC in question １ The digital signature indicates the digital signature attached to the VC. For example, the digital signature ＩｓｓｕｅｒＡ indicates that it is an electronic signature of Issuer A. This electronic signature is, for example, an electronic signature using a public key cryptosystem, and it is possible to determine whether or not the VC has been tampered with by using 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 acceptance unit 101, a VC issuing unit 102, a VC revocation information registration unit 103, and a public key registration unit 104.

[0026] The VC issuance reception unit 101 receives a VC issuance request from a requester. The requester here refers to at least one of a delegate and a delegatee. The request may or may not include attribute information of the requester.

[0027] The VC issuing unit 102 issues a VC that includes attribute information of the requester. At this time, the attribute information included when the VC is requested to be issued 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 revocation information registration unit 103 registers revocation information for invalid VCs in the VDR 400. The public key registration unit 104 registers in the VDR 400 a public key that corresponds to a private key used to create a digital signature.

[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 that can register information related to a public key.

[0029] The VC issuance request unit 201, as a request source, issues a VC issuance request to the issuer server 100. The request source here refers to at least one of the delegate and the agent. The request may or may not include 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 VCs. The public key information registration unit 206 registers in the VDR 400 a public key corresponding to a private key used when creating a digital signature.

[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, a revocation 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 or not to authorize the provision of a predetermined service, and stores, for example, an authorization policy describing conditions related to the trust of the issuer and conditions related to attribute information (including, for example, conditions).

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

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

[0035] The issuer-based structure analysis unit 321 performs issuer-based structure analysis on the VP and generates issuer-based VP structured data. The issuer-target-based structure analysis unit 322 performs issuer-target-based structure analysis on the VP and generates issuer-target-based VP structured data. In this embodiment, structured data is data that structures the relationships between multiple VCs such as issuers, holders, delegates, and agents.

[0036] The revoked VC analysis unit 323 determines valid VCs from the issuer-based VP structured data, the issuer-subject-based VP structured data, and information on invalid VCs in the revocation information cache unit 370, and creates issuer-based valid VP structured data and issuer-subject-based valid VP structured data. At this time, the revoked VC analysis unit 323 also detects spoofing, and if spoofing is detected, deletes the invalid VCs 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 revocation 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 revocation information acquisition unit 331 acquires the ID written in the VP. ＨｏｌｄｅｒHere, if the Holder has been revoked, the revocation information of the Holder may be stored in the revocation information cache unit 370. 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 Holder. On the other hand, if the revocation information of the Holder is not stored, the Holder revocation information acquisition unit 331 searches for the ID Ｈｏｌｄｅｒ The holder revocation information acquisition unit 331 requests the VDR 400 for the revocation information of the holder using the request, and if the corresponding revocation information is stored in the VDR 400, acquires the revocation information of the holder 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 acquires the ID written in the VC. Ｈｏｌｄｅｒ Here, the public key cache unit 380 may store the public key of the Holder. 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 Holder validity verification unit 332 retrieves the public key from the ID Ｈｏｌｄｅｒ If the corresponding public key is stored in the VDR 400, the holder validity verification unit 332 acquires the holder's public key from the VDR 400. The holder validity verification unit 332 also stores this public key in the public key cache unit 380.

[0041] The Holder signature verification unit 334 verifies the Holder's digital signature using the VP hash value, the Holder's digital signature, and the Holder's public key, thereby making it possible to determine whether the VP has been tampered with.

[0042] The VC verification unit 340 includes an issuer revocation information acquisition unit 341, an issuer validity verification unit 342, an issuer revocation information acquisition unit 343, an issuer validity verification unit 344, a VC revocation 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 issuer revocation information acquisition unit 341 acquires the ID written in each VC included in the issuer-based valid VP structured data. 発行対象者 The revocation information cache unit 370 is searched for whether revocation information of each issue target is stored using the above. At this time, each VC included in the issue target base valid VP structured data may be used. The issue target revocation information acquisition unit 341 acquires the revocation information if the revocation information of each issue target is stored. On the other hand, if the revocation information is not stored, the issue target revocation information acquisition unit 341 acquires the ID 発行対象者 and if the relevant revocation information is stored in the VDR 400, the revocation information of the issuance target is acquired from the VDR 400. The issuance target revocation information acquisition unit 341 then stores this revocation information in the revocation information cache unit 370. The issuance target revocation information is then passed to the revocation VC analysis unit 323, which then performs revocation VC analysis.

[0044] The issuance target validity verification unit 342 determines whether each issuer has been revoked based on the revocation information of each issuer.

[0045] The issuer revocation information acquisition unit 343 acquires an ID for each issuer of each VC included in the issuer-based valid VP structured data. Ｉｓｓｕｅｒ The issuer revocation information acquisition unit 343 searches the revocation information cache unit 370 to see if the revocation information of each issuer is stored using the ID. If the revocation information is stored, the issuer revocation information acquisition unit 343 acquires the revocation information. On the other hand, if the revocation information is not stored, the issuer revocation information acquisition unit 343 Ｉｓｓｕｅｒ and if the relevant revocation information is stored in the VDR 400, the issuer revocation information acquisition unit 343 acquires the issuer revocation information from the VDR 400. The issuer revocation information acquisition unit 343 also stores this revocation information in the revocation information cache unit 370.

[0046] The issuer validity verification unit 344 determines whether each issuer has been revoked based on the revocation information of each issuer. The VC revocation information acquisition unit 345 requests the VDR 400 for revocation information of each VC included in the issuer-based valid VP structured data (or issuer-based valid VP structured data), and acquires the revocation information of each VC from the VDR 400.

[0047] The VC validity verification unit 346 determines whether or not a VC included in the issuer-based valid VP structured data (or issuer-based valid VP structured data) has been revoked based on the revocation information of each VC. The issuer public key acquisition unit 347 acquires an ID for each issuer included in the issuer-based valid VP structured data. Ｉｓｓｕｅｒ The issuer public key acquisition unit 347 searches the public key cache unit 380 to see if the issuer public key is stored therein using the ID. If the public key is stored therein, the issuer public key acquisition unit 347 acquires the public key. On the other hand, if the public key is not stored therein, the issuer public key acquisition unit 347 searches the public key cache unit 380 using the ID. Ｉｓｓｕｅｒ The issuer public key acquisition unit 347 requests the issuer public key from the VDR 400 using the above command, and if the corresponding public key is stored in the VDR 400, acquires the issuer public key from the VDR 400. The issuer public key acquisition unit 347 then stores this public key in the public key cache unit 380. The issuer public key acquisition unit 347 also passes this revocation information to the revoked VC analysis unit 323, which then performs revoked VC analysis.

[0048] The issuer signature verification unit 348 verifies the issuer's digital signature for each VC included in the issuer-based valid VP structured data (which may be issuer-based) using the VC's hash value, the issuer's digital signature, and the issuer's public key. If there is a VC that fails verification, the VC is deemed to have expired, and this revocation information is passed to the expired VC analysis unit 323, which performs an expired 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 an authorization policy from the authorization policy storage unit 390. The attribute information verification unit 352 verifies whether the conditions of the attribute information described in the authorization policy and the VCs included in the issuer-based valid VP structured data (or issuer-based valid VP structured data) satisfy 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, and acquires issuer trust information (issuer trust information) described later from the VDR 400, and verifies whether the authorization policy is satisfied based on this issuer trust information (issuer trust information), the conditions related to the trust of the issuer described in the authorization policy, and the issuer information included in the issuer-based valid VP structured data. If the authorization policy is satisfied, the attribute information verification unit 352 and the issuer trust verification unit 353 authorize the provision of a specified service, but if the authorization policy is not satisfied, they do not authorize the provision of the specified service.

[0052] 7 is a diagram showing an example of issuer-based VP structured data. In the example shown in the figure, VCs related to issuers are structured, for example, as a tree structure. The issuer-based VP structured data is, for example, a case where issuer a acts as an issuer to issuer b, who is a holder, and issues a VC as an example of a verifiable certificate. ３ The issuer a is, for example, a VC １ and V.C. ２ The issuer b has, for example, a VC as an example of a verifiable certificate. ３ , V.C. ４ , V.C. ５ It has.

[0053] In this embodiment, the characteristics of VP and VC are utilized to extract the relationship between issuers by performing the following process. For example, each ID included in each VC is used to extract the relationship. Step 1. Identify the entity that is both the issuer and issuer (issuer a in the figure) from the information of each VC. For example, ３The case where the certificate is issued by the issuing party a will be explained. Step 2. The entity identified in step 1 is the issuer of the VC (VC ３ ) to identify the target issuer (target issuer b). Step 3. Regarding the relationship between the target issuers from steps 1 and 2, it is assumed that there is a relationship between the entities identified in steps 1 and 2. It is also assumed that the delegate is in a higher position than the agent. In this example, it is determined that target issuer a is in a higher position than target issuer b. Step 4. Identify the target issuer that is the same as Holder.

[0054] 8 is a diagram showing a specific example of issuer-based VP structured data. In the example shown, VCs related to issuers are structured, for example, as a tree structure. The issuer-based VP structured data shows that Issuer A, for example, １ and V.C. ４ and Issuer B has, for example, VC ２ and V.C. ５ and Issuer C has, for example, VC ３ In the illustrated example, the VC ３ For example, the delegate is the issuer a, and the agent is the issuer b.

[0055] 9 is a block diagram showing an example of the configuration of the VDR 400. The VDR 400 includes ID revocation information 401, VC revocation information 402, a public key 403, and issuer trust information 404.

[0056] For example, if the issuer is Issuer 1, the ID revocation information 401 is Ｉｓｓｕｅｒ１ , revocation information Ｉｓｓｕｅｒ１ ) is managed. For example, if the VC is VC1, the VC revocation information 402 is ＶＣ１ , revocation information ＶＣ１ For example, if the issuer is Issuer 1, the public key 403 is managed in the form of (ID Ｉｓｓｕｅｒ１ , pk Ｉｓｓｕｅｒ１) where pk indicates a public key. Issuer trust information 404 is information indicating the degree of trustworthiness of the issuer.

[0057] 10 is a diagram showing an overview of the VP authorization process. When the VP verification unit 330 receives a VP, it passes the VP to the VP structure analysis unit 320. The VP structure analysis unit 320 performs a predetermined structural analysis on the VP to create structured data. The structured data referred to here is, for example, at least one of the above-mentioned issuer-based valid VP structured data and issuer-based valid VC structured data, and in this embodiment, when there is no need to particularly distinguish between the two, they are collectively referred to simply as "structured data."

[0058] The VC verification unit 340 is an example of a verifiable certificate verification unit, and when it determines that some VCs of the structured data received from the VP structure analysis unit 320 have expired, it passes revocation information about the structured data to the VP structure analysis unit 320. In response to this, the VP structure analysis unit 320 registers the revocation of the structured data and deletes the some VCs from the structured data. As a result, the VC verification unit 340 then targets the remaining structured data from which the some VCs have been deleted as the target for verification. By deleting the expired structured data in this way, it is no longer necessary to refer to the some VCs, thereby reducing processing costs.

[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 passes revocation information about the structured data to the VP structure analysis unit 320. In response to this, 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, the authorization policy verification unit 350 no longer needs to verify the some VCs, and can simply verify the remaining structured data from which the some verifiable certificates have been deleted, thereby reducing processing costs.

[0060] If 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 authorization is permitted. The authorization policy verification unit 350 authorizes the structured data if it does not violate the authorization policy, but does not authorize the structured data if it violates the authorization policy.

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

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

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

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

[0065] In step S104, the stale VC analysis unit 323 determines whether or not 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 revoked VC analysis unit 323 executes step S105. In step S105, the revoked VC analysis unit 323 sets the issuer-based VP structured data as issuer-based valid VP structured data. In step S106, the revoked VC analysis unit 323 sets the issuer-based VP structured data as 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 revoked VC analysis unit 323 executes step S107. In step S107, the revoked VC analysis unit 323 deletes all of the issuers and VCs hanging from those issuers included in the structured data group that cannot be traced from the Holder, and sets the result as issuer-based valid VP structured data. In this way, VCs that cannot be traced from the Holder can be detected as VCs caused by spoofing. By detecting and deleting VCs used for spoofing, only valid VCs that are not spoofed can be used in subsequent verifications. Furthermore, by not using invalid VCs caused by spoofing in subsequent verifications, processing costs 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, and sets it as issuer-based valid VP structured data.

[0069] Furthermore, in step S109 , the revoked VC analysis unit 323 passes the issuer-based valid VP structured data and the issuer-based valid VP structured data to the VC verification unit 340 .

[0070] 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 revocation information acquisition unit 331 acquires the ID Ｈｏｌｄｅｒ In step S202, the revocation information cache unit 370 is searched based on the ID. Ｈｏｌｄｅｒ Revocation information applicable to Ｈｏｌｄｅｒ If there is a Holder revocation information, the Holder revocation information acquisition unit 331 retrieves the revocation information from the revocation information cache unit 370. Ｈｏｌｄｅｒ On the other hand, the ID Ｈｏｌｄｅｒ Revocation information applicable to Ｈｏｌｄｅｒ If there is no such holder, the holder revocation information acquisition unit 331 executes step S203.

[0071] In step S203, the holder revocation information acquisition unit 331 acquires the ID ＨｏｌｄｅｒIn step S204, the VDR 400 is searched for based on the ID. Ｈｏｌｄｅｒ Revocation information applicable to Ｈｏｌｄｅｒ If there is a holder revocation information, the holder revocation information acquisition unit 331 acquires the revocation information from the VDR 400. Ｈｏｌｄｅｒ Get.

[0072] The ID in question Ｈｏｌｄｅｒ Revocation information applicable to Ｈｏｌｄｅｒ If there is a holder revocation information, in step S205, the holder revocation information acquisition unit 331 Ｈｏｌｄｅｒ is stored in the revocation information cache unit 370. Ｈｏｌｄｅｒ Revocation information applicable to Ｈｏｌｄｅｒ If the holder revocation information acquisition unit 331 is unable to acquire the revocation information, the holder revocation information acquisition unit 331 does not access the revocation 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 acquires the ID Ｈｏｌｄｅｒ In step S202, the public key cache unit 380 is searched based on the ID. Ｈｏｌｄｅｒ The public key corresponding to Ｈｏｌｄｅｒ If there is a public key, the Holder public key acquisition unit 333 acquires the public key from the public key cache unit 380. Ｈｏｌｄｅｒ Get.

[0075] On the other hand, the ID Ｈｏｌｄｅｒ The public key corresponding to Ｈｏｌｄｅｒ If there is no Holder public key, in step S209, the Holder public key acquisition unit 333 acquires the ID Ｈｏｌｄｅｒ In step S210, the VDR 400 is searched for based on the ID. Ｈｏｌｄｅｒ The public key corresponding to Ｈｏｌｄｅｒ If there is a public key, the Holder public key acquisition unit 333 acquires the public key from the VDR 400. Ｈｏｌｄｅｒ In step S210, the Holder public key acquisition unit 333 acquires the public key Ｈｏｌｄｅｒ is stored 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] 13 is a diagram showing an example of detecting spoofing using issuer-based VP structured data. This spoofing detection is performed by the VP structure analysis unit 320. In the illustrated issuer-based VP structured data for a certain VP, the left part is the same as the issuer-based VP structured data shown in FIG. 7 above, and it is determined that there is no spoofing. However, the right part indicates that issuer d does not have a VC. ６ and V.C. ７ are hanging, and these VCs ６ and V.C. ７ is not included in the VC of the issuer-based VP structured data on the right, it is determined that it cannot be traced, and it is detected that there has been spoofing.

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

[0079] The delegate issues a request to the issuer server 100 and receives a VC (hereinafter referred to as "VC") from the issuer server 100, which includes the delegate's own attribute information. １ "), and the VC １ The holder of the VC １ The delegate who received the issuance of the VC in this way １ The VC 1 corresponds to the Holder (hereinafter also referred to as "Holder 1") and corresponds to the Holder terminal 200. For example, when the delegator delegates himself as the delegate to the agent to make a request for provision of a predetermined service (service provision request) to the Verifier server 300, the delegator passes two types of VCs to the agent as follows.

[0080] That is, first, the delegate sends a VC (hereinafter referred to as "VC") containing attribute information of the delegate (the delegate) as the delegate of the request. １Secondly, the delegate is a Holder as described above, but in order to delegate to the delegate as the Issuer for the delegate, the delegate (Holder1) sends a VC (hereinafter referred to as "VC") including the attribute information of the delegate (Holder1) to the delegate. ２ At this time, VC １ and VC ２ The agent may hand over the issued VCs together or separately. ２ By receiving the ２ Holder (hereinafter also referred to as "Holder 2") of the VC, which corresponds to the Holder terminal 200. ２ Holder of the VC, while the VC ２ In some cases, the person in charge may also be the issuer of the above.

[0081] Furthermore, the agent (Holder 2) issues a request to the Issuer server 100 and receives a VC (hereinafter referred to as "VC") from the Issuer server 100, which includes the agent's own attribute information. ３ "), and the VC ３ This agent will also be the holder of the VC that has already been received. １ and V.C. ２ VC ３ The Verifier creates a VP (verifiable request for a specific service) with the above added, and issues it to the Verifier.

[0082] The Verifier server 300 performs verification and authorization in response to a verifiable request request using the received VP, and can provide a predetermined service after authorization according to the verification and authorization result. ２ From the attribute information of the delegator in １Based on the attribute information in the document, it is determined whether Holder2 is an agent in relation to Holder1 (also called the "authorization condition"), and if the authorization condition is met, it is determined that the VP is genuine, but 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 uses a VC containing attribute information of a delegate. １ and issues a VC containing the attribute information of the delegator as delegation information to the agent. ２ An issuer server 100 is an example of an issuer device that issues the VC. ２ and V.C. １ When receiving the agent's attribute information, ３ VC １ and V.C. ２ The verifier server 300 is provided with a VP structure analysis unit 320 as described below. That is, when the VP structure analysis unit 320 receives a VP from the holder terminal 200, the verifier server 300 analyzes the VP structure by analyzing the VP structure. ２ The attribute information of the delegator included in １ The attribute information of the delegator contained in the VC can be traced without any inconsistencies, and ３ The attribute information of the agent in １ Delegators in the ２ If the attribute information of the delegate and the agent in the ３ VPs containing the above will be deemed to be genuine.

[0084] In the authorization method according to this embodiment, the issuer server 100 issues a VC containing attribute information of the delegate. １ The first issuing step is to issue a VC including attribute information of the delegator as delegation information for the agent. ２ A second issuing step in which the Holder terminal 200 issues a VC ２ and V.C.１ When receiving the agent's attribute information, ３ VC １ and V.C. ２ a second issuing step of issuing a VP configured by adding the VP to the VP structure analysis unit 320 of the Verifier server 300; and ２ The attribute information of the delegator included in １ and the attribute information of the delegate contained in the VC ３ The attribute information of the agent in １ Delegators in the ２ If the attribute information of the delegate and the agent in the ３ and a verifiable request verification step of determining that the VP containing the request is authentic.

[0085] In this embodiment, if the VP structure analysis unit 320 cannot trace the path without inconsistency as described above, it excludes the path from further verification targets.

[0086] 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 issuer revocation information acquisition unit 341 acquires the ID 発行対象者 In step S302, the revocation information cache unit 370 is searched based on the ID. 発行対象者 Revocation information applicable to 発行対象者 If there is revocation information, the issuer revocation information acquisition unit 341 retrieves the revocation information from the revocation information cache unit 370. 発行対象者 Get.

[0088] On the other hand, the ID 発行対象者 Revocation information applicable to 発行対象者 If there is no ID, in step S303, the issue target person revocation information acquisition unit 341 発行対象者 In step S304, the VDR 400 is searched for based on the ID. 発行対象者 Revocation information applicable to発行対象者 If there is revocation information, the issuance target person revocation information acquisition unit 341 acquires the revocation information from the VDR 400. 発行対象者 Get.

[0089] The ID in question 発行対象者 Revocation information applicable to 発行対象者 If there is a revocation information, in step S305, the issuance target revocation information acquisition unit 341 発行対象者 is stored in the revocation information cache unit 370. Ｈｏｌｄｅｒ Revocation information applicable to Ｈｏｌｄｅｒ If the issuance target person revocation information acquisition unit 341 cannot acquire the revocation information, the issuance target person revocation information acquisition unit 341 does not access the revocation information cache unit 370 .

[0090] In step S306, the issuer validity verification unit 342 verifies the validity of the issuer. Next, in step S307, the revoked VC analysis unit 323 verifies the validity of the VC. In step S308, the issuer revocation information acquisition unit 343 verifies the validity of the ID Ｉｓｓｕｅｒ In step S309, the revocation information cache unit 370 is searched based on the ID. Ｉｓｓｕｅｒ Revocation information applicable to Ｉｓｓｕｅｒ If there is revocation information, the issuer revocation information acquisition unit 343 retrieves the revocation information from the revocation information cache unit 370. Ｉｓｓｕｅｒ Get.

[0091] On the other hand, the ID Ｉｓｓｕｅｒ Revocation information applicable to Ｉｓｓｕｅｒ If there is no ID, in step S310, the issuer revocation information acquisition unit 343 Ｉｓｓｕｅｒ In step S311, the VDR 400 is searched for based on the ID. Ｉｓｓｕｅｒ Revocation information applicable to Ｉｓｓｕｅｒ If there is revocation information, the issuer revocation information acquisition unit 343 acquires the revocation information from the VDR 400. Ｉｓｓｕｅｒ Acquire the ID. Ｉｓｓｕｅｒ Revocation information applicable to Ｉｓｓｕｅｒ If there is revocation information, in step S312, the issuer revocation information acquisition unit 343 Ｉｓｓｕｅｒ is stored in the revocation information cache unit 370. Ｉｓｓｕｅｒ Revocation information applicable to ＩｓｓｕｅｒIf the issuer revocation information acquisition unit 343 is unable to acquire the revocation information, the issuer revocation information acquisition unit 343 does not access the revocation 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 revoked 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 revocation information acquisition unit 345 ＶＣ In step S316, the revocation information cache unit 370 is searched based on the ID. ＶＣ Revocation information applicable to ＶＣ If there is a VC revocation information, the VC revocation information acquisition unit 345 retrieves the revocation information from the revocation information cache unit 370. ＶＣ On the other hand, the ID ＶＣ Revocation information applicable to ＶＣ If there is no VC revocation information, the VC revocation information acquisition unit 345 executes step S317.

[0094] In step S317, the VC revocation information acquisition unit 345 acquires the ID ＶＣ In step S204, the VDR 400 is searched for based on the ID. ＶＣ Revocation information applicable to ＶＣ If there is a VC revocation information, the VC revocation information acquisition unit 345 acquires the revocation information from the VDR 400. ＶＣ Acquire the ID. ＶＣ Revocation information applicable to ＶＣ If there is a VC revocation information, in step S205, the VC revocation information acquisition unit 345 ＶＣ is stored in the revocation information cache unit 370. ＶＣ Revocation information applicable to ＶＣ If the VC revocation information acquisition unit 345 is unable to acquire the revocation information, the VC revocation information acquisition unit 345 does not access the revocation 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 revoked VC analysis unit 323 verifies the validity of the VC in the same manner as in step S307 described above.

[0096] If the VC is valid, in step S322, the issuer public key acquisition unit 347 acquires the ID Ｉｓｓｕｅｒ In step S323, the public key cache unit 380 is searched based on the ID. Ｉｓｓｕｅｒ The public key corresponding to Ｉｓｓｕｅｒ If there is a public key, the issuer public key acquisition unit 347 retrieves the public key from the public key cache unit 380. Ｉｓｓｕｅｒ Get.

[0097] In step S324, the issuer public key acquisition unit 347 acquires the ID Ｉｓｓｕｅｒ In step S325, the VDR 400 is searched for based on the ID. Ｉｓｓｕｅｒ The public key corresponding to Ｉｓｓｕｅｒ If there is an issuer public key, the issuer public key acquisition unit 347 acquires the public key from the VDR 400. Ｉｓｓｕｅｒ In step S326, the issuer public key acquisition unit 347 acquires the public key Ｉｓｓｕｅｒ is stored in the public key cache unit 380.

[0098] In step S227, the issuer signature verification unit 348 verifies the digital signature. Next, in step S328, the revoked 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 examples of when a VC becomes invalid due to revocation. Figure 17 shows an example of when a VC becomes invalid due to revocation of the issuer, and Figure 18 shows an example of when a VC becomes invalid due to revocation of the issuer.

[0100] In the issuer-based VP structured data shown in FIG. 17, the issuer a has expired, and the VC hanging from the issuer a １ and V.C. ２ are invalid. Therefore, these VCs １ and V.C. ２ VC that can include ３ will be treated as invalid.

[0101] On the other hand, in the issuer-based VP structured data shown in FIG. 18, Issuer A has expired, and the VC hanging from Issuer A １ and V.C.４ Therefore, Issuer A, VC １ and V.C. ４ will be treated as invalid.

[0102] (VP Structure Analysis Processing (Second Time and Later)) Fig. 19 is a flowchart showing an example of the procedure of the VP structure analysis processing (second time and later). The VP structure analysis processing shown in Fig. 19 is a VP structure analysis processing executed by the VP structure analysis unit 320 for the second time and later. In other words, the VP structure analysis processing shown in Fig. 19 is executed after the first VP structure analysis processing shown in Fig. 11 is executed.

[0103] In step S121, the revoked VC analysis unit 323 receives revocation information, and in step S122, the revoked VC analysis unit 323 determines whether the issuance target has revoked.

[0104] The revoked VC analysis unit 323 executes step S123 if the issuance target has not been revoked. In step S123, the revoked VC analysis unit 323 determines whether or not the issuer has been revoked. If the issuer has not been revoked, the revoked VC analysis unit 323 executes step S124. In step S124, the revoked VC analysis unit 323 deletes all revoked VCs from the issuer-based valid VP structured data and creates new issuer-based valid VP structured data. Note that step S124 is executed in this manner when the VC has been revoked, and there are mainly two cases in which the VC has been revoked. First, when the VC validity verification has found that it has been revoked, and second, when verification of the issuer's signature has failed. Next, in step S125, the expired VC analysis unit 323 deletes all expired VCs from the issue target based valid VP structured data and sets the data as new issue target based valid VP structured data.

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

[0106] In step S126, the revoked VC analysis unit 323 deletes the revoked issuer and all VCs hanging from that issuer from the issuer-based valid VP structured data, and creates new issuer-based valid VP structured data. Next, in step S127, the revoked VC analysis unit 323 deletes the deleted VCs from the issuer-based valid VP structured data, and creates new issuer-based valid VP structured data.

[0107] On the other hand, if the issuer has expired, the revoked VC analysis unit 323 executes step S128. In step S128, the revoked VC analysis unit 323 deletes the expired issuer and all VCs hanging from the issuer from the issuer-based valid VP structured data, and creates new issuer-based valid VP structured data. In step S129, the revoked VC analysis unit 323 deletes the deleted VCs from the issuer-based valid VP structured data, and creates new issuer-based valid VP structured data.

[0108] 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 or not to authorize the provision of a service based on each VC included in the issuer-based valid VP structured data or the VC included in the issuer-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 that corresponds 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 a VC including the attribute information of the delegate (Holder1). １ , VC containing attribute information from the delegate to the delegate (Holder2) ２ , and a VC containing the attribute information of the trustee (Holder2) ３ Contains:

[0111] Next, in step S403, the attribute information verification unit 352 verifies whether the relationship between these pieces of 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 the VDP 400 has the relevant trust information, the issuer trust verification unit 353 acquires the issuer trust information as the trust information.

[0113] The authorization system 1000 according to this embodiment uses a VC as an example of a first verifiable certificate including attribute information of a trustor. １ and a VC as an example of a second verifiable certificate including attribute information of the delegator (for example, including the signature of the delegator and ID_delegator) as delegation information for the delegatee. ２ The issuer server 100 is an example of an issuer device that issues a VC. ２ and V.C. １ Upon receiving the third verifiable certificate, VC, which is an example of a third verifiable certificate including the attribute information of the trustee, is ３ VC １ and V.C. ２ The present invention includes a Holder terminal 200 as an example of an authorization request device that issues a VP configured by adding a VP to the Holder terminal 200, and a Verifier server 300 as an example of an authorization device that certifies whether the VP received from the Holder terminal 200 is genuine. When the Verifier server 300 receives the VP from the Holder terminal 200, it ２ The attribute information of the delegator included in １ The attribute information of the delegator contained in the VC can be traced without any inconsistencies, and ３ The attribute information of the agent in １ Delegators in the ２ If the attribute information of the delegate and the agent in the ３ The VP structure analysis unit 320 determines that a VP containing the above is genuine.

[0114] In the authorization method according to this embodiment, the issuer server 100 issues a VC containing attribute information of the delegate. １ The first issuing step is to issue a VC including attribute information of the delegator as delegation information for the agent. ２ A second issuing step in which the Holder terminal 200 issues a VC ２ and V.C. １ When receiving the agent's attribute information, ３ VC １ and V.C. ２ a second issuing step of issuing a VP configured by adding the VP to the VP structure analysis unit 320 of the Verifier server 300; and ２ The attribute information of the delegator included in １ The attribute information of the delegator contained in the VC can be traced without any inconsistencies, and ３ The attribute information of the agent in １ Delegators in the ２ If the attribute information of the delegate and the agent in the ３ and a verifiable request verification step of determining that the VP including the VC is genuine. In this way, for example, it is possible to prevent impersonation by an agent using an invalid VC.

[0115] In this embodiment, if the VP structure analysis unit 320 cannot trace the VC without inconsistency as described above, it excludes the VC from the verification target of the verification process thereafter. In this way, the VC verification unit 340 does not need to verify the VC, and processing costs can be reduced.

[0116] In this embodiment, the Verifier 300, which is an example of an authorization device, includes a VC verification unit 340 that, when determining that some VCs in structured data, which is data that structures the relationships between multiple VCs, have expired, deletes the some VCs from the structured data and verifies the remaining structured data. In this way, the VC verification unit 340 does not need to verify the some VCs, thereby reducing processing costs.

[0117] In this embodiment, the Verifier 300 includes an authorization policy verification unit 350 that, when determining that some VCs in structured data, which is data in which the relationships between multiple VCs are structured, have expired, verifies the remaining structured data after some verifiable certificates have been deleted from the structured data. In this way, the authorization policy verification unit 350 no longer needs to verify the some VCs, thereby reducing processing costs.

[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 or not to authorize the provision of a predetermined service, and the authorization policy verification unit 350 authorizes the provision of the service if structured data, which is data that structures the relationships between multiple VCs, does not violate the authorization policy, but does not authorize the provision of the service if the structured data violates the authorization policy. In this way, by setting an appropriate authorization policy in the authorization policy storage unit 390, the authorization policy verification unit 350 can accurately select a 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 issuer trust information, the conditions regarding issuer trust described in the authorization policy, and the issuer information 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 a public key used to authenticate a digital signature, thereby making it possible to detect tampering with a digital signature.

[0121] The authorization system 1000 according to this embodiment is a verification target (e.g., VC １ , V.C. ２ , V.C. ３ , VP) is stored in the revocation information cache unit 370. １ , V.C. ２ , V.C. ３, VP is subject to verification, it can be determined that it is fraudulent.

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

[0123] (2) Second Embodiment The authorization system according to the second embodiment has almost the same configuration and operation as the authorization system 1000 according to the first embodiment, and therefore, differences will be mainly described below. Fig. 21 is a block diagram showing an example of the configuration of the authorization system according to the second embodiment. Note that detailed configurations corresponding to the respective configurations in Fig. 6 are omitted in Fig. 21.

[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, and authorization policy storage unit 390, which were all mounted on the verifier server 300 in the authorization system 1000 according to the first embodiment, are separated from the above-mentioned verifier 397.

[0125] Specifically, in the authorization system according to the second embodiment, 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, a revocation information cache unit 370, a public key cache unit 380, and an authorization policy storage unit 390 are mounted on a VP verification server 399, and the VP verification server 399 is separate from the verifier having an interface 398 that exchanges VCs with the delegater, agent, etc. (and the issuer server 100, the holder terminal 200, the VDR 400, etc.).

[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, 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, as in the first embodiment, and return the authorization decision result to the verifier 397 (its interface 398). The interface 398 returns the contents of this response to an external party (such as an agent).

[0127] In this embodiment, an interface 398 that communicates with the delegate and the agent is separate from a VP verification server 399, which is an example of a verifiable request authorization server that has at least a VP structure analysis unit 320, a VP verification unit 330, a VC verification unit 340, and an authorization policy verification unit 350. By using the VP verification server 399 in this way, each process can be distributed, thereby reducing the processing load on the VP verification server 399, thereby reducing processing costs and eliminating the need to use high-speed but expensive devices, thereby reducing costs for the entire system.

[0128] The present invention is not limited to the above-described embodiments, and includes various modifications and equivalent configurations within the spirit and scope of the appended claims. For example, the above-described embodiments have been described in detail to clearly explain the present invention, and the present invention is not necessarily limited to those including all of the described configurations. Furthermore, the elements described in parallel in the present embodiment may be configured such that at least one of the elements is connected in series to the other elements.

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

[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...Authorization system

Claims

1. An issuer device that issues a first verifiable certificate including attribute information of a delegator and issues a second verifiable certificate including attribute information of the delegator as delegation information to an agent as the delegator; an authorization request device that, when the agent receives the second verifiable certificate and the first verifiable certificate, issues a verifiable request request configured by adding a third verifiable certificate including the attribute information of the agent 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, wherein the authorization device: an authorization system comprising: a structural analysis unit that, upon receiving the verifiable request request from the authorization request device, determines that the verifiable request request including the third verifiable certificate is genuine if attribute information of the principal included in the second verifiable certificate can be traced back without inconsistency to attribute information of the principal included in the first verifiable certificate, and attribute information of the agent in the third verifiable certificate can be traced back without inconsistency to attribute information of the principal in the first verifiable certificate and the principal and the agent in the second verifiable certificate.

2. The authorization system according to claim 1, characterized in that if the structural analysis unit cannot trace the document without any inconsistencies, it excludes the document from subsequent verification targets.

3. The authorization system of claim 1, characterized in that the authorization device is provided with a verifiable certificate verification unit that, when it determines that some of the verifiable certificates in the structured data, which is data that structures the relationships between multiple verifiable certificates, have expired, verifies the remaining structured data after deleting some of the verifiable certificates from the structured data.

4. The authorization system according to claim 1, further comprising an authorization policy verification unit which, when it is determined that some of the verifiable certificates in the structured data, which is data that structures the relationships between multiple verifiable certificates, have expired, verifies the remaining structured data after removing the some of the verifiable certificates from the structured data.

5. An authorization system as described in claim 4, further comprising an authorization policy storage unit that stores an authorization policy indicating criteria for determining whether or not to authorize the provision of a specified service, wherein the authorization policy verification unit authorizes the provision of the service if structured data, which is data that structures the relationships between a plurality of verifiable certificates, does not violate the authorization policy, and does not authorize the provision of the service if the structured data violates the authorization policy.

6. The authorization system according to claim 4, further comprising a trust verification unit that verifies whether the authorization policy is satisfied based on the issuer's trust information, the conditions regarding the trust of the issuer described in the authorization policy, and the information on the issuer included in the structured data of the issuer.

7. The authorization system according to claim 1, further comprising a public key cache unit for storing a public key used for authenticating an electronic signature.

8. The authorization system according to claim 1, further comprising a revocation information cache unit in which revocation information to be verified is stored.

9. The authorization system according to claim 1, wherein the first to third verifiable certificates are Verifiable Credentials, and the verifiable request is a Verifiable Presentation.

10. The authorization system according to claim 3 and claim 4, characterized in that an interface for interacting with the delegator and the agent is separate from a verifiable request request authorization server having at least the structural analysis unit, the verifiable request request verification unit, the verifiable certificate verification unit and the authorization policy verification unit.

11. A first issuing step in which an issuer device issues a first verifiable certificate including attribute information of a delegator; a second issuing step in which the issuer device issues a second verifiable certificate including attribute information of the delegator as delegation information for an agent as the delegator; and a second issuing step in which an authorization request device issues a verifiable request request configured by adding a third verifiable certificate including attribute information of the agent to the first verifiable certificate and the second verifiable certificate when the agent receives the second verifiable certificate and the first verifiable certificate. and a verifiable request request verification step of: when a structural analysis unit of an authorization device receives the verifiable request request from the authorization request device, determining that the verifiable request request including the third verifiable certificate is genuine if attribute information of the principal included in the second verifiable certificate can be traced back without inconsistency to attribute information of the principal included in the first verifiable certificate and attribute information of the agent in the third verifiable certificate can be traced back without inconsistency to attribute information of the principal in the first verifiable certificate and to attribute information of the principal and the agent in the second verifiable certificate.

Images