Advisory Council for the Revision of the identity verification Guidelines (third meeting in fiscal 2024)

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: Thursday, December 5, 2024 (2024) from 18:00 to 20:00
Location: Digital Agency meeting room and online
Proceedings
1. Opening
2. Business
  1. Partial changes to the agenda
  2. Discussion on issues related to the appropriateness of the proposed revision of the Guidelines
3. Closing

Material

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 (Professor, National Institute of Informatics, Director of Trust Digital ID Platform R & D Center)
Takashi Niizaki (President, Cedar Co., Ltd.)
Akihide Higo (Director, TRUSTDOCK Co., Ltd.)
Hisahiro Fujie (Representative Director of OpenID Foundation)
MANSHIO Hisashi (Associate Professor, Faculty of Health Data Science, Juntendo University)
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 and Board Member, FIDO Alliance; Chair, FIDO Japan WG; Director (Board Member), W3C, Inc.)

Agenda (1) Partial changes to the agenda

The secretariat explained the partial changes to the agenda based on Appendix 1.

Agenda (2) Discussion on issues related to the appropriateness of the proposed revision of the Guidelines

"1. Introduction" and "2. identity verification Framework"

The Secretariat provided an explanation on "1. Introduction" and "2. identity verification Framework" in the table of contents of the proposed revision of the Guidelines based on Appendix 2, pages 3 to 19, and experts held a free discussion.

Expert opinion

In writing about fairness in Section 1.5, how would you describe not the object of biometric authentication, but a case where, for example, "there is a person whose fingerprint cannot be registered for some reason", and in such a case, there is a concern that fairness will be impaired (depending on the authentication method)?
In addition, I have some doubts as to whether it is necessary to mention national security in this guideline. It is possible that such systems may fall under Identity Assurance Level 3, but it is not likely that government information systems, which are responsible for ordinary administrative procedures, will fall under it. I personally think that the description of national security is not necessary, because system personnel tend to require more security standards than necessary based on the idea that "their own systems are important." However, considering the case where security is a business purpose, it would be better to describe that it is necessary to consider a higher level when conducting business related to security from the viewpoint of business execution, not from the security item.
The intention of my comment that it would be better to consider national security was based on the assumption that, for example, a legitimate passport could be illegally obtained during passport issuance procedures, which would damage the country's trust and prevent visa exemptions.
It is also related to the comment in advance that it would be better to show examples other than biometric authentication first, but depending on the work you are engaged in, there are people who cannot use fingerprint authentication because their fingerprints have been scraped. For such people, I think it is important to provide other means of biometric authentication. If it is difficult to imagine, there are a number of specific examples such as "there are cases where fingerprints are scraped and fingerprint authentication cannot be used," so I think it is good to show such specific examples. In addition, in terms of national security and skin color, even in Japan, there is a diversity of origin, so I think careful consideration is necessary. There is a point about how to express it, but I think diversity should not be forgotten.
I think it is a sensitive issue as to how much attention should be paid to the expression of what needs to be described in consideration of diversity. I had a concern that the contents that correspond to physical characteristics and disabilities would be misunderstood depending on how to write them. I commented on examples of fairness due to age differences, but I think it is necessary to consider the expressions and phrases.
For example, among eKYC, I think that identification by using a camera to take photos of documents and appearances is a method that cannot be used or is difficult to use for blind people in reality. In addition, I thought it would be desirable to show not only biometric authentication but also literacy by age and the percentage of device possession, etc., and show that there are people who are not eligible if devices are limited.
As an example, I think we can consider taking up a transient situation such as a minor illness or injury.
As a point of reference, in the standards world, the term "demographic bias" is sometimes used to refer to the occurrence of demographic bias rather than direct examples.
(Secretariat) Next, I would like to ask for your comments and opinions on the advantages and disadvantages of the cooperative and non-cooperative models and the names of the models described in Chapter 2.
In the current draft, even though the advantages and disadvantages of the linkage model and the non-linkage model are not described, the structure is such that one of the models must be selected. I think there is no problem with stating that "the linkage model should be adopted with priority", but how about stating it explicitly at the beginning of 2.2? In addition, I think that the reasons such as "why the linkage model should be prioritized" should be stated together with the advantages and disadvantages in another paragraph.
There is also a question about whether it is necessary to actively choose between the non-cooperative model and the cooperative model. In the case of adopting the non-cooperative model, since the organization that provides the service must also construct the IdP as a set, I feel that the burden on the entity that provides each administrative service is heavy. If the government can provide the service by federating reliable IDPs, the overall burden will be lightened. I think it is meaningful to explain such contents and recommend the cooperative model. If the model is just a choice, I think it is necessary to describe the advantages and disadvantages. If not, I think it is good to simply state that the cooperative model is recommended.
I was reading it with the understanding that it is a prerequisite to adopt a collaborative model. Wouldn't it be simpler to write something like "When to adopt a non-collaborative model" and only adopt a non-collaborative model if it matches it, and if not, guide them to adopt a collaborative model?
In my past experience, I have chosen the non-federated model. When I created a system that had to be continuously available even if the IdP was not available, I excluded only certain systems from the federation and adopted the non-federated model. If there are such cases in government services, it may be a criterion for adopting the non-federated model.
I believe that the policy of actively adopting the linkage model is appropriate for large-scale systems that can be seen by the public. On the other hand, it is assumed that the system scale is not so large, and the number of users is limited to a few and the budget for constructing the linkage model cannot be secured. Therefore, it is desirable to provide information on the merits and demerits so that employees can decide which model to adopt.
It does not have to be a message that an IdP must be created. I think the limit is to state that you should check if there is an IdP worth connecting to around the necessary business system. I think there are systems with different service levels. I think it is not necessary to write in a way that makes it a purpose to connect to an IdP.
I thought it was necessary to clarify that IAL and AAL, which are described before the linkage model, are "basic technologies for properly constructing the federation model."
The non-federated model could be called "legacy" or "integrated".
What about words like "standalone" and "monolithic"?
If you say "all-in-one type" or "stand-alone type", it will not be converted to Non-Federated Model by machine translation, but the meaning will be understood.
I don't think we need to insist on being translated as a Non-Federated Model. We need to coordinate terms necessary for mapping with other countries, but I would like to emphasize that the meaning is understood.
How about changing Non-Federated Model to Katakana and making it "Non-Federated Model"?
It is not desirable because it will make it difficult for the people to understand. I think you can use Katakana words that are widely known and appear in Japanese dictionaries, but I think federation is difficult.
In the Japanese localization work I am involved in, as a rule, I translate them into Chinese characters, and only when there is no corresponding Chinese character, I write and annotate them in Katakana.
In principle, it is desirable to use Chinese characters after explaining terms that can be translated correctly. It is also important to have parallel translations in order to establish concepts in Japan.
For reference, if you translate the Federated Model with the machine translation service, it will be a "Federated Model".
I would like to ask another committee member who often uses English. Is there another term that is used with the same meaning as Federation?
There may have been in the past, but I don't think we use terms other than Federation very often these days.
When I translated OpenID 2.0 in the past, I thought it was a mistake to translate Federation as "Identity Federation". The term "Identity Federation" has been used to some extent in the world, and I wanted to discuss whether the translation was appropriate.
Among the companies that I work for, we use the term "ID Federation" to refer to Federation. I think the term "ID Federation" is a term that has gained a certain level of citizenship. Recently, the term "Federation" has come to be understood, but I think the term "ID Federation" is appropriate if it is to create a Japanese word.
In the definition of terms, if we define that ID linkage is realized by using a federation technology (for example, OpenID or SAML), I think there will be no big misunderstanding.
I think the translation of Federation should be ID linkage, but it should be noted that when the word ID is used, various meanings such as Identity and Identifier are mixed.
For reference, I used to describe the Non-Federation Model as "monolithic" and the Federation Model as "division of labor". It was easy to explain as "efficiency is good because of division of labor".
In one paper, the Non-Federation Model was described as the "Isolated Identity Model." It might be good to look for words that exist in the world like that.

"3.1. Identification"

The Secretariat gave an explanation on "3.1. Identification" based on Document 2, pages 20 to 30, and experts held a free discussion.

Expert opinion

Regarding the term "identity verification documents," after the explanation that "identity verification" was broken down into "identification" and "verification of the person in question," the word "identity verification" documents before being broken down appeared again in the chapter of "identification," and I felt it was strange because of the inconsistency. I also felt it was a problem that the term "verification" was applied to both Validation and Verification.
I always say that we should use words that include the subject of certification, because the word "certification" alone does not tell us what we are certifying. In the NIST guidelines, Verification means "association with the body", so Verification cannot be used in the sense of signature verification.
As for the order of the table of contents, how about writing the overall picture of the process first instead of writing threats and countermeasures all of a sudden?
Are threats and countermeasures written first in this draft guideline because they were written first in the current guideline?
(Secretariat) In the current Guidelines, the three processes are not described in the main body of the Guidelines, but in a separate volume. As the Advisory Panel proceeded this time, one major theme was "developing threat-based response standards," so I thought I would first explain the threat and then explain the process to counter it.
I agree with the description from the threat. However, I think it would be better to clarify the content explained by the secretariat in the guidelines. In addition, I think it would be desirable to have a summary of the relationship between each of the three processes (Resolution, Validation, and Verification).
(Secretariat) In response to your comments, we have recognized that there should be an overview chart at the beginning. I believe that there are other places in the Guidelines where an overview chart should be inserted, and we would like to review them as well.
When making an overview diagram, I think it will help readers to understand by including threats in the diagram. I think it is important to be understood, so I think the order of description does not matter.
Although each component is explained in Section 2.1, readers may forget the contents of the explanation as they read the guideline. Therefore, it is recommended that the purpose and outline of each component be described in Section 3.
As stated in the first comment on page 27 of Appendix 2, I think it would be better to indicate what needs to be done for what purpose in the identification process. Also, I thought it would be more understandable if there were a diagram that would show which process is called "identification" in the entire identity verification.
As a method of risk analysis, "threats" and "vulnerabilities" are listed, and countermeasures against them are considered. However, even if the procedures are described in this guideline, I felt that it is not always easy for readers to understand.
(Secretariat) As you pointed out, in the current draft, only rough threats are listed at the beginning. However, with this method, there are some parts where specific threats cannot be written out, so we will make improvements based on the contents of the comments in the same part of the person's certification.
I thought that it would be better to describe the considerations for using postal mail, including the sending of the confirmation code, in the "Supplement to Identity Confirmation - Identity Confirmation by Postal Mail," which is outside the scope of this discussion.
Is the procedure of the identity verification method using verification codes standardized to some extent in the world? Recently, I myself have considered it, but I thought that there is a high possibility that it will be used incorrectly if the risks and processes are not carefully confirmed. I doubt if there is any knowledge in the world about the method of authenticating by sending verification codes.
There are cases that even general companies send confirmation codes by mail.
It is probably to confirm the address.
In that regard, when we use the word identification, I feel that the perspective of "what do you want to confirm" by identification is important.
I believe it is necessary to state that sending the confirmation code does not mean that it is enough to simply send the number, and that confirmation and tailoring of the mission is necessary.
As for the means of mailing, it is necessary to pay attention to whether there is a legal identity verification effect or not. For example, private services that do not have a laws and ordinances effect cannot be used for identity verification in administrative procedures, although person-only mail is regulated in the.
There may not be any legal regulations, but the services provided by some private companies are considered to be equivalent to those of person-only mail. When using confirmation codes in cases where person-only mail cannot be used, considerable ingenuity must be used in consideration of these points, and in such cases, tailoring is important. If you write it in an easy-to-understand way, it will be used without sufficient confirmation, so I thought it was necessary to write it carefully.
When we created OpenID Connect for Identity Assurance, there was a postal debate, and we used the abstract term Secure Mail.
In foreign countries, it is written separately from ordinary mail and Secure Mail which sends legal documents.
Secure Mail is similar to Japanese registered mail, and it is traceable. It should be noted that what kind of mailing method Secure Mail refers to differs from country to country. When just sending a verification code, we confirm the reachability of the address as attribute information, and in the case of receiving mail only for the person himself, Identity Verification is performed by ID, so it is a completely different nature. In addition, I felt that it is extremely difficult to make a tailoring, including whether or not to add a forwarding prohibition.
I thought it was necessary to keep in mind that the word "Mail" might be misunderstood as "e-mail".
(Secretariat) The current draft does not include the content you just discussed, so in addition to expanding the content, we would like to consider changing the position of the confirmation code depending on the situation.
In the discussion point (2), "Explanation of methods whose strength varies depending on various factors", I think the description itself is necessary, but for the reader, it becomes "What should I do then?" There is no clear solution, but for example, NIST has written about the "necessity of training". I think it is difficult to describe uniformly even in this guideline, but I thought it would be better to go into some kind of guideline and made a comment.
No matter how much training is conducted, there is a risk of variation, so if it is not acceptable, it would be desirable to state that it is better to use a digital method.
I think it is desirable to clearly state in the guidelines that "it is important to systemize in order to eliminate various factors" by giving an example such as My Number Card's authentication machine.
In summary, it is meaningful to write that training must be conducted in depth, but if the risk of variation cannot be tolerated, it is necessary to write that it should be systematized.
Wouldn't it be a good idea to include the fact that "there will be variations" as a threat in advance?
I think you can be proud of the fact that you can make a strict My Number Card instantly with the identity verification information and face photo on the IC chip.

' 3.2. Certification of the person in question'.

The secretariat explained "3.2. Certification of the person concerned" based on Document 2, pages 31 to 51, and the experts held a free discussion.

Expert opinion

I don't think it's a good idea to translate Authenticator as authentication "information"; it could be taken as data.
If it is "authentication information", it may be considered as "credential", and it may be considered differently from the meaning of Authenticator.
I am aware that there are arguments that we should no longer insist on the three elements of authentication. There is also a movement to define authentication elements from a new perspective. On top of that, I thought that it would be a little too aggressive to delete the three elements of authentication now, assuming the readers of this guideline this time. The three elements of authentication include authentication using a living body, and it is important to possess it, and if the possession can be guaranteed, it can be an effective countermeasure against phishing attacks to some extent, I can simply explain. No matter how many times knowledge authentication is repeated, it will be phishing. I think it is better not to delete it immediately and to continue using it.
Regarding one time passwords for e-mail, some customers still use e-mail with care. Considering the current situation, I think some people may consider e-mail addresses as possession. On the other hand, the problem is that attackers use e-mail addresses and aliases that are easy to obtain. From that point of view, it is clear that e-mail addresses have less of an element of possession compared to SMS. In addition, one time passwords are not possession and are not resistant to phishing. I think it is necessary to clearly write that one time passwords using e-mail addresses are not possession authentication.
Regarding the consultation point (4), "Phishing Resistance Requirements for Personal Authentication Assurance Level 2A," NIST is still in the draft stage and does not intend to strongly insist that "it must be used," but we would like to actively promote the point of giving users a choice. Recently, attacks have become more advanced, and phishing has been targeted in places where it has not been targeted before, so I think it is desirable to strongly promote measures against phishing.
I have a question about how to solve the bootstrap problem if one time passwords using e-mail are not considered possession authentication. This guideline does not describe the registration process of the Authenticator, but I think it may affect it. After describing the registration process, I think it is necessary to consider whether it is consistent or not.
As far as I understand, the description in NIST's AAL2 that e-mail is not physically bound is just a definition in AAL2. I think that the description that e-mail is not considered to be owned because the possession of e-mail is diluted is a bit aggressive. However, the credentials for accessing e-mail are eventually the same as the knowledge element that you are trying to use, and it is not easy to operate and confirm that the possession element and the knowledge element are "disjoint". It is true that the risks are different, so if you can express the level such as level 2 plus or level 2 minus so that you can understand it, I think it is acceptable to describe it together with each risk.
It is necessary to distinguish between an attack that steals and uses the user's own e-mail address and an attack that prepares a new e-mail address. SMS is difficult to occur because it is a phone number and cannot be obtained without a contract, but e-mail addresses are easier to obtain, so it is important to consider both.
Readers will not be able to distinguish between two risk scenarios: a takeover of an existing account and the creation of a new account by a person with malicious intent, unless this is stated intentionally and explicitly. Usually, I would focus only on account takeovers. I think it is common to use a mobile phone address as a key to prevent the registration of multiple accounts, which is often used in campaign applications. On the other hand, one time passwords using an email address are assumed to be used as a means to confirm whether or not the person is the person, regardless of whether or not the person has malicious intent, and it would be good to state this as a means, although there is a risk.
I think it depends on the mission whether the risk is acceptable or not. Now that many systems have come out with My Number Card documents that can firmly confirm identities like identity verification, I wonder if there are any procedures within the administrative services that can accept such risks. If we make a distinction at the timing of this revision, we may be able to withstand the threat until the revision in a few years.
I agree with the idea of taking measures against account hijacking in the identity verification process, but I think we can distinguish the malicious creation of multiple new accounts by taking measures in the identity verification process.
Section 2.1, "Outline of Identity Confirmation", states that "Applicants who wish to use procedures and services are uniquely identified by collecting their attributes." On the other hand, we believe it is necessary to state that it is necessary to avoid a situation where multiple accounts can be created by using a free email.
In the current discussion, there are many meanings in the element of "possession." Rather than eliminating all three elements of authentication at once, I think that it is necessary to separately deal with detailed threats such as the possibility of copying Credentials among the possession. The absence of the description of Credential Management Phase is one of the characteristics of NIST SP 800-63, but I think that the threats and countermeasures related to Credential Management Phase should be dealt with as part of "identification".
NIST SP 800-63-4 2nd PD's Syncable Authenticator also stuck to the concept of ownership, which is that information is contained in a certain device, but even if it is synchronized in the cloud, if the cloud is secure and shared among its owners, it can be considered phishing resistant and equivalent to possession. I thought it would be simpler to understand that e-mail addresses and SMS one time passwords are only knowledge authentication and not property.
How about writing the point that the cost of obtaining an e-mail address is too low in the Resolution of the identification? I think it is related to the threat of "insufficient identification", and I think there is a problem in trying to "identify" with an e-mail address that is only an attribute.
Assuming that the readers of the guidelines are general administrative officials, I think it will be difficult for them to fully understand such detailed stories. If it is an administrative procedure, I think the procedures that can be assumed to some extent will be limited. I thought that risks could be reduced by giving examples of methods at the same time as stopping sticking to the three elements of certification.
If I show an example, it is assumed that there will be only tailoring. If an amateur tries to do tailoring, he or she will do tailoring that is not appropriate, so I think it is necessary to write a warning.
I think that the content of the three elements of authentication may change, but the authentication information seems to be independent of each other. In the future, the number of axes may change, but at present, it would be better for you to be aware of the three elements. If you are no longer aware of the three elements of authentication, it is conceivable that you will try to do something with only one element, such as two step verification, instead of two-factor authentication. Since there are various administrative procedures, I think that tailoring will inevitably occur.
At the last fiscal year's Advisory Panel, I heard that it was the contractor that actually operated the system, and that public officer would supervise it.
I believe that the confirmation of the e-mail address at the time of issuing the Credential is not a personal authentication, but one of the identification processes. What attributes must be collected at the time of identification varies from mission to mission. First of all, it is important to determine what information is required at the time of identification.
E-mail addresses have group addresses, and there are operations that are not tied to one entity. It is difficult to detect, and I think it is necessary to state whether the risk can be tolerated in the mission execution as a point of discussion.
In practice, if you can't use e-mail as an Activation Factor, I think you have a pretty big problem.
For practical purposes, how about describing the points of tailoring in a separate volume? It seems impossible to explain everything in this book.
I think it would be good to describe the risks by combining incidents and tailoring, and to call for attention when actually doing it.
If the account recovery is weakened, it will become the starting point of an attack, so I think you have to be careful. On the other hand, in the case of a person who has passed away, is unable to operate on his / her own, or is unconscious, etc., I think it is necessary to consider what to do as an administrative service. It is assumed that a response will be taken by someone other than the person himself / herself so that it is clear that the person is not the person himself / herself.
In NIST SP 63-63-4 2nd PD, the Authenticator binding was also listed side by side with the account recovery. When it comes to two elements, I think it is necessary to organize Post Enrollment Binding, etc. 800

' 3.3. Federation'

The Secretariat gave an explanation on "3.3. Federation" based on Document 2, pages 52 to 59, and experts held a free discussion.

Expert opinion

I'm in favor of writing federations as a uniform standard, and I think if you leverage OpenID Connect and SAML in the right profile, you're at the right operational level.
I'm close to that opinion, too. The three levels of NIST are, after all, CSRF-capable, CSRF-incapable, and Holder-Binding-capable. I don't think "CSRF-capable" is necessary because it's not acceptable at this point. I don't think Holder-Binding can be implemented (in a common way), so I hope it can be added in the future.
I don't think there is a need to forcibly divide them by level.
I think it is meaningful to list the threats and describe the countermeasures because the federation can be an entry point.
In the actual operation of the federation, I think that skilled personnel will deal with it by forming a trust framework, so I don't think you need to be so nervous.
I wonder if they really have the skills. As SaaS is also increasing, there are cases where IDPs are set up and connected by imitation, and there are a wide variety of them.

Closing

(Secretariat) That will be all for today's meeting. Thank you again for your time today.