Expert Meeting for Revision of Personal Identification Guidelines (5th meeting in fiscal 2023)

We will hold an expert meeting for the next revision of the digital society "DS-500 Guidelines on Online Identification Methods for Administrative Procedures", which has been developed as one of the Promotion Standard Guidelines, in .

Overview

Date and time: Tuesday, February 27, 2024, from 18:00 to 20:00
Location: Digital Agency Meeting Room and online
Agenda:
1. Opening
2. Proceedings
  1. Interim report (draft) for fiscal 2023
  2. Additional Issue Discussion
3. Adjournment

Materials

Attendees

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

Explanation of Opening and Holding Outline

(Greetings and Secretariat Explanation)

Now, I would like to begin the fifth meeting of the Expert Council on the revision of the Guidelines for Identity Confirmation. Thank you for taking the time to gather.
There are two main points that I would like you to discuss today. First, I would like you to confirm the "Interim Report (Draft) for Fiscal 2023" prepared based on the previous discussions. Second, I would like you to discuss the points related to federation, which I have additionally brought this time.

Agenda (1) Interim summary (draft) for fiscal 2023

The Secretariat explained the results of the current review of the Interim Report for FY 2023 (draft) based on Material 1, and experts held free discussions.

(Expert Opinion)

Revision point 1: The scope and name of application of the Guidelines have been changed / Revision point 2: The "Basic Concept" of mission execution, etc. has been explained

The Secretariat explained the amendments to the materials and the "Matters to be Considered in the Future" summarizing the contents of the discussions so far, and confirmed the additional opinions from the experts.

I don't think we have been able to discuss much about identification documents other than My Number Card at this meeting. In the NIST concept, the evidence strength of each certificate is clarified, and the guarantee level is determined by the combination of them. Therefore, I would like to be careful not to have a discussion based on My Number Card.

Revision point (3): Define and explain the framework for identity verification

The Secretariat explained the results of the review of the materials and the "Matters to be Considered in the Future," 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 a wallet, and the frame marked "ID provider" in this figure should be regarded as an attribute provider, not an IdP. The wallet model and the authentication cooperation model are very similar, and I think that specifying the attribute provider makes the difference clear.
Regarding the use of terms, I was concerned that the term "RP" is also used in the non-authenticated collaboration model. In addition, terms such as Issuer, Holder, Verifier, and Credential in the wallet model are used in different meanings from NIST, so I felt that it would be good to review the names of the terms while taking into consideration the overall consistency.
- Secretariat: If NIST SP 800-63-4 is published with ambiguous definitions of terms, what action should we take?
- Expert: Even if the definition of NIST is ambiguous, I think it is necessary to define it properly in preparation for creating a correspondence table for interoperability with other countries.
On P22, it is written that "a model in which the Issuer and the Verifier can be separated", but I feel that it is more accurate to say "a model in which the Verifier information cannot be passed to the Issuer".
On page 18, the word "identity" is used in the "identification" section, but please be aware that the meaning of the word "person" in the person authentication is different.
The wallet model focuses on confirmation of qualification retention rather than identity confirmation. Matching attribute information alone is not sufficient to verify the validity of the issued certificate, so it is signed and verified. Therefore, we believe that there is little need to force it into the wallet at the time of this revision.
You said that the term "authentication cooperation" would be included in "future considerations" and sent ahead, but I feel that it is okay to replace the term with "ID cooperation" in this interim summary document.
In the wallet model diagram, the Verifier is also written in the Issuer's box, but if this Verifier means "person verification," I thought it might be necessary in the Issuer's frame. In addition, "Verify" in the sense of validation by passing the Verifiable Presentation simply means validation of credentials, so I felt that it should be separated from "Verify" in the act of authenticating the person.
Verify in the sense of cryptographically authenticating credentials is different from Verify for person validation at NIST, so I don't think it should be forcibly arranged with other models in order to prevent them from being confused and discussed. There is no doubt that the wallet model is a model to be paid attention to in the future, so I think it is possible to consider a method of describing it separately without arranging it with the authentication linkage model.
I felt that the reader would take it that the wallet model mentioned in this document was added in response to the impact of DIW (Digital Identity Wallet), which is being studied in Digital Agency in parallel, but what is the actual situation?
- Secretariat: The wallet model in this document has been organized in preparation for the addition scheduled in NIST SP 800-63-4 Second Public Draft. Since it was not affected by the parallel DIW efforts, we recognized that it is necessary to explain that point properly.
It may be better to include the term and clarify that it is positioned separately from the other two models.
Regarding the description on page 24, if there is no clear use cases that accepts the certification results and attribute information from the private sector side at this point, I felt that deleting the description on page 24 would be a simple story.
In the work that I was involved in, I realized that there was a certain rate of data entry errors, and I strongly felt the possibility of cooperation of private sector's proprietary information. Therefore, I was pleased to see the existence of page 24.
Based on the discussion so far, a strict guarantee level is defined, and there is a Verifiable Credential of the Issuer issued from there. It is very meaningful that only what is necessary for authentication can be disclosed, so I don't think the existence of page 24 itself is a problem.
Regarding the second point on page 24, which is the description of the Trust Framework, it is necessary not only for cooperation outside the government but also for cooperation within the government, so I think it is good to consider the description again. Even when the wallet model is illustrated, it is effective to add an attribute provider because it can clearly position the person who provides the identification and can show that there can be more than one authoritative source.
I thought that if it were generalized as an attribution provider, it would be a little different from identity verification, so I felt that it would be good to discuss it separately. In addition, regarding the Trust Framework, there is a development that is expected to be realized, such as making the Common Research use cases System (e-Rad) available with a university ID. Therefore, I would like to leave the red frame on page 24.
I think it will change depending on how the attribute provider is used. I think it is good to include it for the future, but all attribute providers do not perform the same level of identity verification, and there are cases where another person's authentication is required as a prerequisite for providing attributes, so I felt that it is necessary to review the description.
As for the wallet model, I remember that we had to pay attention to how it would appear in NIST SP 800-63-4 Second Public Draft in the previous discussion.
- Secretariat: The current proposal is based on the opinion that it is better to include it in this revised version after considering the future period until the revised version is published, the frequency of review after publication, and the life of the revised guideline.
We need to consider the time span, and we also need to increase the resolution of the identification guarantee level. Due to future aggregation, we believe that the current guidelines will not be able to express the guarantee level as it is. We will also have to consider the guarantee level by attribute, and I feel that we will not be able to reach a conclusion unless we advance the discussion with a sense of granularity.
It is difficult to discuss Verifiable Credential, but it will surely be useful in the future. Since it is an area that is gaining attention, I understand the significance of dealing with it, but at least it should be an attribute provider rather than an identity provider. In addition, the terms Verify and Credential appear here and there, so I feel that it is important to consider and proceed with the discussion so that general readers can correctly understand the meaning of the terms in each context.
Regarding the examination of a hybrid model of an authenticated cooperation model and a non-authenticated cooperation model in the "Future Considerations," I think it is necessary to conduct name-based aggregation in order to prevent individuals from using multiple IDs in use cases, where, for example, only one application per person is allowed. Are there any prospects for technology to solve this problem?
- Secretariat: It is true that we have not yet considered specific measures, but I believe that the possibility of detection depends on what kind of identification is performed. In particular, we recognize that Issue needs to consider procedures that do not use the My Number.
I think there will be a discussion about federation in the second half of today, but I was asking if it would be up to you to keep it a technical discussion and leave it to the reader to consider, or if it would be up to you to describe what is necessary to ensure user uniqueness across actual service interactions.
The question of "have you established the technology?" is technically difficult because some technologies are currently in the research stage. I don't think there is anything that can be used by anyone with high reliability yet, but it is certain that research is being advanced by engineers around the world.
I understand that the description itself is not ridiculous because there is no possibility of realization.
I believe that there is essentially no reason to actively separate the government IdP and the private sector IdP on page 19, but simply the difference in which Trust framework they belong to.
I think it is good for Trust to leave the question of whether or not the Issue Framework should be created for governance of transparency and quality assurance, but I think you are right.
I understand that today is the final episode, but is it okay?
- Secretariat: Regarding the comments received today, we will revise the part that has a major problem in the current draft by the end of this fiscal year, but we expect that the part that needs additional consideration will be handed over to the next fiscal year as a future consideration.

Revision point ④: Review part of the guarantee level and measures standards - Review of the identification guarantee level

If "Comparison of Biometric Information" on page 29 refers to Biometric Authentication, it is strange that remote facial recognition is described as a method. If it means facial recognition in the visual inspection instead of Biometric Authentication, I feel that the part of the annotation "Biometric Collection" is inconsistent.
- Secretariat: What we intend to do here is to confirm the latter's appearance, and for example, we assume that the content is to save a photograph of the face when the identity is confirmed. We would like to revise the description so that it will be as intended without forcibly linking it with the words of NIST.
Regarding the disguise of biometric information on page 32, the disguise of appearance by wearing a mask is different from the disguise of biometric information, and regarding the latter, there is a well-organized document, so I think it is good to organize and introduce it.
On page 33, the number of identification documents required for Identity Verification Guarantee Level 3 is mentioned. For example, it seems that there are examples in which one point is required when using an authentic / counterfeit judgment machine and two points are required when not using one. Therefore, I think it is better to write the details in the guidelines this time.
In the detailed part of the Identity Verification Guarantee Level 2 on page 30, there is a part where the relationship between the certification strength and the detail level seems to be reversed, such as Level 2B and Level 2C. In addition, it is not possible to confirm only by collecting copies of the physical validation ticket, so please correct the description.
In the Verification section of the table on page 29, it seems that the grouping policies of the validation methods differ from the certification guarantee level of the person. If c) and d) are separated into three elements of knowledge, biometric, and possession certification, it will be easier to respond when new methods appear 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 confirmation of his appearance is added when the guarantee level is raised.
It seems possible to apply the idea that the reliability will be improved if the validation can be made based on two factors: the identification document and the identification of the applicants.
As I mentioned before, it may be better to bring the certification guarantee level of the person in question first. There are some business operators who perform Validation properly but Verification is somewhat appropriate.
As for the person authentication guarantee level, answers such as "Password alone is NG" and "two step authentication is NG" are coming into sight. However, the identity verification guarantee level is difficult to organize due to the fact that identification documents differ from country to country, and I feel that its importance is increasing. I feel that the current order is fine because credentials that can be used for person authentication can be issued on the premise of identity verification.
Verification includes many elements of Authentication, so I think it is difficult to separate them neatly.
Note that NIST SP 800. 06-63-4 uses the word Verification in two senses. In addition, saving a face photo has a meaning to prevent multiple registration, but I thought I couldn't read it with the current description.
I understand the necessity of collecting face copies, and I think it is important to state the retention period, the purpose of collection, and the terms of destruction.
Since it is a personal data, I think that safety management, access management, destruction and storage period when it is no longer necessary should be considered as a set.
Regarding the subdivision of Identity Verification Guarantee Level 2 into five stages on page 30, I understand that it is subdivided in this way, but I was wondering if it would work in actual operation. In addition, I was confused about how to read the table on page 32, and I was able to confirm that the notation in the legend lacks accuracy, so I would like to ask you to review the description.
- Secretariat: As you pointed out, we will correct the point that the legend is not accurate.
Please check the definition of Presentation Attack once within the Secretariat.
According to the NIST Biometric Collection, methods such as facial recognition, facial photo comparison, and fingerprint comparison are described, and it seems that IAL3 is also recognized in the method of taking a photo of a face and comparing it with a passport image, as is done in immigration. Resistance to Presentation Attack and LiveNess Check are particularly required to be checked in the remote case, but they are not so distinguished. Biometric information includes the collection and recording of Biometric templates for the convenience of the CSP, and the storage of facial photos of people who have just appeared at the counter. You mentioned earlier that it is important to write down the purpose, but the purpose of collecting biometric information is to facilitate the identification of IAL3 in account recovery, so I think it is better to write down that clearly.
Regarding c), "Authentication using an authentication function (such as a personal identification number) on an identification document", is it what is written in the current guidelines or is it something that is newly added this time?
- Secretariat: There is no description as a model in the current guidelines, and it is newly added this time in consideration of My Number Card.
I can understand that it is a description that is conscious of My Number Card, but the meaning of the 4-digit PIN number of a bank cash card and the 4-digit PIN number for activating a tamper-resistant area such as My Number Card are clearly different, so I thought it was necessary to describe that point so that the reader could read it. In addition, if it was conscious of My Number Card, I felt that the content was not so different from e), and I felt strange. I understand that the input of the PIN number is to activate the IC card and take out an electronic signature or a ticket image via an app by the function of the IC card, so I felt that c) might be misunderstood as a means itself.
- Secretariat: As you know, we actually enter the password to implement e), but when we separate it into Verification and Validation, we used the current description to express how it works. However, as you are concerned, we feel that it may cause misunderstanding, so we 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 be based on the use of a registration code, but it may cause misunderstanding if it includes identity confirmation using a mail to be received only by the person himself / herself, etc., so it is better to change the method of description.
I'm sorry for asking a basic question, but could you explain what the table on page 32 is written for? What does the reader judge by looking at this?
- Secretariat: The table on page 32 summarizes the differences in threat resistance among Assurance Levels 1, 2, and 3 with respect to the content described on page 29. It is not intended to be used by the reader of the guideline to make any judgments by looking at this table.
Is it correct to understand that only if a) and e) are checked in the column of guarantee level 3, guarantee level 3 will be accepted?
- Secretariat: As you know.

Revision point ④: Review part of the guarantee level and countermeasure standards - Review / revision of the person certification guarantee level Point ⑤: Completely review the risk assessment process

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

Agenda (2) Additional discussion points

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

You explained that "Dynamic implementation may be unnecessary", but I think that Dynamic Registration using Client Attestation may be necessary in the wallet model. Next, regarding Bound Authenticator, I think that it should be noted whether there is a registration means other than PIV card now that Token Binding has disappeared. In addition, Shared Signaling has been adopted by Apple and others and is attracting attention in the United States, so it may be good to include it in consideration that the revised guidelines will be used in the long term. However, I think that it is too much to be "required" and should be "recommended" only.
Technically, the conditions of NIST FAL2 are to be able to withstand the distribution of the identification results of NIST IAL3 using NIST AAL3, and I think that itself is appropriate. If I had to say it, the Trust Agreement is quite an important matter, so I think it would be good to specify that the combination of the identification guarantee level and the person authentication guarantee level should be properly examined. The minimum is to describe Static, and I personally think that it is not necessary to consider the description of Dynamic.
Dynamic Trust Agreement and Dynamic Registration are completely different things, so I think they need to be considered separately.
In NIST FAL, when a personal data is included in an assertion, encryption is required regardless of the level. In SAML, it is not rare that an e-mail address is used as an identifier, so if encryption is required to satisfy the conditions of the authentication cooperation guarantee level, the impact will be significant. I think it is necessary to consider what measures can be adopted and what kind of impact there will be if conditions are added. I heard that it is important not to set the conditions loosely, but to specify the parts that will be affected and urge the implementation side to take necessary measures.
Regarding the necessity of Shared Signaling, I felt that it might be possible to make an appropriate comment if you could break down the future planned cooperation with RP a little more and specify what kind of thing is possible.
From the perspective of the RP side, I would be happy to have Shared Signaling, but on the other hand, as an individual, I was a little worried that if the cooperation became complex in the future, attribute information might be unintentionally updated due to the consent of the past signal transmission.
- Secretariat: Since the purpose of Shared Signaling is to notify changes and not to rewrite attribute information, I think there is no problem in that point.
Regarding shared signaling, rather than encouraging implementation from the guidelines, I think it is more important to define it in the interface specifications of the actual IdP and increase the number of RPs that use it. Since it is a technology that is currently in progress, 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 design should consider adding it to the interface specifications. However, it does not have a negative impact, so there should be no problem if it is described sparingly.
There are a number of businesses in private sector that follow the guidelines issued by related ministries and agencies such as the FSA, but I feel that there will be applications such as appropriate handling can be done if there is Signaling about the fact that something linked to an account that has no problem until some time has been included in the sanctions list.
- Secretariat: As explained at the beginning, we would like to continue to consider additional issues based on the opinions we received today. Thank you very much.

Closing / Future Schedule Guidance

(Administration Office)

All of you who are active on the front lines have had very strong discussions, and it has been a fulfilling year for the Secretariat. Although the difficult situation will continue next year, such as the release of the NIST SP 800-63-4 Second Public Draft, there is a growing momentum to advance international consideration in this field in the United States and Europe, and I think that the importance of this field is clearly increasing. On the other hand, due to the delay in DIW consideration in Europe and the increase in stakeholders, I have a sense of crisis that the situation will become more fluid in the future. In the next fiscal year, I will be aware of the distinction between what should be discussed and what should be taken as a standard, and I will be consciously producing output so that it can be linked to international contributions. Thank you for your continued support.
Thank you very much for participating for a long time and for your various opinions today.
()