Expert Meeting for Revision of Personal Identification Guidelines (4th 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, January 30, 2024, from 18:00 to 20:00
Location: Digital Agency Meeting Room and online
Agenda:
1. Opening
2. Proceedings
  1. Issue Discussion: Policy for Revision of the Identity Confirmation Guidelines (Draft)
    - Revision Point (1): "Scope and name of the Guideline have been changed"
    - Revision Point (4) "Review of Guarantee Level and Standards for Measures"
    - Revision Point (5) "Completely review the risk assessment process" and
    - Revision point (vi) "Expansion of reference materials and tools for risk assessment and method selection"
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.)

Agenda (1) Explanation of the opening and outline of the meeting

(Greetings and Secretariat Explanation)

Now, I would like to begin the fourth meeting of the Expert Council for the revision of the Guidelines for Identity Confirmation. Thank you for taking the time to gather.
While there are various specific moves in identity management-related matters in Digital Agency, the importance of identity verification is increasing, and it is increasingly necessary to proceed with examinations that are aware of international interoperability by referring to the results of mapping conducted between Europe and the United States. We believe that it is important to advance discussions as our own affairs after understanding technological progress and various efforts in a timely manner, not just incorporating overseas trends such as the United States, so we would appreciate your continued guidance.
There are three main points that I would like you to discuss today. Please discuss the points of the revision of the Guidelines for Identity Confirmation that are under consideration.

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

Revision Point (1): "Scope and name of the Guideline have been changed"

The Secretariat explained the results of the current review of revision point (1) based on Material 1, and the experts held free discussions.

(Expert Opinion)

You said that it is planned to include employees in administrative operation. Does that mean that a uniform standard will be created to ensure the same level of identification as that of applicants for administrative procedures?
- Secretariat: We recognize that the identification of Although it is still under consideration whether or not it can be completely consistent, it is under consideration whether or not the same standard can be applied. Since NIST SP 800-63-4, which is used as a reference, has a similar policy, we are considering whether or not this guideline can be modeled after it.
Is there any RP that is expected to target administrative operation workers?
- Secretariat: We recognize that the identification of Information systems used for internal office work are assumed to be the main RP.
I think it is good to expand the scope of application, but the expected risks and the scope of impact are clearly different between the services for citizens and the services for internal use, so I think it is necessary to describe the scope of application in consideration of the difference.
I felt that the fact that it is targeted at contractors involved in administrative operation is slightly different from the policy of excluding corporations from the revised guidelines. It is assumed that the identification confirmation when a corporation performs administrative procedures and the identification confirmation performed for a contractor engaged in administrative operation are similar, so I think that it is better to separate the categories of employees and contractors.
- Secretariat: We recognize that the identification of The identification confirmation for the contractor is assumed to be the identification confirmation of the worker as a natural person who actually uses the system. If the identification confirmation as a juridical person is required for the contractor, it is assumed that the Guidelines for Juridical Persons to be separately developed will be applied.
When targeting individuals viewed through business operators, we believe that business operators should view individuals based on the premise that a certain level of screening is performed when hiring such individuals. Therefore, we believe that government organizations do not need to verify the identity of individuals from scratch. Therefore, we felt that it would be better to separate this part.
- Secretariat: We recognize that the identification of We believe that it is necessary to consider this matter in the future, but there is no intention or purpose to make the identification of the current contractor stricter by these guidelines. On the other hand, we recognize that there are many cases in which the person in question is authenticated when the system account is paid to the contractor, and we expect that it will be applied to such cases.
In that case, I agree.
I was wondering if this part was written on the premise that the same PIV system as in the United States would be introduced in Japan. I think the level of clearance is different from that in the case of providing general services to the people, so I was a little worried that this part was not written with emphasis on this.
I also felt that PIV and other topics would be included in the scope. I think it would be consistent with the policy of tightening the Identity Confirmation Guarantee Level 3 on the premise that it will be adopted in extremely important use cases. In addition, I felt that it would be appropriate if the purpose was to unify and enforce the internal rules on security, such as the account issuance process and authority management specified by each ministry and system.
Do you assume that private sector companies will use these guidelines to verify the identity of their customers and the government will accept the results?
- Secretariat: We recognize that the identification of At present, we do not assume that much.
In the provision of services, I think there are parts where individuals and corporations cannot be separated, and I felt a sense of surprise at the policy of excluding corporations from the scope of this revision. Is there any reason?
- Secretariat: We recognize that the identification of Although it has been a misleading explanation, it is assumed that corporations will be organized after being cut out into separate guidelines.
In that case, what is the chronological relationship with the revision of the Guidelines?
- Secretariat: We recognize that the identification of We are considering whether we can make it in time for the revision of the Guidelines for Identity Verification. However, if the Guidelines for Corporations cannot be developed in time, we believe that simple scope out will not be possible.
The users of the service may be individuals or corporations such as schools and organizations, and we naturally understand that different elements will be introduced. In the concept of Enterprise Attestation of FIDO, on the premise that employees are identified as a company or organization, there is a distinction between privacy issues for individuals and the fact that the company controls them. However, if there is no bottom line, it will be ruined, so I felt that it is important to keep it at the minimum within the same time frame.
- Secretariat: We recognize that the identification of As you pointed out, it is a problem that the existing standards that existed in the current Guidelines will disappear. Therefore, we believe that it is necessary to take measures such as keeping the part for corporations as a separate volume at the time of revision at least so that the Guidelines will not be discontinued.
I understand that corporate identity verification involves difficult issues, but I think it is necessary to take an approach of setting a target and reaching a conclusion by that timing, rather than postponing it because it is difficult.
- Secretariat: We recognize that the identification of have important implications. We recognize that the current Guidelines are strongly aware of specific authentication methods such as gBizID and Commercial Registration and Authentication Bureau, and that they are more like identity verification for natural persons who are in charge of corporate procedures than authenticating corporations themselves. In order to align with the guidelines of other countries, we believe that this is a theme that should be considered along with confirmation of attributes such as affiliation. In addition, I believe that you are correct in pointing out that there is a problem that the scope out of corporations from the Guidelines creates a blank space. The situation regarding the use of My Number Card in corporate procedures and the hurdles to the introduction of multi-factor authentication, particularly for small and medium-sized enterprises, has changed since the issuance of the current Guidelines, so we recognized that it is necessary to carefully describe and explain the background of changing the scope after sorting out such environmental changes.
Identity verification and person authentication are different things, and I think that there is almost no difference in the concept of the strength of authentication required at the time of person authentication between individuals and employees. If I had to say, the concept of privacy is different. On the other hand, identity verification is different from that of individuals in that it is based on the premise that companies and organizations use identity verification if they are employees, and that it is based on the premise that the relationship with the affiliation is confirmed. By comparing modern approaches, I think that there are things that can be done in the remaining period, so it is better to consider as much as possible instead of suddenly removing corporations from the scope.
Among OpenID Connect for Identity Assurance, there is a profile called Authority Claims. The first thing I was talking about when I made this design is that the parties who are authenticating are individuals, and how to express the relationship between individuals and corporations as attributes. If we can properly express the relationship, it will be settled naturally without removing it from the scope this time. In the United Kingdom, the registration information of corporations is disclosed as open data in a database called Companies House, but how to link the data and individuals is the design concept of Authority Claims. I think that the confirmation of the authenticity of corporations themselves is originally outside the scope, so I don't think it is necessary to include it, and if we narrow down the scope to the relationship between individuals and corporations, we don't have to discuss removing the scope.
When I think about it from the perspective of outsourcers, I felt that it would be difficult to expand the scope to include subcontractors and temporary employees who belong to different "departments." If it means the authority to decide which person is allowed to do which work, it may be possible to control it.
Due to the background of the regulation of employment, there are cases in which employees of the subcontractor are in charge of important operations. I think the reality is that we have omitted background checks, which should have been done in the United States, because no serious problems have occurred so far. On the other hand, there is a case in which it is a compliance issue to confirm the identity of the other party in the service provision contract, so I think it is a very difficult issue.
- Secretariat: We recognize that the identification of corporation cannot be completely eliminated because it is referred to by gBizID and others. At least, we would like to continue the guideline in the form of a separate volume with the content equivalent to the current guideline, but the granularity of the description differs greatly from the main part, so we would like to continue to consider the timing of the update.

Revision Point (4) "Review of Guarantee Level and Standards for Measures"

The Secretariat explained the results of the current review of revision point ④ based on Material 1, and the experts held free discussions.
(Expert Opinion)

The threats listed in the table on page 22 appear to range in content from common to uncommon. Are they aggregated from multiple sources?
- Secretariat: We recognize that the identification of The black parts are defined in the current guideline, and the blue parts are extracted as threats that should be considered for countermeasures by referring to the NIST document and the guidance on phishing resistance of the US CISA.
What kind of threats are real-time phishing, multi-factor authentication fatigue attack, and SIM swap described here? In addition, when classifying from Level 2A to 2C, it is not described which method corresponds to which level. Please tell me about them.
- Secretariat: We recognize that the identification of Rear time data type phishing is a type of phishing attack in which a fake site is prepared and the credentials entered into it are relayed in real time. I think this falls under a type of man-in-the-middle attack, but it refers to a type of phishing attack in which information is stolen in the form of a proxy to break through two-factor authentication. Multi-factor authentication fatigue attack refers to a type of attack in which a large number of requests are sent to the type of Authenticator app that only requires the user to press the OK button to authenticate, aiming for erroneous login approval by authorized users. SIM swap refers to all types of attacks in which a SIM is stolen from another person's SIM, such as from the process of reissuing a SIM when it is lost.
- Secretariat: We recognize that the identification of As specific examples of methods from Level 2A to 2C, we assume that FIDO-based authentication or PKI-based authentication is used as the 2A method that can prevent real time data type phishing. As the 2B method that can prevent multi-factor authentication fatigue attacks, we assume that Authenticator, which allows users to enter numbers at the time of authentication, is used, and OTP using SMS is used as the 2C method.
In order to prevent SIM swapping, it is essentially necessary to take measures at the time of identity verification, not at the time of person authentication. Therefore, we felt uncomfortable about posting it on the table that defines the person authentication guarantee level.
The methods described as 2A to 2C assumptions are clearly different in strength, so I agree with the policy of subdividing the certification guarantee level of the person.
In the black part of the threats on page 22, there are "man-in-the-middle attacks" and "replay attacks", but I thought there was no method that could prevent these attacks but could not prevent real time data type phishing. In addition, it is technically difficult to prevent "session hijacking", and I think that there will be no Authenticator that can be dealt with.
Considering that the guidelines are also referred to by private sector, I was a little concerned whether the three classifications of Levels 2A to 2C are subdivided in consideration of adoptability and burden, or are simply subdivided in terms of the need for defense, and whether the standards and granularity are not consistent, including the discussion of session hijacking earlier.
- Secretariat: We recognize that the identification of The black parts in the table are the descriptions in the current guidelines, but we recognized that it is necessary to clarify and update the definitions. In addition, we recognized that Issue pointed out that the black parts and the blue parts (additional parts) are not consistent in granularity, and that there seems to be a contradiction in the descriptions. Therefore, we will re-organize and clarify the types and definitions of threats used as the criteria here.
Regarding the black part, at the time when NIST SP 800-63-3 was issued, there was a wide range of definitions of terms, so I think it is described as a man-in-the-middle attack. I think the purpose of this time is to highlight the difference between real time data type phishing and non-real data phishing and make readers aware of it, so I think it would be good if we could adjust it by reviewing the definition of the terms.
I feel that the level of understanding and maturity of measures in this area is clearly different now than it was when NIST SP 800-63-3 was published. Documents from that time say that tamper-resistant devices are sufficient. However, it is now common understanding that if a cookie is defrauded by session management after person authentication is completed, it is out. NIST SP 800-63-4 also uses the expression Attack-in-the-Middle. I think it is necessary to suggest that there are attacks that cannot be prevented even if the defined identity and identity assurance levels are achieved. There is no doubt that the moment of authentication is important, but I feel it is dangerous that this method seems to solve all the threats.
If it is a proprietary channel, there may be cases where measures can be implemented, so there is no problem in recommending measures, but I think it is difficult to make them mandatory.
Although it is logical to subdivide the person authentication guarantee level from 2A to 2C, from the perspective of the Verifier, there is probably a problem of how a certain authenticator determines the corresponding level. Even in the FIDO authenticator, there are those that require fingerprint authentication and those that do not, and in the Authenticator app, I think it is impossible to distinguish between those that are unlocked after face authentication and those that are simply displayed with a number.
I have a different opinion on that point. There should be a range of choices on whether or not it has to be biometric authentication to achieve Level 2A, and I feel that the detailed certification elements are too fragmented.
In that case, we thought that a registry of authentication keys would be necessary, and we thought that it would be necessary to make it possible for the user to check which authentication keys are mapped to which levels.
I can understand that opinion, but I don't know to what extent it is necessary to understand it. For example, the specifications of passkeys differ depending on the company that makes a implementation, and there are many cases where it is not known whether users register and use biometric authentication as an authentication method. Even so, the person's authentication guarantee level can be achieved at 2A in any case, so I don't think it is necessary for implementation.
In the case of FIDO, it may be so. On the other hand, in the case of software-based Authenticator, I think there are various variations.
I wondered if I could manage 2A through 2C if I were using a registry to manage how that authentication was done.
In relation to this, there is a description of the HW token in the level 3 part, but I think a low-quality HW token is not good. What NIST is saying is that the HW is FIPS 140 level 2 or level 3 certified.
I believe that imposing such restrictions will be the very issue of certification standards, but I feel that it will come down to the question of how the RP will know that it has truly been certified with such restrictions.
I think CSP has no choice but to guarantee it.
I think I can make a implementation because the certificate key relationship is defined when registering credentials.
In that case, we need a mechanism to determine which HW tokens meet the criteria and which do not.
In addition to this meta concept, we also need guidance when making a implementation. When it comes to HW tokens with Personal Authentication Guarantee Level 3, at least FIDO's security keys have security certification levels 1 to 3 +, and I think the one used by the U.S. government is 2 + or higher. Because metadata services are available there, HW tokens can be managed.
I think it is necessary to subdivide from 2A to 2C, and when it is subdivided, it is possible to distinguish the authorization key into each level, and I think it should be written that management, authorization, and validation for the authorization key are necessary for level 3.
You mean that I can't make a implementation unless it is written in a state that I can map properly.
You're right.
I think the discussion now is a very big part of the functions and requirements of the conventional Trust Framework. It needs to be described properly. In addition, if the government can control the participating CSP, I think the Authenticator can be managed and restricted, but if the CSP in private sector is accepted, the design of the Trust Framework should be very important. If it is a closed world like academia, it is easy to promote it, but if the government is to provide services to the people, I think how to control CSP will be a big Issue in terms of implementation.
In that sense, there is a wide range of Level 2A FIDoS and passkeys, and there is a difference depending on the implementation. In the past, OS platform vendors and manufacturers mainly provided passkeys, but recently, vendors providing so-called password managers have come to provide passkeys, and it has been announced that the implementation of users has expanded.
For the vertical axis of this table, it is necessary to be registered in the metadata service, that is, the evaluation axis that the Authenticator is managed.
You mentioned Level 3 HW, but FIPS 140-2 is probably fine, and the common criteria Evaluation Guarantee Level 4 + is probably fine. However, FIDO and the like are controversial, but what the Restricted Operating Environment is is very important. Is it good to use Arm's Secure Element, is it bad if there is no dedicated Secure Element, or is it good if it is a implementation backed by Apple's Secure Enclave? I think it is a troubling point that we cannot talk about HW strictly side by side. However, in reality, some people use these as the highest level, so I think it is necessary to take care of how to handle gray zones that are not reflected in the NIST scale.
The same story also appears at Level 2, and NIST takes a pessimistic view of the problem of not knowing whether the Authenticator actually performs local time data type. Some Authenticators operate only with a tap, while others authenticate with a fingerprint, and unless you know what it is, it is interpreted that the Authenticator does not perform local password authentication or biometric authentication equivalent. On the other hand, considering real authentication phishing resistance, there are cases in which attacks that can not be prevented even with a two factor OTP can be prevented even with a single-factor type that operates only with a tap of Authentication Intent with FIDO Authenticator, so I thought it would be good to discuss these cases in consideration of local authentication.
The distinction between a single element and two elements may be subtle, as there are cases where a good single element is better than a bad two elements.
Except for the tap-only security key, FIDO credentials that are installed on a smartphone and tied to a single gesture such as a PIN, pattern authentication, or biometric authentication are two elements of a single gesture for the FIDO Alliance. It is a combination of not only knowledge but also user operation or biometric information and credential possession, so it is clearly said that it is not a single element, and I think it is better to distinguish it.
There may not be such a implementation anymore, but there must have been a time when authentication could be performed without entering a PIN with the Authenticator of a smartphone, and what is happening now? I think it is OK if the keystore is tied up to the point where it is not protected by HW if a PIN is not entered, but I think it is gray in the current situation. At least it is clearly written that NIST SP 800-63-3 is considered to be pessimistic, and I thought that I had to interpret it as a scale of which I understand what I want to say. I think it is what 63-4 will be.
I think there were many talks from the solution provider side, and I think that the solution provider can identify the guarantee level of the solution they provide if they are segmented and have criteria, but I was curious about whether the requesting side can respond by designating a segmented level such as Level 2A or 2B. In the flow of analyzing the risk and determining the guarantee level to be requested, I am worried about whether I can have a resolution that can classify administrative procedures from 2A to 2C. Of course, the guarantee level and the risk are corresponding, so each level should be derived from the fact that this risk should be addressed or acceptable.
It is known that two step authentication using OTP for SMS and e-mail and authentication using FIDO are clearly different in terms of the occurrence of damage, so I think it is better to consider it positively.
I think that the operation that Level 2 is good will be major. If we subdivide and color code from there, I think that we have to convey the effect to the reader. I think that there is a possibility that an industrial consensus will be formed in a long time like the current Act on Prevention of Transfer of Criminal Proceeds, but in this guideline, I think that it is okay to be forward-looking to the extent that we appeal, "2A has an effect."
I think it is important to write the level division in a way that the reader can understand from the viewpoint of the effect. In today's material, I think that 2A and the rest do not have to be the same level 2. In an extreme case, I think that it is OK to set only the password as level 0 and drop 2B and 2C to level 1, or to set the level to four levels in total.
Even 2C is effective in terms of reducing erroneous logins. For services with a large number of accounts, it is possible for someone to set a similar ID and password and be mistakenly logged in. Even at the 2C level, it is possible to prevent such erroneous logins by incorporating two-factor authentication.
As for the wrong login, I think it is good to add it as a threat. There was a case where a family member logged in with the same browser, and the husband mistakenly donated a large amount of money with the account of the wife.
There can be several patterns, such as staying logged in or logging into a different account.
Although it is a part that is difficult to understand, it is an important event.
Again, 2A and 2C are clearly different in effect. For 2B, Microsoft has recently changed Authenticator to an input type, and is clearly aware of making it resistant to it. I think the vertical items should be revised, but I think it will be quite good. Then, next, we will talk about what is the meaning of separating 2A and 3. In fact, it is a implementation to ensure phishing resistance, and depending on the content of the credentials, I think there is little necessity for tamper resistance. Even at my company, I told my partner companies at an early stage that secure elements are unnecessary for that purpose. It is called Restricted Operating Environments, and it is protected by HW, but the software that operates it is running in user space, and it is sufficient. Then, in many cases, it does not have to be Level 3. How should I explain that?
I think the problem is that there is no threat that is the difference between 2A and 3 in this table. Originally, tamper resistance was intended to cover threats such as stealing a physical device and analyzing the chip with an electron microscope.
If the system is like My Number Card, where Basic4 information is included in the credentials, it will naturally be necessary to put them in tamper-resistant devices, and if the credentials are random strings that have no meaning even if you look at them, I think there is little need for tamper resistance. I think it is better to clearly write down the threat to distinguish between Level3 and 2A.
If it is ISO/IEC 29115, the duplication of credentials is included in the threat and can be distinguished. On the other hand, even if you do not write HW only, it will be covered. Another thing is that if you write the lending and borrowing of credentials, and if you have to deal with it at level 3, you will probably be able to distinguish between 3 and 2A because real-time biometric authentication will be required.
If it is an old-fashioned expression, I think it will be fail-safe or foolproof, and I feel that it is okay to make a mistake without malicious intent and to make a mistake with malicious intent.
If you add credential replication, borrowing and lending, and incorrect login to this threat, remove SIM swap, and make session hijacking mandatory, Level 2 is impossible, so I think it is good to make it recommended. By the way, in ISO/IEC 29115, session hijacking and man-in-the-middle are written separately. Man-in-the-middle is the moment of authentication, and session hijacking is after authentication.
I felt that readers would not be able to follow me unless I wrote about what can be done to prevent threats.
- Secretariat: We recognize that the identification of As you said, we plan to post as reference information that the same method as identity verification applies to person authentication, which is currently widely used in the world.
If there is no operation guidance, it probably cannot be used. I think it is good to organize the level division as I mentioned earlier.
- Secretariat: We recognize that the identification of level, we would like to consider it again based on your comments.
When I look at it from an amateur's point of view, I feel that it is better to say "HW token with tamper resistance" because it is easier for the reader to understand. As a supplementary story, I thought that there is a difference in judgment as to which is better, whether it is better to write that this is essential and this is recommended at this level, or to write that "please protect it for the time being" even if you do not understand the meaning even if you read it.
I understand what you are saying, and in that sense, I confirmed what 2A to 2C are. NIST SP 800 63-4 should include synced passkey, which should correspond to 2A in this table. It is accepted that credentials are phishing resistant, including leaving the device, but it is clearly different from 3. I think it will be easier if the method is written properly.
I think there is a high possibility that something will be declared in the near future, so I think it will be easy to understand. It is easy to understand that it is declared at a certain security level that it is okay to drop it, so I think it is good to think that it will move toward the 3 side with the times because I understand that there are gray zones of 2A and 3.
It will change with the progress of technology, but I think it is good if it is arranged that there is such a thing as a implementation example at what stage of the level.

Revision point (5) "Fully review the risk assessment process" and revision point (6) "Expansion of reference materials and tools for risk assessment and method selection"

The Secretariat explained the results of the current review of Revision Point 5 and Revision Point 6 based on Material 1, and the experts held free discussions.

(Expert Opinion)

Until now, I think we have been discussing the issue on the premise of regulation of CSP operated by the government. When certifying that an external IdP meets the government's standards, it is a little difficult to think about whether to accept the certification result of the external IdP as it is or to make a certain reservation. For example, if the government intends to create and operate a receiver of the Trust Framework, I think that the use of the external IdP is not an tailoring but to have the system that wants to use it enter the framework. I was a little skeptical about whether the government was thinking so much.
- Secretariat: We recognize that the identification of or the Trust Framework. In addition, we believe that it is necessary to confirm whether or not it is within the scope of these guidelines. At this point, we are thinking at the level of assuming that we can respond as much as possible to cases of cooperation with private sector that are expected in the future.
What is the definition of external IdP here? The description in NIST SP 800-63-3 is that the protocol between a CSP and an RP that are not in the same tightly coupled system is governed at the federation level, so it is not limited to external IdP and includes IdP within the government. Based on this point, I think it is good to define what is expressed as external IdP in this document.
- Secretariat: We recognize that the identification of For example, from the perspective of the person in charge of the online application system, gBizID and Mynaportal are systems of different organization within the government, so in that sense, they were expressed as external IdP. As you pointed out, we recognized that we could not consider IdP in the same organization and the same system implementation due to loose coupling.
I find it very strange to put the concept of federations into tailoring, so could you explain why you decided to do so?
- Secretariat: We recognize that the identification of government agencies are limited, if we decide to use an external IdP first and conduct risk assessments, it is possible that there will be no external IdP that guarantees the required level. If so, we thought that it would be more natural for the consideration side to determine the guarantee level first and use it if there is a government IdP that meets the conditions.
I don't think you think much about the case where the same entity uses an outbound CSP systematically. For example, even if the authentication part is an independent system in the same department of the government and there is only one IdP and one RP, it is not good if there is a problem with the protocol between them. Therefore, I think it is the spirit of NIST SP 800-63 that if the person requires authentication assurance level 3, the authentication cooperation level 3 should be adopted. Considering this, I think it is too late to include it in the tailoring part.
When I talked about federations before, I think we discussed whether we were talking about means or protocols. I agree that it is too late to decide the timing of tailoring because we need to consider how to determine the reliance on external results in defining the Identity Assurance Level and the Identity Assurance Level.
Aside from whether or not the tailoring process will be a hit, I don't think it is strange that the story of federation and IdP will come up in the selection of methods, and I think that it will be judged whether or not federation can be done after identifying the necessary level by starting with risk assessments. I think that the IdP that can be used has been decided in advance, but I didn't think it was strange that the options of making a implementation or relying on federations are listed flat. I think that the upper part of the table on page 36 is certainly true, and I thought that it is a story of whether or not to enter the Trust Framework, or a story of taking care of the IdP by evaluating the IdP including himself.
I also thought that the use of external IdP should be considered at the timing of risk evaluation, not at the time of tailoring.
I think that when you decide what to think, you decide where to think. I understand that the required identity verification guarantee level and the person authentication guarantee level are decided, and it may be possible for someone to take over them. If the RP does not do anything but relies on the IdP 100% including the process, there is no particular problem. However, in the pattern in which the RP originally has an ID and PW and links them, or in the pattern in which the IdP is used as a means to obtain an identity card instead of as an authentication method, the protocol of the federation is technically determined, but it may be used for different purposes. Therefore, I think that if the federation is to be performed, the risk assessment for performing the federation should be properly performed, regardless of whether the timing for consideration is the first half or the second half.
When I comment on the "identification of risks" part, I wonder if there is a connection between risk assessments and impact assessments. spoofs and lending and borrowing of credentials are mentioned as possible risks, but since the results are all combined, I did not know how the results of identifying risks affect risk assessments. I felt that it is necessary to include the idea of multiplying by the probability of occurrence of the risk.
- Secretariat: We recognize that the identification of risks is not necessarily linked to the degree of impact of risks. The results of risk identification in 3.2 are expected to be used not only for risk evaluation but also for selecting methods in tailoring.
I feel that it is difficult to judge whether it was lent or borrowed or stolen on a risk basis because the results are combined.
I don't think it's a problem to describe them separately to distinguish them as triggers of events, but I think the risks that are occurring as a result are the same.
I think it is related to the matter of adding the evaluation items of the person certification guarantee level that was mentioned earlier.
In terms of business, there is a story that you can be hospitalized in a spoofs as a result of lending and borrowing an insurance card, but I think that analysis of such risks is quite difficult. You can come up with the types of risks by distinguishing them, but to be honest, I don't know if you should make it so. Originally, it is assumed that administrative officers and business operators who support them will do this, so I think it is quite difficult.
My company is also having a little trouble with federations, and I have learned from my past experience that it is important to evaluate the other party correctly when federating with an external party. For example, according to the rules of the company to which I belong, phone numbers that are once linked cannot be easily changed, but partner companies can change them. There are threats that I did not realize in the past preliminary examination, and I think it is really difficult to evaluate them. If I had to say, it is not impossible to understand the nuance of the term tailoring and depending on the time, but I think it is very difficult to evaluate risks. I think it is necessary to conduct a fairly careful risk analysis for ID cooperation. Even if I maintain a certain level, if the other party is bad, there is a possibility that a problem will occur, and I thought it would be better to write down what should be done as a measure against it.
When I was aware that this guideline would be referred to from the private sector side, I felt that it would be better to write that there is an option of relying on others to lower the burden of consideration, and that it should be read with this idea in mind at an earlier stage.
I think we have learned from the past that we need to be particularly careful when there is a difference between the guarantee level required by the RP and the guarantee level provided by the IdP. I think the pattern of relying 100% on the IdP is OK, but if not, it is OK to receive a high-level certification result, but we have to think about what to do after receiving it, whether to bind it so that it cannot be changed, or whether there will be a loophole. I think bad things will happen if private service is used for light My Number Card authentication, so we need to be particularly careful about federated risk analysis. I think it will be difficult to talk about it in a separate volume, but I think it is necessary to tell that it is not that easy.
At the very least, the central ministries and agencies are divided, so there are circumstances that we do not understand, but I feel that the state of being too scattered and mixed up may not produce a healthy state.
I think it is good to add whether or not the result of authentication can be correctly conveyed to the RP as an evaluation element of the person authentication guarantee level.
The original meaning of the authenticated cooperation assurance level is that. That's why the word "external" was stuck, and it becomes difficult as soon as it becomes cross organization because it becomes a story of how to create a framework and operate it. There are few modern systems where the RP and the CSP are not separated, and I think they are separated in some way. It's just a story of OpenID Connect or Kerberos. I think the first step of the authenticated cooperation level is to talk about how trustworthy the protocol used is.
I think we must properly respond to the definition of external IdP, and when I look at the table on page 36, it seems to say that only (2) should be suddenly selected as an external IdP. IdP is an Identity Provider, not an Identity Verification Method, so it is strange that it appears in the selection of an identity verification method.

Closing and Next Guidance

(Administration Office)

That is all I would like to discuss today. The next fifth meeting is scheduled for Tuesday, February 27, 2024. We will summarize the entire revised policy of the guidelines that we received opinions from you last time and this time, and we will bring a list of the remaining matters to be discussed. In addition, we plan to discuss some additional issues that we would like to discuss.
Thank you very much for participating for a long time and for your various opinions today. We look forward to your next visit.

()