The 1st meeting of the Technical Working Group of the Advisory Council on the Identification of Issues in Attribute Certification

Last Updated:: Jan 6, 2026

Overview

Date: December 3, 2025 (Wed) from 16:00 to 18:00
Location: Online (Microsoft Teams)
- *The live stream has ended.
Agenda:
1. Opening
2. How to conduct a meeting
3. Mutual election of the chairs
4. Agenda: Discussion on "Issue 2: Technical and Operational Measures"
5. Closing and Communication

Material

Minutes

Secretariat (Kitainoue): The first meeting of the "Technical Working Group of the Expert Council on the Arrangement of Issues of Attribute Certification" will now begin.
Everyone, thank you very much for taking time out of your busy schedule today. I am Kitainoue from Digital Agency, serving as the secretariat. Nice to meet you.
On behalf of the Secretariat, I would like to welcome Mr. Kusunoki, Mayor of Group of Common Functions for Digital Society, Digital Agency, to this Conference.

Secretariat (Kusunoki) On behalf of the secretariat, I would like to say a few words at the opening of the meeting. I am Kusunoki from Group of Common Functions for Digital Society, Digital Agency. Nice to meet you.

As a forum for discussions on the realization of attribute certification in the digital domain, which is necessary for the digital completion of administrative procedures and data utilization, a new expert panel on the issues of attribute certification was established this fiscal year, and the first meeting of the main body was held in October this year. It was considered that discussions based on specialized knowledge would be necessary to present specific recommended technical requirements for advanced technologies such as VC and DIW, and it was decided to establish a technical working group under the main body meeting.

In this working group, we would like you to discuss what kind of technical and operational measures should be taken for the risks that need to be dealt with particularly in the use of VC / DIW, such as spoofing and name-based aggregation, which were sorted out at the main meeting. The results of this discussion are expected to be compiled as guidelines for the use of attribute certification by VC / DIW, and we aim to show the outline this year.

In order to promote the early social implementation of these technologies in an appropriate manner, I look forward to hearing frank opinions from the members of the committee and to active discussions.

Secretariat (Kitainoue): Next, I would like to explain how the plenary meetings are conducted.
Please refer to the installation outline in Material 1. We would like to realize the attribution certification necessary for digital completion and automation of administrative procedures, etc., and we would like to promote the utilization of VC / DIW toward such a major purpose. On the other hand, we are in a situation where the expected risks due to the new technology and appropriate technical and operational measures against the risks have not been organized. For this reason, we would like you to discuss the technical and operational measures from a professional perspective at this plenary meeting. The members are the 11 people you see. I will omit the introduction of each person due to time constraints.
Please refer to the next page. The Chair will be elected from among the Committee members. The secretariat will be in Digital Agency. Guest speakers and observers may be invited if necessary.
Lastly, the plenary sessions will be open to the public in principle, and materials and minutes will also be made available to the public.
That's all for my explanation. Please raise your hand if you have any questions or comments on how to proceed with the meeting, and if you are a member of the committee who participated online, please press the raise button on the Teams feature.

There doesn't seem to be anything special, so we can move on to the next topic.
In accordance with the Establishment Guidelines, the chairperson of the meeting will be decided by mutual election of the committee members. The Secretariat would like to recommend Professor Motonori Nakamura for the chair of the meeting, following on from last year's "Expert Panel on Governance in the Use of Verifiable Credentials (VC/VDC)." What do you think? Please raise your hand if you have any objections, and press the raise button on the Teams feature if you are an online member.

Since there were no objections, I would like to ask Professor Motonori Nakamura to chair this meeting. Professor Nakamura, could you give us a few words?

Nakamura, Chairman: .

This time, as the chair, I think we have gathered experts who are more knowledgeable than me. Even from the standpoint of a university, this VC is a very hot topic on how to make ID online, so I think it would be good to think about it together with your discussion. Thank you very much.

Secretariat (Kitainoue): , Chairman, thank you very much.

Now, let's move on to the next topic. Before we start the discussion, the secretariat will explain the purpose of establishing the meeting, the goal of this year, the scope of the discussion, and the risks to be discussed and their countermeasures. After the explanation of the materials, I would like to ask Chairman Nakamura to proceed with the discussion.
Then, the secretariat will explain each of them based on Material 2.

Secretariat (Nakagawa): Mr. . Thank you again for your cooperation.

After I have explained about one third of the details, my colleague will give a more detailed explanation. I believe that if I explain the background, issues, derivative certificates, and other points to be noted by the issuer at the beginning, it would be helpful for future discussions and when you consider whether the technical aspects can be ensured. Therefore, I would like to explain from there.

It is reproduced from the materials of the Advisory Council of the main body, which corresponds to the Working Group, so some of you may have seen it, but I would like to explain it without fear of duplication. Thank you.

First of all, regarding the background and issues, as you know, in My Number Card, it has already become popular, and we are a little closer to reaching 100 million cards, and it is said that we have just reached 100 million cards. On the other hand, although identification has been realized in terms of procedures and applications, there are certificates of qualifications and attributes, such as a copy of residence certificate, or a Tax Declaration Certificate. Also, among private companies, for example, school attendance certificates, academic records, or enrollment certificates. When you change jobs at a company, there is a need for private companies and semi-private companies to issue such certificates.

In terms of digitalization, I believe there are cases where certificates are provided in PDF. On the other hand, I believe there is also an aspect that it makes it easier to forge certificates. I believe there are technologies to prevent that, but I also believe there is a high risk of impersonation, which may be the case with certificates of residence currently provided in paper form. In addition, I believe that PDF is inferior in terms of machine-readability, and automatic data processing is also difficult.

In that sense, in order for people to feel that it has become more convenient, I think credentials and attribution certificates are important. In that sense, in the next page, which is about the purpose, I would like to work on how to make it more convenient using this VC-DIW. Furthermore, when we think about the need to spread it, I think it is good to be able to implement it cheaply, easily, and quickly. If you want security too much, it will be difficult to use, and it depends on the use case. So, I think it may not be possible to unify all of this, but how to balance this is important in terms of spread. I think it is also important in terms of ensuring availability.

I think it is related to usability, and there are laws, laws and regulations, ministerial ordinances, and government ordinances as systems, but I think we need to reconsider whether these things are really necessary. I would not say this is unnecessary, but if we think it is necessary and create it properly from the beginning, it will be difficult to use it. I think we need to consider the balance around this.

On the other hand, I believe there are some who would like to see some sort of indication, but we need to consider what exactly is necessary and sufficient, and we would like to proceed with the consideration while continuously evaluating our actions in pursuing our goals.

I will skip the next page, but I will introduce that VC and DIW are like this once again.

Page 6 is currently displayed on the screen. This time, I have told you that we are relatively close to covering the identification certificates indicated by My Number Card on the far left. The right side that is "Action required" is exactly the right side of the qualification certificates and attribution certificates, which are △ and ×. We would like to work on these points toward digitization. Please refer to this as well.

Please refer to page 8. Although certificates have been digitized, I believe that a copy of a certificate of residence will also be an example. Aside from whether this is appropriate or not, and just to make it easier to understand, if you submit a certificate of residence as it is at a convenience store, a copy of the certificate of residence will be issued as the content certified by the municipality. I think there are many cases where it is sufficient to submit a copy of the certificate of residence in the private sector. I wonder if it is really credible as a proof. There must be use cases where a certificate is issued by a legitimate authority and it is necessary to ensure the same level of originality and legal evidentiary power, and it is important for public certificates issued by administrative agencies to firmly secure this. I have written that we need to pay attention to this.

If you go to the left side of the page, you will see that you are the issuer of a conventional paper or other official certificate. In the case of a so-called certificate of residence, it is issued by each municipality. If you make a copy of this, for example, it will be issued by me. If I make a copy at a convenience store, it will be issued by me. I think it will be wrong.

From the right side of the page, in that sense, it is written that a VC is issued by a legitimate organization, for example, a legitimate organization may be established in the case of outsourcing. However, if a person who does not have authority in laws and regulations issues a VC, I think it should be noted that this may also be a copy.

The next nine pages are derivative certificates, which are more like copies, but I would also like to say that in addition to other information, for example, if you wanted to create something like a certificate that includes a certificate of tax payment on the residence certificate, which is not a case in the real world now, I think it is a world where you can do it. I think there is a question as to whether it can really be said to be a certificate if it is issued after being properly certified by each municipality. First of all, there is a certificate of residence. For example, there is a certificate of residence in which I live and have many children. If someone writes a certificate of income equivalent to a Tax Declaration Certificate on it. If you create something that is equivalent to an income of a whole household, it will be a derivative certificate, but it will not be a certificate that is affixed at that time. I am saying that it cannot be certified unless each party can make inquiries to the legitimate issuer of each information and confirm that it is correct or that the information issued is that of the person.

This is a written statement, but a derivative certificate is issued by a person who does not have the same legal evidentiary power as the original certificate. If a third party confirms the original certificate at a certain point in time, it can be said that the person who saw and copied it made the copy, but it is not more than that. I think it is necessary to confirm with the original issuer whether the information is correct or not.

It may be difficult to understand the explanation, but basically, a certificate must be the responsibility of the issuer. If someone makes a copy of it or modifies it in some way, it cannot be said to be a certificate. This is what I wanted to say, both on paper and electronically.
Let me tell you that first, and from the next page, I would like to ask my colleagues. Thank you very much.

Secretariat (Sawada): Thank you, .

What Nakagawa said was part of today's discussion as a whole, but it was a point that I particularly wanted to share with him, so I highlighted it in my explanation.

Next, I would like to look back on the discussions and introduce the trends so far. First of all, it is a brief review of last year's meeting, but in last year's "DIW Advisory Board", I summarized that DIW has various advantages for each stakeholder. In addition, since VC and DIW are integrated, it is okay to read "DIW" as VC · DIW.

In addition, we also sorted out three types of use cases in which DIW can be expected to be utilized. We also identified risks that are of concern when using such VC and DIW. We also received opinions on what governance is necessary for the Verifier or Wallet Provider as a countermeasure against those risks. In addition, at the "Expert Meeting on Governance in the Use of Verifiable Credentials (VC/VDC)," which was another meeting body last year, we discussed the responsibilities of the Issuer in particular.

Based on these discussions, in the report of the "DIW Advisory Board", regarding the measures necessary for VC and DIW to deal with various risks that cannot be covered by the existing governance, we have organized such a framework with technical, operational, and institutional governance as shown in the blue frame. I would like you to consider this fiscal year as a continuation of this discussion. Therefore, I would like you to consider that the overall picture of the risks of VC and DIW is based on the discussion of last year. That is the review of the brief discussion of last year.

Next, I will explain about the growing expectations for the use of VC. On this page, an image of the prospect of digitalization and advancement of certificates is illustrated. In this, what we, the administration, should first focus on is certificates issued by the government, such as the certificate of residence in dark blue, or certificates verified by the government, such as employment certificates. In response, we will promote it while making rules, including the formulation of guidelines. In addition, we are looking at promoting use cases between the people below us, and in the future, advanced certificate utilization such as push-type administrative services as written on the right. I would like to share this image of the prospect as a premise for discussion.

On page 18, we introduce recent trends in VC and DIW, including topics in the EU and the United States, as well as standardization of related technologies. Due to time constraints, we will not go into details, but we recognize that we are at the stage where parts for social implementation are being assembled, with the OID4VP and OID4VCI specifications finally approved and the SD-JWT specification published as an RFC.

Next, I would like to look back on the first main body meeting. First of all, what were the discussion points of the main body meeting? We discussed what kind of discipline is necessary for the inherent risks of VC / DIW, which were sorted out at the last year's meeting, in other words, how to encourage countermeasures. As a result, we largely agreed on the policy of starting to formulate guidelines for the use of VC / DIW. We also received opinions that it is important to consider the scope of the guidelines, the expected readers, and the enforcement, and that we should embody the image of use cases and discuss them including low-risk use cases. Based on these, we set the discussion points for this technical working. In addition, we received various opinions on the necessity of legal measures and certification systems and expectations for dissemination activities.

Next, I will explain today's issues. First of all, in the technical working session held today, we will discuss technical and operational measures. This is because the main meeting I mentioned earlier discussed disciplinary methods for measures, and I would like the technical working session to discuss the implementation details of measures.

Before we get into the discussion, I would like to talk about the assumed scope of the guidelines that will be developed through this meeting. First of all, as it is written at the top of this page, strict measures are not necessarily required for all use cases, so the level of measure requirements is divided into two stages. To be specific, we are thinking of dividing it into two stages, the minimum measure that should be implemented for all use cases and the proposed measure that is recommended for relatively high-risk use cases. Through this, we would like to make it a document that does not become excessive measures and that allows each organization to select recommended measures.

In addition, as shown in the right column, the guidelines are basically intended to be applied to administrative agencies, but it is assumed that private sector can also be used as a reference. In addition, how to apply and operate the guidelines will be discussed at the main body meeting, not at this technical working group.

Next, I would like to ask about the goal of this year's meeting. As for the goal image, I assume that we will compile the outline of the guidelines that show the measures to be taken against threat risks to public use cases. I assume that the guidelines here will be positioned, for example, in the digital society standards promotion guidelines that are being formulated for the government and society digitalization. Once again, in this technical working group, I would like you to discuss the ideal way of technical and operational measures that should be described in the guidelines.

In addition, as shown in the column on the right, the expected effects of the guidelines include facilitating the examination of specifications, ensuring interoperability, and reassuring users by ensuring the implementation of risk measures. However, especially at the stage of the discussion of this outline, I think that it will be a document with the meaning of making decisions on whether or not to introduce VC in administrative agencies, or making this direction known to private companies.

Next, in response to the comments from the members of the main meeting, I will introduce two use cases that will be the subject of discussion this time. However, as shown in the red on the page, they are only fictitious use cases for discussing risk countermeasures, and please note that the guidelines we aim for are not specialized for specific use cases, but are common documents for public use cases.

The first use case is a VC with a copy of a residence certificate as a government-issued certificate. This is the same as a paper residence certificate, and there are no restrictions on who can present it, and it is assumed to be used as household information or proof of residency. Basically, the local government will issue a copy of the residence certificate to the person's wallet, and from there, we would like you to assume that it will be used to selectively disclose attributes to private companies online or in person.

The second use case that the government will receive is a VC working certificate. This is something that will be used for the screening of nursery school admissions, just like the paper operation. For this one, the company where the person works will issue a VC working certificate to the person, and present it to the local government online or in person, or link the VC to APIs on the online application system. I would like you to assume this usage.

We will also have time to discuss these two concrete use cases later today.

Next, I will explain the threats and risks that are the subject of the discussion. First of all, about the overall picture, based on the organization of the risks discussed last year, this page has reorganized the threats according to the VC life cycle. For example, by spoofing, you can issue a VC to a third party, VC data can be leaked from a smartphone, or you can accept the presentation of a VC by a fake issuer. I think there are various threats.

Next, regarding these threats, the types of risks are summarized on page 30. From the top, there are the following four types: (1) impersonation by theft or reuse of legitimate VCs, (2) damage from acceptance of counterfeit or derivative VCs, (3) invasion of privacy caused by VCs, and (4) deterioration of availability and convenience of VCs. The details of each risk will be explained later.

Incidentally, not all VC / DIW risks can be covered in this fiscal year's discussions. Risks that generally occur in web services and those that do not have many points of discussion in the measures are excluded from the discussion. In addition, for example, there may be common points of discussion not only in VC but also in other means such as signed PDF, such as leakage of private keys, but I think there are parts that have not been sufficiently discussed in measures against these threats, so there are some that are being discussed in the plenary session. Next, I will introduce specific measures for the four risks I mentioned earlier.

Secretariat (Ishii): Then, I will explain the following pages from Ishii in Digital Agency.

First, I will explain the concept of measures required for public use cases. Page 35 is a reprint of the main meeting, but it shows the overall picture of the technical and operational aspects required for public use cases. From page 36, I will explain the details of measures to be taken for each of risk types (1) to (4).

The first risk is the risk of theft or re-use of VCs. This refers to the overall risk of third parties abusing VCs by stealing or leaking VCs through attacks at various stages of the VC lifecycle. We present measures against the theft or re-use of VCs from four perspectives. The first is the "identity verification at the time of VC issuance." At the time of VC issuance, a mechanism to prevent spoofing by third parties at the issuance stage, such as identity verification by My Number Card or authentication by IDs and passwords, can be considered. The second is the "linking of VCs and holders," or so-called holder binding, which is a mechanism that can detect attempts to use stolen VCs by linking VCs and holders using attribute information or encryption keys. Furthermore, "secure management of encryption keys" protects the keys themselves, and a mechanism that prevents unauthorized retrieval from wallets by storing keys in a secure area such as the Secure Element of a smartphone or an external HSM is considered. Since there are several possible key management methods, they are shown in detail on page 2. Finally, there is "management of validity and revocation status" as a risk reduction measure. There are measures to minimize the risk of abuse even if VCs are stolen, such as setting expiration dates, limiting the number of presentations, and managing revocation by the Status Provider.

On page 37, the secretariat's proposal shows the concept of the level of measures according to the risk of theft and re-use of VC. First of all, as a minimum measure to be implemented in any use case, we believe that a basic "identity verification" for the issuer and "linking between VC and Holder" by attribute information such as name and date of birth are necessary. On top of that, we believe that it is necessary to take additional strict measures for VC that can be used for important procedures and high-risk use cases where the impact of theft or re-use is large, such as a copy of residence certificate or facial photo identification used for identity verification documents, and those that can be used for important procedures. Specific measures include implementing Holder Binding based on encryption keys and biometric information, and utilizing advanced security areas such as Secure Element and HSM as "safe management of encryption keys," in addition to "strict identity verification at the time of VC issuance."

In this way, by setting the level of measures in stages according to the size of the risk in the use case, we believe that we can prevent excessive measures in all use cases. In addition, we would like you to discuss the contents of the measures shown here and the pros and cons of dividing the minimum measures and additional measures after this.

On page 38, the key management methods and restrictions are shown for your reference. A detailed description is omitted due to time constraints. However, four major combinations of wallet provision and key storage areas are shown with reference to the EUDIW ARF. The considerations for each combination are listed for your reference.

The second risk is about the risks related to counterfeit VCs and derivative VCs. The risk of counterfeit VCs refers to the risk of issuing VCs by fictitious companies and universities and being used for illegal receipt of benefits and misrepresentation of records. The risk of derivative VCs, which is a repetition of the page of the derivative certificates at the beginning, refers to the risk that they will not be considered legitimate certificates in the first place and the Verifier will not accept them, and the risk of causing social confusion. For both counterfeit VCs and derivative VCs, digital signatures alone cannot prevent fraud and impersonation, so we believe that additional measures are necessary.

The main measures against counterfeit VCs and derivative VCs are shown from two perspectives. The first important measure is "guaranteeing the identity of the VC's signature." By linking the public key to verify the issuer's signature attached to the VC with the actual issuer, it is possible to verify that the signature is attached by the expected issuer and is not a fake Issuer or a different issuer from the original. However, this meeting assumes a conventional trust anchor using PKIs and X. 509 certificates instead of a distributed repository, which may be used in Decentralized Identity. Another measure is "guaranteeing the eligibility of the VC's issuer." In addition to simply verifying the signature, there may be a mechanism that can verify that the VC's issuer is a qualified organization that meets certain conditions. For example, by publishing a list of the issuer's attributes or preparing a list of issuers who guarantee the eligibility, the Verifier can determine the eligibility of the issuer by itself. For reference, examples of implementations in other countries are shown in the second page.

On page 42, the concept of the level of measures according to the risks related to counterfeit VCs and derivative VCs is shown as a proposal by the secretariat. First of all, as a minimum proposal that should be implemented in any use case, we believe that "guaranteeing the identity of the VC's signature" is necessary. On top of that, since it is difficult for the Verifier to judge the eligibility of the Issuer individually when there are many Issuers or when they change frequently, we believe that additional measures are necessary so that the Verifier can judge the eligibility of the issuer by disclosing the attribute list and eligibility list of the VC issuer.

For your reference, I will not go into the details, but EUDIW has introduced a system called Trusted List, and the US mobile driver's license has introduced a system called VICAL.

The third risk is about privacy risk. VCs contain information that is easy to link together, such as signature values, and if multiple Verifiers intentionally share the information of the presented VCs, there is a risk that privacy protected by selective disclosure will be violated.

"Selective disclosure" is the first and basic measure against privacy-related threats. By disclosing only part of the attribute information contained in VC, it is possible to avoid the exposure of unnecessary information and fundamentally reduce the risk of name-based aggregation based on attributes. However, in selective disclosure, there is a risk that VC signatures themselves will be abused as identifiers, so as a countermeasure, "name-based aggregation mitigation measures based on signature values" are necessary, and a mechanism to prevent tracking based on signature values, such as a bulk issuance of multiple VCs and a rotation function, is possible. Furthermore, in addition to signature values, metadata contained in VCs, such as issuance time and various identifiers, may be subject to name-based aggregation, so as a countermeasure, "name-based aggregation mitigation measures based on metadata" are important, and mechanisms such as minimization of metadata, randomization, and shortening of identifier life are possible. Finally, there is "name-based aggregation mitigation measures based on Verifier restrictions" in the form of supplementing technical measures, and by limiting the presentation destination of VCs to specific trusted Verifiers, it is possible to consider a mechanism to reduce the risk of information being shared between multiple Verifiers in the first place. Many of these measures depend on the VC format and need to be implemented not only by the Issuer but also by the Wallet and Verifier.

On page 47, the concept of the level of measures according to privacy risks is shown as a proposal by the secretariat. As a basic idea, since privacy risks differ greatly depending on the use of the VC, we believe that it is appropriate not to establish measures that should be implemented at least, including VCs for specific uses that are presented only to specific Verifiers. On the other hand, for multi-use VCs, the need for selective disclosure is high, and for VCs that are presented frequently and submitted to a large number of Verifiers, the risk of consolidation increases, so additional measures are required. Specifically, we believe that it is desirable to take various measures such as "selective disclosure," "consolidation reduction measures based on signature values," and "consolidation reduction measures based on metadata." In addition, measures to reduce consolidation due to zero knowledge proof-based technology and Verifier restrictions are not candidates for the standard of measures at this time from the perspective of technical maturity and implementation difficulty.

For reference, the relationship between the VC format and privacy-related measures is shown. Although a detailed description is omitted due to time constraints, whether or not "minimization of presentation attributes by predicate proofs" and "zero knowledge proofs" can be implemented may depend on whether or not the VC format can be supported.

Finally, the fourth risk is related to the availability and convenience of VC. This is the risk that if the VC does not have the required compatibility when the service of the Wallet Provider or Issuer is terminated or the terminal is replaced, the VC cannot be transferred and cannot be used. We have presented measures from four perspectives regarding the main measures against the deterioration of VC availability and convenience. The first and basic measure is "ensuring the transferability of VCs and technical compatibility between terminals and wallets." It is possible to consider a mechanism that allows holders to continuously use VCs, such as establishing a VC backup, restore, and reissue function and a VC export function to another wallet in case of device loss or device replacement. Furthermore, there is "technical and operational measures against the impact of specification changes" as an issue that arises over time. We consider measures such as guaranteeing the validity of VCs issued with old specifications, managing revocation status when using VCs with old and new specifications together, and multi-version support. In addition, we believe that it is necessary to conduct an appropriate impact survey to ensure such compatibility when modifying the current functions in accordance with the changes to the guidelines to be formulated at the meeting.

On page 52, the secretariat's proposal shows the concept of the level of measures according to the risk of VC availability and convenience. As a basic concept, since the frequency of loss and replacement of terminals is high and the impact is large, the secretariat positions the measures organized on the previous page as minimum measures that should be implemented in any use case.

Next, I would like to explain the points I would like you to discuss regarding Issue 2. There are three major points that I would like you to discuss toward the formulation of the guidelines. In Issue 2-1, regarding the content of technical measures against the four risks I have just explained and the appropriateness of the level of measures, whether it is a minimum implementation measure or an additional measure, I would like you to check whether the content organized in this document is excessive or insufficient, and I would like you to focus on discussing the minimum measures that should be implemented in all use cases. In Issue 2-2, regarding whether there are risks that are difficult to solve only with technical measures, I would like you to give your opinion on the necessity of measures such as disciplines to supplement technical measures, and if necessary, I would like you to consider them as candidates for the agenda of the next main body meeting. In Issue 2-3, I would like you to consider whether the above general measures actually function appropriately in specific subjects such as a copy of residence certificate and Certificate of Employment, and I would like you to discuss these risk measure standards as well.

This is the end of the document explanation from the secretariat. Then, once again, I would like to ask Chairman Nakamura to proceed with the discussion from now on. Thank you in advance.

Nakamura, Chairman: Thank you for your explanation.

There are materials prepared by the secretariat, and we will proceed with the discussion in accordance with them. However, based on the background that you explained at the beginning, we need to make a digitalization of various certificates, and there are new technologies such as DIW and VC, so discussions will be made on the premise of these technologies. That is the outline of the discussion. I think that is OK. Having said that, I would like you to first look at these materials and then, today, I would like you to give us some comments on how to proceed with the discussion.

As I believe you have already heard, this technical working group has met twice this fiscal year, and today is the first meeting. The second meeting will be held in January, and we would like to create guidelines. The rough schedule is to compile the guidelines toward the end of this fiscal year for the time being. However, I think that many of you do not think that all the discussions will be concluded at these two meetings and a consolidated guideline will be completed. However, since this is a meeting where you all gather to discuss, I think it would be good if we can coordinate our views, communicate in an offline setting, and advance the areas that we can brush up more in parallel or between meetings.

In this document, the key words "VC" and "DIW" suddenly appeared at the beginning, but the definition of these words was not mentioned at all. Since we do not know what we should discuss, I think we need to share our views on this point at the beginning.

You gave me a brief explanation of the materials, and I skipped some parts. Looking at the materials as a whole, I think that the secretariat's image is somewhat unclear. Even so, there are various keywords that are not unified in consciousness, and there are things that are different from what I thought, so I think it is better to confirm them at the beginning. I also received the materials in advance and checked them with the secretariat, but first of all, various things can be assumed for VC, and as long as you do not specify a specific standard, I think the VC you are imagining is different.

First of all, broadly speaking, what form of trust are you envisioning? When we consider the so-called conventional PKI-like form and the trendy distributed trust-like form, of course, there is a VC in Architecture that envisions a distributed trust, so what will happen there? For the time being, we will not be envisioning a distributed trust at this meeting, so I think this will be the first agreement, but as a general framework, I agree with your understanding.

On top of that, it may not be necessary to limit ourselves to the traditional trust model of PKIs. The goal of what we are actually discussing is not just to create guidelines, but to aim for the early digitalization of certificates in the world as guidelines necessary to realize something that can actually be used by everyone. In that sense, I think it would be more efficient to use existing trust mechanisms where they can be used. From that perspective, I think there will be various opinions.

So, first of all, on that premise, if a trust can be established in some way, in the context of VC / DIW, there is an issuer and a verifier, how to confirm the identity in this document, how to confirm the holder, how the issuer can confirm the holder, how to confirm the holder as a verifier, or how to confirm the issuer, trust or a reliable identification of the other party is required for various relationships. However, what kind of relationship exists in the first place has not yet been organized in this document. We need to proceed with the discussion while imagining actual use cases. It is necessary to confirm these relationships, and at that time, whether there are risks such as impersonation, etc., should be examined in detail for each individual, which is our final confirmation work, I think. When thinking about how to confirm the other party in such a case, although it is something like an identifier in the sense of an ID, as an issuer, whether it was actually issued as a correct organization or not, of course, the ID as an issuer must be confirmed. For example, if a certificate is to be issued for the information on the residence certificate that should be verified, what should be the ID to show who the residence certificate is for? In that regard, since the Public Personal Authentication can only receive the basic four pieces of information, and information to identify individuals such as the My Number cannot be basically obtained from the Public Personal Authentication, there are probably various ways of thinking about how to identify the person who should be verified on that premise. There are aspects that are not mentioned in this document from the perspective of the ID. Therefore, I think we need to discuss with you first about how to organize that.

In this context, as we proceed with our discussion today, what should be confirmed first? If you have any other opinions, I would like you to speak about them first. Do you have any opinions, Mr. Sakamura?

Committee Member Sakimura: Actually, I wanted to send comments in advance, so I wrote down the issues, but it ended up being more than 10 sheets of A4 paper. Essentially, if you write down an issue, you also have to present a solution proposal for it, but if you do so, it's impossible, and it won't make it in time, so I ended up not sending it.

The technical working group needs to take care of the lack of consideration of interoperability from the viewpoint. At the board room level, it is called VC, but in Europe, for example, it is called VC in one word, but when it comes to companies, I think it is better to use VReI and AnonCreds. We need to consider what to do with these points. Also, in practice, implementations created by reading English or Japanese standards will vary, so there is no need to prepare a test suite at all. I was a little concerned.

Also, the protocol layer. In the introduction of the news, it was mentioned that the final decision was made on OpenID4VCI and OpenID4VP. However, since it is originally a technical working, I think we have to talk about it at that level. There are man-in-the-middle attacks and legitimate VC, but I feel that preventing the reuse of such things depends very much on this protocol. Therefore, I have to include that point of view.

In relation to what I just said, I would like you to use your words carefully. This is a technical issue, so I did not mention it at the meeting. However, as Professor Motonori Nakamura mentioned, what is the definition of VC / DIW? What is a distributed trust? Also, as pointed out at the meeting, we learned the word "qualification" from "certification." Authentication and Certification. Since we are going to do it again, I would like you to use different words. Also, regarding derived VC and derived certificates, for example, the difference from NIST FIPS 201 derived certificates, I think it is necessary to say it clearly, so I would like you to define it clearly.

It's about threats, risks, scope and privacy treatment, and there are serious privacy and security threats that are not covered this year. I think requests for more information than necessary, unauthorized access to data in the wallet by the Wallet Provider, and collection of usage history are DIW-specific and serious privacy risks. I think it's a bit premature to exclude this by saying that it is common to all web services or that it has a small impact on the promotion of countermeasures. I think it's a problem specific to wallets that they are quickly taken away by a fake Verifier.

In addition, there is a problem that privacy is taken up in a very narrow way mainly by name-based aggregation.
I won't go into details because it will take time, but privacy, for example, has eight principles in the OECD and 11 in the ISO, so it is necessary to look at them in a balanced manner, so we will look at it from that perspective in accordance with the framework.

Also, I have the impression that there is a premise that Verifier restrictions are not taken, but I wonder if this is also the case. In general, that is fine, and I think users need to be able to override it, but I wonder if there is an approach of limiting the distribution range especially for sensitive data.

In addition, zero knowledge proof is an advanced privacy technology, but it also has a major aspect of a technology to ensure scalability. This is good when it is not used much, but Batch Credential Issuance will probably overload the Issuer when VC is used heavily. I think that the technical working should consider this properly.

In addition, although derived certificates are not well defined, I believe there is a strong tendency to exclude them, and I wonder if there are any challenges due to this. If we put too much out there, for example, without referring to FIPS 201-3 or NIST SP 800-157, there is a possibility that it will affect Derived Credentials in general, so I think it is not a good idea.

In the world of identity, the Notarization model, in which a trusted third party organization issues a digital certificate after verifying the original paper document, is also common and important. In eIDAS 1.0, it is an official identity document and paper, but the fact that this has been confirmed at the counter and its format, etc., are attached with metadata such as date and time, and the bank issues it to QTSP as an ID token, and QTSP creates a short-term qualified certificate, and the user creates this qualified document, which is currently qualified, a Qualified Certificate, and a Qualified Signature. This model is currently in common use, so I wonder if it should be completely eliminated. When VC is used for certificates that have been issued in the past and are difficult to reissue now, such as certificates of small and medium-sized companies that are not making progress in digital transformation, I think the Notarization model is very effective. So, I think we should think about this properly. As it is, unless the organization that has the original data responds to VC issuance, it will not come into the Wallet.

This is related to the current issue. When it comes to Notarization, proper people must follow proper procedures. Therefore, there should be a framework for accreditation, auditing, and incident reporting, but this document omits a point. What to do with auditability is also something that must be done by technical working groups.

In addition, setting up use cases is also a challenge. For example, in the case of a residence certificate VC, there are many models in which not only the person in question but also a representative or a family member goes to get it, and there is a gap with the reality that only the person in question can get it. What to do? Employment certificate The ecosystem of VC is very simplified, and it is basic to present it from the corporate HR system to the government, but there are various things such as HR outsourcers, SaaS vendors, and intermediate gateways, so I don't think we can think about it twice.

Actually, I think the most important use case is for VCs to present multiple VCs together in a single VP. We need to properly include that in the use case and consider it. If not, we can just go with a normal federation.

Also, the issue of VC portability between wallets is mentioned on page 51. We need to properly consider what to do technically, but I don't think we can do it twice.

Holder Binding, Key Management, and Terminal-Dependent Issues. Holder Binding requirements and how to deal with proxy usage need to be considered technically. Also, the key life cycle, the agility of the algorithm, and its future have not been discussed much.
To put it in a broad framework, I think about this much of the review items are missing, and I feel it is quite difficult. That's all.

Nakamura, Chairman: .

Secretariat (Katsunobu Kato): From the Secretariat, I heard that Commissioner Sakae Fuji will be making remarks online.

Nakamura, Chairman: , please.

Committee Member Sakae Fuji: 's remarks were lengthy, I thought it would be better for him to be brief. I also have similar comments, but I will keep them as short as possible.

First of all, from Chairman Nakamura's remarks on whether there were omissions or not, I felt that what was conspicuously lacking was the perspective of the holders, that is, the users. Second, I noticed that the interoperability and the usage of words that Mr. Sakamura mentioned earlier were quite rough for technical working. These are the two major points.

When it comes to the perspective of the holder and the perspective of the user, you mentioned that it is a derivative VC and the risk. Then, I think we need to include the perspective of UI, including how to make it clear to the holder. For example, the use case of government from the private sector and vice versa was specified. It is important to make it clear to the user that this is a derivative, and the holder has to know whether the Verifier really wants the original, or whether it is a copy or a derivative. In this regard, technically speaking, the eligibility of the Issuer and Trusted List were mentioned earlier. How to disclose metadata related to the Verifier and what attributes should be included in the Trusted List were discussed together with the EU case. I think we need to properly discuss these issues.

The other is privacy. As mentioned by Mr. Sakimura, this is a topic that goes too far in terms of linkability and unlinkability. There was also a topic at the end. How to consider the inclusion of multiple VCs in a VP. In fact, it is also necessary to talk about this holder binding, or how to consider the establishment of binding between VCs. For example, by including credentials issued by a private company and identification issued by a public organization in the same VP, and assuming that they are issued from the wallet to some extent, if it can be established that they refer to the same person by being bound, for example, information related to PII (Personally Identifiable Information) can be reduced as much as possible for the credential side. I felt that it would be very useful to consider this, including technological security, when considering use cases.

As for the accuracy of the second point, it is about interoperability. I think it has been skipped as a material earlier, but I thought that it would have to be revised to some extent on the assumption that the material will be released. Especially on page 48. For example, although it is written as W3C VCs, I personally feel that data models and formats are being discussed together. For example, although it is written as W3C VCs, whether this refers to Data Integrity VC or W3C VCDM is not understood from the material. Considering that whether or not selective disclosure and zero knowledge proof can be implemented is in the table, I think that this is probably talking about Data Integrity VC. The reason is that it is a feature of Data Integrity VC that whether it can be done or not depends on the signature method adopted. This is a completely different layer from W3C VCDM. In other words, it is a different layer from data models. If we do not express that this layer is different somewhere, the discussion will probably proceed within the keyword of VC, and we will not be able to sharply discuss what is being referred to. I am concerned that this will eventually have a major impact on interoperability. I feel that it is important to prepare to be able to discuss this in detail, especially in the technical working. That is all.

Nakamura, Chairman: Thank you very much.

Secretariat (Sawada): Thank you, , if I may add anything, I would like to apologize for the lack of definition of the term. However, in order to make the best use of the time you have gathered here today, I would appreciate it if you would postpone the discussion on the definition itself as much as possible and just make a statement on what kind of system is necessary and confirm it to the extent necessary.

Also, as I mentioned in my explanation, I understand that the content is not covered completely. It is not possible to deal with all of it at once. Therefore, it is in the form of a selection. Of course, I would like to hear your opinion that the selection is not the main point. However, since some of the contents were already presented at the main meeting, I would like to return the opinions of the technical working group from a technical point of view. Therefore, I would be very grateful if you could make conscious remarks. That is all from the secretariat.

Nakamura, Chairman: I would like to add that, in this discussion, a copy of a certificate of residence or a working certificate was raised as an actual use case. In the discussion at the parent meeting, VC / DIW was also discussed as an extremely abstract topic, and it was predicted that there would be insufficient sharing of understanding in the technical working in the first place, so assuming several specific use cases would make it easier for the technical working to discuss. Therefore, a copy of a certificate of residence and a working certificate were presented. However, the handling of a copy of a certificate of residence is still ambiguous in today's materials, and there are various ways of using it. After all, that is ambiguous, and I would like to work out how to do it technically in this specific pattern. However, I have not been able to go into such a specific pattern. In that sense, at today's stage, I think it is meaningless to go into the specific use cases of a copy of a certificate of residence and a working certificate. However, I think it would be good to receive opinions on this entire material for today, assuming that point.

As for the definition, I think it would be good to align our awareness after sorting it out later. First of all, at today's stage, what kind of discussion should we have? We would like to hear various opinions mainly on the points that have been left out. We discussed with the secretariat in advance about the final form of the document. When we prepare the final document, even if we cannot come up with in-depth and detailed guidelines, we will have to consider them as items for the table of contents. Although time is up this time, we need to continue to work on the details if possible in the next fiscal year. We would like to at least identify those items for this fiscal year. From that perspective, I think it would be good to point out the various points that have been left out.

If you have any additional information, please let me know.

Committee Member Itakura: . Is it correct to understand that today's goal is to have a meeting where everyone raises issues that are thought to be missing in the measures?

Nakamura, Chairman: That's right. If there are any items that should be taken into consideration, I would like you to point them out.

Committee Member Itakura: .

I will be speaking on that premise. First of all, I will not be talking about definitions today. However, what I thought was that the issue of how to consider risks would be overwhelmingly unclear. I thought that the level of countermeasures would differ depending on what was considered high risk and what was considered low risk, and that unless the issues were properly sorted out, the discussion would be unclear.

There are several aspects that are lacking in the measures, but first, from the perspective of the need to protect the entire life cycle of non-VC identities, I think we need to cover not only the measures taken by the VC mechanism alone, but also the technologies derived from it. For example, in the case of linking VC and Holder, I think there is a way to do binding within VC, or a way to use technology such as mTLS, so I think there are more things that can be considered in the entire life cycle of identities rather than VC alone.

The other point is that the terms "Issuer" and "Holder" often appear, but I don't think the perspective of the wallet comes out very much. For example, not only the binding of Holder and VC, but also the binding of the wallet and credentials may be necessary. How can we verify that the wallet itself is properly managed and that no harm has been done? I think the perspective of how the issuer can manage the wallet is necessary.

Also, as you said about use cases, if we don't go beyond the residence certificate VC or work certificate, the risks will change, so in that sense, I think it would be quite difficult to talk about it in these two sessions. I thought it would be good if we could narrow down the points of discussion a little more and discuss measures.

Nakamura, Chairman: .

That's right. Therefore, I think it would be a good idea to go a little deeper into the issue of residence certificates, and although there are various patterns, we should first consider this pattern to the end. However, I am not sure if that is the model we or the government are aiming for in the first place. Based on how to proceed with that, if you still have any opinions, please let me know.

Committee member Niizaki: , I talked about key management earlier, and there is something like a difference between smartphones and IC cards, and IC cards are not close to the reader while they are held. They are independent and hold up to the reader only when they are used. Even if smartphones have secure chips, they are around. They are always there, and instead, smartphones can monitor and check if they are working properly, so we are dealing with two different things, so I think there is a discussion about smartphones with Wallet. Regarding the Secure Element, for example, I think there will be various stages, such as whether applets with CC authentication must be included in the Secure Element, or whether it is OK to use the keystore provided by the operating system and the keystore provided by the API. EUDIW has recently described the Secure Element and the keystore separately, so I think it would be good to have something like this for this usage.

In addition, I have a feeling that the issuance process will be included in this, and I have felt that only the confirmation process has been done so far, but when the issuer becomes an administrative agency and it becomes within the scope of VC, including the past, I wonder whether or not the issuance process will be included in the guidelines.

Nakamura, Chairman: , thank you very much. Next, Committee Member Nakamura.

Mr Kenichi Nakamura: ): There is no end to the list, but if this is implemented in society and citizens can use it with peace of mind, it will be extremely important to make the interaction with users as light as possible. In particular, when issuing certificates, citizens will of course bring their diplomas and certificates of residence to driving schools, but after all, if it is to confirm whether they are correct or not, these certificates will have to be digitally certified by the correct issuer, which will put more and more burdens on various things. At such times, VC, in our world, it is called mobile document (mdoc), and we need to categorize them, including how they are used, their purpose, and the sensitivity of the data stored there. In particular, if we force them to issue documents that must be issued by the private sector and are very costly, this can easily become a loophole. Therefore, in order to create a system that can issue appropriate documents, including the effectiveness of implementation and economic burden, we need to create good guidelines. For example, if you have a certificate like this, you need to do at least this much, and I think you don't need to write that you don't have to do this much because it will cost a lot, but I think we need to make it easy to understand these things.

The other is on the receiving end. In the case of analog certificates, if you make a copy many times, the image will deteriorate and you will immediately know that it is a copy. If the original is in color but comes out in black and white, you will know at once that it is a copy. If you look at it, you will know that the characters are crushed. However, in the case of digital certificates, you will not be able to distinguish between them. At such times, one of the problems is how valid the credential is. The term "derived certificate" is probably a bad one, and Derived Credentials may be better. In short, a credential issued by the original Issuer has such validity. However, it can prove everything that the original certificate has. How to convey this to the user is a very difficult situation.

Since this is a digital world, I think that it is necessary to create a system that does not inconvenience users by making it clear to the digital world that the power of digital can be used, for example, for something that has this kind of efficacy, and that the user and the recipient can accept it as it is because it has the original efficacy, or that it is a derivative and they should bring the original.

Nakamura, Chairman: .

Committee member Minai: My name is Minai . Nice to meet you.

Since Committee Member Sakimura has already said that there are about 10 pages worth of technical matters that need to be touched upon, I would like to speak without going in the other direction.

Committee Member Itakura commented on the wallet side, but I do not think there is much to talk about. The reason why I am concerned about this is that as a result of the advancement of digital exchange of various things, there are parts that are out of touch with the sense of human operation, and I think there are quite a lot of stories that people actually do it without knowing what they are doing. If we think on the premise that it will progress to some extent, especially on the wallet side, I think that the strength of the measures that must be taken will change considerably depending on how the VC exchanged in that case is transferred from issuance. Therefore, when we talk about discussions including these points, I have a strong impression that the discussion of writing layers on what are the issues that must be taken and the discussion of looking at use cases have become chicken and egg. If so, I am quite concerned about what the exit will be. That is all.

Nakamura, Chairman: , thank you very much. Now, Committee Member Kuriyama.

Committee Member Kuriyama: I am Kuriyama of NTT DoCoMo.

In terms of excess or deficiency, this time, I think there is a "proof of attribution" section. The first thing I felt when I read the material was what attribution information you want to prove in the first place. It is also stated in the Holder Binding section, but I think the name, date of birth, and address are probably different. For example, in the case of a certificate of residence, it would be the name, date of birth, address, and relationship of the family member. Also, in the case of an employment certificate with a use case, it would be that you work for a company, and if you search for other employment certificates, there will be a huge amount of information, so it would be necessary to include all of this. I think there is a variety of such information. First of all, we need to identify what information there is and what kind of information there is. If we do not talk about risks, everyone will discuss privacy and the Personal Information Protection Act with their names, dates of birth, and addresses in mind every time, so I think it would be better to clarify what information you want to prove and discuss it.

From that perspective, as Commissioner Sakae Fuji mentioned earlier, I think it may be possible to discuss that name-based aggregation may not be necessary. For example, in the case of age determination, if only the results of age determination are available if age information is desired, I think the risk could be reduced to some extent.

As another scope of the guidelines, I think there are two categories: VC, which is issued by the government, and VC, which is issued by the private sector. With regard to the government's issuance, I think it will be possible to clarify certification to some extent. On the other hand, with regard to private sector's services, I think the concept of certification will change greatly depending on whether the service is for consumers or for enterprises. With regard to consumer services, I think it will be a common idea to strengthen security, but with regard to enterprises, for example, I think it will be more like having work certificates in the company's system and issuing them as VC, and certification and identity verification will appear there, so I think we should formulate guidelines from that perspective.

That's all.

Nakamura, Chairman: .

As for the various opinions we received just now, going back to the issuance process I mentioned earlier, we need to work out a little more. On the other hand, what kind of image do you have for the handling of information after verification? In this Issuer and Verifier model, I think technology is often talked about as if the middle is responsible but the two ends are unaware. However, in the end, when performing various procedures, in terms of how to handle the information obtained through verification, whether it should be digital or not, for example, if you think that it is not a human being who will confirm the contents of a Certificate of Employment after all, to what extent is it necessary to be able to handle it as digital as an attribute? I was listening to you while thinking that I don't know well. At that time, the PDF format that we have so far would be fine. Since the issuing company also handles various attributes, it would be difficult to unify them. I also don't know well to what extent we need to unify them.

We need to discuss the details of the actual procedures, including how the information will be handled and how it will be handled after verification. After that, we need to talk about the risks of name-based aggregation and the need to legally regulate it. It may be the main meeting that will actually discuss this, but I thought while listening to your opinion that we need to grasp the flow of these procedures when talking about technology.
Have I exhausted your opinion?

Committee member Niizaki: Holder Binding. When you break it down into its elements, I think it includes the authentication of the person and confirmation of the person's intention, and I wonder if the results of the normal binding will be used as evidence. I wonder if it will be structured as if the person presented the document with the person's intention.

Also, regarding privacy, when a VC is posted to his / her wallet, I think it is necessary to say that the contents of the VC will be posted, and I wonder if it is acceptable to say that the data that is actually posted will be posted.

Nakamura, Chairman: .

Well, there are probably various use cases. For example, there is a model of sealed proof such as a transcript that is not disclosed to the applicant but handed over to the submitter. I thought we should make a proper use case including that.

Also, with regard to the holder binding, etc., there was an explanation in the document that an agent would be required in the case of a residence certificate. However, there are various cases that can be imagined, such as how the certificate should be obtained on behalf of the person and whether the obtained certificate should be given to the person. If it is necessary to thoroughly verify whether the agent will correctly give the obtained certificate to the person, we need to carefully design the flow of the procedure and confirmation. Since there is a great degree of freedom in this regard, it is not clear to what extent the agent model should be considered. There is also a case that an agent will be required because they have to actually go to the government office to obtain it. If we can communicate online, it would be enough to obtain the certificate via the Internet without having an agent go there. Therefore, we need to carefully consider what kind of situation the agent is required in.

Committee Member Sakimura: For example, when you are in ICU, you can only do it by proxy. You can't operate it by yourself.

Secretariat (Kusunoki): This is in To put it in an easy-to-understand example, I think it is a common story to support people who are not well versed in IT or systems, such as when tax returns are filed by tax accountants, or when a person himself is asked to collect certified documents, or when there is a scope of representation.

Nakamura, Chairman: In such a case, we wonder if this substitution is correct. As you just mentioned, there is a discussion on how to designate a substitute when you are in the ICU. Therefore, the question of what kind of situation allows substitution will also involve a relatively detailed discussion of the system. We need to present a premise on how far we need to assume this when considering the technology.

Mr Kenichi Nakamura: himself, but the most difficult thing is to prove that he was asked correctly.

Dr. Koiwai: , some people are asking whether we should discuss this issue now, since it has not changed on paper.

Secretariat (Sawada): Thank you, This is a supplementary point, but I think that the discussion has naturally shifted to residence certificates, etc. This time, we have excluded acquisition by proxy from the assumed use cases. As you say, such a thing is always assumed when citizens actually use it in the field, but even if they really use it, they will implement VC from the most basic stage, so I would like you to assume that they will acquire it by themselves and use it, not by a proxy.

Nakamura, Chairman: Thank you very much. Now, Committee Member Sakimura, please.

Committee Member Sakimura: , I thought that we would be creating guidelines. In that case, I would like to see the title and scope of the guidelines first. On the other hand, we need a draft table of contents, and we will look at it from a technical point of view to see if the draft table of contents is adequate. We did not do it this fiscal year, but we will leave it as it is and postpone it. In the sense of creating guidelines, I think it is necessary to make it so that readers can see that this part is still there.

Nakamura, Chairman: That's right. So, when we say, "There is a possibility, but we don't think about it at first," we completely forget about it and discuss the details of the technology. Then, when we say, "We should think about it later," we have to tear it all down and think about it from scratch. This is very difficult. So, of course, we have to assume it from the beginning and think about what will happen. That's what I wanted to say.

Committee Member Itakura: In that sense, I think there was a discussion on allowances to supplement technical measures in the current agenda, and there are various issues such as user education, how to deal with the process, and how to deal with the revocation management process, so I think we will probably not go that far, so we will need to make a drastic decision to scope them out and talk only about technology.

Committee Member Sakimura: or Mr. Nakamura, but I think you talked about the issuance process. For example, there is a current issue in the US, and financial institutions cannot judge whether or not the mDL issued by each state is consistent with the Real ID Act or the CIP regulations by looking at the mDL issued by each state, so there is talk about adding metadata. I think that kind of talk is extremely technical, so it is subject to technical working.

Mr Kenichi Nakamura: effect.

Nakamura, Chairman: In that sense, in preparing the overall guidelines, when I think at the level of the draft table of contents, I would like to clearly write the part that says we will think about it in the future and the part that says we will not think about it from the beginning but it will be a challenge. I believe there are many other points on this point in addition to what you have just said, but I would like you to comment on any points that you have noticed later. Do you think you will be able to make any other remarks at this time? It will take 30 minutes, and in the expected course of events, in the remaining 30 minutes, I would like to receive opinions on the case of residence certificates and working certificates and on risk measures. Since the materials have been prepared, I think most of the opinions have already been given, but if you have any points that you have noticed, please let me know.

Ryūya Nakamura: May I ask one question? As a person who is pushing forward with DX of enterprises and traditional industries every day, I have a feeling that there are quite a lot of different characters overall, and I think they ask us to do various things and make various things, but I was a little concerned about the perspective of incentives and motivation.

Incentive has various meanings, and when discussing privacy, it has a meaning of incentive for the attacker or the source of the threat, and it also has a meaning of motivation for the characters who operate the overall protocol, I think. What I have been thinking about this theme for a long time is that VC and other themes around this are very exciting and interesting in the world after it has spread, but to be honest, most of the short-term use cases up to that point are quite plain, and I think it is difficult to create an image of the momentum of the path to that point. When I say here, I am very concerned about how to reduce the cost of checking it when you buy alcohol or having the company verify your salary. When considering security and privacy, it is important to see if people will listen to what you say, and since it is a technical working, it is possible to reduce the burden with technology and products, and it is something I want to do, so overall, I think it is good to include such a perspective. In a sense, I think people do not even check PayPay payments now, so I have been concerned about how to have a verifier in such a global line.

Nakamura, Chairman: .

Dr. Koiwai: , I was wondering about one of the use cases that I am talking about now, which is that what we have to think about will change completely depending on how long we assume the expiration date of the documents to be issued. With the current paper certificates of residence, most people have restrictions such as those issued within the past few months, so most people will go to get them again when they need them, but something like a graduation certificate will be used for the rest of their lives. Then, when we start thinking about long ones, we will come up with various issues such as when a smartphone is lost, what to do with backups, and what to do with the resistance of the key algorithm, so we have to include these issues if we should think about them in reverse. If we should start thinking about something a little easier, I think we can proceed with the discussion on the assumption that the documents will be consumed within a few months after they are issued, but I think there is one point.

Nakamura, Chairman: .

In that sense, it is not necessarily necessary to use the expiration date of certificates that are currently exchanged in paper form as it is, but if it costs money to issue certificates in such a situation, I would like to use them for a long time. Since digitalization will be made, if it costs less to reissue them, they can be issued when needed, and in that case, the expiration date does not need to be that long. In fact, I do not need to think much about how to recover a lost wallet. Therefore, I think we should assume various cases. However, if there is even one with a long expiration date, the wallet may have to be managed well. What should be the design of such a wallet? From what perspective should we design a wallet? Under what conditions should a wallet be used? These should be clearly defined in the guidelines.

Committee member Sako: . I think it is related to Point 2-1. On page 47, there is a proposal by the secretariat in "Concept of the level of measures according to risk." The second line says, "It is difficult to assume the risk of name-based aggregation for VCs that are presented only to specific verifiers, and there is no need for selective disclosure for VCs that are used only for specific purposes. Therefore, it is considered appropriate not to establish" minimum measures that should be implemented "common to all use cases." I think this is a discussion of use cases to determine a low level. In this expression (VC that is presented only to specific verifiers or VC that is used only for specific purposes), it is not clear what kind of use cases are assumed, and I wonder if it is really necessary to use VC in this use case in the first place. If the minimum level of the guideline is to be considered, if there are no specific use cases, I thought that it would be used as an excuse that "it is good because minimum measures are taken" even if measures are actually required. That is all.

Nakamura, Chairman: Thank you very much. If there are any comments from the side that made the material, please let us know.

Secretariat (Sawada): Thank you, , as you said, first of all, we haven't seen what kind of certificates will be VC in the future, and there are still some parts that haven't been decided. However, on the other hand, this is a chicken and egg issue, but when each ministry and government thinks that VC can be used for the digitalization of certificates, we still don't know what the issues are and what the differences are from paper or PDF. Even if we show the rough elements there and eventually decide whether the certificates we manage are high level or low level after that, the situation in the government is that we don't get started unless we have reference information such as rough guidelines and ideas. Therefore, as you pointed out, what kind of cases are high risk is now abstract, but we would appreciate it if you could give us your opinion by thinking about the situation of a fictitious use case to some extent.

Committee member Sako: , what I just said was that I thought it was difficult to think about what to assume as low risk because there were no specific use cases.

If the secretariat is at a low level and does not want to include them by any means, I think it would be better to consider the low level based on the use cases of (I) and (ii) this time.

Secretariat (Sawada): Thank you, .

I think it's complicated because there is no minimum level of privacy here, but the VC's original content is, for example, information that is not very important and is considered to have no problem even if it is leaked, or it is only presented to a specific person and is managed only there. The flip side of what is written as high risk is low risk.

Mr Kenichi Nakamura: : Documents are probably used for certain purposes, and most of them are used for certain purposes. Such documents are less likely to be diverted. However, licenses and passports are used in various ways as ID. Therefore, when they are used for purposes other than the original purpose, we do not know how they will be used, which increases the risk. Therefore, since documents are specifically used in such ways, this document is only used for this purpose, so the risk is low, and since it is used as a derivative in this way, we must consider the risk. I think it is difficult to discuss unless we specifically define what causes the risk.

Nakamura, Chairman: That's right.

Committee Member Itakura: , there has been a lot of discussion about incentives and motivation, but I think the approach is a bit different between how to get people to use VCs and how to shut down services that are already spreading. It would be best if we could discuss both, but I thought there might be an approach of focusing on one or the other and discussing more low-risk areas this time.

Also, regarding the point raised in issue 2-3 about whether it is appropriate in the case of a copy of a residence certificate or an employment certificate, I think it would be difficult to consider the validity of the measures unless we clarify a little more about what will happen when these are used illegally and risk events occur, so I thought it would be better to dig a little deeper.

Nakamura, Chairman: .

That's right. This is related to what I said earlier. For example, on page 24, there is a diagram that shows the image of the guidelines this time, and the minimum measures to be implemented are written uniformly. I think your opinion is that whether it is a uniform decision in the first place. There are cases where it can be lower for each use case. So, where should we aim as an overall guideline? There are various use cases, and there are some that can be evaluated with lower risks. It will be complicated if we make it more flexible, so let's match the minimum line here. If it makes it easier for users to understand, I think that's one approach. However, if you say that if the minimum line is set at a certain level, it will be difficult to use in these situations, and what has been easy to do so far will become difficult, then we have to think about lowering it further. Then, even if you say that you are assuming such guidelines from the beginning, there is a question that it is really so. I think it would be better to include specific use cases and share an image of the direction of one guideline that may be possible as an explanation of this page. What you have been talking about is such a discussion.

Mr Kenichi Nakamura: For example, one of the possible risks is when you receive a residence certificate or a work certificate. Originally, when a digital VC comes in, the digital signature proves authenticity and integrity, so it should be closed there. However, if you cannot guarantee authenticity, it is the same as with analog, and if you call the issuer and say, "Is it right that this person brought this thing?", there is no privacy anymore.

Therefore, the thing that should be avoided most is that. When you receive a Certificate of Employment or certificate of residence, you need something that can prove that it is issued by the correct issuer and that you do not need to inquire about it one by one. In that case, how many municipalities issue certificates of residence, and how can you tell that they are correct? If it is a certificate of employment, the number of companies is far larger than that. In such a situation, how can you trust the signature of the issuer? How to realize this at a low cost, in other words, without imposing an economic burden, is what I think we should consider technically.

Committee Member Sakimura: In a word, when you receive a VC or VP, how do you reconfigure the trust chain from there?

Nakamura, Chairman: That's right. Therefore, I think the main meeting should discuss whether such technologies are really necessary in the world or to what extent they should be considered as technologies. However, I think it is quite difficult to discuss how to integrate them. We have to discuss in detail while assuming various things as technologies.

Committee member Niizaki: I think there are talks that the population will decrease in the future, so it will be unbearable if it is not automated.

Dr. Koiwai: You are right. When the goal is to create something that can be easily processed by the system as a document in order to automate it, I think there will definitely be a discussion about whether it is VC or not. However, I am a bit concerned about whether the government, the secretariat, or the main meeting wants to realize it with this including that.

Nakamura, Chairman: Well, as Mr. Sakamura said, there is talk that what can be done with federation is good enough, and it is a bit of a problem if it is said that VC will be discussed suddenly and decisively.

Secretariat (Kusunoki): This is in The reason why we are focusing on VC is, as you know, there was a study group last year. One reason is that even though My Number information integration has progressed to a certain extent and My Number Card has spread, the amount of paper has not decreased at all. In the first place, when I talk with politicians and others, they say that issuing certificates at convenience stores is convenient, but they always say why they are printing out paper in the first place. There are tax certificates, residence certificates, and many other offices that print out such paper, and there is no prospect of automation in the current situation, including delivery. In considering how to do the parts that cannot be done by back office cooperation, of course there is the option of federation, but back office cooperation will increase N x N infinitely, and we must consider whether it can really be done.

Another reason is that many Derived IDs have appeared in society as if they were becoming VC-like. The reason why Derived IDs are recognized in such a society is that, for example, although some kind of accredited certification authority for Electronic Signatures in Global and National Commerce Act has an aspect of Derived IDs, it has a solid auditing mechanism and it is positioned properly by law. On the other hand, there are many VCs who are not, and they were sorted out at the FinTech verification test Hub with Financial Services Agency last fiscal year. If you think about it, you will understand what you can and cannot do, but it is surprisingly not documented. If you do not sort out what you can and cannot do before the world is greatly confused, you will be in trouble.

The first is how to further digitalization certificates and attached documents, which are obstacles to My Number System, that could not be done by digitalization alone, and how to make it a native AI agent. The second is how to deal with the situation where there are various things that are not well understood in the real world, such as VC, and there are 10 or 20 wallets. I think we need to think carefully about this and issue a message quickly.

Mr Kenichi Nakamura: , that's exactly what I agree with, and I personally don't care about DIW or VC, the most important thing is how to reduce the processing load by having a AI agent do this personal processing, which is basically trusting the document, verifying it, and then processing it. That's why we have trust, we have signed data, and I think we should focus a little bit more on that.

Secretariat (Kusunoki): This is in , so I think a signed PDF would be fine. However, when I tried to do so with the residence certificate, Ministry of Internal Affairs and Communications scolded me, and I printed it out and it looked like a real residence certificate. There were various discussions at the review meeting of the Resident System Division. Since the interim report has been submitted and the residence certificate is widely used by the public and private sectors as a certificate, it would be helpful if you could organize the points such as how to satisfy the risk profile they are worried about. I would like to provide information properly.

Nakamura, Chairman: , I would like to ask him to do so.

Committee Member Sakae Fuji: I don't think it will end, so I've been listening to various suggestions and discussions. I'm not sure how far I can go back, but I remember that last year's VC governance talk started small, with what kind of measures we would take against Derived Credentials, which is still a hot topic.

When it comes to technology, if we talk about guidelines in general and create all the guidelines without dividing them too much, I think we will not be able to finish the next time as we did this time. If we can do this, the resulting document will be a big work that people all over the world will refer to. Therefore, if we do not narrow down the derived credentials to the three perspectives of the issuer, the user, and the presenter, how can we appropriately and technically determine and take action? If we start talking about risks, there will be infinite risks and various use cases will come out, so there is no need to answer it here. However, I thought it would be good if the secretariat members narrow down these points and then talk about where we should comment from a technical point of view next time.

Nakamura, Chairman: Thank you very much. Well, the time for this meeting is almost up, so we only have one meeting left in the next month. I would like to prepare for the next meeting so that we can have as efficient a discussion as possible. There is only a little time left, but if there is anything you really want to say at the end, please let me know.

I wonder if it will be all right. Thank you very much. In that case, I would like to ask the secretariat to explain the rest.

Secretariat (Kitainoue):
Thank you very much for the discussion. Prior to the closing of the meeting, the secretariat will make an administrative contact. First of all, thank you very much for the various opinions you gave us today. We would like to reflect the opinions you gave us in the agenda and discussions for the next meeting. In particular, at the end, we received a strong opinion from Mr. Sakae Fuji, who said that a draft table of contents is necessary to show where the discussions should be focused in this fiscal year as they spread, so I would like to write a draft table of contents in detail and bring it to the next meeting. Based on that, the secretariat thinks that we should record what should be discussed at the center or what should be considered in the future, and we would like to show it clearly in this way, and we would like to ask you to discuss it at the next meeting.

In addition, the minutes of today's meeting will be published on the Digital Agency website after being confirmed by the committee members at a later date. In addition, the next meeting and other details are planned to be held as shown in Document 3, which is currently projected. As you have just pointed out, we have asked for a discussion at the beginning of next month, and I would like to ask for the continued support of the relevant committee members.

On behalf of the Secretariat, Mr. Nakagawa from Director, Group of Common Functions for Digital Society, Digital Agency, would like to close the meeting.

Secretariat (Nakagawa): Mr. , Thank you very much. I had the materials prepared for the closing remarks, but I will speak without looking at them.

I have been a government official for more than 20 years, and this was the first time for me to join a committee that did not include people with use cases for this purpose. For example, in the case of residence certificates, there are cases where the Resident Systems Division comes with a company that wants to issue a VC for residence certificates, and I think it is normal to have you discuss it. I wonder what I should do, but there is no doubt that we cannot move forward unless we produce some output, and I think everyone understood that and discussed it.

Based on what you've told me, if a table of contents is quite difficult, I think a task list that is a little categorized would be very helpful. Based on this, sub-working will be held next fiscal year in a categorized form. For example, if we have to start with the definition of terms, a term definition sub-working will be held. After all, it may be a use case, and since risks can be considered according to the use case, it may be good to have a sub-working group that deals with them in an integrated manner, and furthermore, regarding the user interface, it may be necessary to think about how to make it clear that it has been proven here and there, but it has not been proven here. For example, a certificate of residence is fine if it is a certificate of residence, but if such people come together, what kind of cases are used in the world, and what kind of people are having trouble with it, unless we do it with someone who can speak in the first person, it will be difficult to talk about all the means. I am very sorry for everyone, but in that sense, I feel that there may have been a point that grasped the sky. I would like to reflect on how we should create a place for that.

In that sense, on the other hand, it will take more than a year and a half if we are serious about this, so if we do so, we will start from the next fiscal year, including the budget. I feel that it would be very helpful if you could just output what to do with the composition of the sub-working and the task list over the next year and a year and a half. Earlier, I submitted the secretariat's proposal for the table of contents, but I wondered if there was a possibility of such a proposal, and I asked Professor Nakamura about it.

I would like to take in the discussions while listening to them. In that sense, I asked whether the main meeting was also a technical working session or, I am not sure, whether it was necessary to sort out the technical aspects when talking about it, and whether there was an output from the technical working session. That is what I came up with when I visited you today. Therefore, I would like to work toward a specific output like that. I would like to ask for your continued support. I think it was a little divergent today, but I would like to consider how to summarize it a little bit, including that point.

Thank you for taking time out of your busy schedule today.

Secretariat (Kitainoue): With this, we would like to conclude the first meeting of the Technical Working Group of the Expert Meeting on Sorting out Issues in Attribute Certification. Thank you very much.