Advisory Panel for the Revision of the identity verification Guidelines (1st meeting in FY 2024)

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 and time: Tuesday, September 17, 2024 (2024) from 18:00 to 20:00
Place: Digital Agency meeting room and online
Order of business
1. Opening
2. Proceedings
  1. Explanation of the outline of the meeting
  2. Discussion Points for the Revision of the Guidelines
    - Items to Consider Incorporating from NIST SP 800-63-4 2 pd
3. Adjournment

Material

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 Hiroyuki (Professor, National Institute of Informatics (Director General, Trust Digital ID Platform R & D Center))
Taku Niizaki (President of Cedar Co., Ltd.)
Akihide Higo (Director of TRUSTDOCK Co., Ltd.)
Hisahiro Fujiei (Representative Director of OpenID Foundation)
Hisashi Mitsushio (Associate Professor, Faculty of Health Data Science, Juntendo University)
Toru Minai (Deputy General Manager, Market Research Office, Innovation Management Department, Japan Credit Bureau, Ltd.)
Koichi Moriyama (Chief Security Architect, NTT DoCoMo, Inc. , Member of the Board of Directors of the Executive Council of the FIDO Alliance, Chairman of the FIDO Japan WG, Executive Director (Board member) of W3C, Inc. )

Opening address

Secretariat

The Advisory Council has entered its third year. Thank you for your support every year. The 2nd public draft of NIST SP 800-63-4 was released, and this year will be the final year of the Advisory Council.
Regarding the proposed revision of the guidelines, first of all, we would like to reduce the number of pages as much as possible. I feel that there is no need for this guideline to have a large number of pages. We would like to use easy-to-understand diagrams and write in easy-to-understand Japanese that can be machine-translated. By writing in simple Japanese, it will be easier to translate and will be read by people from various countries. In addition, in the part before the table of contents, we would like to state that "The higher the assurance level, the better." Since the percentage of people who read the table of contents and subsequent parts is low, we would like to state at least what we want people to read. Regarding the adoption of standard technology, we are taking Public-Private Partnership into consideration, so we would like to state that the part specific to administrative agencies and the part that is not so can be clearly distinguished. We would like to include the item of Acknowledgement. It was not a guideline until now, but I would like to state those who contributed by taking requests and making comments. In addition, in order to reduce the number of pages, we are considering creating a separate volume if necessary. We would like to create it while paying attention to the above points.
As in the previous fiscal year, I would like to thank all the members who have deep insights into each of them for coming together. As for identity verification, I understood that in the past few years there have been rapid environmental changes such as the emergence of FIDO and passkeys, as well as various attacks, but I did not think that it would attract this much attention from the public. SP 63-63-4 The 2nd public draft (2 pd) was released later than scheduled, but I would like to catch up with 63-4 and hold discussions looking ahead to the next 5-10 years. I expect discussions that will not only determine Japan's rules but also contribute to what the world is troubled about. 800

Agenda (1) Outline of the meeting

The secretariat explained the outline of the Expert Panel based on Material 1.

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

The secretariat explained the points of today's discussion based on Material 2, and the experts held free discussions.

Opinion of experts

Regarding "③ Identity Proofing Roles / Types," it describes what the Proofing Agent must do when determining the authenticity of an identity document, and the need to train the Agent as well. I feel that perhaps it is necessary to give some examples of what kind of attacks have occurred to those who use the guidelines.
Is it an image that exemplifies attack methods that can actually occur or have occurred in the past?
Yes. It is not necessary if the authenticity is determined mechanically, but I think it would be desirable to have an example of what to check when looking at the physical face of the ticket at hand while the reading of IC chips is not widespread. Overseas, it is said that the person in charge of checking ID documents is educated about what kind of attacks can occur.
Regarding the phishing resistance of AAL2 in (5), I feel that phishing attacks are an unavoidable issue from the viewpoint of business operators. On the other hand, I feel that it may be difficult for financial institutions to introduce FIDO and passkeys again depending on their financial circumstances. I feel that it is necessary to write as a requirement, but as a practical matter, how far business operators should respond to phishing remains a concern.
We are also concerned that the implementation of measures to prevent phishing may lead to attacks in different places, especially in account recovery.
At the NIST seminar, it was clearly stated that account recovery is possible if three people you know guarantee it, but Facebook has done away with that method in the past. I guess that's because they used that method and an attack occurred. I think we need to pay attention to that.
If you send the code to three friends and use it to recover the account, you will fall into that authentication level. I feel that the problem is that the authentication levels are not consistent between account registration and account recovery.
In 2 pd, the method of account recovery was described for each AAL. I feel that the stance of considering the method of account recovery for each guarantee level is very good. I feel that it is good to consider describing the recommended method while referring to the contents.
Regarding "④ Renewal of IAL1 and review of IAL2", regarding IAL, it is said that IAL1 can be certified with one Fair Evidence, but the requirements for Fair Evidence have been strengthened, and I feel that it is not always necessary to collect this much information in IAL1.
I agree with you. In the initial public draft (ipd), if it is the same person as the person who received the application before and it is not necessary to verify including the core attributes, it was IAL0. In the identity verification Guidelines, it would be better not to follow it and leave IAL0.
In 2 pd, the word of IAL0 itself is deleted, but it is embedded in the text, and I think there is a high possibility that it will not be noticed. It is assumed that the administrative field will be used only from IAL1 and above, but it may be better to describe it in a way that is easy for readers to understand, considering that it will be referred to from the private sector.
If we proceed with ID documents used in Japan in mind, it will be possible to classify them in accordance with the current situation in Japan.
I agree. In the United States, there are many ID documents that cannot be used for identity verification. Therefore, I do not think there is a need to follow the United States in classifying IAL levels. I think it is appropriate for the Japanese government to consider how to implement My Number Card for citizens who do not possess identity verification.
With this revision, I feel that IAL has become easier to incorporate into Japan. Before the revision, the Evidence required for IAL3 required two Superior Evidence pages, which no one could achieve. To correct this situation, it was revised to one Superior Evidence page. In response, I believe that IAL1 and IAL2 were revised to differentiate IAL2 and IAL3.
In 2 pd, evidence with a photo is listed as an or condition as Fair Evidence, but in Japan, for example, it is an image to discuss whether a copy of the resident record is equivalent. The resident record has a certain degree of physical measures, a reference number, and no face photo, but it can be confirmed to some extent if you make an inquiry. In this way, it may be good to consider while thinking about an ID document that can actually be used.
Regarding the Fair Evidence, when I talked with the TSA in Washington D.C. last week, I heard that the certificates issued by the UNHCR to refugees fall under IAL2 according to the NIST standard. From the viewpoint of equity, the Tribal Certificate issued to Native Americans had to be changed to IAL2. I feel that there is a contradiction that the certificates issued by the UNHCR have not been verified for Core Attribute, but this is the situation in the United States, so I will leave it aside this time. I feel that these arrangements will give us a clue on how to implement My Number Card for Japanese nationals who do not have identity verification.
For example, there are citizens who do not have any identity verification documents with a photo after returning their driver's licenses.
You can receive a Driving Career Certificate when you return your driver's license. Is it considered equivalent to a driver's license?
There is a photo on the Driving Career Certificate, but it doesn't have an IC chip.
You also need to think about the confirmation of eligibility on your health insurance card. That's right about the IC chips on your Driving Career Certificate.
Technically speaking, it should be difficult to forge the face of an IC card that has been shaded with laser engraving. However, it is necessary to take into account that it is possible to forge the face of an IC card that has not been shaded with laser engraving by removing the printing on the face of the card with acetone and reprinting it using a thermal transfer printer.
Regarding account recovery, we have discussed how much we should confirm in the event of a disaster. Doesn't NIST have such a description?
While NIST does describe the means of account recovery, it does not describe its risks.
I feel that there is a big psychological barrier to implementing a strict confirmation of appearance. If the machine only sends out an alert, there will not be a big problem. However, I feel that it is difficult to request a work to implement a strict confirmation of identity by carefully comparing the face with the photo on the identity verification document.
As a national guideline, is it possible to make it easier for on-site personnel to confirm facial features if they include a statement such as "remove your mask" when confirming facial features?
Privacy and human rights issues need to be taken into consideration, but as a business operator, if there is a statement in the guidelines to confirm appearance, it will be easier to operate.
As a way of thinking about risk management, I think it is necessary to identify accounts that have not gone through a formal process, such as "removing the mask", as high-risk accounts.
I think there are many similar processes in the world for responding to risks, such as passing through a machine or making a videophone call to a person in charge when there is doubt.
In 2 pd, there were a lot of descriptions about Promoting Agent and Trusted Referee, but there were also a lot of descriptions about Applicant Reference. It was also written about handling exceptions related to these, so I felt it was necessary to reflect it in the identity verification Guidelines.
Applicant Reference is important, isn't it? I feel that it becomes necessary especially in the case of disaster response.
In 2 pd, I recognize that the reorganization of roles related to Applicant Reference is a major change. However, it is not required in the identity verification Guidelines so far, so I think we have to think about how to reflect it in the identity verification Guidelines. In addition, I think that each role cannot be achieved unless it is prepared including training.
There's not a lot of talk about the Process Assistant.
In order to achieve mission delivery, Trusted Referee and Applicant Reference must be defined. If an Applicant Reference colludes with a malicious person, anything can be done, so how to translate it into guidelines is considered to be difficult.
It was a long time ago, but in Canada, Applicant Reference was carried out by public servants.
In countries where all schools are public, all teachers are public servants, and in countries where the health care system is public, primary care doctors are public servants, so it may be easier to implement in such countries.
In the case of Germany, it is considered that post office workers are applicable. In the case of Trusted Referee as a business operator, I think how to train will be a problem, but it is not easy to create an image of realization.
In 2 pd, we recognize that various descriptions have been added and modified, from those that are often discussed in the industry to those that are not yet discussed. Which definitions have been discussed for (2) Risk Management review and (3) Identity Protecting Roles/Types?
At least, ③ Trusted Referee of Identity Protecting Roles/Types has been described since ipd. There was a certain discussion in this revision, and the description seems to be more refined.
In ipd, the Trusted Referee was a kind of Promoting Agent, and could be the same person.
The ipd stated that Trusted Referee is one of the Agent's roles.
I think that it is very good to clearly define and describe each Role like 2 pd, because it clarifies what we do as a business operator.
At the time of 64-3, it was clearly stated in the final FAQ that "there is room for discussion," and it was stated that the distinction between IAL and AAL would be meaningful in the future. In compiling DS-500, it may be meaningful to include contents that are somewhat challenging but will be considered in the future.
Especially when it comes to the wallet model, which I think is in a completely immature state.
In that sense, we recognize that discussions must be conducted on the premise of a schedule for when the guidelines will be revised. There is no problem with reference by the private sector, but administrative officials must comply with the contents of the guidelines, so we need to take that into consideration (if challenging contents are included). In particular, regarding wallets, we recognize that various discussions are taking place in Digital Agency, but I think that we also need to take into consideration how they are implemented in the world.
In the initial forecast, the final version of 63-4 was expected to be released early, but it is far behind the forecast. We must not rely too much on the NIST schedule and proceed with the revision of the guidelines. Just as we are swayed by the NIST schedule, I think many people will be affected by the revision schedule of the identity verification Guidelines. Also, for example, we should consider releasing what is being prepared and accepting pull requests.
Revision of the identity verification Guidelines will be necessary for a long time to come, so I think it would be good to decide at least when to revise them.
In that sense, taking into account the upcoming revision of laws and ordinances related to the card substitute electromagnetic record, we believe that it is necessary to consider modularizing DS-500 and releasing a revised version as soon as possible regardless of SP 800-63-4.
Isn't it more important to adopt the issues that Digital Agency is aware of than to consider whether to adopt what comes out of NIST from time to time?
I was impressed that the 2 pd changes were compiled in such a short period of time, but I was frankly a little surprised that a lot of content related to wallets was included as shown in (1), (6), and (7) on page 3 of the document. In last year's discussion, there should have been a discussion that the wallet model could be considered as a separate framework, so I have a little doubt about whether it is necessary to go this far and consider reflecting it in the identity verification Guidelines.
Regarding (5), the strengthening of the phishing resistance requirement of AAL2, it may sound biased in terms of position, but phishing damage cannot be prevented even in two step verification, and many damages have occurred. However, as I reported last year, there are multiple examples where the occurrence of damages has been suppressed as a result of making FIDO mandatory. There was talk that it was difficult to implement, but from the perspective of protecting citizens from damage, I think that the revision of NIST to provide phishing resistance options in IAL2 is a wise decision, and I think that it should be referred to in the identity verification Guidelines. On top of that, regarding account recovery, I think it would be better to include the contents that we were able to discuss well last year.
I understand that there are discussions about the requirements for wallets of ⑥ and ⑦, but I think they can be treated as a separate volume.
In identity verification, I feel that it is important to emphasize the confirmation of appearance and to convey the assurance of phishing resistance in authentication.
As you mentioned, the content of the wallet is described in the revised content of 2 pd, but I think that "credentials" are more important than "wallet". If we mainly reflect the story of the wallet, that may become ambiguous. In the identity verification Guidelines, I think we can focus on how to handle "My Number Card equipped with a smartphone". In that sense, I do not think it is necessary to define the wallet model of (1).
Of course, the case of obtaining credentials and attributes from a wallet can be assumed, but I thought it would not be necessary to define it as a "model". Also, regarding (6), I feel that it was written with the intention of using mDL for authentication due to the unique circumstances of the United States.
Looking at the NIST IAM roadmap, I could see the intention to use mDL for authentication as the background of introducing the wallet model in 2 pd.
As the experts said, I felt that it would be better not to include wallets in the main part of the identity verification Guidelines by force, but to summarize them in a separate discussion paper. On the other hand, how to handle identity verification by "Card Substitute Electromagnetic Records" stipulated by law in the Guidelines is an urgent institutional issue.
JPKI will be used for both iPhones and Androids anyway, so for the time being, I think it's OK to think on that premise. On the other hand, if identity verification is to be approved for the card replacement electromagnetic record alone in the future, it is of course necessary to consider how to describe it as a guideline. Regardless of the wallet model in EUDIW and SP 800-63-4, how to treat the card replacement electromagnetic record under Japanese law in the identity verification Guidelines, I thought it would be a different discussion.
Basically, I feel that it boils down to the Identity Evidence story of what is in the identity document.
I think that the strength of what is written in the ID document and how it was issued, and the strength of how the data extracted from the ID document is transferred, should be written in 63C, but if we keep that in mind, we probably won't need to mention the "wallet" itself.
From a general user's point of view, I feel that the IdP (Issuer) comes out with a card and shows it to the RP model is intuitively easier to understand, while the wallet model is more difficult to understand.
We realized that it may be easier to understand from the user's point of view if we understand it from the perspective of "credentials." It may be difficult to specify and implement the system, but I felt that it would be easy to understand as a guideline.
For the DS 500, I think that the specific credentials of "My Number Card" will be treated in the text, so I felt that it would be good to embed the smartphone installation in the guideline in the same way.
Isn't it important to define it as "something using an electromagnetic record" or "something bound to a device" rather than a specific means?
Yes. I think it would be ideal if the content could include things that could be implemented in the future without naming specific means of realization.
In order to do that, I think the requirements should be stated in the form of "Be compliant with this Threat", for example, "Be compliant with Credential Duplication Attack".
Regarding the means, we need to consider the next My Number Card as well, and I recognize that the specific means in the guidelines will need to be explained and updated as needed. Therefore, we have no choice but to publish the guidelines as a normative document and then publish reference information on the specific means as an informative document. At the beginning, I stated that this year is the final year, and I recognized that we must continue to hold discussions on the parts that have been codified.
Ideally, I feel that we need to have active discussions within a larger identity community and think about when to move forward as a community.
The current identity verification Guidelines received the most inquiries in the risk analysis part. At that time, it was based on the draft phase of SP 800-63-3, and there were some inquiries caused by that. I am worried that it will be the same this time.
Regarding the risk analyses in the current guidelines, I feel that they were written in a way that would be easy for experts to understand. At the expert meeting last year, we discussed that it would be better to prepare a collection of case studies in the form of a separate volume because not all events can be described in the flow chart, and whether it would be better to set up a risk analyst in Digital Agency.
Will the risk analyst be placed in Digital Agency or in the local government? I would like to start a discussion on what and how much should be prepared when implementing these guidelines in society.
From the perspective of making risk management easier, we would like to reflect the Define the Online Service part of this revision in DS-500.
The changes on page 8 include (Step1) the addition of Define the Online Service and (Step 5) new metrics to be collected by Continuously Evaluate & amp; Improve.
I feel that having the metrics explicit makes it easier to understand what needs to be done.
(Step 5) Regarding Continuously Evaluate & amp; Improve, although it is normal from the viewpoint of the Risk Management Framework of the United States, I am concerned whether this culture will take root in Japan. Once you decide, I think it will be fixed.
I think there are many people who are not convinced without a flowchart. For example, if you use a flowchart without thinking about it, there will be strict requirements, but if you analyze it in detail, the requirements will be adjusted. That may be a way to think about it.
For example, NIST SP800-60B predefines CIA (Confidentiality / Integrity / Availability) for each federal job. I don't know if it is actually used, but I think it is very easy to understand, but when I tried to do it, it was very difficult.
It is the same recognition. In the past, when we conducted business risk analysis, we thought that all value flows and data flows could be expressed in a graph structure, but in the end, we did not express it in an easy-to-understand form, and in the end, we described it in a specific business. We think it is necessary to describe it in a form that can be imagined specifically.
If you look at the tables listed under 60B, you will see that few are classified as moderate or high, and most are classified as low. In general, agents tend to estimate the risk of their work to be high.
I feel that it is easy to happen in the culture of the government office. I think that it is easy to become excessive security by conducting risk analysis by people who are not in charge of the site, with the idea of "because I can not take responsibility when something happens".
I feel that there are many people who think, "It is better to implement the highest level of security." The purpose is to prevent anything from happening, and I think that conducting risk analysis in the center is likely to lead to over-security.
It may be better to conduct a centralized risk analysis, but as soon as the person in charge is replaced, it becomes a strict standard, and as a result, it may become a standard that no one observes.
It would be better to have a few patterns that can be mapped, rather than building them from scratch or using the same criteria for everything.
For example, I think it would be good to think specifically about what the work of IAL1 is.
Originally, the tax office operated under the concept of IAL1. The idea was that if there was an error, an amended return should be carried out, and identity verification was not carried out. I think this was the result of risk analysis at the site.
I feel that it is necessary to understand that it is not to conduct a perfect risk analysis once, but to make it appropriate over time. Our company began to conduct risk analysis in 2021, but at the beginning, there were some places where it was a little too much judgment. As a result, the operation of the site became difficult, and it was gradually adjusted.
As other members said, I don't think we can make continuous improvements without collecting data. First, if we make improvements focusing on data, I think no one will be able to complain when we make improvements. For the sake of guidelines, it is not necessary to collect data on all authentication systems, but how about obtaining data on the typical part of authentication?
I think it's good. I would like to state that we will do maintenance based on the data.
For this reason (Step 5), we recognized that it is important to describe the metrics that should be collected by Continuously Evaluate & amp; Improve. We believe that it is necessary to have people understand that data acquisition is necessary to realize continuous improvement. I feel that the private sector has not done much on this point.
I think it is a very good initiative. In the past, it was said that the service became difficult to use intuitively due to the strengthening of security. I feel that it is in a very good condition that we are able to actively confirm and discuss instead of sensory and personal evaluation because we improved it by using numbers in the examination based on data.
Thank you very much for the very meaningful discussion. With five minutes remaining in the plenary session, I look forward to hearing from you if you have any comments throughout.
Regarding "sending a code to an address" as described in the reform of IAL1 and the review of IAL2 in Individual Issue ④, there is only a description of sending a confirmation code to a verified address, but there is a concept that NIST does not have, such as identity verification Post, and I feel that it is necessary to discuss whether it is better not to write it in the guideline. I think there are only a few companies that can actually implement it.
Will a business that can do that become some kind of Trusted Referee?
Yes. In the end, the person in charge will go there with the confirmation code and make a identity verification for Onsite in some way.
In Japan, the postal service plays an important part in the identity verification process. The reliability and delivery of the postal service are different from those in the United States. For example, in Japan, forwarding is possible when moving, but it is not possible in the United States. I think that a separate consideration is necessary based on such risks.
I would like to ask NIST how they view the risks to address sales and address lending.
Regarding mail, in addition to how to handle it as a confirmation code, I feel that methods such as sending it to the address on the Basic Resident Register by the local government, signing and sealing it, and returning it with a copy of the identity verification document enclosed will remain for the time being. I feel that it is necessary to consider how to handle it, because if all mail is sent as a mail to be received only by the person himself, the cost will increase.
I think that it should be described as a physical means to bind to digital.
Regarding the handling of mail, it was pointed out at the expert meeting last year, and it was listed as a future consideration in the interim summary. The secretariat is also conducting consideration, and we are preparing to present the results of consideration together with the revised guideline at the third and fourth expert meetings.

Adjournment

Secretariat

This concludes the plenary session. Today's minutes will be sent to each committee member within two weeks from today, so please check them. Thank you very much for the long discussion today.

(End)