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

Advisory Council for Revision of the identity verification Guidelines (second meeting in fiscal 2023)

An expert panel will be held for the next revision of the "DS-500 Guidelines on Online identity verification Methods for Administrative Procedures" , which has been developed as one of the Digital Society Promotion Standard Guidelines.

Overview

  • Date and Time: Thursday, November 16, 2023 from 18:00 to 20:00
  • Location: Meeting room on the 20th floor of Digital Agency and online
  • Agenda:
    1. Opening
    2. Business
    3. Discussion Points for Revision of the Guidelines
      • Point 4: Review of the risk assessment process
    4. Closing

Material

Related policy

Minutes

Attendee

  • Tatsuya Kadohara (Specialist Solutions Architect, Security)
  • GOTO Satoshi (General Manager, RCS Development Dept., DX Business Div., Business Promotion Div., Toppan Edge Co., Ltd.)
  • Natsuhiko Sakimura, OpenID Foundation Chairman
  • Amane Sato (Associate Professor, Information Technology Center, The University of Tokyo / Next Generation Certification Cooperation Working Group, National Institute of Informatics Academic Certification Cooperation Committee / Trust Working Group, Chief)
  • Akihide Higo (Director, TRUSTDOCK Co., Ltd.)
  • Hisahiro Fujie (Representative Director of OpenID Foundation)
  • Minai Toru (Deputy General Manager, Market Research Office, Innovation Division, Japan Credit Bureau Co., Ltd.
  • MORIYAMA Koichi (Chief Security Architect, NTT DoCoMo Inc., Executive Council of FIDO Alliance, Board Member, Chair of FIDO Japan WG, Director of W3C, Inc. (Board Member))

Agenda (1) Opening and Outline of the Meeting

(Explanation by the Secretariat)

  • Now, I would like to begin the second meeting of the Advisory Panel on the Revision of the identity verification Guidelines. Thank you all for taking the time out of your busy schedule to gather here. Today, I have prepared two points of discussion: "How to reflect the risk evaluation process" and "What kind of support can be provided in Digital Agency for risk evaluation?"

Agenda (2) Discussion Points for Revision of the Guidelines

Issue 4-1. How the revised risk assessment process by NIST should be reflected

The Secretariat explained the current policy on Point 4-1 based on Appendix 1, and experts held free discussions.

(Expert Opinions)
  • Is the figure on page 7 of Appendix 1 an image of tailoring, in which methods and threats are segmented and reflected in the segmentation of assurance levels 1 and 2? Depending on the type of procedure, which pattern the threat is, is confirmed in advance when designing, and as a result, the method is decided? Risk assessment is roughly done first, isn't it?
    • Secretariat: In order to prevent the complexity of the review process in Step 1, we would like to avoid fragmentation of assurance levels. The review procedure is as you know. For example, we assume that we first conduct a rough risk assessment in three stages by category, such as "how much damage to life is expected", and then select a method to be adopted while observing the threat resistance of the method corresponding to the assurance level.
  • I wondered if Step 1 was unnecessary if threat resistance could determine the approach to take.
    • Secretariat: Task Force, but there are concerns that assurance levels 1, 2, and 3 are useful as standards for communication, and that if we start from step 2, we will inevitably choose the "highest method that can respond to all threats (a method equivalent to level 3)," so we are considering a two step process of selecting a method for determining the assurance level.
  • In Step 2, the method is subdivided. Is it used by RP in administrative procedures? OIDC I said bring Evidence. Are you thinking about that?
    • Secretariat: The figure on page 7 assumes a model in which the RP implements its own identification and authentication functions, but I believe a similar concept will be adopted in the case of a federation.
  • In the case of a federation, would the administrative procedure side specify the Authenticator to be used? For example, in this method, A, B, and C are not accepted, or something like that?
    • Secretariat: IdP provides multiple means of verification, tailoring will be conducted from the perspective of whether or not those methods can be adopted in the relevant procedures, and we believe that methods that do not have the necessary threat resistance will not be accepted.
  • In the figure on page 7, in the case of assurance level 3, responses to threats a, b, c, and d are mandatory. In the case of assurance level 2, resistance to threats c and d is mandatory, and for threat b, it is mandatory or recommended. Do you mean that the required threat resistance is determined by the assurance level?
    • Secretariat: Response Standards. It is assumed that the criteria will be "face-to-face" at the same granularity as NIST. However, as for the certification assurance level of the person concerned, I believe that some threat resistance itself may be a measure standard as in the NIST AAL.
  • In Step 1 in the figure on page 7, for each xAL category, if you imagine a solid, there are three layers of risk assessment. On the other hand, if you choose a method on the right side, it will be decided as if it is degenerate, but I wondered if the solid will ride on the plane well. I think that example is what I talked about earlier, but it seems that brain conversion is necessary here.
  • If you first confirm what kind of threats are in the cluster of risks, and if there are threats a, b, and c as the threats, for example, you select Method A or B as the corresponding method, it may be better to reverse the positional relationship in the figure.
  • There was a comment that only Step 2 would be fine. However, in the actual field, it is sometimes difficult to judge the necessity of threat resistance, and it can also be used for communication such as "In this case, Level 2 is fine, isn't it?", so I think the classification of Step 1 is very useful as guidance. However, Step 1 also has six categories, and if you understand them and judge the level of three stages, even Step 1 will be a surprisingly difficult process.
  • From the perspective of who will be the readers of the Guidelines, for example, as there are various differences in the methods defined by the Criminal Proceeds Act, there are differences in threat resistance even among methods that fall under the same level. In terms of thinking about what identity verification should be like, I think the threat-based approach on the right side is useful. On the other hand, there are few people who can suddenly understand and judge from the necessity of threat resistance as described on the right side, so the level-based approach on the left side is useful for such people. If we can break down the left and right approaches in this way according to the purpose, I thought it would be a very good document.
  • If I speak from the standpoint of a company that is engaged in system development, I think that basically the introduction of services is a process of conducting risk assessment at a place like an in-house steering committee. However, I am aware that there are many cases in which expert judgment is left to security consultants or the vendor who developed the system. I think it is the same not only for companies but also for administrative procedures and local governments. In that case, I think the point of who is supposed to be the main reader of the reference materials for this guideline becomes important. If you are trying to do it in-house in an organization, the approach on the left may be good. If you are asking experts to look at it, the approach on the right may be good.
  • I agree with what you are saying. I think the approach on the right is very detailed, but for example, when the word "phishing resistance" comes up, it is honestly difficult to think about what kind of impact it will have on my business. As a person who has been involved in security consulting for a long time, I think it is extremely important to think about how it can be operated, and I think it is meaningless to create something that cannot be operated no matter how well organized it is. What we used to do was the approach on the left side of this figure. For example, we designed it so that it can be roughly classified into levels by asking simple questions such as "Do you handle personal information?" and then increased the resolution by involving experts who have insight into risk analysis. I thought that the operation would not work unless we assumed a step-by-step flow in which on-site people first make a rough judgment and then consult with experts in their own organization to further subdivide it. In that regard, I felt that this document was a little too well written.
  • In last year's discussion, there was a debate on whether risk analyses should be centralized in Digital Agency or in the field, and it was hard to come up with an answer. However, in my experience, there were many issues related to whether or not operations could be carried out. Therefore, I have an image that Step 1 in this diagram should be more simple, with about two steps. After that, I will consult with experts in the organization and raise the resolution if necessary. If it is necessary to raise the resolution, I will raise it to a centralized location and make a decision. I feel that such a hierarchical structure can be reflected in the process.
  • I was also concerned about whether the term "tailoring" would be understood. I think it is necessary to clarify what the readers of the guidelines should do and what they should achieve in this situation. I made a comment because I think the main point of this plan is to firmly carry out tailoring.
    • Secretariat: tailoring" needs to be replaced and explained. In terms of who the readers of the guidelines are, they are basically officials in charge of administrative procedures, and depending on the scale of the system, it is assumed that support business operators will also be involved, so I believe that the guidelines should be written in a way that assumes that at least administrative officials alone will consider them. Based on what you have just discussed, I assumed that Step 1 would be considered by administrative officials in charge of administrative procedures, but I thought that Step 2 would require consideration by experts, so I recognized that it is necessary to think by changing the readers assumed for each step. In addition, the significance of dividing Step 1 was also discussed several times today, but I thought that it is necessary to consider two types of readers, those who read Step 1 and those who have to read both Steps 1 and 2, considering the difference in readers.
  • The approach on the left is for those who plan administrative procedures. Those who have an understanding of laws and ordinances and a certain level of awareness of the system, but who need to be consulted on the details of security. The approach on the right is for those who can accurately understand and judge security and other viewpoints. If such an image of the expected reader is written somewhere, I think it will be easy to understand in the process of creating the document.
  • We tend to read NIST SP 800-63 all the time, but OMB M 04 - 04 is what US administrators read. The risk level is specified from the perspective of whether people will die or whether they will suffer great damage if they make a mistake, and I think that's all the job of an administrator. NIST SP 800-63 includes the perspectives of fairness and privacy, but basically, I think the left side is to draw the line of risk, such as what will happen if we cannot provide this administrative service or if we provide it to the wrong party. After the level is specified at such granularity, experts will make detailed judgments according to the threat, and if it is about privacy, the organization alone may not be able to judge whether it is OK to accept the remaining risk, so stakeholder consultation will be necessary.
    There was talk that it might be complicated to evaluate risks in six categories, but I think this much is necessary.
(Explanation by the Secretariat)
  • According to the original plan, I was going to summarize Point 4-1., but based on the opinions I received, I thought it would be better to go directly to Point 4-2. first, and then receive comments as a whole, so I will explain Point 4-2.

Issue 4-2. What kind of examination support and control is necessary for appropriate risk assessment?

The secretariat explained the current policy on Point 4-2 based on Appendix 1, and the experts held free discussions.

(Expert Opinions)
  • What exactly are the administrative procedures that fall under Level 3? If you know that, it would be faster to make a decision by excluding that amount.
    • Secretariat: We considered the idea of examining the patterns of administrative procedures and directly presenting the guarantee level. However, considering that these guidelines will be operated for a certain period of time after the revision and that they will be referred to by local governments and the private sector, the task force has been considering the idea of first writing what the guidelines should be and compiling examples of administrative procedures applicable to each level as informative information.
  • When I looked at the description of the actual risk impact, I thought that if I had to choose from three levels (2), (3), and (4) on page 13, the risk impact would be higher. Therefore, I thought that the way of asking "whether it is applicable or not" would be effective in preventing the risk impact from being higher.
  • When we are in a position to evaluate risks, it may be difficult to say "not applicable" completely. In particular, in cases related to privacy, we cannot say "not applicable," and I was concerned that there may be quite a few cases that will be judged as Level 3 with this way of asking. I think there may be a range of cases that are "not applicable in principle, but may be applicable in this pattern," and I think that thinking about it will lead to a good risk assessment.
  • We also prepare and submit a "preliminary sheet" to the Steering Committee, but the purpose of the sheet is more like a communication tool with the Steering Committee than an accurate judgment on the sheet, so I think this worksheet is positioned as a communication tool.
  • The PIA report is like that. You have to think carefully to write a report, and I think it will be very easy to use as a communication tool if the items of the report are decided.
    • Secretariat: . This tool is also used as a communication tool, but by leaving this sheet as a "document of risk assessment results", we hope that it will lead to continuous improvement.
  • It may be a completely different point of view, but does the documented risk evaluation result correspond to what is disclosed as an administrative document? If so, it would be a hint to attackers, so I thought I had to be careful when handling it.
    • Secretariat: At the time of information disclosure request, it will be treated in the same way as a design document of a normal information system, and I believe that the part with security concerns will be handled in a non-disclosure manner.
  • For reference, in Europe, the PIA report must be published by making a "PIA report for publication".
(Explanation by the Secretariat)
  • To summarize based on the discussions so far, I would like to use the worksheets described in Point 4-2. to make it easier for administrative officials to consider the risk assessments in Step 1. However, that assessment alone is too granular, and in some cases, even if it is determined to be Level 3, from the viewpoint of fairness and privacy, we should consider combining methods equivalent to Level 2 with supplementary measures. In this way, I recognized that it would be ideal to create guidelines that can adjust the process of tailoring in Step 2 while involving experts and support providers.
  • According to the results of interviews with actual study cases, there are procedures that adopt methods different from those shown in the current guidelines from the viewpoint of usability. We would like to make it possible to define such tailoring on the site side as a process.
(Expert Opinions)
  • As for the failure mode of identification, I think it is necessary to consider whether it should be considered on a tailoring basis or whether it should be included in the risk evaluation of Step 1. As a well-known example, there is a case in Uganda where a pregnant woman who did not have a national ID was denied medical care. In such a case, the inability to identify herself is related to the risk of life and death. It is easy to think only from the perspective of security, but we also have to consider the risk of failing to provide administrative services, and I think this perspective should be included in the risk evaluation on the left side of page 7.
  • As I told you at the last meeting, the problem with the flowchart of the guarantee level judgment is that there is "If Then" but there is no "Else". In the risk assessment, I think it would be good to consider "what to do if something cannot be done" and "what to do in other exceptional cases" in the risk assessment of Step 1, and then divide it into three guarantee levels.
  • In the example of this risk assessment worksheet, it says "Fill in the risk if applicable", but even if it is not applicable, I think it is necessary to keep the basis of the judgment as a record.
  • If the options are "Applicable" or "Not Applicable", there is a concern that the edge case will be captured. As a way of thinking, I think it would be better to ask whether there is any unacceptable risk remaining based on the concept of alternative control in PCI DSS. If so, for example, if we want to adopt another method from the viewpoint of usability, etc., by taking alternative control, we may be able to make an acceptance judgment of the remaining risk. I think it is important to have the judgment result written here.
  • It is very important to keep it in writing. There was a discussion earlier about whether or not it will be disclosed, but I think it is better to share it at least within the administrative organization.
  • The part that is accepted as a residual risk should be recorded and made public. Even if the content is organized within the administration, there is a possibility that private business operators who cannot understand the intention may use the certificate of the administration for another purpose, so I think it has a role to prevent that.
  • I think that the purpose of the worksheet is to use it as a common language. From that point of view, I think that the amount of information will be reduced if only the reason for applicability / non-applicability is written, and I think that it is also important to have specific failure modes written. I think that it may be good to think about what kind of undesirable things will happen when you are unable to provide your own services, and to keep it as a record. At first, it may take time due to the pain of childbirth, but as it accumulates, it will be possible to refer to past judgments, and I think it will lead to overall efficiency.
  • I would like to say something negative. In terms of how to fill out this risk evaluation worksheet, based on the discussions so far, I think it will require a fairly high level of skills. It is very important, so training and knowledge-sharing will be necessary. On the other hand, I think it will be possible to create human resources specialized in this examination in each organization, so I was listening to you with the idea that Digital Agency should create a system and mechanism where anyone can conduct the base risk evaluation as much as possible and then experts can make detailed judgments.
  • Let me confirm one thing. What is the relationship between the risk assessment worksheet on page 13 and the failure mode on page 12 of the handout?
    • Secretariat: I think that the failure modes to be considered will probably differ depending on the administrative procedure, so I described examples of major failure modes such as "providing a service to the wrong person" and "not being able to provide the service itself" in the guidelines and asked them to judge the degree of risk impact when a failure mode that should be considered in the procedure occurs on the worksheet. Based on the matter you commented earlier, I think it would be good to let them write out the failure modes that should be considered at the top of this worksheet.
  • Originally, when risk analysis professionals consider, what are the assets to be protected and what are the attack paths? They list them and consider attack scenarios. Around this point, failure modes will appear. They will determine the guarantee level and risk acceptance, organize the remaining risks, and confirm the achievement of security goals. However, even if all of them are required, the operation will not work. Therefore, I think that failure modes are those that can be written with high accuracy by the person in charge of administrative procedures as a party concerned.
(Explanation by the Secretariat)
  • As the scheduled end time is approaching, I would like to summarize. Regarding Point 4-2, I would like to thank you for your opinions and advice, including on the worksheet. I will try to include your comments so that this worksheet will work.
  • Finally, I would like to ask for your comments on the pros and cons of the approach using this worksheet. I feel that I have received a general evaluation in the discussions so far, but on the other hand, the secretariat is concerned that the flow chart has been deleted at NIST. I would appreciate it if you could comment on if you have any particularly negative opinions on whether we should proceed with the study using this worksheet.
(Expert Opinions)
  • I think it's good. It's not that once you decide, it's not over. If you assume that you actively reflect the feedback you get while operating and continue operating, you will also learn about the operation.
  • If you want to document the results of the study, in any case, you have to decide on common entries and a table of contents structure. I think this worksheet is a more detailed version of that. It just so happens that the table of contents structure is in the form of a worksheet, so I think it's good, too.
  • I think it's good, too. By using a worksheet, you can create something close to a risk analysis for the first time, and I think the soul is breathed into the flow chart. If you suddenly go to the flow chart, you won't be able to understand it well, so I think it's necessary to organize it with this worksheet.
  • I think it's just a matter of how you call the document because you need it both as a record keeping tool and as a communication tool.
(Explanation by the Secretariat)
  • Thank you very much. Regarding step 1, risk evaluation, I would like to proceed with the current plan. On the other hand, regarding step 2, tailoring, I think it may be necessary to sort out a little, so I will consider today's opinions within the secretariat and prepare to explain it as a draft plan at the third meeting.

Closing and Next Announcement

(Secretariat)

  • Today, although I was only able to attend from the middle of the day, I felt that the level of discussion was very excellent because everyone was really serious about their work, and I thought once again that it was important to have specific discussions such as how to infuse the soul and whether the God resides in the details. In order to make the guidelines into a form, one or two more steps are necessary, as you pointed out. Therefore, I think it is really important not only to bring NIST SP 63-63-4 as an imported study, but also to repeatedly think about how to adapt to specific threats and various technologies in Japan, and to keep a record of the history as a document while responding to new threats. Through such activities, I hope to raise the level of security not only at government offices but also in the private sector. Thank you for your continued guidance. Thank you very much. 800
  • That will be all for today's meeting. The next meeting is scheduled for Tuesday, December 26. Thank you very much again today.

END