Skip to main content

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 ".

Expert Meeting for Revision of Personal Identification Guidelines (first meeting in fiscal 2023)

We will hold an expert meeting for the next revision of the digital society "DS-500 Guidelines on Online Identification Methods for Administrative Procedures", which has been developed as one of the Promotion Standard Guidelines, in .

Overview

  • Date and time: October 31, 2023 (Tue) from 18:00 to 20:00
  • Location: Digital Agency 20th Floor Meeting Room and online
  • Agenda:
    1. Opening
    2. Proceedings
      1. Explanation of the outline of the event
      2. Discussion on issues concerning the revision of the Guidelines
        • Issue 1. Review of Identification Assurance Level
        • Issue 2. Review of the person's certification and assurance level
    3. Adjournment

Materials

Relevant policies

Minutes

Attendees

  • Tatsuya Kadohara (Specialist Solutions Architect, Security, Amazon Web Services Japan LLC)
  • Satoshi Goto (General Manager of RCS development Department, DX Business Headquarters, Business Promotion Headquarters, TOPPAN EDGE Co., Ltd.)
  • Natsuhiko Sakimura (OpenID Foundation Chairman)
  • SATO Shuko (Associate Professor, Information Technology Center, The University of Tokyo; Chief of the Next Generation Certification Collaboration Working Group / Trust Working Group, Academic Certification Collaboration Committee, National Institute of Informatics)
  • Akihide Higo (Director of TRUSTDOCK Co., Ltd.)
  • Naohiro Fujiei (Representative Director of OpenID Foundation)
  • Toru Minai (Deputy General Manager, Market Research Office, Innovation Management Department, Japan Credit Bureau, Ltd.)
  • MORIYAMA Koichi (Chief security Architect, NTT DOCOMO, INC., Member of the Board of Directors of the FIDO Alliance Executive Council, Chairman of the FIDO Japan WG, Director (Board member) of W3C, Inc.)

Agenda (1) Explanation of the opening and outline of the meeting

Secretariat

  • I have always thought that the time required to set up a video conference would be shortened due to the evolution of technology, but it has been a quarter of a century since we were disappointed. I feel that it is an old and new problem. Similarly, I had briefly thought that various problems would be solved by the spread of My Number Card for ID, the theme of the conference. However, with more than 90 million cards issued so far, problems with linkage and agents have become apparent, and I feel that it is not enough to just issue credentials. Such problems are being discussed in the examination of electronic power of attorney, but as the government has been studying the issue of identity verification guarantee level and person identification guarantee level for nearly 20 years, and the foundation has been established, edge cases have been discovered in the midst of increasing utilization, and many discussions for review are required in foreign countries, so I think that it is an extremely high-profile field. I feel that we must proceed with our own examination with a sense of skin and touch, while firmly catching up with discussions around the world on what is happening in the world, what needs are emerging, what kind of technology is possible, and where there are gaps. Thank you for your continued guidance.
  • I would like to explain today's meeting. Thank you for participating in the meeting as you did last year. For this year's meeting, we plan to disclose the materials and minutes on our website. In addition, we plan to hold a total of five meetings this year. As a current plan, we plan to hold three meetings in 2023 to discuss the issues, and in the two meetings scheduled for 2024, we plan to advance the discussions based on the draft of the revised version of the Identity Confirmation Guidelines prepared by this task force. The issues to be discussed in the three meetings scheduled for 2023 are listed in the outline of the meeting in Material 1. As a future schedule, we plan to prepare a draft of the revised version of the Identity Confirmation Guidelines by the end of this fiscal year, incorporate the contents of NIST SP 800-63-4, which is scheduled to be finalized at the end of the fiscal year, in the first half of the next fiscal year, and finalize and issue the revised version while discussing with you.

Agenda (2) Discussion on issues for the revision of the Guidelines

Regarding "Issue 1. Review of Identification Guarantee Level"

The Secretariat explained the current policies on Issues 1-1 to 1-3 based on Material 2, and the experts held free discussions.

Opinion of experts

  • The secretariat explained about the theft of identification cards, but I think NIST is also considering the lending and borrowing of identification cards. I felt that it is necessary to consider whether the current policies should be maintained when considering the lending and borrowing of identification cards in Japan. In addition, I was curious about the relationship between the policy of the first issuance of My Number Card and the process of reissuance in the event of loss and the policy to be established in the Guidelines for Identity Verification. If it takes a long time to reissue, it will be troublesome if administrative procedures cannot be performed during that time, so I feel that it is necessary to include the point of what kind of remedial measures should be taken in the Guidelines. NIST SP 800-63-4 also contains a statement to the effect that exceptions should not be excluded due to the lack of identification cards, so I would like to hear your view on how to handle such exceptions.
  • I think there is no problem with the general policy of aligning with NIST IAL3. However, at this point in time, what is meant by Supervised Remote Identity Proofing in NIST, and the interoperability of ID evidence in Japan and the interoperability of ID evidence in the United States are naturally different, so I think it is necessary to work on the definition and market view in parallel. For this reason, even if we declare that we will align with NIST IAL3, I think it is unclear whether we can truly realize it, and I think it is a point that we must deepen our discussion.
  • Regarding the comparison of biometric information, in the case of Supervised Remote, authenticating with a digital account in AAL2 or FAL2 should have been included in the requirements for Verification, and authentication with My Number Card and PIN proves that you have accessed your registered My Number Card account, so I think it conforms to NIST IAL3. However, as mentioned earlier, if PIN information is also shared when a My Number Card is lent or borrowed, authentication by another person will be possible. Since there is talk of making the recording of biometric information mandatory, heuristic control can be realized by tracking later, but it will not be preventive control. Therefore, I think it is good to have a sense of whether it is acceptable in light of the conventional approach of administration.
  • In the first place, I think it would be better to leave room for discussion on whether or not it is necessary to consider fixing the identification guarantee level to three levels. In the internal digital identity guidelines created by our company, we have considered whether or not the three levels of NISTIC should be followed, and as a result, we have set it to three levels. I think the operation is generally going well, but I realize that there are cases where it is better to add plus or minus to the three levels when considering the strictness. In this study, if the identification guarantee level 3 is defined as a very strict level that does not fall under general administrative procedures, the actual guarantee level will be two levels, Level 1 and Level 2. Therefore, for example, I think there is room for consideration on defining an additional identification guarantee level equivalent to NISTIC Level 3, such as 3 +.
  • Regarding biometric information comparison, recently in private sector, there is a trend that health insurance card without a face photo cannot be used as an identification document. We believe that the need for facial recognition has been understood, including the problem of borrowing and lending identity documents. On the other hand, we believe that it is practically effective to perform remote identification by multi-factor authentication with E-Certificate and PIN in My Number Card. In fact, we have confirmed that JPKI has been increasingly used in our business since March 2022 when it was gradually made available. However, there are some people who do not remember their PIN. Recently, we have started identity confirmation by the presence of IC chips and facial recognition since September. If we simply say "biometric information comparison is not essential" in the Identity Confirmation Guidelines, I think it will be interpreted as "facial recognition is not necessary." Therefore, I think it is better not to actively promote such an idea, including borrowing and lending.
  • There are not many other opinions on the registration code, so I think it is fine to discuss it individually, but I personally think it is meaningful.
  • Regarding Argument 1-2, it seems that the results of validation and the confirmation of appearance are treated in the same way, so I think that a slight difference should be made. At least, I thought that it is important to create a state in which Relying Party can confirm what was used for validation.
  • If we discuss biometric authentication, there is a high possibility that various halations will occur, so I feel that we must proceed carefully in terms of how to make it known to the people. The other is false acceptance rate (FAR). If we try to accept foreign nationals who have a Japanese resident record and have a My Number Card, I think it will be difficult unless we raise the acceptance rate to a certain extent.
  • I agree with the idea of aligning Identity Verification Assurance Level 3 with NIST IAL3 in consideration of interoperability with foreign countries in the future. However, I am concerned that different levels may be mixed, as seen in the case where many methods were concentrated in Level 2 and subdivided when the private sector Identity Verification Guidelines were examined at DADC about two years ago. Regarding the Identity Verification Assurance Level 2, if biometric authentication is performed when knowledge authentication is impossible, there is a possibility that it will be read, so I think it is okay to describe it as "Public Personal Authentication or".
  • As a separate matter, the current Guidelines for Identity Confirmation describe "face-to-face or remote," and we recognize that online procedures and postal procedures were included in remote procedures, but since the materials this time describe "remote" and "digital evidence," we would like to ask whether postal procedures should be excluded from the baseline.
  • I am also concerned that the scope of the Identity Verification Guarantee Level 2 will be expanded. When private sector refers to the revised Identity Verification Guidelines, I think all the confirmation of finance-related procedures will be Level 2. Since various procedures such as opening a bank account and creating a credit card will be concentrated at Level 2, I felt that it would be easier for private sector to accept it if private business published a guide that recommends considering the fragmentation of the Identity Verification Guarantee Level as appropriate when referring to the Identity Verification Guidelines at private sector.
  • If identification guarantee level 3 is to be tightened, the level to be basically selected will be 1 or 2. If the necessary guarantee level is to be considered based on risk assessment, I am concerned about whether administrative procedures can be accommodated in level 2, or whether criteria can be set that can be allocated to level 2 because criteria are important.
  • I think it is a problem that there is a possibility that the identification guarantee level will be substantially two levels, but I think it was easy to operate because the information collected by the Japanese government is reliable and Level 2 is also easy to certify. At this point, it seems that there is no problem with two levels, but in consideration of future Japanese security, it may be necessary to consider it a little flexibly. Currently, My Number Card is used for employee authentication in government agencies, but I think that the identification guarantee level 3 is a matter of being prepared to operate the equivalent of another PIV in the United States, but is this recognition correct?
  • As for the registration code, I think the use of e-mail addresses is the gap between Level 1 and Level 2. Young people use registration codes by e-mail instead of mail or phone, so I think there is a difference.
  • With regard to the point that it may be okay to have two levels in Japan, I feel that there is a place where the theory of nature is not enough, considering that many foreigners are coming to Japan and the methods of crime are becoming more complex. Discrimination based on the country of origin of the user should never be allowed, and it would be good if the guarantee level could be defined with fairness and strictness.
  • As for e-mail addresses, there have been cases in which they are cunningly attacked by using aliases or Gmail problems, so I think it is better to carefully judge whether or not you have an e-mail address. It has been pointed out that the ability to receive e-mail and the ability to receive SMS should be distinguished, and I am aware that some business operators actually operate them as such.
  • In the past, there was a discussion about whether Level 2 minus or Level 1.5 was necessary even in the era when there were four guarantee levels. Therefore, I think that if we set the guarantee level to two levels, although it is more substantial, the resolution for the guarantee level will be further reduced. In response to the current situation, there are many descriptions about tailoring in NIST SP 800-63-4, so I think it is necessary to be aware of how to think about it.
  • Regarding the point that it is not necessary to make a biometric authentication, I think it would be easier to understand if you could sort out the reason why it is necessary to respond to such threats. Considering theft, it is covered, but considering lending and borrowing, it is not covered. Special fraud is also considered to be a case of lending and borrowing an identification card.
  • As for registration codes, there is naturally a gradation of reliability depending on the means, so it is necessary to distinguish them, as I recognize. At last year's meeting, I discussed that it would be better to define the lower level as thickly as possible, and that it would be an idea to respond by combining the high level of the person's authentication guarantee level with the identity verification guarantee level 0. I think it would be difficult to determine the validity of registration codes only from the perspective of the identity verification guarantee level. I think there will be less difference at the lower level. It is true that there will be many cases that fall under Level 2, and I think that the lower level of Level 2 does not guarantee the reliability of conducting administrative procedures in Japan only at the identity verification guarantee level. Therefore, I think it would be good to define Level 1 thickly and combine it with the person's authentication guarantee level to guide the direction of responding to the risk.
  • Regarding the registered code, I could not imagine what kind of use cases it would be used for and how it would lead to cost cuts by making a variety of low-level countermeasure standards.
  • When I think about a Level 1 registration code from the perspective of a business operator, I imagine that it is to attach a photographed image of an identification card to an email or upload it to a website. If a registration code is added to Level 1, I thought that there would be a modification to make these procedures currently in operation fall under Level 1. I think that it is safe to notify an address of a registration code, but when I think about sending various notifications other than a registration code in the future, I think that it is meaningful to take in information such as a mobile phone number and use it as a contact address.
  • To introduce an example at a university, two-factor authentication has just been introduced at the university, but although mobile phone numbers are registered, they are not verified only by self-reporting. In such a case, registered mobile phone numbers cannot be treated as registration codes, but the operation is surprisingly successful, so it is considered reasonable to treat mobile phone numbers as registration codes. This story is about the person authentication guarantee level, but my idea is that it is better to keep the registration codes that can be adopted at Level 1 and Level 2 at the identity verification guarantee level.
  • I think that the story of increasing the identification guarantee level 1 is true. NIST IAL1 and NIST IAL2 used to be joined together, and NIST IAL0 is missing this time, so I understand that NIST IAL1 is actually expanding its base as a trend in the United States.
  • Regarding the registration code, I think that the concept of controlling the length of the validity period by changing the length of the validity period for each means of communication by contacting the applicant, for example, 24 hours for e-mail and a certain period of time for mail to an address, is good. However, since receiving SMS and receiving e-mail are different from the viewpoint of Authentication, it is good to distinguish the use of SMS as a means of authenticating the person. I think that there may be variations as a means of identification, but I feel that deeper consideration is necessary as a means of authenticating the person.
  • The standard required for each guarantee level is described for each item of the measure standard item, but in reality, the risk is reduced by going through the confirmation method defined as the measure standard for the assumed risk, and as a result, if this level of achievement is achieved, the NIST xAL will be what it is. Therefore, when tailoring, if you are too caught up in the measure standard items presented by NIST, the accuracy will be reduced and the result will not be convincing. Therefore, I think it is necessary to consider it by decomposing it from the viewpoint of what the risk is. I think it is also described in the measure standard of the current guidelines, but I think it is necessary to take into account the viewpoints of existence, survivability, and uniqueness, and to discuss what the survivability visa is like when a photo identification card is used.
  • Going back to the registration code, in Japan, there is a plus alpha system to confirm the address like a specified mail, and I think it is separate from the story that it is identity verification guarantee level 1 because the registration code is sent by mail and presented to the address, so I thought that an adjustment such as making it identity verification guarantee level 2 by checking by a trained delivery person in addition to presenting the registration code could be considered.
  • There is a possibility that the issue setting will be broken, so in that case, I would like you to point out. Today, there were various discussions about the fact that if the Identity Confirmation Guarantee Level 3 is adjusted to the NIST IAL3 standard, the required standard of measures is too high, and many procedures are concentrated on Level 2. In addition, Level 2 was mainly talked about the necessity of comparing biological information at the time of online identity confirmation. When considering the situation in which identity confirmation in the administration will occur, it was said that it is an extremely special and limited case that NIST IAL3 level confirmation is required. In the future, more people will be required to confirm identity online. The premise of the current My Number Card and next version of the My Number Card is that identity confirmation is currently performed at the level of going to public office and referring to the Basic Resident Register. I have always felt that what level of identity confirmation is performed here will be important. If identity confirmation at the time of My Number Card issuance is performed at a certain level, the quality of identity confirmation using My Number Card will be higher, so it is not included in the subject of today's issue, but I think that what face-to-face identity confirmation in public authorities should be is important.
  • Face-to-face identification also has a spoofs problem, and I am aware that there are cases where the effectiveness of verifying the identity of the submitted ID is increased even at the store. However, there are criminal groups that think about ways to slip through the verification process, so it is not simple. However, if face-to-face identification is sublimated to a certain level, at least those installed in next version of the My Number Card or smartphone after that will play their roles very effectively online. Therefore, the identity verification assurance level and the person identification assurance level are also important, but the core part of identity verification, which is called an endpoint in another technology, should be thoroughly implemented. I think that will be the Trust chain after that, so I made a statement that I thought was very important, although it was not included in today's discussion.
  • In the explanation from the Office, you said that you were considering changing the title of the Guidelines for Identity Verification. However, I recognize that the current Guidelines for Identity Verification issued in 2019 state that identity verification for both individuals and corporations is applicable. However, at least the subject of today's discussion is only identity verification for individuals. Are you planning to discuss identity verification for corporations at some place in the future? Or are you planning to remove identity verification for corporations from the scope of the Guidelines for Identity Verification? As reference information, there are business operators in the Trusted Web who are considering use cases and demonstration experiments for identity verification for corporations, so I thought it would be beneficial to use the results well in cooperation with such places.
  • NIST strongly regrets that the thorough implementation of the guidelines in SP 800-63-3 led to the exclusion of residents from public service. NIST emphasized in the briefing session on SP 800-63-4 that tailoring should be taken to prevent such a situation from occurring in the future. Unfortunately, tailoring is not working well in the United States either. If the standards for measures are made stricter than necessary, it may become a golden rule and be excluded. This is a common occurrence overseas. For example, in Uganda, there have been reports of cases in which medical care was not received because a national ID card was not obtained despite the urgent need for medical care. Since public service requires a wide range of funds, I think it is important how to incorporate it into documents so that people can read them.
  • What was particularly impressive to me among the changes from SP-800-63-3 to SP-800-63-4 was that the flow chart, which had been quite complex, was eliminated. Since the flow chart was eliminated, each of us had to examine it by ourselves. I think that there is such a concept that if it is described in detail in the guideline, it will not be able to respond to the really necessary needs.
  • I think that the elimination of the flow chart is correct in terms of direction, and I understand that risk assessment is not to be done with a flow chart. Even those who feel grateful for the existence of the flow chart should realize that in the end, risk assessment must be done properly when actually using the flow chart. If risk assessment is done correctly, I think that the necessary guarantee level is determined by following the flow chart, but regarding the impact on business, what is applicable to serious, medium, and low, respectively, is discussed, so in the end, I think that the problem is shelved.
  • I believe that NIST SP 800-63 was originally intended for government employees, and as a remnant of that, the risk of credential replication in the event that the PIV of an employee is stolen is very heavy, and that is IAL3. I recognize that the risk of the system I am assuming is because the data of various citizens who can access with the authority when a certain Authenticator is stolen spreads horizontally. When it comes to a service like government-to-citizen, I think that the scope of influence is basically limited to the scope of a specific user, and I think that it will be better to map the risk by imagining both services and determining whether the service should be set to Identity Verification Guarantee Level 3 or whether the service should be set to Level 2. I think that it will be better to converge on which request level this service should be. In order to build a common understanding, I think it is important to think about what kind of system is required to be Identity Verification Guarantee Level 3.
  • There have been repeated comments from several committee members, including myself, but it is good to proceed with consideration based on the means, but I think it would be good if the guidelines can clearly show which threats are being addressed. I think there are many cases where it is not necessary to consider the threats of various use cases, and there should be many benefits such as eliminating the exclusion of residents from services by enabling flexible responses, and making tailoring easier. I would like you to consider them. I have commented on the same in NIST SP 800-63-4.
  • In addition, I would like you to include consideration of exception processing from the beginning. This time, I am quite My Number Card-centric, and I think that is fine, but I would like you to describe how to handle the case of losing a My Number Card in a way that is easy to read.
  • I understand that the registration code is different in authentication strength, so it is necessary to clearly distinguish between mail and other means, and that a certain level of strength can be maintained for specific mail among mail. Therefore, I would like to make some additional comments.
  • If it is made into a threat base, it should come out properly. Various threats should be eliminated by adopting specified mail.
  • It's a very broad story, and it seems to be difficult to summarize it in the form of N to N to N, but I think that's true.

Further Discussion: Implications of Guidelines and Assurance Levels

  • In our company, the level of risk measures has clearly been raised by the establishment of the internal guidelines. The same applies to the identity verification guarantee level, and even more so to the person identification guarantee level, which is the issue to be discussed later. When experts gather like this conference, it is argued that it is essentially not the case, but when considered from the perspective of actual implementation, it is easier to proceed with the response if we set a guarantee level that can be used as a common language. On the other hand, the flowchart was deleted in SP 800-63-4, and we received a request to make the flowchart of the guideline more detailed. In this way, when developing and revising the guideline, we feel that it is necessary to consider it from the perspective of the person who actually uses it.
  • The same thing is happening at universities, and there is a problem that there are not many people who can list threats and destroy them one by one, in other words, who can respond intelligently at an advanced level. Even so, it is necessary to maintain a certain level, so I think the only way is to raise the level of operation little by little by indicating in the guidelines that it is okay to do this. In that sense, even if it is not very meaningful because there are more technical options, I think it is still significant for those who respond on the ground to guide the way of thinking. From the side that asks students to do various things, it is something that I feel strongly.
  • In both explanation and evaluation, if there is no framework for that, it will be difficult to respond. I think it would be convenient if there was something. However, I think it is necessary to tell them that it should not be closed there.
  • In private sector, for example, if a problem occurs in a service, criteria are set based on the amount of damage and business impact, and if there is even one high, it is 0 0. I think it is relatively easy to create a framework. In the case of the government, the position is different, so I think it is difficult.
  • Regarding risks, of course I agree with the opinion that we should proceed with responses after conducting proper risk assessments. However, I feel that the definition of risk in the current NIST SP 800-63-4 is quite rough. When conducting design based on the guidelines, if we evaluate risks based on criteria such as whether they are related to human life, they are often lumped together in one place. If we are to respond on a risk basis, I think the question is how precisely we can define risks in administrative procedures.
  • In terms of flowcharts, while it is better to have it as a common language, it is also true that there are opinions that are too tied to it. In my opinion, the worst part of the flowchart of SP 800-63-3 is that it is all Yes/No binary. I think it would be useful if a flowchart could be completed in consideration of the point that exceptions must be made as in the previous story.

Regarding "Issue 2. Review of the Person Certification Guarantee Level"

The Secretariat explained the current policy on Issue 2-1 based on Material 2, and the experts held a free discussion.

Opinion of experts

  • I have been involved in phishing resistance for many years, so I think I can make a proposal. Our company has a track record of eliminating inquiries from customers saying that they are making transactions that they do not remember by actually limiting the authentication to be phishing resistant for a certain service site. The results are extremely confident, and the amount of damage has decreased overall. We believe that phishing resistance in the authentication required to use the service is extremely important for people to live their lives with peace of mind. You just mentioned that the Identity Verification Guarantee Level 3 in the Identity Verification Guidelines should be equivalent to NIST IAL3, but if there is room for adjustment in the definition of the Identity Verification Guarantee Level, I understand that it is very meaningful in practice to draw a line between those that are phishing resistant or close to it, and those that are not phishing resistant but outbound in the table on page 13.
  • I think it is quite difficult to make phishing resistance mandatory, but I think it is better to clearly indicate the strength of the degree of recommendation for the authentication methods that can be selected at Level 2. The nature of the type of attack that makes economic sense if you send an e-mail to 10,000 people and receive 100,000 yen from one of them is completely different from the risk of being copied by stealing the token of the PIV card of one government employee. Therefore, there is no doubt that the importance of phishing attacks is increasing as long as there are online attacks targeting an unspecified number of people. Basically, I think there is no problem as summarized in the materials.
  • On the other hand, even if we take one time password authentication without phishing resistance as an example, we recognize that there is a big difference between doing and not doing multi-factor authentication in the first place. Although there is a difference in the effect of further reducing the impact of attacks to zero, we are a little concerned that if we narrow the options too much, it will become difficult to use or we will move to the direction of quitting, so I think it is good to leave them as options.
  • While advising local government, even if it is a simple method to realize multi-factor authentication or phishing resistance as much as possible, for example, if it becomes essential for the person's authentication guarantee level 2, it is difficult for local government to choose. local government staff are in direct contact with residents and users are visible, so I feel that the obstacles to making it and getting it accepted will increase. On the other hand, I think it is difficult to remove it, so I thought that I had to read how public acceptance will progress.
  • Two step verification is really easy to break through, so I would like you to keep the line between two step verification and non-Wi-Fi. In addition, there is a password + SMS authentication code in the document, but there is no description of receiving a one time password by email. There is a difference, and there are good and bad, but as a menu, I think it is better to prepare both.

Additional Discussion: The Granularity of Threats and Methods in Guidelines

  • Threats change, but I think we should not hesitate to explicitly state threats that are known at the present time. As long as the degree of recommendation changes, I don't think it will be conveyed to users unless there is a reason for what is difficult to recommend and what is strongly recommended. I think it is possible to extend the expiration date of the document on the face of the letter by writing that what threats are listed as those that should not be adopted, and that if the probability of occurrence increases as time changes and becomes common, it can no longer be used. NIST also keeps SMS as an option while sending a message as Restricted, and I think it was a good way to do it, and I think I had to write so.
  • The Anti-Phishing Guidelines issued by the Anti-Phishing Council include pre - and post-measures such as "Points to Note when Sending Emails to Users" and "Responses in the Event of Phishing." I thought it would be a clue that if phishing resistance cannot be made essential at Level 2, you can refer to these points.

Closing and Next Guidance

Secretariat

  • That's all I would like to discuss today. The next meeting is scheduled for Thursday, November 16. Thank you very much for participating for a long time and for your various opinions today.

()