This page has been translated using TexTra by NICT. Please note that the translation may not be completely accurate.If you find any mistranslations, we appreciate your feedback on the "Request form for improving the automatic translation ".

The 2nd meeting of the Technical Working Group of the Advisory Council on the Identification of Issues in Attribute Certification

Last Updated:

Overview

  • Date and time: January 8, 2026 (Thursday) from 14:00 to 16:00
  • Location: Online (Microsoft Teams) * The live streaming has ended.
  • Agenda:
    1. Opening
    2. Explanation of the policy based on opinions at the first meeting of the technical working group
    3. Agenda: "Discussion on matters to be considered in subject use cases, etc."
    4. Closing and Communication

Material

Minutes

Secretariat (Kitainoue): We will now begin the "Technical Working Group (2nd) of the Expert Meeting on Sorting out Issues of Attribution Certification". Everyone, thank you very much for taking time out of your busy schedule today. Thank you very much.

As time is limited, I would like to move on to the agenda immediately.

Prior to the discussion, the secretariat will explain the materials.

After the explanation of the materials, I would like to ask Chairman Nakamura to proceed with the discussion. Thank you very much. Then, the secretariat will explain based on Material 1.

Secretariat (Sawada): First of all, I would like to explain the policy of the Conference based on the discussion in the previous meeting.

At the first technical working session, we received many opinions about the conference as a whole, including its scope and goals for this fiscal year.

For example, we received opinions that there are not enough items to consider in the discussion of technical guidelines, and that it is difficult to discuss risk measures. We also received opinions that the use cases for the presented copy of residence certificate and employment certificate are coarse-grained for technical discussion. We also received opinions that the scope of discussion should be more specific and clarified. Based on these opinions, we reviewed the issues and background, and rearranged the goals and how to proceed with the discussion for this fiscal year.

Looking back at the background of the original deliberations of this conference, in the process of aiming for the digitalization of administrative procedures, although progress has been made in reducing the number of documents through information collaboration between administrative agencies and in digitalization, there is still a large amount of paper and simple PDF exchanges of certificates between the government and the private sector. In this regard, suggestions were obtained at meetings up to last year that it would be effective to work on information collaboration through users using VC and DIW to further improve digitization and convenience.

In addition, at the previous meeting, we focused on risk countermeasures, but if we take a step back and look at the overall picture of the obstacles to the use of VC / DIW by the government, first of all, on the technical side, as in the previous meeting, there are issues and constraints on the consideration and implementation of specifications for the use of VC / DIW. On the environmental and infrastructure side, for example, usage environments such as signing keys and wallets and the ecosystem to maintain them are not yet in place. In addition, in terms of laws and regulations, institutions and governance, we believe that the lack of laws and regulations and institutions that can issue and use public certificates in VC format is a major challenge.

Going back to these, we have re-arranged the goals of this fiscal year's discussion and how to proceed with the discussion. First of all, as for the topic use case of the discussion, we will continue to use a copy of residence certificate and employment certificate as the topic. Also, as a goal for this fiscal year, first of all, we will organize the overall picture of the matters to be considered for the implementation of the topic use case as a draft "List of Matters to be Considered". We will discuss this in a separate sheet outside of today's meeting. Also, among them, in order to clarify the matters that need to be dealt with in advance, which are particularly obstacles to consideration, we will pick up and discuss the issues that seem to be particularly important today.

In this way, today's second technical working session will focus on the perspective of technology in particular, and at the second main body meeting scheduled for February, we would like to discuss issues that cannot be addressed by technology alone, including perspectives such as governance. Based on this, at this point, I think we can envision how we will move forward in the next fiscal year and beyond. First, we will discuss specific promotion of individual use cases involving stakeholders, consider the standards for measures to be considered, that is, the guidelines that we focused on last time, and discuss other individual issues related to the handling of VC.

Let's move on to a discussion of specific considerations around the two use cases.

Secretariat (Katsunobu Kato): The first use case is a work certificate, which is an example of a certificate issued by a private company and received by the government. Regarding the premise of the use case here, first of all, for the purpose of the VC, we assume that it will be issued by a private company and presented to the local government when entering a nursery school, etc. We assume that it will also be used for the annual current status notification. As for the method of issuing the VC, we assume that the work certificate VC will be issued either manually by the person in charge at the company to which they belong or in cooperation with the personnel labor system when applying on Mynaportal. For the issuance, we assume two patterns: linking the VC to Mynaportal via APIs and storing the VC in users' smartphones. There are three patterns for presenting the VC. The first is to present the work certificate VC issued from the VC's issuance platform as an attached document for the application on Mynaportal. The second is to present the work certificate VC online when the applicant uses the local government's online application system. The third is for the applicant to present the work certificate VC face-to-face at the city hall counter, etc. Regarding the series of flows from issuance to presentation, it would be appreciated if you could see the figure on the right side of this document.

Next, I would like to explain the issues that are expected in this use case and the solutions to them. I have three questions. The first question is about the interoperability issue due to the difference in the data structure of the VC. Currently, there are differences in the form of the employment certificate in terms of operation. If the data structure is not unified when making it into a VC, it would be ideal to ensure interoperability so that any data structure can be stored in the wallet and can be verified by the Verifier. On the other hand, for example, if a certain local government cannot handle a specific data structure and issues related to interoperability such as not being able to receive the employment certificate VC are actualized, I think it is necessary to sort them out. The points I would like you to discuss are how the decline in interoperability due to the difference in the data structure of the VC will become actualized in the series of processes from issuance to presentation and verification, and when solving it, for example, we are considering formulating a common VC form by the government, but is that really the only solution? Please discuss these points.

The second point is about the challenges for local governments to verify the work certificate VC easily. The local government that receives the work certificate VC must trust the VC. Specifically, it is necessary to confirm the existence of the issuing company and verify the non-tampering of the work certificate VC. While the signature verification attached to the VC is considered valid, it is necessary to consider whether it is sufficient.

The third issue is about verifying signatures when the issuing entities are different. In line with the second issue, if signature verification is recognized as valid, it is necessary to consider how private companies, which are actually the issuing entities of employment certificates, can attach signatures on the platform that issues employment certificates.

As for the points for discussion, as written in the blue frame on the right, I believe that the second and third points are common, and they are the signing method that can be easily and commonly used by each private company, which is the issuing entity of the employment certificate, on the VC issuance platform and what is the method of provision. In addition, in the verification of the employment certificate, as I will give an example later, I would like you to discuss whether the signature method in the document is sufficient to confirm the existence of particularly important companies. In addition, I believe that there are types of signature methods, so I would appreciate it if you could discuss an appropriate method based on supplementary examples.

Based on this perspective, the following sections describe the specific issues and points for discussion. This page shows where and how the concern that some users and verifiers may not be able to use VC due to the inconsistency of VC by employment certificate may materialize.

Next, we summarized the existence of the company required for the verification of the work certificate VC, whether the document method exemplified here is sufficient for the verification of non-falsification, and whether it can be an appropriate method including convenience.

In addition, of course, I believe there are many other issues in realizing the work certificate VC, so I have listed some of them as a reference. Now, I would like everyone to discuss possible issues and solutions based on this work certificate.

I will hand over the further proceedings to Captain Nakamura. Nice to meet you, Captain Nakamura.

President Nakamura: In Thank you for your explanation.

Today, we will discuss the two use cases in order. First of all, you explained the first use case in the handout. I think the handout includes the preconditions assumed to some extent. As we proceed with the discussion, if you have any questions about the handout, I think it would be better to ask them first. Do you all understand the content of the handout?

For example, on page 7, there are two descriptions on how to issue a VC, and the material on the back is also classified in that way, but I don't quite understand the image of the flow of the first part, which says that the VC will be linked to Mynaportal through APIs, etc. Assuming that Mynaportal is basically a site accessed by individuals, I don't quite understand how the relationship between the individuals to be certified and the companies to be certified will relate to Mynaportal in terms of how companies upload work certificates there, so I would appreciate it if you could add that.

Secretariat (Sawada): We have consulted with the ministries and agencies in charge on this point, but no specific specifications have been decided, and it is difficult to present specific assumptions here.

Secretariat (Katsunobu Kato): Let me add that although it is specified as a VC issuance platform, each company that is to issue work certificates can issue VCs using that platform. As I said, the method of data linkage from there to Mynaportal has not been decided yet, but I would like you to imagine that it will be treated as an attached document to the application, and imagine the flow of VC linkage from the VC issuance platform to Mynaportal.

President Nakamura: In In such a case, 1 and 2 are distinguished. The 2 is a flow in which a company as an Issuer issues certificates, which are stored in a wallet and submitted to the government. As for 1, there is no wallet and Mynaportal is used instead. I don't know if it is called a Web Wallet. Should I imagine such an image?

Secretariat (Sawada): That's right. I mean that there are two patterns, one is through the wallet that users enter or log in to this terminal, and the other is through the procedure-related platform. I would like you to think that there are both with and without wallets.

Committee member Niizaki: diagram, Item 2, "VC-issued," is the one that writes to the wallet, and Item 1, "VC-issued," is the one that presents to Mynaportal through APIs. There is a VC-issued platform, and does it guarantee data compatibility or something like that?

Secretariat (Katsunobu Kato): Thank you very much. The guarantee of compatibility that you mentioned at the end is exactly what you meant by (I), for example. I raised it as an issue in (I), but I have prepared the materials with the aim of having discussions on this issue, including whether it is necessary to take certain measures.

Committee member Niizaki: So, for example, someone decides on the data format of the work certificate, and companies issue certificates based on that, or perhaps the platform bundles them all together and is in charge of issuing the VC for the same data work certificate, you assume both?

Secretariat (Katsunobu Kato): Basically, we assume that the company to which the work certificate is issued and the company to which the applicant belongs will issue a VC using the issuing platform, so we do not assume that the issuing platform itself will voluntarily issue any data.

Committee member Niizaki: map, it says things like manual input and various collaborations, so to go to the extreme, for companies that can't handle it that much, the platform will get the data and issue it as a VC in a clean form. Is that your image?

Secretariat (Katsunobu Kato): Since it is also assumed to a certain extent that data will be linked from the labor-related system originally prepared by the company, I think it is also assumed that the necessary data will be received in it, converted into VC, and issued.

Committee member Kenichi Nakamura: , I'm sorry, but when I look at this picture, I don't understand why VC must be issued to Mynaportal once. I think Mynaportal will know information that they don't need to know. So, as Mynaportal, for example, if they use My Number Card to confirm the users, and if they can confirm the users, they can inform the local government about it, and the local government will go to the VC issuing platform to get it, it would be very understandable.

Secretariat (Katsunobu Kato): Although I have not been able to express myself in this document, I believe there are issues related to privacy that you mentioned, so of course there are issues that are not described in this document.

Committee member Kenichi Nakamura: I understand. In other words, although the details will be discussed later, the route will be broadly divided into direct issuance to the person in question and online issuance. What is today's agenda?

Committee Member Sakimura: 's point. In short, is it correct to understand that (I) is not an IHV model, and (ii) and (iii) are IHV models?

Secretariat (Sawada): Yes. With your understanding, the overall framework is fine.

Committee Member Sakimura: I would like to confirm one more point. What is the key that this VC issuance platform uses when issuing VC?

Secretariat (Sawada): That is exactly what we have raised as an issue this time.

Committee Member Sakimura: I got it. I got ahead of myself.

President Nakamura: In The current key means a key as an Issuer.

Committee Member Sakimura: It is the key as an Issuer.

Dr. Sakae Fuji: issues VCs, and there is something in common with wallets, and from there they are presented to local governments. Assuming that certain protocols are standardized, is it correct to understand that we should consider interoperability for the data structures in Issue 1? In other words, when we talk about interoperability, we usually have to think about various things, including protocols and how to type signatures, but in this case, is the scope just whether or not there is interoperability for differences in data structures?

Secretariat (Katsunobu Kato): You are right. If I were to add, it would be a difference in terms of operation, but at present, I believe that there is a current situation in which employment certificates are not necessarily issued in a unified form. When it becomes VC as it is, although it is expressed as a data structure, I think that it should be ideal that any VC can handle the wallet and the local government as a Verifier can verify, but I think there are concerns that this will not necessarily happen.

I believe there are various patterns other than this, such as where and in what form it may not be received, but I have provided some examples. If there is a possibility that these concerns will surface, we need to sort them out. That is the background of the discussion.

Dr. Sakae Fuji: In other words, in this picture, the VC issuance platform is the same, so it is assumed that all the infrastructure for issuance is already in place, but for wallets, there is an X at the bottom because free wallets may come in. As for the presentation part, basically, when it is handed over to the local government, it is assumed that the infrastructure is in place, so it is OK in the protocol layer, but there is a difference in data, so there are cases where there are problems in receiving it.

Secretariat (Katsunobu Kato): Yes.

Committee Member Kuriyama: Thank you, May I ask a question? Regarding the use case of storing VCs in the user's smartphone, is it correct to understand that the user is supposed to access the VC-issuing platform with a smartphone and store the VC in the wallet?

Secretariat (Katsunobu Kato): Yes. That's correct. You're right.

Committee Member Kuriyama: Thank you, I see. In that case, will the authentication method be included in the scope of the discussion, or will it not be included in this meeting?

Secretariat (Katsunobu Kato): Thank you very much. There is no provision for the certification part. It is not included in the scope this time. However, if you think that we cannot consider the issues mentioned this time unless we discuss such matters, please let us know.

Committee Member Kuriyama: Thank you, . I understood. What I didn't understand was what would be used for authentication in the first place. When the affiliated company issues a VC on the VC-issuing platform, what IDs and passwords would the users authenticate with? I thought that if there was no discussion on whether to authenticate with an employee number and company password, or whether to authenticate with My Number Card's Public Personal Authentication, etc., it would be a source of illegal access, so I checked that this part was not listed. identity verification

Committee Member Sakimura: If you can't do that, you can't do holder binding.

Secretariat (Sawada): That certification part is taken up as a point of discussion in the use case of a copy of residence certificate, but in this work certificate, it is missing from the point of discussion this time because various assumptions have not been decided yet.

Secretariat (Kadohara): The purpose of the opinion given by Committee Member Kuriyama was not to certify in My Number Card, but to certify from the perspective of who the company belongs to. I think it would be more appropriate to receive comments on that aspect.

President Nakamura: In In that sense, in addition to the initial certification, when issuing a VC, to whom the VC is issued will probably be a matter of discussion related to certification. However, whether it is My Number Card or something else, there will be various assumptions such as how it is linked to corporate IDs and whether it is linked or not. If we do not clarify these assumptions, I think the entire design behind it will change. Therefore, that point has not been decided yet, and I am aware that we need to discuss various possibilities today while there are various degrees of freedom.

Dr. Sakae Fuji: Hypothetically speaking, if there were such a use case, we would have to decide on it as a given.

President Nakamura: In In that sense, with these two patterns that you presented today, although there may be other patterns, are you not going to touch on them today, or if you do, are you going to proceed with your comments to the extent that we need to consider them?

Committee member Kenichi Nakamura: ): May I have one point? I think it's confusing because it says "issuance" in Japanese, and it's from the company they belong to to the VC issuance platform. This is just Issuance, and where it says VC issuance, it's not Issuance but Provisioning. Since they are completely different, I think it would be better to use Japanese to make that distinction, not to use English, but to use terms that make it clear what they do.

Secretariat (Katsunobu Kato): Thank you. You are absolutely right.

Mr. Kusunoki (Secretariat): At the closing meeting in This is an important point, but there is no good Japanese where everyone uses katakana. You are talking about Issuing and Provisioning, which is extremely important, and I think it is a great output in itself if this part can be written in Kanji. This is an important point.

Committee member Kenichi Nakamura: certification and issuance is dubious.

Mr. Kusunoki (Secretariat): At the closing meeting in It's suspicious. Certification and authorization are also suspicious, and there are many things like that in this world.

Dr. Koiwai: I would like to return to the topic of . I would appreciate it if you could correct it if the direction is different. However, I do not have a specific image of a VC issuance platform. For example, is it assumed that some country or some public organization recognized by the country will launch one as a reliable third party, or is it assumed that there will be multiple private companies?

Secretariat (Katsunobu Kato): I am sorry for not being able to add the premise. It is the idea that the government prepares as you mentioned in the first sentence.

Dr. Koiwai: I would like to return to the topic of When I thought that way, I felt that I would go back to the point of asking if VC is really necessary when I realize it. After all, the issue this time is on the premise that since it is difficult to exchange information between the government and the private sector, we will do it through users, but if the government prepares one VC-issuing platform, and companies and local governments cooperate with it, as proposed here, I thought that it would actually be possible to have the platform directly cooperate with local governments with that data.

Secretariat (Katsunobu Kato): I think this is a very important opinion. First of all, as a VC, I believe that being verifiable will be an advantage. Also, as stated in the issues of (ii) and (iii) in the material, when employment certificates are handed over to local governments for admission to nursery schools, etc., there is a need to confirm the existence of companies and verify the non-falsification of the certificates themselves. In such cases, VCs will be able to utilize media with technologies that can meet such needs. We believe these two points are major.

Mr. Kusunoki (Secretariat): At the closing meeting in The bigger point is that if there is only a trusted channel between national entities, then you don't need a VC. You need to make it Verifiable to avoid the risk of rewriting it to favor childcare centers because there are people in between or unreliable channels. In this sense, if you link the APIs directly from the VC publishing platform to Mynaportal, you just need to link the APIs from the beginning, and you don't need a VC.

Committee member Kenichi Nakamura: Let's go one step further. In short, a trust point is a VC issuance platform. What is necessary for a trust point to be "Verifiable" is whether or not the issuing company can be trusted when it becomes an issuing company. Therefore, I think the matter will change drastically depending on which trust point is placed.

Mr. Kusunoki (Secretariat): At the closing meeting in When we talk about this, we probably have to clearly talk about what the main threat is, and the most common one is the risk that the person himself fills in an excel file and submits it by himself, not by the general affairs department of the company. So, this VC-issued platform is authenticated through gBizID or something, and the person who has the right representation as a company issues the work certificate, and we want to verify this. I think that was the talk about whether VC could be used there, but on the other hand, if the VC-issued platform and Mynaportal are tightly coupled and the data is passed through directly through APIs, we have been pointed out that VC is not necessary in the first place.

President Nakamura: In committee

Committee Member Sakimura: , there are two points. When I was reading it briefly, I thought that there were multiple platforms, but if there is only one, it would be an extremely centralized system. I think it is completely opposite to the idea of IHV. Even if that happens, I wonder about it. Large companies would like to issue their own VCs, so I wonder about it. At the same time, if we do it in such a tightly coupled manner, it is better to consider other risks. In an extreme case, if the platform issues it, especially if it issues it directly, it should not be signed. If it is signed, there is a risk of diversion. If it is unsigned, only the person who directly receives it can trust it. The point is that Mynaportal knows for sure that he / she received it from the VC issuer, so he / she knows that it was issued by that company. Then, for example, considering the risk that the data will be reused in some way, the risk of reusing it is lower if it is unsigned. I think that such a story can be made because the person who is presented will not believe it because it is not signed and cannot be trusted.

In German and other countries, the reason why they did not issue signed data in eIDAS 1.0 was quite in the background, and it seems that they did not attach a signature considering the possibility that the recipient would reuse it without permission. Now, in eIDAS 2.0, we are very particular about holder binding in order to reduce the reuse risk. If a VC is issued directly from the platform like (1) to Mynaportal in this API-linkage, holder binding is naturally not possible, and the reuse risk that the Germans were worried about will become actualized, so I think it is necessary to think about it.

Mr. Kusunoki (Secretariat): At the closing meeting in In fact, the exact same argument was made in Mynaportal, and there was a background that I did not put my signature in the PDF or CSV of the self-information API at first, but in reality, some online application may upload what they downloaded later, so it is difficult to convey awareness. I think this is an important point.

Committee Member Sakimura: If the Relying Party understands that it is downloaded and uploaded there and takes that risk, I think it is good because it is the responsibility of the Relying Party. I don't think we should worry about that. But I think we should make that distinction.

Dr. Sakae Fuji: Regarding the earlier discussion on (I) and (ii), since (I) made it difficult to understand, I think (I) should probably be deleted. In short, if you are talking about Wallet or VC, it is better to focus on (ii) so that the discussion will not be dispersed. This is the first point.

The other question is whether there is one VC issuance platform now. This is related to this. You mentioned the difference in data structures in Issue 1. I felt that if there is one platform, there will be no difference, and I also thought that there were multiple. If this is a common platform provided by the government, point 1 of the discussion, "I think it is necessary to establish a common VC format for the government, what do you think?" is written. I think the answer is "I think so." Is that correct?

Secretariat (Katsunobu Kato): Thank you very much. I am also sorry for the lack of supplementary information. The form of the VC or the form of the employment certificate can be formulated by the local government, and the specifications are active on the platform or can be applied.

Dr. Sakae Fuji: , it's one of the VC platforms, but I want to put it in the Tokyo Metropolitan Government, so it's a platform where I have to choose the style of the Tokyo Metropolitan Government.

Secretariat (Katsunobu Kato): You are right. The form will be formulated by the local government.

Committee member Niizaki: If you do that, you can make 2,000 in the worst case.

Mr. Kusunoki (Secretariat): At the closing meeting in This seems to be quite difficult in practice, and in the end, there are about three patterns. The point is that if it is a place where you can enter a nursery school freely, you can use a standard form. If it is a place that is not easy to enter and the population is not very large, you can make a phone call and listen one by one. The competition is very high, for example, if you can't even make a phone call, it seems that there are circumstances that it is difficult to do clerical work unless you write in as much detail as possible. I also think that it should be standardized, but in order to do so, I think you should think about changing from work.

Dr. Sakae Fuji: If that is the case, doesn't it need to be discussed here?

Mr. Kusunoki (Secretariat): At the closing meeting in Since this is a matter of business, I would like to receive various opinions on how to do it as a VC, and whether there should be one publishing platform or not. In fact, since IDs must be distributed to the General Affairs Department of a company, I wonder whether everyone will use gBizID or whether it will spread in this way at the business site level of a large company, including tens of thousands of employees.

Dr. Sakae Fuji: In that sense, if it is a discussion about whether the government should prepare one VC platform or should accept multiple ones, I think it would be meaningful to discuss it here.

Mr. Kusunoki (Secretariat): At the closing meeting in I would very much like to see such issues discussed.

President Nakamura: In , a number of points have already been confirmed. First of all, regarding the first question, which was asked by Mr. Sakimura, whether it would be possible to enter Mynaportal directly from the platform, if I was asked whether it would be an IHV model, I would answer yes. Do you think this is a matter for discussion here?

Secretariat (Sawada): Did you just point out that if it does not fall under the IHV model, it would be out of the scope of the discussion?

President Nakamura: In It is my understanding that this discussion is premised on the premise that the IHV model is the reason why PDFs are not considered. I would like to confirm whether this premise is true at the outset.

Secretariat (Sawada): In that sense, I would like to discuss the case of using VC-DIW, as you said, and I think it is possible to point out that VC is not necessary in the first place if it is API-linked, and that it is different from the IHV model. If so, I think it would be good to receive your opinion in the form of (ii) only when it is through Wallet. The reason is that the use case presented this time is based on the business situation of the people concerned, and it is a possibility that can be possible now, so I think it is not necessary to pick it all up here. This API linkage has caused confusion, so I would like you to focus on (ii) of the use case, which is through Wallet, and make remarks.

President Nakamura: In Thank you very much. Based on that premise, I feel that most of today's time will be spent on it. Therefore, I think we should focus on discussing what requirements are necessary for the wallet based on the IHV model. In such a case, what to do with Binding, which has been talked about earlier, will probably be involved in the design, and how to standardize the contents of the VC. In terms of items, I feel that it would be good if we can unify names to some extent and provide freedom in other areas. However, in addition to that, what we assume to be included here, such as subject ID, will probably be a discussion related to the essence of the IHV model. There are specifications such as eIDAS that define the policy to a certain extent, but I think we are talking about whether it is not related to that or whether we are referring to it or whether we are talking about how to proceed with the discussion and consideration. In that case, I think we need to share our views as the Government of Japan or the Digital Agency on what to think about the issue of name-based aggregation or the leakage of personal data as the initial design. Risks are mentioned in various places, but the risk assumption will change depending on the design of the premise. So, we would like to expand the discussion by giving examples of some of these patterns. If there is a direction from Digital Agency, should we narrow it down to those patterns and discuss here? If there are any assumptions, how should we proceed with the discussion? That is what I would like to ask you.

Secretariat (Sawada): At the moment, I don't fully understand which part I need to check.

President Nakamura: In For example, a VC is issued. The name and other human-readable items are included there. In addition, for example, as discussed earlier, for whom is this VC issued? That is, although some information for binding as a machine is required, I think that there are probably three or four types of information to be entered as binding information. There are various variations, such as entering a globally unique PID, entering a PPID, and entering a certificate. Of course, there is a choice of whether to include an identifier in the VC or not. If so, we must design a system that presents a VC while linking with personal authentication. I think the initial design of what to enter as a VC ID will affect the entire system. The most important point is what the assumption is.

Secretariat (Katsunobu Kato): Thank you very much. I think I briefly touched on this earlier, but of course, the issues you just mentioned are that we must promote the use of VC for work certificates and copies of residence certificates, although they are only given as examples and models this time, and we are in the position of having to consider and advance specific system specifications, so if there is a need for the discussion you mentioned in the consideration, I would like you to include the background. On the other hand, in the case of work certificates that I raised this time, there are issues from (I) to (iii), but in advancing such consideration, if our particular concerns do not materialize, I think that will be the end of it, and if there is a concern that could materialize and a certain allowance is necessary for it, I think it is the background or setting purpose of this meeting. I think what I would like you to discuss in particular falls under the issues from (I) to (iii). Based on that consideration, or as you also mentioned, for example, more detailed discussions are necessary, and I believe you have just heard about the content of VC data, but if there is a need to consider the subject of the credential, I would like you to make a statement and discuss it based on that.

President Nakamura: In Thank you very much. We have about 10 minutes left to discuss the first use case. There are two points that I would like to confirm a little more. It is unclear what kind of interaction is assumed here in the assumption of (3) on page 7, which is the presentation in a face-to-face meeting. I believe that the discussion will change depending on whether it is a face-to-face meeting in which the screen is shown for confirmation, or a face-to-face meeting in which data is exchanged via NFC or the like and the data is accurately delivered digitally like mdoc. What are your thoughts on this?

Secretariat (Sawada): The specific details have not been decided yet, and I'm afraid that we have limited time, so I think it would be easier to discuss the main points of the agenda if we had that. To be honest, our use cases this time are all tentative, so if they were set like this, I would like to hear your opinion from the perspective of what technical issues and concerns there are for each point. Rather than delving into the use cases in detail, I would like to hear your opinion as far as I can imagine.

Mr. Kusunoki (Secretariat): At the closing meeting in What to do with the current subject IDs is actually a very important topic, and in this flow, after all, in the Issuing part, the company, not the person, pulls the trigger for Issuing, so in order to ensure that the employment certificate issued by the company reaches the person, some kind of mechanism is necessary, that's what Mr. Nakamura pointed out. This is what we have to answer properly, and it's not in the current format. In basic four information, we basically collate names based on four information, the place of residence registration, date of birth, name, and gender. This is also very fragile, but if everyone does identity verification in My Number Card properly, they will not miss the work.

No, no, subject IDs are still necessary, and if you are discussing whether My Number is good because it is in the social security field, it is necessary to consider reviewing the Number Act, and I think it can be pointed out that it should be something different in terms of privacy impact. In this use case, I think there are various ways to set subject IDs, such as what is appropriate as a subject ID, or even if no subject ID is set, a company can send an e-mail to the person at the time when the company issues an e-mail address and have the person step on the link, or name identification by e-mail address. Your opinion on that, or something like this should not be used as a subject ID, for example, I feel that certificate serial numbers are dangerous, and My Number is also exciting. Do you have any opinion on that?

Committee Member Sakimura: clarification question. In this case, is the recipient limited to the municipality?

Secretariat (Sawada): Yes, I think so.

Committee Member Sakimura: , I think it would be better if it was written as a premise, but what kind of workflow is assumed for the local government to confirm that the subject of the VC is the current applicant when presented with this? As Kusunoki Director-General just said, in the case of comparing the four pieces of information, it will be necessary to confirm in some way that the applicant's body matches the four pieces of information, and then the workflow will be to submit it together with My Number Card. In that case, if the certificate serial is included as the core schema in the data, it will be compared with it, and if it is compared with the four pieces of information, I think it will be a matter of having the four pieces of information in the core scheme.

Secretariat (Sawada): On the contrary, if you have any suggestions as to which is more desirable.

Committee member Kenichi Nakamura: First of all, we need to know the details of the operation. For example, the way of doing things will change completely depending on whether or not we allow proxies.

President Nakamura: In We are supposed to discuss two use cases today, but for each use case, whether we are giving some direction on the design of IHV VC, or whether we are discussing to aim for one platform that has various procedures based on these two topics, I would like to share our awareness.

Secretariat (Sawada): , I would rather say the latter, and although I have mentioned these two use cases, a Certificate of Employment and a copy of a residence certificate, they are the subject of discussion, and I do not know whether they will necessarily be set as currently tentatively indicated in the future, and they have not been decided yet. I have mentioned other documents, for example, this employment certificate, as examples of documents issued by private companies and received by the government during procedures, and I would like to discuss how they should be in the future and what issues are expected, which will be of reference for other types of certificates.

Aiming for one platform that Professor Nakamura mentioned earlier means that there is one procedure platform in this example, but this is not necessarily the case with other certificates, and that is only in the process of the procedure in this case.

President Nakamura: In In that sense, I think there are various ways of thinking about what a platform is. For example, if there is an IHV system based on the standards specified in eIDAS 2.0, and if you use it, various VCs can operate on it. Is it a discussion to aim for a Japanese version of the same thing? No, no, that is not the case. Instead, several standards are considered separately. It may not be one platform, and a platform may be created for each of various procedures. I think there are various ways of thinking about that.

Committee member Kenichi Nakamura: This platform only looks like a broker in terms of its role. So, if you are a broker, you can define what kind of governance model you should be as a broker, so I think it would be easier to create a model if you say so. Platforms are very vague in that sense, so I think it would be easier to define what role they play as a role model.

Committee Member Sakimura: I think it is true that the platform is a broker here, but in short, it is a person who receives some form of certificate issued by a company and issues a derivative certificate that can be consumed by a local government.

Committee member Kenichi Nakamura: That's right.

Dr. Koiwai: I would like to return to the topic of , I think you are presenting this as an example of a use case in terms of how to use the IHV model. In that sense, if we think only about employment certificates, of course it will be submitted to local governments, but when we think about similar use cases such as companies issuing very similar documents such as certificates of enrollment and having to use them when looking for a new job, the recipients will not be limited to local governments. When we think about what to do with the ID and subject identifier mentioned earlier, there may be a discussion that My Number may not be able to be used, and there will be a lot of talk about maiden names and aliases. With this in mind, I think there will also be a discussion that if companies do not make it widely available, they will not be motivated to do it.

Also, as you are discussing now, I think it was difficult to understand about the platform. However, there was a little discussion in the chat. Depending on the size of the company or the business category of the company, how these documents are issued will change completely, so I think it may be okay to have only one platform. There may be companies that think it would be easier for them to have their own private keys and issue them themselves. If they are small companies, they may want to leave it to someone else, including that. Considering that there are several such cases, I feel that it would be better to use the IHV model, and at that time, I thought that the issues of (I), (ii), and (iii) would become apparent. This is my vague opinion, but that is all.

President Nakamura: In , Itakura-san.

Committee Member Itakura: , I would like to add something to what you just said, but I also believe that everyone probably thinks that it is not only local governments that receive it, and I also believe that it is not only within Japan. For example, when obtaining a visa for another country, there will be cases such as presenting it to another country or presenting it to an embassy, so perhaps interoperability is about what interoperability is for. So, while keeping this use case as a theme, perhaps we need to look at the overall picture of the potential spread in the future and discuss it.

As for the platform, I also think that a single platform is not realistic, and I think that there are cases in which the company to which it belongs issues it, usually for large companies. Also, I think that the platform will change depending on whether it is a new platform, an existing information sharing platform, or something like an employment certificate preparation website, so I think it will be good if we can discuss such points as points that have not been decided.

President Nakamura: In .

Committee member Kenichi Nakamura: ): You mentioned the example of eIDAS, but I think the term platform should be used in the sense that it is a toolbox approach, and in this use case, this toolbox and this toolbox will be used to solve security and privacy issues in this field, and in this application, this and this should be used.

Committee member Niizaki: If the data format or something like that is included within a certain range or included in the standard, I do not know what the name will be, but I think that such a mechanism is necessary. If it is okay for local governments to decide, I think that some kind of control framework is necessary. As for the use, as you said, if I look into it now, there are cases where a certificate of employment is required even when renting, or it is submitted to the private sector for various other uses, and there are cases. Then, there will be cases where it is submitted to the private sector online or face-to-face using Wallet.

Also, when it comes to automation, if the original idea was to automate something with a lot of variations and use VC for automation, I think we need to control VC in some way. I think we need some kind of mechanism for formatting, data, protocols, and so on.

Secretariat (Katsunobu Kato): As you said, I think there are still many things we need to think about. The government should establish something common and certain for the issuance of VC, and I think this is one of them. As you said, for example, we must definitely consider assuming overseas use in the future, but I think it is quite difficult to suddenly prepare everything that will be used in various use cases. In this case, the scope is narrowed down to whether VC can be used in use cases that are verified by local governments in the procedure of nursery school admission.

As Commissioner Koiwai mentioned, including issues such as incentives, there are various possible use cases, so I think we need to make sure to decide where to start.

Committee member Kenichi Nakamura: On the other hand, if we don't narrow it down, the discussion will diverge, so if we are going to conduct a trial, for example, I think it would be good to decide on this use, and first check whether it will work well or not.

Committee member Sako: , I have an opinion from a new point of view.

In the first place, returning to the issue of what an employment certificate should prove, it may be a story of the distant future, but originally, all the information that shows the relationship between the company to which he / she belongs and the employees, for example, a work contract, is held by the person who becomes a VC, and by showing such information as when the person signed the contract to the local government, it will become a Certificate of Employment. Even if the contents required as an employment certificate by the local government are different, I thought it would be ideal if it could be adjusted by the VP's selective disclosure. That's all.

Committee Member Sakimura: On the contrary, if you think about it, the state will have the platform and control it centrally, which is extremely disgusting.

Mr. Kusunoki (Secretariat): At the closing meeting in The reality is that if you want to reduce the burden, you have to put your mouth in the place where you have the data, so even if the government provides such a thing, I wonder if the people who will work with you will be those who have a lot of people and input data, or those who are sensitive to capital investments at small and medium-sized companies. As a result, I think there is probably an argument that VC is beneficial if it ensures interoperability across multiple platforms.

On the other hand, as Mr. Niizaki pointed out, we are quite concerned that some kind of system will be required if we try to create a mold. In other words, there will be discussions that we should create a platform because it is difficult to issue VC. It is probably more difficult to change the schema of VC than to change the Excel form a little. I think there will be discussions that we need such a platform after thinking hard because there are many people who think it is difficult. This is the history of schema-full documents. I wonder if it would be good if we could issue VC as easily as Excel. I wonder in which direction it will go.

Committee member Kenichi Nakamura: ): This may be my personal opinion, but in the past, information was issued in bulk, such as by physically issuing a printout or putting it in a chip, and this resulted in the issuance of unnecessary data. Therefore, the system of selective disclosure was adopted. However, if it became possible to issue what was needed in real time from a database, then, frankly speaking, there would be no need for selective disclosure. Rather, from a mid - to long-term perspective, I think it would be necessary to have a proper database, or rather, a proper database of data, and to be able to issue what was needed in real time. In that case, rather than converting data at some point, I think we would be moving in the direction of having data at the source so that we could be asked anything at all.

President Nakamura: In It's almost time, but there is one more thing I wanted to confirm. On page 10, the signing key of the signing agent appears below. Here, I would like to confirm whether it is an image that the signing agent has only one signing key, or whether it is within the scope of the assumption that each company issuing the Certificate of Employment has a different key so that the Issuer can be properly verified. Do you have an image of that?

Committee member Kenichi Nakamura: In the case of eIDAS's remote signature, the remote HSM has multiple keys for this person and this person.

President Nakamura: In In that sense, I think we should change the locks properly, but the way it is written here makes it seem like we don't think much about it, so I was a little worried about that.

Secretariat (Sawada): company can understand?

President Nakamura: In If the issuer's signature is to be given a certain level of responsibility, I think it is necessary to make a clear distinction.

Committee member Kenichi Nakamura: In short, the key is equivalent to a company seal in terms of hanko.

Committee Member Sakimura: That's what I just heard. Whose key is it?

Dr. Koiwai: I would like to return to the topic of As long as it is the company seal, the concept doesn't change whether it is stamped by the president of the company, the general manager of the general affairs department, or the person of the BPO company acting on behalf of the company.

Committee member Kenichi Nakamura: That's right. Usually, you are supposed to sign when you are told to sign to a person who has the authority to sign.

Dr. Koiwai: I would like to return to the topic of So, on that premise, there is no need to think about a concept like a signature key for an agent company.

Committee member Kenichi Nakamura: However, when you say an agency, you don't know the company. Even if the agency has the platform, it doesn't matter as long as they know that this key belongs to this company.

Mr. Kusunoki (Secretariat): At the closing meeting in I would like to ask a question. For example, currently, various companies' HR and general affairs systems are in SaaS. There is only one TLS key in that system, right? I would like to ask if the attributes contained in the keys and certificates are important. On the other hand, if at least the existence of an agent has been confirmed, whether it is signed by a legitimate authority or not can be determined by asking the agent. Even so, whether it must be signed with a different key for each company, I think it is better to listen to your opinions carefully.

For example, in regard to the copy of the certificate of residence that I will talk about later, in My Number Card, although currently it is issued by municipalities, issuance is concentrated on the J-LIS, and since last year, passports have also been issued centrally by the national government. Therefore, I think it is possible to discuss whether it is necessary for keys to differ depending on the company if it is possible to respond to threats.

President Nakamura: In I think it will be a matter of what needs to be verified by the verifier to recognize that the signature is correct, and who will ensure governance when a common key is used. I think we will have to do our best with the system, regardless of the technology, so it is not good to assume that only one key is needed at this stage.

Committee member Kenichi Nakamura: There are models where there is a single key, because what you're signing with that key is reliable.

Committee Member Sakimura: I think the point is how to prove the relationship that the key guarantees non-falsification and the agent is duly entrusted by the original issuer, but there are some systems that do not know that.

President Nakamura: In So, in terms of whether or not to ensure transparency, if it is possible to find out by looking at the log and investigating something about the company, that may be fine, but it is necessary to make it possible with a system.

Committee member Kenichi Nakamura: If the subject of a key is a public key certificate, then trust the subject.

Committee member Niizaki: , but you need to prove the existence of both your proxy and your employer.

Committee Member Sakimura: Of course, you need to prove your existence, and you also need to prove that you have properly entrusted the agency business. That's how you have to create a trust chain.

President Nakamura: In That's why I feel that this discussion will come up again in the future.

Secretariat (Sawada): The latter half of the document deals with signatures.

President Nakamura: In , the second half, please.

Secretariat (Katsunobu Kato): , I would like to move on to a copy of your residence certificate.

Next is an example of a use case issued by the government and received by the private sector. A copy of the certificate of residence Regarding the VC, I would like to talk about the premise of the use case here as well. First of all, regarding the use, it is defined as the use for which the person presents a copy of the certificate of residence issued by the local government to the private sector to prove his or her household information. The method of issuing the VC is only online, and the requester for the issuance is only the person himself or herself. In addition, the items to be stated are those of the whole household, and as with the paper certificate of residence, it will be possible to select whether or not to state the personal number at the time of issuance. At the bottom, regarding the method of presenting the VC, it will be possible to present it online or in person. Selective disclosure is also possible, and it will be possible to reuse the same VC by presenting it to multiple Verifiers.

Next, I will explain the issues and solutions that can be expected in this use case as the matters that I would like you to discuss. There are 4 points.

The first point is about the challenge of signatures for detecting forgery and tampering. Although the issuing entity of certificates of residence is the mayor of municipality of each local government, it is necessary to consider appropriate methods for attaching digital signatures to VC. I think that multiple Architecture can be assumed as points for discussion, but I would like to ask you to discuss what method is suitable for realizing VC of a copy of certificate of residence and what important viewpoint is the reason for deciding the signing method.

The second point is the issue of spoofing detection methods. This is written as a supplement at the bottom, but it is also mentioned in the interim report of the "Working Group on Efficient and Effective Basic Resident Register Administration Using Digital Technology". In order to confirm that the person presenting the VC is the person subject to the VC and is not a spoofing, it is necessary to consider appropriate methods from the perspective of effectiveness and cost, including binding with biometric data, for example. Here, in particular, in order to confirm whether the person operating the wallet at the time of presenting the VC is the same person at the time of issuing the VC, we would like you to discuss what is appropriate, including identity verification of the wallet.

Next, the third question is about the issue of the usage environments in the form of wallets. In the case of wallets such as native apps, for example, there are issues such as that users without smartphones cannot use them, that they depend on the specifications of hardware and operating systems, and that platform operators need to respond individually. Copy of residence certificate In order to promote the spread of VC, I would like to ask about the ideal form of wallets that can be used regardless of device environments. For example, while Web Wallet is an option, I recognize that there are concerns and considerations such as offline use and wallet binding methods, and I would like you to discuss these serious concerns when implementing Web Wallet and solutions to them.

Lastly, the fourth point is the challenge to provide safe and convenient wallets. Currently, there is no mechanism to evaluate the robustness or interoperability of wallets, and each wallet provider is developing its own wallet, so I believe there will be discussions on whether quantitative safety evaluation and interoperability are sufficient. In response to this, in order to ensure the safety and interoperability necessary to promote the use of the resident card VC, for example, a conformance test may be necessary. However, in order to prevent the increase in response costs, I believe the requirements should be minimized, and I would like to see discussions on the validity and the existence of alternative measures.

In the following, specific challenges and discussion points are presented for each challenge. As for the challenges of signatures for detecting forgery and falsification, as currently shown, specific images of possible Architecture are presented. Please discuss what is appropriate for the exemplified Architecture and from what perspective Architecture should be decided.

Next, regarding the challenge of the spoofing detection method, I would like to ask you to discuss the validity of the method illustrated here, especially from the perspective of ensuring the identity of the presented VC.

The third point is about the challenges of the usage environment with the wallet format. As I explained earlier, the challenges, concerns, and points to be clarified are described for both the native app type and the Web Wallet, so I would like you to discuss each point.

Finally, regarding the issue of providing secure and convenient wallets, while we believe that conformance testing is useful for evaluating and ensuring the robustness and interoperability of wallets, we also believe that there are concerns, so we would like to hear your opinions.

Then, I would like you to discuss the expected issues and solutions based on this residence certificate. I will hand over the proceedings to Chairman Nakamura again, Chairman Nakamura, thank you.

President Nakamura: In Thank you very much. In that case, regarding the second use case in the latter half, first of all, if you have any questions regarding this content, please let me know.

Kuriyama-san, please.

Committee Member Kuriyama: Thank you, First of all, on page 14, in the section "Ensuring the authenticity of the certificate", I do not understand very well whether this certificate of residence copy VC must have the same legal validity as paper, so could you please tell me the purpose of the description specifically?

Secretariat (Sawada): Thank you very much. When a certificate of residence is used as a VC, to what extent is it required to be equivalent to a paper certificate? This is not something to be clarified here. However, it is written as follows based on the general theory that when some kind of certificate issued by the government is converted into a VC certificate and issued as a VC certificate instead of a paper certificate, it will be a problem if it cannot be used in the same manner as a paper certificate.

Mr. Kusunoki (Secretariat): At the closing meeting in I would like to add that, originally, there was a request from cities, wards, towns and villages to allow electronic issuance of copies of residence certificates, and in response to that, a study group in Ministry of Internal Affairs and Communications has been considering it. Among them, there was a discussion that a signed PDF would be good, but it was rejected. I think it was around spring this year. The reason why it was rejected was that already computerized taxation certificates are not used in such a variety of situations, and a copy of residence certificate is used in various situations to confirm identity, and although it is not an identification card in itself, it is a type of identification document that is fairly important, so it should not be easy to show what you have received to other people. We have received fairly specific requirements this time, and we are giving examples of whether the current Verifiable Credential can satisfy these requirements. We have received a considerable number of opinions, including that it should be better to have selective disclosures, and this is the background of the interim report, which says that Digital Agency will consider it from now on.

Committee Member Kuriyama: Thank you, . I have an additional question. I have just read through the Ministry of Internal Affairs and Communications's one, and I was wondering if we should use My Number Card's Public Personal Authentication for identity verification, and I wondered if there was a discussion about whether it would be the same for this VC with a copy of the residence certificate. I thought it would be treated from the perspective of certifying household information, so I made a comment on whether it would be better to clearly state that the way of writing here and the use case of VC with a copy of the residence certificate are different. That's all.

Mr. Kusunoki (Secretariat): At the closing meeting in issue, including common law, a copy of the residence certificate alone is not recognized as an identification card, and a copy of the residence certificate should not be widely called a identity verification document. Whatever identification is used as an identity proof is not legally required, but it is used as a social custom or act of fact, so I basically understand that it is a discussion in Ministry of Internal Affairs and Communications that the risk of it being transferred should be dealt with. I think that it is not a discussion here on the premise that a copy of the residence certificate alone is an identification card.

President Nakamura: In Then, based on the discussion, when we digitize the residence certificate, we should make it clear that it is not used for personal identification or identity verification, and we should write something specific about it so that everyone can use it. Therefore, we should clearly separate the identity verification, the function to confirm the identity of the person, and the purpose of proving the attribution information of the stated content. Here, the content of the residence certificate is simply the purpose of proving the attribution information. Whether the person presents it or not may be confirmed by a combination of other means, and is it okay to write it as a clear result of the consideration?

Secretariat (Sawada): As an assumption of the use case of this discussion, I would like to receive opinions on how to use a copy of the certificate of residence to show household information and attribute information.

Dr. Koiwai: I would like to return to the topic of , this is a follow-up to what you just said, but on the other hand, this time, when a VC was newly created with the same validity as a copy of a residence certificate, it was made possible only for the person himself to present it. Because of this, now, in effect, the residence certificate is used as a method of identification, and I am very concerned that it may further encourage this, and I thought that I should be very careful about this.

President Nakamura: In Thank you very much. In that sense, I think it is the design of how to get it out of the wallet. I think it would be good if two means were provided, one is to give it without information about the identity of the person in question, in the sense of simply showing the content to various people and submitting it, and the other is to give it in a form that can prove that the person in question has submitted it. I think it would be good if these two means could be used in a way that is easy for the user to understand, but I think it would be difficult.

Anything else, Mr. Sakae Fuji?

Dr. Sakae Fuji: In the proviso, the appropriateness of the use case is outside the scope of discussion, so I would like to focus on the technical part and confirm once again what the secretariat wants to confirm after all. Listening to the discussion, it seems that most of the discussion is about the use case and appropriateness, so you are raising the points of discussion. Could you tell me once again what you want to confirm specifically, technically?

Does ① mean that you want to ask what kind of signature algorithm is good?

Secretariat (Katsunobu Kato): Yes. We believe that it is necessary to evaluate the appropriateness of the Architecture shown as an example, so we would like to receive opinions on the contents of this example.

Dr. Sakae Fuji: Second, I would like to know how to check the binding of the credentials and Holder in various situations, and how to do it all at once.

Secretariat (Katsunobu Kato): document, there is a description in the form of "Examples of Spoofing that May Occur." This is an example of the type of spoofing of residence certificates that we are concerned about. As for what kind of measures can be considered in response to this, there is a first thought that a general wallet binding may not be sufficient, and there is a need for additional measures. Here, we have listed two additional measures in the form of binding using information used for identity authentication. The two points are that the wallet must authenticate the operator at the time of issuance, and that the wallet must be able to authenticate the operator and the person at the time of presentation, and that it must be confirmed whether it is consistent with the time of issuance. Therefore, I have also written an appropriate method here. I would like to receive your opinion.

Dr. Sakae Fuji: In that sense, the use cases are given as examples, but even if I hear the two points now, what I want to confirm is the technology.

Secretariat (Katsunobu Kato): That's right.

Dr. Sakae Fuji: I understand. With that taste, if I have anything to confirm or ask after this, I would like to submit it.

President Nakamura: In If we continue as we are, (2), what kind of impersonation is assumed, is a little vague. There are cases of impersonation in the sense of whether the person is presenting the information, and there are cases of impersonation of the content of the information, and there are cases of impersonation of the content of the information, including forgery and falsification. In such cases, how should it be presented? Since there are probably signatures of the Issuer, if the signatures are correct, it is safe to assume that there is no impersonation of the content. Therefore, I do not know what the "impersonation" here refers to as a concerned impersonation. However, in this use case, identity verification does not assume it. If so, I do not know what this "impersonation" is.

Secretariat (Sawada): document, it's written in red letters, but here, a third person pretends to be the owner. This is a risk in the case where the content of the VC itself is legitimate.

Dr. Sakae Fuji: We just need to make sure that the person making the issuance and the person making the presentation haven't changed.

Secretariat (Sawada): Yes, how the Holder Binding can and should be done.

Secretariat (Kadohara): We would like to hear your opinion on the level of confirming the identity with something like unlocking the PIN lock of the smartphone, or whether or not to repeatedly present something like identity confirmation at the same timing of issuance using JPKI or something like that every time.

Dr. Sakae Fuji: , you are talking about the world asking for single sign-on. The latter half of the discussion that Mr. Kadohara mentioned is necessary at least in the model that the Verifier relies on. If it is a model that the Verifier does not rely on and the Verifier itself confirms, as described in the example, I don't know if the biometric is a face photo or not, but the Verifier directly observes the biometric information written in the credentials and the information of the person giving the presentation to confirm the identity, and I think that there are only two options for issuing credentials that can satisfy this.

President Nakamura: In , I don't think we should judge the risks we discuss, whether we are seeking a identity verification with such strict presenters or not. However, I would like to share as a premise whether we should discuss with such assumptions. The system is built on the premise that the biometric function of smartphones will be used correctly. I think the design of the system will probably change depending on whether we think it is not our responsibility even if it is intentionally misused, and whether we should consider technical measures to prevent such misuse.

Mr. Kusunoki (Secretariat): At the closing meeting in , I don't think there will be any discussion unless there is some kind of premise, so I wonder if it would be sufficient to discuss what would be possible under what conditions. I wonder if it would be appropriate to separate discussions on smartphone lending and borrowing, biometric authentication break-through, twins, and so on. For example, the most recent issue I was concerned about a little over two years ago, which I have not yet solved, is the confirmation of the number when joining the company. In this case, not only the person's My Number but also the My Numbers of all dependents are required. This is difficult only for My Number Card, and a paper residence certificate is required. This is the case with family registers and residence certificates. Although a family register information linkage system has been established for family registers, the Juki Net does not actually have household information. Nowadays, even between national organizations, there are many cases where people fall back to paper when they want to find out about their families. Including such cases, the fact that nothing can be done without a digitalization, in the end, without paper has not changed, and I would like to make a digitalization somehow. At such a time, Ministry of Internal Affairs and Communications's consideration was not that a signed PDF would be insufficient, so I would be very grateful if you could explain their concerns in a proper technical manner and discuss what they are concerned about and how far they can go.

President Nakamura: In In relation to this, for example, among today's use cases, I think there was a resident record with My Number as an example. Regarding the handling of this, is it necessary to technically consider a certain level of strict handling, or should it be discussed from the perspective of leaving it to the operation in the same way as ordinary resident records without My Number?

Mr. Kusunoki (Secretariat): At the closing meeting in While there is a widely shared concern that digital formats are easier to reproduce than paper formats, there have been discussions in Ministry of Internal Affairs and Communications that electronic delivery is not appropriate unless such requirements are met, such as "only the person can present the document," as shown on page 14. The point at issue is whether it is possible to meet these requirements easily. Holder Binding is quite limited in the environment, such as the limited number of viewers supported. Therefore, I would like to receive technical opinions on what is possible and what is difficult in the general world, such as whether it can be done only with a browser and FIDO.

Secretariat (Sawada): online Today, Committee Members Tatsuya Nakamura and Minai were present, and we received their opinions in a chat a while ago, but I would like them to also make oral statements.

Dr. Minai: Mr. Kusunoki made a comment earlier, and I think it will be quite involved. Since there are AI agents, there is talk of uncontrolled VC issuance, there is a will to stop it completely, and there is talk of a VC issuance platform, if there is such a talk that the will will go a long time ago, I thought it would be easier to discuss if I wrote it down on the premise that this is the winning will. , I wrote it in the chat earlier because it was not something to be talked about largely in the multi-brand display area. At present, I have no particular comment in the multi-brand display area.

President Nakamura: In , if there is anything else, please let us know.

Committee member Sako, please.

Committee member Sako: , I wrote a paper at the "Symposium on Cryptography and Information Security" to be held this month, and I hope that this is exactly the case where Mynaportal will appear. I don't know if the wallet has a VC or a Holder Binding private key, but if My Number Card decides to have Holder's private key, there is a VC in Mynaportal, you can download the VC from Mynaportal, and with your own My Number Card private key, you can prove that it is a VC issued to you. At that time, together with my students, I found that the information that must be hidden in the VC can be hidden by selective disclosure, which can be done by tapping the current APIs of My Number Card. I thought that this method would be an easy way to realize a resident card VC in the future.

Committee Member Sakimura: According to the definition of Web Wallet, recently there has been a lot of wallet washing, and I wonder if this is a wallet. For example, in the context of eIDAS 2.0, what the Greek Universities Network (GUnet) is doing is, if you have a key in your student ID card or smart card, and you go to a kiosk and you beep, an encrypted Binary Large Object (Blob) comes down to your browser from the server side, and on the browser, a temporary wallet is created, and you can present it using that. Selective disclosure can also be done, of course. If you log out, it disappears from there. So, I think that this kind of Web Wallet will be a useful reference.

President Nakamura: In It is only a temporary.

Committee Member Sakimura: After all, it's a response to people who don't have smartphones. In that case, there won't be any PCs either. Then, it will no longer be a kiosk terminal or something like that. In Japan, I think it will be an ATM device that can be used at convenience stores, so I think it will be something like, please make it available there.

Mr. Kusunoki (Secretariat): At the closing meeting in I think there are several reasons why we are talking about Web Wallet here. Access to keys on smartphones is quite difficult, and even if we wait for the spread of wallets, they cannot be used freely for the various use cases we want. In this situation, how can we cut the chicken-and-egg dilemma? I think there is a Greek example like the one you just gave us. Including others, especially now, when AI agents are discussing various applications and support autonomously, there will probably be a variety of needs for wallets, not just one type, including server-based and locally operated ones. There will probably be technical issues in terms of how to realize various wallets at an early stage, without barriers, and in a world with interoperability. I would like to hear your opinions.

Committee member Niizaki: Regarding the Web Wallet, I think crypto-agility will be fairly easy. It is easier to replace it from the server rather than replacing it with something that is easy to handle and local. If the original database is owned by the government, I wonder if it can be placed in the cloud. I think it is the same. Although I am saying something very violent.

Committee Member Sakimura: To put it bluntly, I think that if it is taken every time, it should be a federation as usual.

Committee member Niizaki: However, it seems that the consent of the person in question has been obtained, so if the person in question wishes to retain a document stating that he or she has presented the document, I believe that there is a case in which the document was presented via a wallet, which would be in the form of a proxy. However, it would be difficult to say what the difference is from the consent of the person in question under the Federation.

Mr. Kusunoki (Secretariat): At the closing meeting in I don't think the number of connecting paths will increase if it is a federation. Each person has to do everything according to the situation they want to show. Mainapo API is a kind of federation, and we are experimenting with API linkage. Then, can we connect with companies all over Japan?

President Nakamura: In So, it is a similar argument to the issue of how strictly the Issuer and Verifier should be confirmed in the IHV model. If you think that the signing key of a free Issuer is not allowed, you should manage it accordingly.

Mr. Kusunoki (Secretariat): At the closing meeting in Depending on the use case, for example, if we want to turn all receipts into VCs, we need to consider a world where all kinds of people can be issuers. I don't think we need a society where everyone issues a copy of a residence certificate, but when it comes to receipts, invoices, and other vouchers that are widely distributed in paper form, I think it's difficult to fit them into the scale that can be covered by API integration.

President Nakamura: In That is, use cases are divided into several levels, and for this level of VC, it seems that the issuer needs to verify this kind of classification. How should it be designed? How many levels should be created?

Dr. Koiwai: I would like to return to the topic of I thought it was related to that, but in the end, I think the Issuer will probably ask about how much security they want to guarantee to the VC they issue. If so, I think it will be a world where the Issuer will choose the Wallet. In such a case, if we just think about the copy of the residence certificate, it may be okay to use only the national wallet, but there will be a discussion about whether all the residence certificate mentioned earlier and various other VCs will be stored in the national wallet in the future. If that happens, I think we should at least create a wallet that can be provided by more various people.

President Nakamura: In At that time, there will probably be several levels of wallets, and I don't think it is necessary to handle all of them with one wallet. However, from the user's perspective, there are many applications, which makes it difficult to use, so I think we need to talk about how the wallet is designed, including the user experience.

Dr. Koiwai: I would like to return to the topic of To put it the other way around, if we aim for a wallet that can be used widely and broadly, the security level that we can realistically achieve is this level, so there is a possibility that we may have to ask the issuer to bear with it.

President Nakamura: In In that sense, I think it is natural for the government to use wallets that are above this level, and for the private sector to freely use wallets that are below this level and are not too risky.

Dr. Sakae Fuji: , Considering the current possibility that various wallets and various credentials will be included, it will probably not be possible to say that this level is good for a single use case or that it is good to have this kind of function. One of the important points is that presenting multiple credentials at the same time is a major advantage of this IHV model. At that time, when looking at the level of the credentials alone and when presenting multiple credentials, if one of the credentials is at a different level, it will naturally occur. For example, when considering that a copy of the certificate of residence and the certificate of graduation must be presented at a Japanese company when seeking employment, the level of the use case in Japan should be considered, but the certificate of graduation may be presented to a university overseas. For example, if it is said that this level is required by EU regulations when presenting it to a university in the EU, I think it will be dragged there. As a copy of the certificate of residence must be presented at the same time and must be included in the same wallet. Therefore, we will have to consider such matters when implementing it in society this time, but this time we will consider it only in this use case. However, I was asking because I thought we might have to decide whether it would be good in the case of a single VC or a single wallet, and what would happen when we expand it to that extent.

Dr. Koiwai: I would like to return to the topic of Just to add a little bit more, in the end, what we need to bind will also change. In the worst case, we can have two wallets and present them separately. However, if we do so, we will not be able to prove that the two presenters are the same. In that case, if we have to bind by attribute, what should we do with that attribute?

Dr. Sakae Fuji: , so when we think about this use case, I think it is probably important to consider whether or not it is a premise that one wallet can store multiple credentials and a certain level of trust in the wallet binding.

Committee member Niizaki: You mentioned the case where a copy of a residence certificate is used by a person who is not the holder of the residence certificate, but there is only a name for a copy of a residence certificate. After all, I think that bringing an additional ID and presenting two will be the case when a copy of a residence certificate is used for important administrative procedures.

In a similar vein, a vaccination certificate. There have been cases where two vaccination certificates, one for overseas and the other with a passport and passport number, were used together. I wonder if there are talks about such a combination, such as using only VC or using the other one if only one is not enough.

Mr. Kusunoki (Secretariat): At the closing meeting in As you said, the use case of the Number Act is exactly the same as that of the vaccination certificate, which is the question of how to bind a copy of the residence certificate as a number verification document, as well as My Number Card or an electromagnetic record as an identity verification document. For example, when submitting My Number for all family members, currently five people have to hold up a card reader to enter their PINs, but if you hold up My Number Card together with a copy of the residence certificate for five people, whether the remaining number can be assumed to be correct if the head of household or someone else has submitted it, and so on. As with the vaccination certificate, for those that require a really high level of identity verification, it is possible to submit a verification document as an attribute verification and an ID together. As for how to technically do the binding in the wallet, I think there are various ways, such as issuing a different certificate for the binding at the time of issuing the certificate, so if possible, I would be very grateful if you could carefully confirm whether there are any requirements ① ② ③ ④ that are not impossible to realize in VC.

President Nakamura: In It's almost time, but what I'm worried about in the material is, for example, in (3), there is a description such as "users who don't have smartphones cannot use it," but I don't know how we are required to consider this, and I think it would be better to clarify whether the stance is that people who cannot use VC on smartphones can use the conventional method, or whether the goal is to consider a mechanism for some kind of digitalization with VC in the future.

If people who do not have conventional smartphones have no choice, I think it would be better not to mention what to do if they do not have smartphones. I would appreciate it if the system designers could clarify which direction they are aiming for.

Committee member Kenichi Nakamura: If you want to do it, you can do it, but in short, it seems to be a matter of how much it will cost depending on how much you rescue. If it is not so costly, I think it would be more convenient to expand it to this extent because I can pick up as much as I can. For example, the number of people with smartphones will increase, and unless we think about it step by step, I think there will be no end to it.

Dr. Koiwai: I would like to return to the topic of Based on the fact that how much people who do not have smartphones or computers remember My Number Card's PIN numbers.

Committee Member Itakura: I think it's probably good to start with smartphones.

President Nakamura: In We are running out of time, so if there are any comments you would like to add at the end, please do so.

Dr. Koiwai: I would like to return to the topic of spoofing detection, but when presenting a VC here, I thought it would be important to properly confirm whether the Verifier is correct. That's all.

President Nakamura: In Thank you very much.

In that sense, eIDAS 2.0 will appear in various places. Then, when what we are trying to do is actually reflected in the framework of eIDAS 2.0, the specifications of which have already been discussed to some extent, if there is a discussion about what is the problem or if the Japanese systems do not match, I think we can discuss based on that. If there is such a framework that has been worked out to a certain extent, I think it would be good to evaluate to what extent we can design the systems or make a digitalization for the procedures. Have there already been such efforts?

Mr. Kusunoki (Secretariat): At the closing meeting in As an expert, I think I need to talk about this with the Ministry of Internal Affairs and Communications Study Group. In relation to eIDAS, an extremely heavy system has been presented. On the other hand, what will be realized there is, for the most part, what we have already realized in My Number Card. The scope of the Study Group is how to digitalization as many documents as possible. There may be parts that fall within the scope of eIDAS 2.0. We will have to learn a lot about that. On the other hand, on the assumption that we have already realized what we are doing at the level of the world's top runners, we will probably have to consider how to propose and create something beyond that and involve other countries.

At this time, the technical working group will temporarily end this fiscal year, so there will be discussions on what to do from the next fiscal year onward. However, I believe that these two technical working sessions have provided considerable guidance on what should be discussed in detail so that we can have more concrete discussions and organize the issues to be solved, including whether it is better to hold discussions or to do things by moving things around at hand in order to do things properly. Based on this, I think we need to be able to present something that can be properly addressed.

President Nakamura: In The meeting will be held twice, but this will be the last meeting of this fiscal year, and we will summarize the results and report them to the parent meeting.

Secretariat (Ishii): Since Minai, who participated online, has just one statement to make, I would like to connect the call.

Dr. Minai: Mr. Kusunoki made a comment earlier, and I think it will be quite involved. Since there are AI agents, there is talk of uncontrolled VC issuance, there is a will to stop it completely, and there is talk of a VC issuance platform, if there is such a talk that the will will go a long time ago, I thought it would be easier to discuss if I wrote it down on the premise that this is the winning will.

President Nakamura: In We will discuss how to continue the discussion for the next fiscal year, including that, and we will keep an eye on the situation, including whether or not you will gather again next fiscal year. Regarding the main meeting, we need to sort out to some extent from the perspective of technology, and based on that, we need to discuss what we should think about institutional aspects. I would like to continue to receive your opinions, including that. How long will Slack be maintained?

Secretariat (Kitainoue): Even if today's meeting is over, I don't know if we can say that it will be until the end of this fiscal year, but at least Slack itself will continue until the main meeting is over, so I understand that we will continue to communicate on the spot.

President Nakamura: In , if there is anything you are concerned about again, I would like to discuss it on Slack and other occasions, so if there is another time, I would appreciate your continued support.

Should I return it to the office?

Secretariat (Kitainoue): Thank you very much.

Prior to the closing of the meeting, the secretariat will provide an administrative communication including how to summarize the meeting going forward. Regarding the technical working session, although there have been some remarks, this will be the final meeting for this fiscal year. We will not report to the main meeting with the materials discussed today, but we will create a separate material for the report that fully reflects the opinions received today, and we plan to report it at the second main meeting scheduled for February 26. As the chairperson just mentioned, I believe we will be asking all committee members to continue to confirm matters not only at this meeting but also by utilizing Slack, etc., and I would like to ask for your continued cooperation.

In addition, I would like to announce today's proceedings on the Digital Agency website after confirming with the committee members at a later date. Thank you for your understanding.

On behalf of the Secretariat, Mr. Kusunoki, Mayor of Group of Common Functions for Digital Society, Digital Agency, would like to close the meeting with a few words.

Mr. Kusunoki (Secretariat): At the closing meeting in , I would like to extend greetings on behalf of the Secretariat.

The technical working group meeting was held for such a short period of only two months, and I believe that I was able to receive many opinions from the members even within the limited time. First of all, I would like to express my sincere gratitude.

The Study Group on Wallet has been held repeatedly for several years in different forms, and it has taken longer than expected. This is not only the case in Japan, but also in the world and in many European countries, where people are suffering considerably. On the other hand, the situation has changed significantly since then, including the case of AI agents, and the need to coordinate information through individuals has become more specific in some places, and there are more and more places that need to be urgently sorted out. In this situation, it is not enough to just wait with your mouth open, and as Mr. Sako suggested this time, I believe that we are facing these issues together within the community, not just at the Study Group, but with society as a whole.

This year's meeting of the Technical Working Group will end today. However, I believe that we will continue to ask the members to review the feedback to the main meeting and the outcomes of the meeting based on the second meeting of the main meeting. Although it will be a difficult time at the end of the fiscal year, I would like to ask for your continued cooperation. Thank you very much.

Secretariat (Kitainoue): With that being said, I would like to conclude the meeting of the "Technical Working Group of the Advisory Council on Identifying Issues in Attribute Certification." Thank you very much.

Greater than or