Advisory Council for the Revision of the identity verification Guidelines (fifth 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: Tuesday, February 27, 2024, from 18:00 to 20:00
Location: Digital Agency meeting room and online
Agenda:
1. Opening
2. Business
  1. FY 2023 Interim Report (Draft)
  2. Additional discussion of issues
3. Closing

Material

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))

Explanation of the opening and outline of the meeting

(Greetings and Secretariat Briefing)

Now, I would like to begin the fifth meeting of the Advisory Panel on the Revision of the identity verification Guidelines. Thank you for taking the time out of your busy schedule to gather here.
There are two main points that I would like you to discuss today. First, I would like to ask you to confirm the "2023 Interim Report (Draft)," which was prepared based on the previous discussions. Second, I would like to ask you to discuss points related to the Federation, which I have added this time.

Agenda (1) FY 2023 Interim Report (Draft)

Based on Appendix 1, the secretariat explained the results of the current study on the FY 2023 interim report (draft), and experts held free discussions.

(Expert Opinions)

Revision point (1): The scope and name of the guideline were changed / Revision point (2): "Basic concept" such as mission execution was explained.

The Secretariat explained the points to be revised in the materials and the "Items for Future Consideration" that summarize the discussions so far, and confirmed additional opinions from experts.

I don't think we were able to discuss much about identity verification documents other than My Number Card at this meeting. According to the NIST's concept, the evidence strength for each certification is clarified and the assurance level is determined by the combination of them, so I think it would be good if we could have a subsequent discussion with care so that the discussion doesn't end up with My Number Card.

Revision point (3): Definition and explanation of the framework of identity verification

The secretariat explained the results of the review of the materials and the "Matters for Future Consideration," which summarized the contents of the discussions so far, and the experts held free discussions.

The model is well organized, and I feel that it makes it easier to notice problems. First of all, I think it is better to specify the attribute provider. The IdP in the wallet model is the wallet, and the box labeled "ID provider" in this figure should be considered as an attribute provider, not an IdP. The wallet model and the authentication linkage model are very similar, and by specifying the attribute provider, I think the difference becomes clear.
As for the usage of terms, I was concerned about whether the term "RP" is used even in the non-authentication linkage model. In addition, the terms such as Issuer, Holder, Verifier, and Credential in the wallet model are used in different meanings from those in NIST, so I felt that it would be good to reconsider the names of terms while considering the overall consistency.
- Secretariat: If NIST SP 63-63-4 is published with a vague definition of terms, what action should we take? 800
- Expert: Even if the definition of NIST is vague, I think it is necessary to define it properly in preparation for creating a correspondence table for interoperability with other countries.
On page 22, there is a description of "a model in which Issuer and Verifier can be separated", but I think it is more accurate to say "a model in which Verifier information can not be passed to Issuer".
The word "person" is used in the "identification" on page 18, but please note that the meaning of the word "person" in the person authentication is different.
The wallet model focuses on the verification of credentials, rather than identity verification, and verifies issued certificates with signatures because the matching of attributes alone is insufficient to validate them. Therefore, we believe that there is little need to forcibly include them in this revision.
It was said that the term "authentication linkage" would be included in "future considerations" and sent ahead, but I feel that it is OK to replace it with the term "ID linkage" in this interim report.
In the wallet model diagram, the Verifier is also written in the Issuer box, but if this Verifier means to "verify the person", I thought it would be necessary for the Issuer frame as well. Also, I felt that "Verify" in the sense of verifying by passing a Verifiable Presentation should be separated from "Verify" in the act of verifying the person because it simply means to verify credentials.
Since Verify, which verifies credentials cryptographically, and Verify, which performs personal authentication at NIST, are two different things, I don't think we should put them in the same category as other models in order to prevent them from being mixed up and discussed. There is no doubt that the wallet model is a model that we should pay attention to in the future, so I think we should consider describing it separately from the authentication linkage model.
I felt that the reference to the wallet model in this material would be taken by readers as an addition influenced by the DIW (Digital Identity Wallet), which is being considered in parallel in Digital Agency, but what is the reality?
- Secretariat: The wallet model in this document has been arranged in preparation for the addition scheduled in NIST SP 800-63-4 Second Public Draft. It was not affected by the parallel DIW initiatives, so we recognized that it was necessary to provide a proper explanation on that point.
It might be better to include the terminology and make it clear that it is positioned separately from the other two models.
Regarding the description on page 24, if there is no clear use case for accepting authentication results and attribute information from the private sector at this point, I felt that it would be a simple matter to delete the description on page 24.
In the work I was involved in, I realized that there was a certain rate of data input errors, and I strongly felt the possibility of collaboration of private sector attribute information, so I was pleased by the presence of 24 pages.
Based on the discussion so far, a strict guarantee level is defined, there is a Verifiable Credential of Issuer issued from there, and it is very meaningful to realize disclosure of only what is necessary for authentication, so I think there is no problem with the existence of page 24 itself.
Regarding the second point on page 24, the description of the trust framework is necessary not only for cooperation outside the government but also for cooperation within the government, so I think it would be good to reconsider the description. Even when the wallet model is illustrated, the addition of an attribute provider is effective because it clearly positions the identity provider and shows that there can be multiple authoritative sources.
In terms of the trust framework, there are use cases that are expected to be realized, such as making the Common Research and Development System for the Cabinet Office and Ministries (e-Rad) available for university IDs, so I would like to leave the red frame on page 24 unchanged.
I think it will change depending on how you use the attribute provider. I think it is good to include it for future use, but not all attribute providers perform the same level of identification, and there are cases where different authentication is required as a prerequisite for providing attributes, so I felt that it is necessary to review the description.
Regarding the wallet model, I remember that in the previous discussions, we were supposed to pay attention to how it would appear in the NIST SP 800-63-4 Second Public Draft.
- Secretariat: As a result of examining the current draft from the viewpoint of the future period until the publication of the revised version, the frequency of review after the publication, the life of the revised guideline, etc., the result is based on the opinion that it is better to include it in this revised version.
Time span also needs to be taken into consideration, and I think it is necessary to raise the resolution of the identification guarantee level. I think that the current guidelines will not be able to express the guarantee level as it is due to future consolidation, etc. I feel that I will have to think about the guarantee level in units of attributes, and that I will not be able to reach a conclusion unless I proceed with discussions with a sense of granularity.
The discussion on Verifiable Credentials is difficult, but it will be useful in the future. I understand the significance of dealing with it because it is an area that is getting more and more attention, but at least it should be an attribute provider, not an identity provider. Also, as the words Verify and Credential appear here and there, I feel it is important to consider it so that the general reader can correctly understand the meaning of the words in each context.
With regard to the consideration of a hybrid model of an authentication linkage model and a non-authentication linkage model in "Future Considerations," for example, in a use case where only one application is allowed per person, I think it is necessary to collate names in order to prevent individuals from using multiple IDs. Are there any prospects for the technology to solve this problem?
- Secretariat: The fact is that we have not yet considered specific countermeasures, but we believe that whether or not to detect it depends on what kind of identification is performed. In particular, we recognized that it is necessary to consider procedures that do not use the My Number.
I think there will be a discussion about federation later in the day, but I was told that it depends on whether the discussion should be limited to technical topics and left to the reader, or whether it should include what is necessary to ensure user uniqueness across actual service linkages.
Some technologies are currently in the research stage, and I think it is difficult to answer the question of whether they are technically established. I don't think there is anything that anyone can use with high reliability yet, but it is certain that research is being advanced by engineers around the world.
I understood that it is not a story that the description itself is ridiculous because there is no possibility of realization.
On page 19, I think there is essentially no reason to actively separate government IDPs from private IDPs, it is simply a difference in which trust framework they belong to.
I think it would be good to leave the issue of whether or not a trust framework should be created to govern transparency and quality assurance, and I think you are right.
I understand that today is the last episode, but is it okay?
- Secretariat: With regard to the comments we received today, we will revise the current draft by the end of this fiscal year if there are any significant problems with the current draft. However, we assume that the comments that require additional consideration will be submitted to the next fiscal year for further consideration.

Revision point ④: Partial revision of guarantee levels and countermeasure standards - Revision of identification guarantee levels

If "Comparison of Biometric Information" on page 29 refers to Biometric Authentication, I feel uncomfortable with the description of remote facial recognition as the method. If it means visual facial recognition instead of Biometric Authentication, I feel that the description of Biometric Collection in the annotation part is inconsistent.
- Secretariat: What is intended here is the latter, which is to confirm the appearance. For example, it is assumed that a photograph of the face at the time of identity confirmation will be saved. I would like to review it so that it is not tied to the words of NIST and it is described as intended.
Regarding the falsification of biometric information on page 32, the falsification of facial appearance by wearing a mask is different from the falsification of biometric information, and there is a well-organized document on the latter, so I think it is good to organize and introduce it.
On page 33, the number of identity verification documents required for Identity Assurance Level 3 is mentioned. For example, in some cases, the number of documents required is one when using an authentication machine and two when not, so I think it is better to write the details in this guideline.
In the detailed part of Identity Assurance Level 2 on page 30, there is a part where the relationship between authentication strength and detail level seems to be reversed, as in Level 2B and Level 2C, so please check it. In addition, collecting copies of physical verification tickets alone does not confirm it, so please correct the description.
In the Verification section of the table on page 29, I feel that the grouping policy of the verification method is different from the certification assurance level of the person in question. If c) and d) are grouped separately and made into three elements of knowledge, living body, and possession certification, it will be easier to respond when a new method appears in the future.
Since there is a relatively high possibility that a 4-digit PIN number with a small number of combinations will match even if it is not the person himself, I think that the confirmation of appearance is added when the guarantee level is raised.
It seems to be possible to apply the idea that the reliability will increase if we can verify with two factors in the confirmation of the identity verification documents and the applicants' identity.
As I mentioned before, it might be better to bring up the certification and assurance level first. There are some companies that do validation properly but do verification a little appropriately.
As for the level of personal identification assurance, there are many answers, such as "Password only is not acceptable" and "two step verification is not acceptable." However, as for the level of personal identification assurance, it is difficult to organize it because identity verification documents differ from country to country, and I feel that it is becoming more important. I feel that the current order is good because credentials that can be used for personal identification can be issued on the premise of personal identification.
There are a lot of elements of Authentication in Verification, so I think it's difficult to separate them neatly.
Please note that NIST SP 800-63-4 uses the term Verification in two ways. Also, saving the face photo has a meaning to prevent multiple registrations, but I thought it could not be read with the current description.
I understand the need to collect face copies, and I think it is important to describe the retention period, the purpose of collection, and the conditions for destruction.
Since it is personal information, I think that safety management, access management, and the expiration date of destruction and storage when it is no longer necessary should be considered as a set.
Regarding the subdivision of Identity Assurance Level 2 on page 30 into five levels, while I understand that it is subdivided in this way, I was concerned about whether it would function in actual operation. In addition, I was confused about how to read the table on page 32, and I confirmed that there were parts where the notation of the legend seemed to lack accuracy, so I would like to ask you to review the description.
- Secretariat: As you pointed out, we would like to make a correction regarding the fact that the legend is not accurate.
Please confirm the definition of Presentation Attack within the secretariat.
In the NIST Biometric Collection, methods such as facial recognition, facial photo comparison, and fingerprint comparison are described, and it seems that IAL3 is also accepted in the method of taking a facial photo and comparing it with a passport image, as is done at immigration inspection. It says that Presentation Attack resistance and LiveNess Check should be checked especially in remote cases, but there is not much distinction. When it comes to biometric information, it includes collecting and recording biometric templates for the convenience of CSP, and simply storing facial photos of people who appear at the counter. It was mentioned earlier that it is important to write the purpose, but the purpose of collecting biometric information is to facilitate IAL3 identification in account recovery, so I think it is better to write it firmly.
Is the "certification by the certification function of identity verification documents (PIN number, etc.)" in c) what is written in the current guideline or what is newly added this time?
- Secretariat: Guidelines, there is no description as a model, and it is newly added with awareness of My Number Card this time.
I can understand that the description was made with My Number Card in mind, but the 4-digit PIN number on a bank cash card and the 4-digit PIN number for activating a tamper-resistant area like My Number Card are clearly different in meaning, so I thought it was necessary to describe it so that the reader can read that point. Also, if it was made with My Number Card in mind, I felt that the content was not much different from e), and I felt it was strange. I understand that the input of the PIN number is just for activating the IC card and taking out the electronic signature or the face image through the application by the function of the IC card, so I felt that c) would be misunderstood as a means itself.
- Secretariat: As you know, I actually input the PIN number to perform e), but I used the current description to express how it functions when it is separated into Verification and Validation. However, as you are concerned, I felt that there is a possibility of misunderstanding, so I would like to consider it again.
Regarding the Identity Confirmation Guarantee Level 1 on page 28, there is a description of "by mail, etc.", which seems to assume the use of the registration code, but it may cause misunderstanding if it includes the identity confirmation using the personal identification mail, etc., so I think it is better to change the description method.
Excuse me for asking a basic question, but could you explain what the purpose of the table on page 32 is? What do readers judge when they see it?
- Secretariat: The table on page 32 summarizes the differences in threat resistance between Assurance Levels 1, 2, and 3 compared to the table on page 29, and is not intended to be used by the readers of the Guidelines to make any judgments.
Am I correct in assuming that only if a) and e) are checked in the Assurance Level 3 column will I be granted Assurance Level 3?
- Secretariat: As you know.

Revision point ④: Partial review of guarantee level and countermeasure standards - Review of certification guarantee level / Revision point ⑤: Comprehensive review of risk assessment process

The Secretariat explained the points to be revised in the materials and the "Items for Future Consideration" that summarize the discussions so far, and confirmed additional opinions from experts.

When we compared the countermeasure standards for the certification assurance level of the person concerned with ISO/IEC 29115, we found that there were four points that were lacking. If we add the four points of Credential Theft, Credential Sharing, Credential Duplication, and Offline Guessing, I think it will be more complete. It is consistent with ISO/IEC, and we can explain that the reason why tamper-resistant hardware is required is to acquire resistance against Credential Duplication, and that the reason why linkage using biometric information is required is to acquire resistance against Credential Theft and Credential Sharing.

Agenda (2) Additional Discussion Points

The Secretariat explained the points newly added based on Appendix 2, and experts held free discussions.

There was an explanation that "Dynamic Registration may not be necessary", but in the wallet model, I think Dynamic Registration using Client Attestation may be necessary. Next, regarding the Bound Authenticator, I think we should pay attention to whether there is any other implementation means other than the PIV card now that Token Binding is no longer available. In addition, Shared Signaling has been adopted by Apple and other companies and is attracting attention in the United States, so it may be good to include it in consideration of the fact that the revised guidelines will be used for a long time. However, I think it is too much to make it "mandatory" and should be limited to "recommended".
Technically, the conditions of NIST FAL2 are to be able to withstand the distribution of NIST IAL3 identity verification results using NIST AAL3, and I think that in itself is appropriate. If I had to say, since the Trust Agreement is a fairly important matter, I think it would be good to clearly state that the combination of the identity verification guarantee level and the personal authentication guarantee level should be properly considered. The minimum requirement is to describe Static, and I personally think that it is not necessary to study to describe Dynamic.
Dynamic Trust Agreement and Dynamic Registration are completely different stories, so I think they need to be considered separately.
In NIST FAL, encryption is required regardless of the level of personal information contained in the Assertion. In SAML, it is not uncommon for an e-mail address to be used as an identifier. Therefore, if encryption is required to meet the conditions for the authentication linkage assurance level, the impact will be quite large. I think it is necessary to consider what measures can be adopted and what kind of impact will be caused by the addition of conditions. I do not mean that the conditions should be set loosely, but it is important to clearly state the parts that will be affected and to encourage implementers to take necessary measures.
Regarding the necessity of Shared Signaling, I felt that it would be possible to make appropriate comments if we could break down the planned cooperation with RP a little more and specify what kind of things would be possible.
From the standpoint of the RP side, I would be happy if there was shared signaling, but on the other hand, as an individual, I was a little worried that in the future, when the cooperation becomes complicated, unintended updating of attribute information might be done by consent of signal transmission in the past.
- Secretariat: Shared Signaling is for notification of changes and not for rewriting attribute information, so I think there is no problem with that point.
As for Shared Signaling, I think it is more important to define it in the actual IdP interface specifications and increase the number of RPs that use it than to encourage implementation from the guidelines. Since it is an ongoing technology, I don't think there is much relationship between being described in the guidelines and being adopted at the time of implementation. If it is a necessary specification, the IdP designer should consider adding it to the interface specifications. However, it doesn't cause any bad effects, so I think there is no problem as long as it is described sparingly.
There are a number of private companies that follow the guidelines issued by the Financial Services Agency and other relevant ministries and agencies, but I think there will be applications where Signaling will be able to handle appropriately when something linked to an account that is fine until a certain time is put on the sanctions list.
- Secretariat: As I explained at the beginning, I would like to continue to consider additional points based on the comments I received today. Thank you very much.

Announcement of closing and future schedule

(Secretariat)

It has been a fruitful year for the secretariat as well, with intense discussions by those who are active on the front lines. The difficult situation will continue in the next fiscal year, including the release of the NIST SP 800-63-4 Second Public Draft. However, I believe the importance of this field is clearly increasing, as there is a growing momentum to promote international consideration in the United States and Europe. On the other hand, I have a sense of crisis that the situation will become more fluid in the future due to the delay in the consideration of the DIW in Europe and the increase in stakeholders. In the next fiscal year, I will be conscious of the sharp distinction between what should be discussed and what should be taken as a standard, and I will consciously output it so that it will also lead to international contributions, so I would appreciate your continued support.
Thank you very much for your long participation and various opinions today.

END