Second meeting of the Advisory Council for the revision of the identity verification Guidelines in fiscal 2023

We will hold an expert meeting for the next revision of 's "DS-500 Guidelines on Online identity verification Methods for Administrative Procedures," which has been developed as one of the standard guidelines for promoting the digital society, in .

Overview

Date: 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. Proceedings
3. Discussion Points for the Revision of the Guidelines
  - Issue 4. Review of the risk assessment process
4. Adjournment

Material

Related policy

Standard Guidelines for the Promotion of the Digital

Minutes

Attendee

Tatsuya Kadohara (Specialist Solutions Architect, Security, Amazon Web Services Japan GK)
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; Next Generation Certification Collaboration Working Group / Trust Working Group, Academic Certification Collaboration Committee, National Institute of Informatics, Chief)
Akihide Higo (Director of TRUSTDOCK Co., Ltd.)
Hisahiro 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 of NTT DoCoMo, Inc., FIDO Alliance Executive Council, Board member, FIDO Japan WG Chair, W3C, Inc. Director (Board member))

Agenda (1) Explanation of Opening and Holding Outline

(Explanation by the secretariat)

Now, I would like to begin the second meeting of the Advisory Council for the revision of the identity verification Guidelines. Thank you all for coming to this meeting despite your busy schedule. Today, we 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 on points for the revision of the Guidelines

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

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

(Expert Opinion)

In the diagram on page 7 of Handout 1, is it an image of tailoring, subdividing methods and threats, and reflecting them in guarantee level 1 and 2 subdivisions? Does it mean that depending on the type of procedure, which pattern the threat is, it is confirmed in advance at the time of design, and as a result, the method is decided? Risk assessment is done roughly at the beginning, right?
- Secretariat: In order to prevent the complexity of the review process in Step 1, we would like to avoid the fragmentation of the assurance level. As you are aware of the review procedure, we first conduct a rough three step risk assessment by category, for example, "How much damage to life is expected?" After that, we expect to select the method to be adopted while looking at the threat resistance of the method corresponding to the assurance level.
We wondered if Step 1 was unnecessary if we could determine the approach to adopt based on threat resilience.
- Secretariat: Task Force, but there are concerns that Assurance Levels 1, 2, and 3 are useful as criteria for communication, and that if we start from Step 2, the "highest method that can respond to all threats (a method equivalent to Level 3)" will inevitably be chosen, so we are considering a two step process of selecting a method for Assurance Level judgment.
You said that you would subdivide the method in Step 2, but is that what RPs in administrative procedures use? OIDC says to bring Evidence, but is that what you are thinking?
- Secretariat: The diagram on page 7 assumes a model in which the RP implements its own identity verification and identity authentication functions. However, I believe that the same idea can be adopted in the case of federation.
In the case of federation, is it like specifying the Authenticator used by the administrative procedure side? For example, this method does not accept A, B, and C, or something like that?
- Secretariat: If an IdP provides multiple authentication methods, we will conduct an tailoring from the perspective of whether those methods can be adopted in the relevant procedures, and we will not accept methods that do not have the necessary threat resistance.
In the diagram on page 7, in the case of assurance level 3, it is essential to respond to threats a, b, c, and d. In the case of assurance level 2, resistance to threats c and d is essential, and for threat b, it is essential or recommended. Is it correct to say that the necessary threat resistance is determined by the assurance level?
- Secretariat: We do not assume that we will directly write more and more about threat resistance as a requirement of the countermeasure standards. We assume standards such as "face-to-face" with the same granularity as NIST. However, as for the certification assurance level of the person in question, I think that threat resistance itself may become a countermeasure standard in some cases as in NIST AAL.
In Step 1 of 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 was wondering if the solid fits well on the plane. I think an example of this is what you said earlier, but it seems that conversion in the brain is quite necessary here.
If the flow is to first confirm what kind of threat there is in the cluster of risks, and if there are threats a, b, and c, for example, as the threats, choose 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, but in the actual field, there are cases where it is difficult to judge the necessity of threat resistance, and it can be used for communication such as "In this case, Level 2 is fine, isn't it?", so I think the classification of levels in Step 1 is very useful as guidance. However, Step 1 also has six categories, and if we judge the three levels after understanding that, even Step 1 will be a surprisingly difficult process.
From the perspective of who will be the readers of the guidelines, the threat-based approach on the right is useful in terms of thinking about identity verification, because there are differences in threat resistance even for methods that fall under the same level, as there are actually various differences in methods prescribed in the Criminal Proceeds Act. On the other hand, there are few people who can understand and judge from the necessity of threat resistance written on the right, so the level-based approach on the left is useful for such people. I thought it would be a very good document if I could break down the approach on the left and the approach on the right according to the purpose.
Speaking from the perspective of a company engaged in system development, I think that basically, when introducing a service, the process is to conduct risk assessment at a place like the in-house steering committee, but I recognize that there are many cases where experts leave the decision to the security consultant or the vendor who developed the system. I think the same is true not only for companies but also for administrative procedures and local governments. In that case, I think the point of who is assumed to be the main reader of the reference materials of this guideline becomes important. If you try to do it in-house in an organization, the approach on the left should be good, and if you ask experts to see it, the approach on the right should be good.
I agree with what you are saying. The approach on the right is very detailed, but when the word "phishing resistance" comes up, to be honest, I think it is difficult to think about what kind of impact it will have on your business. As a person who has been involved in security consulting for a long time, I think it is extremely important to know whether the operation will work, and I think it is meaningless to make something that does not work no matter how neatly it is organized. I often used the approach on the left of this diagram, for example, designing it so that it can be roughly divided into levels by a simple question such as "Do you handle personal information?" The work to increase the resolution from there is to involve experts who have insight into risk analysis. I thought that the operation would not work unless we assume a step-by-step flow in which people on the ground first make rough decisions, and then consult with experts in their own organizations to further subdivide them, so in that regard, I felt that this material was written a little too neatly.
In last year's discussion, there was a debate over whether risk analysis should be done by Digital Agency in a centralized manner or by the field, and it was difficult to come up with an answer. However, in my experience, there were many issues related to whether or not operations would work, so I have an image that Step 1 in this diagram should be simpler, with about two steps. After that, I will consult with experts in the organization, and if necessary, raise the resolution, and if it is necessary to raise it to a higher level, raise it to a centralized place 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 the reader of the guidelines needs to clarify what exactly should be done and what should be achieved in this situation. I made a comment because I think the gist of this proposal is to firmly implement tailoring.
- Secretariat: tailoring" needs to be replaced and explained. In addition, regarding who will read the guidelines, basically it is an official in charge of administrative procedures, and depending on the scale of the system, it is assumed that support providers will also be there, so at least when the administrative officer alone examines it, I think it must be written based on the assumption. Based on the contents of the discussion just now, I assumed that Step 1 would be examined by the administrative officer in charge of administrative procedures, but I thought that Step 2 would need to be examined by experts, so I recognized that it is necessary to consider different readers for each step. In addition, the significance of dividing Step 1 was discussed several times today, and I thought that it is necessary to consider two types of readers, those who read Step 1 and those who have to read both 1 and 2, considering the difference in readers.
The approach on the left is for those who plan administrative procedures, and 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 aspects. If such an image of the intended reader is written somewhere, I think it will be easier to understand in the process of making the document.
We tend to read NIST SP 800-63 all the time, but OMB M 04 - 04 is what U.S. administrators read. Risk levels are defined from the perspective of whether people will die or suffer great damage if they make a mistake, and I think that's the end of the administrative administrator's job. NIST SP 800-63 includes the perspective of fairness and privacy, but I think that the left part is basically to draw the line of risk, such as what will happen if the administrative service is not provided or if it is provided to the wrong entity. After the level is defined at such a granularity, experts make a detailed judgment according to the threat, and when it comes to privacy, there are cases where the organization alone cannot decide whether to accept the residual risk, so stakeholder consultation may be necessary.
Regarding the assessment of risk in six categories You said it might be complicated, but I think this much is necessary.

(Explanation by the secretariat)

According to the original plan, we were going to summarize Issue 4-1 after this, but based on the opinions we received, we thought it would be better to go directly to Issue 4-2 first, and then receive comments as a whole, so I will explain Issue 4-2.

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

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

(Expert Opinion)

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.
- Secretariat: We considered a method of directly presenting the assurance level by examining the pattern of administrative procedures, but considering that the 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 was considering writing the theory of what should be in the guidelines first and summarizing the 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 was asked to choose from three levels around ② ③ ④ on page 13, it would be likely to have an upward swing, so I thought that the way of asking "Applicable or not applicable" would be effective in preventing an upward swing.
When I am in a position to assess risks, it may be difficult to say "completely not applicable." In particular, I could not say "not applicable" in areas such as those related to privacy, and I was concerned that there would be a fair number of cases that would be judged as Level 3 by this way of listening. I think it would be good to have a range of possible cases such as "not applicable in principle, but may be applicable in this pattern," and I think that thinking about that will lead to a good risk assessment.
At our company, when we ask the steering committee, we make a "front clearance sheet" and submit it, but the purpose is not to make an accurate judgment on the sheet, but more as a communication tool with the steering committee, so I think this worksheet is also positioned as a communication tool.
The PIA report is like that. You have to think properly to write a report, and I think it will be very easy to use as a communication tool if you decide the items of the report.
- Secretariat: Thank you very much. This tool is also a communication tool, but by keeping this sheet as a "document of risk assessment results," we hope it will lead to continuous improvement.
It may be a completely different angle, but does the documented risk evaluation result fall under what is disclosed as an administrative document? If so, it will be a hint to the attacker, so I thought I had to be careful about handling it.
- Secretariat: At the time of information disclosure request, I think it will be treated in the same way as a normal information system design document, and parts that have security concerns will be handled in a closed manner.
For your information, in Europe, the PIA report must be published by making a "public PIA report".

(Explanation by the secretariat)

Based on the discussions so far, I would like to sort it out for now. Using the worksheet and other materials explained in Point 4-2., I think that the risk evaluation in Step 1 can somehow be made easier for administrative officials to consider. However, that judgment alone is too granular, and in some cases, even if it is judged as Level 3, from the viewpoint of fairness and privacy, a method equivalent to Level 2 should be combined with supplementary measures. I recognized that it would be ideal if the tailoring process in Step 2 could be made into a guideline that can be adjusted through the involvement of experts and support providers.
When we interviewed actual examples of study, from the viewpoint of usability, some procedures adopted methods different from those shown in the current guidelines, and we would like to be able to define such tailoring on the field side as a process well.

(Expert Opinion)

I think we need to consider whether the failure mode of identification should be considered on a tailoring basis, or whether it should be included in the risk evaluation in Step 1 in the first place. A famous example is the case of a pregnant woman in Uganda who was denied medical care because she did not have a national ID. In such cases, the lack of identification 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 think about 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 mentioned in the previous meeting, the problem with the flowchart of the assurance level determination is that there is an "If Then" but not an "Else". In the risk assessment, I think it would be good to divide it into three levels of assurance, including "what to do if you can't do something" and "what to do in other exceptional cases" in the risk assessment of step 1.
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 a record of the grounds for the judgment.
If the options are "applicable" or "not applicable," there may be a concern that the edge case will be caught. As a way of thinking, I think it would be better to ask whether there are any unacceptable risks remaining with the idea of alternative control in PCI DSS. If you do so, for example, if you want to adopt another method from the viewpoint of usability, etc., you can make a judgment on the acceptance of residual risks by taking alternative control. I think it is important to have the result of that judgment written here.
It is very important to keep it in writing. There was a discussion earlier about whether it will be open to the public, but I think it is better to share it at least within the administrative body.
The part that has been accepted and judged as a residual risk should be recorded and made public. Even if the content is organized in the administration, there is a possibility that a private business operator who cannot understand the intention may use the administrative certificate for another purpose, so I think it also has a role to prevent that.
I think 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 being applicable / not applicable is written, and I think it is also important to have them write down the specific failure mode. I think it would be good for the jurisdiction to think about what kind of undesirable things will happen when they fail to provide their own service, and to think about keeping it as a record. It may take time at first because of the pain of birth, but as you accumulate, you will be able to refer to past judgments, and I think it will lead to overall efficiency.
On a slightly negative note, how to fill out this risk evaluation worksheet, based on the discussions so far, I think it will require quite high skills. It is very important, so I think training and knowledge-sharing will be necessary. On the other hand, I think it will be difficult to create human resources specialized in this examination in each organization, so I was listening to you while thinking that Digital Agency should create a system and mechanism in which anyone can conduct risk evaluations as a base 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 of the document and the failure mode on page 12?
- Secretariat: I believe that the failure mode to be considered will probably differ depending on the administrative procedure, so I had an image of writing examples of major failure modes such as "service is provided to the wrong person" and "the service itself cannot be provided" in the guidelines, and having the degree of risk impact when the failure mode to be considered occurs in the procedure judged on the worksheet. Based on the matter you commented earlier, I think it would be good to have the failure mode to be considered written down at the top of this worksheet.
When a professional of risk analysis examines, what are the assets to be protected and what are the attack paths? He or she should make a list of them and think about an attack scenario. Around this point, a failure mode will appear, and he or she will judge the guarantee level and risk acceptance, sort out the remaining risks, and confirm the achievement of the security goal. However, even if you ask for all of them, the operation will not work. Therefore, I think that the failure mode is the one in which the jurisdiction of the administrative procedure can be written with high accuracy as a party concerned.

(Explanation by the secretariat)

As the scheduled end time is approaching, I would like to summarize it. Regarding the issue 4-2, thank you for your many opinions and advice, including the worksheet part. I would like to include your comments so that this worksheet can work.
Finally, I would like you to comment again on the pros and cons of the approach based on this worksheet. I feel that the discussions so far have generally been evaluated, but on the other hand, the secretariat is concerned that the flowchart has been deleted at NIST, and I would appreciate it if you could comment on any particularly negative opinions on whether it is okay to proceed with the policy of using this worksheet.

(Expert Opinion)

I think it's good. Once you decide, it's not the end. If you assume that you will continue to operate by actively reflecting the feedback you get while operating, you will also learn about operation.
If we ask for documentation of the study results, we have to decide on a common entry and table of contents in any case. I think the worksheet this time is one level more detailed than that. It just 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 a good idea, too. By using a worksheet, you can do something close to risk analysis for the first time, and I think you can breathe your soul into the flow chart. If you go straight to the flow chart, you'll be in a state where you don't understand well, so I think you need to sort it out with this worksheet.
These documents are necessary both in terms of keeping records and in terms of tools for communication, so I think the difference is just how to call the document.

(Explanation by the secretariat)

Thank you very much. Regarding the risk evaluation part of Step 1, I would like to proceed with the current policies. On the other hand, regarding the tailoring part of Step 2, I think we need to sort it out a little, so I will consider the opinions I received today within the secretariat and prepare to explain them as a draft of policies at the third meeting.

Closing and Next Meeting Information

(Secretariat)

Today, I participated from the middle of the meeting, but I felt that the level of the discussion was very excellent because they were really enthusiastic about the discussion and they were serious about it, and I thought again that it is important to have concrete discussions such as how to breathe in the soul and God is in the details. While listening to your point, I thought again that one or two more steps are necessary in order to put the guidelines into shape, so I think it is really important not only to bring NIST SP 800-63-4 as an imported study, but also to repeatedly think about specific threats in Japan and how to adapt various technologies, and to keep a record of the history as a document while responding to newly emerging threats. Through such activities, I hope to raise the level of security not only in government offices but also in the private sector. Thank you for your continued guidance.
That's all for today's meeting. The next meeting is scheduled for Tuesday, December 26. Thank you again for today.

(End)