Advisory Council for the Revision of the identity verification Guidelines (fourth 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, January 30, 2024, from 18:00 to 20:00
Location: Digital Agency meeting room and online
Agenda:
1. Opening
2. Business
  1. Discussion on issues: Proposed revision of the identity verification Guidelines
    - Revision Point (1) "Scope and Name of Application of the Guidelines"
    - Revision Point (iv) "Partial Review of Guarantee Levels and Countermeasure Standards"
    - Revision Point (v) "Comprehensive review of risk assessment process" and
    - Revision point (vi) "Expansion of reference materials and tools for risk assessment and method selection"
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))

Agenda (1) Opening and Outline of the Meeting

(Greetings and Secretariat Briefing)

Now, I would like to begin the fourth meeting of the Advisory Council for the Revision of the identity verification Guidelines. Thank you for taking the time out of your busy schedule to gather here.
While there are various specific movements related to identity management in Digital Agency, the importance of identity verification is increasing, and there is a growing need to consider international interoperability while referring to the mapping results conducted between Europe and the United States. We believe that it is important not only to simply incorporate overseas trends, including those in the United States, but also to advance discussions on our own account after grasping the progress of technology and various initiatives in a timely manner. We would appreciate your continued guidance.
There are three main points that I would like you to discuss today. I would like to ask for a discussion on the points of revision of the identity verification Guidelines, which are under consideration.

Agenda (2) Discussion Points for Revision of the Guidelines

Revision Point (1) "Scope and Name of Application of the Guidelines"

The secretariat explained the results of the current study on revision point (1) based on Appendix 1, and experts held a free discussion.

(Expert Opinions)

Does this mean that a unified standard will be created to provide the same level of identity verification as applicants for administrative procedures?
- Secretariat: We recognize that the identification of Although it is still under consideration whether it can be completely matched, we are considering whether equivalent standards can be applied. As NIST SP 800-63-4, which is used as a reference, has a similar policy, we are considering whether this guideline can follow it.
Are there any RPs that are expected to target administrative workers?
- Secretariat: We recognize that the identification of internal administration are assumed as the main RPs.
I think it would be a good idea to expand the scope of application. However, there is a clear difference in the expected risks and scope of impact between public services and internal services, and I believe that the description should take into account the difference.
I felt that there was a slight discrepancy between the revised Guidelines and the revised Guidelines, which seek to exclude corporations from the scope of application. It is assumed that the identity verification for corporations to carry out administrative procedures and the identity verification for corporations engaged in administrative work will be similar, so I think it would be better to separate the categories of employees and contractors.
- Secretariat: We recognize that the identification of The identity verification for the outsourcing business operator assumes the identity verification of the workers as natural persons who actually use the system. If the outsourcing business operator requires the identity verification as a corporation, it is assumed that the Guidelines for Corporations to be separately developed will be applied.
In the case of targeting individuals viewed through business operators, since business operators should view individuals on the premise that a certain level of screening has been done when hiring them, I do not think that government agencies will conduct identity verification from scratch, and I felt that it would be better to separate that part.
- Secretariat: We recognize that the identification of We believe that this point needs to be considered in the future, but there is no intention or purpose to tighten the identification confirmation of the current contractor by this guideline. On the other hand, we recognize that there are many cases where the person in charge is authenticated in the case of paying out the system account to the contractor, and we assume that it will be applied to such cases.
In that case, I agree.
I was wondering if this part was written on the assumption 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 public, so I was a little concerned that the description did not emphasize that.
I also felt that PIV would be included in the scope. I think it would be consistent with the policy of tightening the Identity Assurance Level 3 on the premise of adoption for extremely important use cases. In addition, if the purpose is to unify and enforce internal regulations on security such as the account issuance process and authority management determined by each government agency and system, I felt it was appropriate.
Do you assume a case where a private company conducts a identity verification using this guideline and the government accepts the result?
- Secretariat: We recognize that the identification of Currently, we do not expect that.
In the provision of services, I believe that there are parts that cannot be separated between individuals and corporations, and I felt that the policy of excluding corporations from the scope in this revision was abrupt. Is there any reason?
- Secretariat: We recognize that the identification of Although I gave a misleading explanation, I assume that the company will be sorted out under a separate guideline.
In that case, what is the chronological relationship with the revision of the Guidelines?
- Secretariat: We recognize that the identification of and identity verification Guidelines. However, if the preparation of the Guidelines for Corporate Clients cannot be completed in time, we will not be able to simply go out of scope.
The users of services can be individuals or legal entities such as schools or organizations, and we naturally understand that there are other elements that come into play. FIDO's approach to Enterprise Attestation also distinguishes between the issue of privacy for individuals and the difference in the sense that the company controls it, on the assumption that the company or organization has identified its employees. However, without some kind of bottom line, it will be lost, so I felt that it is important to keep it to the minimum in 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 least at the time of revision so that the guidelines will not be discontinued.
I understand that the identity verification of a corporation involves difficult issues, but I think it is necessary to take an approach of setting a goal and reaching a conclusion by that timing, rather than putting it off because it is difficult.
- Secretariat: We recognize that the identification of We believe that the comments received from everyone have important implications. The current guidelines are strongly conscious of each specific means of certification, such as the gBizID and the Commercial Registration and Certification Bureau, and rather than certifying legal entities themselves, we recognize that the content is closer to the identity verification for natural persons, such as those in charge of procedures at companies. In order to be consistent with the guidelines of other countries, we believe that it is a theme that should be considered along with confirming the attributes such as the organization to which they belong. In addition, I believe that you are correct in pointing out that leaving legal entities out of the scope of the guidelines may create a blank space. Since the current guidelines were issued, the situation has changed, such as the use of My Number Card in legal entities' procedures and the hurdles to introducing multi-factor authentication, especially in small and medium-sized companies. We recognized that it is necessary to carefully describe and explain the background of changing the scope after sorting out such environmental changes.
Personal identification and personal authentication are two different things. I think the concept of the strength of authentication required at the time is almost the same for individuals and employees. To say the least, the concept of privacy is different. On the other hand, personal identification differs from that of individuals in that it is based on the premise that companies and organizations adopt personal identification for employees and then confirm the relationship with the affiliation. By comparing modern concepts, I think there are things that can be done during the remaining period, so I think it is better to consider as much as possible rather than suddenly excluding corporations from the scope.
Within OpenID Connect for Identity Assurance, there is a profile called Authority Claims. The first thing I talked about when designing this is that the subject of authentication is only individuals, and how to express the relationship between individuals and corporations as attributes. If we can properly express that relationship, it will naturally fall within the scope of this time without being removed. In the UK, the registration information of corporations is disclosed as open data in a database called Companies House, but how to link that data with individuals is the design concept of Authority Claims. I think 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 the scope to the relationship between individuals and corporations, we will not have to discuss removing the scope.
When I think about it from the perspective of the subcontractor, I felt that it would be difficult to expand the target to subcontractors and temporary employees who belong to different "organizations". In terms of the authority to allow which person to do what work, it may be possible to control it.
In Japan, due to the background of employment regulations, there are cases where employees of subcontractors are in charge of important operations. I believe that the reality is that the background check, which should have been done like in the United States, has been omitted because no serious problems have occurred so far. On the other hand, there is also an arrangement that confirming the identity of the counterparty in the service contract itself is a compliance issue, so I think it is a very difficult issue.
- Secretariat: We recognize that the identification of Corporation is referenced by gBizID and other organizations, we recognize that it cannot be completely eliminated. We would like to keep the Guidelines in the form of a separate volume at least equivalent to the contents of the current Guidelines, but the granularity of the description will be significantly different from that of the main part, so we will continue to consider when to update it.

Revision Point (iv) "Partial Review of Guarantee Levels and Countermeasure Standards"

The secretariat explained the results of the current study on revision point ④ based on Appendix 1, and the experts held a free discussion.

(Expert Opinions)

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 part is defined within the current guidelines, and the blue part is extracted as a threat for which countermeasures should be considered while referring to the NIST document and the U.S. CISA guidance on phishing resistance in this revision.
What are the threats described here for real-time phishing, multi-factor authentication fatigue attack, and SIM swap, respectively? Also, when classifying from Level 2A to 2C, there is no description of which method corresponds to which level, so please tell me about it.
- Secretariat: We recognize that the identification of Rear time data type Phishing refers to a type of phishing attack in which a fake site is prepared and the authentication information entered into it is relayed in real time. I think this is a kind 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 the two-factor authentication. Multi-factor authentication fatigue attack refers to a type of attack in which a large number of requests are sent to an Authenticator application that authenticates only by pressing the OK button, aiming to falsely authorize a legitimate user to log in. SIM swap refers to a general attack that steals someone else's SIM from the process of reissuing the SIM when it is lost.
- Secretariat: We recognize that the identification of As for specific examples of Level 2A to 2C methods, FIDO-based or PKI-based certificates are assumed to be used as Level 2A methods that can prevent real time data type phishing. Multi-factor authentication As for Level 2B methods that can prevent fatigue attacks, a type of Authenticator that requires a number to be entered at the time of authentication is assumed, and OTP using SMS is assumed for Level 2C.
In order to prevent SIM swapping, it is essentially necessary to take measures at the time of identification, not at the time of authentication of the person in question, so I felt it was strange to include it in the table defining the authentication assurance level of the person in question.
There is a clear difference in strength between the methods explained as the assumption of 2A to 2C, so I agree with the policy of subdividing the certification assurance level of the person in question.
In the black part of the threat on page 22, there are "man-in-the-middle attacks" and "replay attacks," but I thought that there is no method that can prevent these attacks but cannot prevent real time data type phishing. Also, it is technically difficult to prevent "session hijacking," and I think that there will be no Authenticators that can be supported.
Considering that the guidelines are also referred to by the private sector, I was a little concerned about whether the three categories from Level 2A to 2C were subdivided in consideration of the possibility of adoption and the burden, or simply from the viewpoint of the necessity of defense, and whether the standards and granularity were not aligned, including the talk about session hijacking earlier.
- Secretariat: We recognize that the identification of The black parts in the table are from the current guidelines, but we recognized that the definitions need to be clarified and updated. In addition, we recognized that the points that the black parts and the blue parts (additional parts) are not consistent in terms of granularity and that there seems to be a contradiction in the descriptions as a problem, so we will once again organize and clarify the types and definitions of threats to be used as a standard here.
When NIST SP 63-63-3 was issued, there was a wide range of definitions for the terms in black, 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 phishing that is not so and to make readers aware of it, so I think it is good if it can be adjusted by reviewing the definition of the term. 800
When NIST SP 800. 0-63-3 was published, I felt that there was a clear difference in the level of understanding and maturity of countermeasures in this area. At that time, the document stated that tamper-resistant devices would be fine, but now it is common to understand that it is out if a cookie is defrauded by session management after authentication is completed, and NIST SP 800. 0-63-4 also adopted the expression "Attacker-in-the-Middle." It is necessary to suggest that there are attacks that cannot be prevented even if the defined identification assurance level and personal authentication assurance level are achieved. There is no doubt that the moment of authentication is important, but I feel that it is dangerous that this method seems to solve all threats.
If it is a proprietary channel, I think there are cases where countermeasures can be implemented, so there is no problem with recommending countermeasures, but I think it is difficult to make it mandatory.
Although it is logical to break down the authentication assurance level from 2A to 2C, from the viewpoint of the Verifier, there is probably a problem with how a certain authenticator determines the appropriate level. There are some FIDO authenticators that require fingerprint authentication and others that do not, and I don't think it is possible to distinguish between the Authenticator application that unlocks the lock after face authentication and the one that simply displays a number.
I have a different opinion on that point. There should be a wide range of choices in terms of whether or not biometric authentication is required to achieve Level 2A, and I feel that there is too much fragmentation of detailed authentication elements.
In this case, we thought that a registry of authentication keys would be required, and that users should be able to see which authentication keys are mapped to which levels.
I understand that opinion, but I don't know how much I need to understand. For example, passkeys have different specifications depending on the company that implements them, and there are many cases where it is not known whether users register and use biometric authentication as an authentication method. Even so, the personal authentication guarantee level can be achieved at 2A in all cases, so I don't think it is necessary for implementation.
That may be the case with FIDO. On the other hand, when it comes to software-based authenticators, I think there is a lot of variation.
If you use a registry to manage how that authentication happens, I thought you could manage 2A through 2C as well.
In relation to this, there is a description of HW token in level 3, but I don't think HW token with bad quality is good. NIST is talking about HW with FIPS 140 level 2 or level 3 certification, right?
I think that such a restriction would be the certification standard, but I feel that it comes down to the problem of how the RP knows that it has really been certified by that.
I think it has to be guaranteed by the CSP.
The authentication key relationship is defined when the credentials are registered, so I think it can be implemented.
I think we need a mechanism to determine which HW tokens meet the criteria and which do not.
In addition to this meta concept, we need some guidance on how to implement it. In terms of HW tokens with Identity Assurance Level 3, at least FIDO's security keys have security certification levels from 1 to 3 +, and I think the U.S. government uses 2 + or higher, where metadata services are available to manage HW tokens.
I think it is necessary to subdivide it from 2A to 2C, and when we subdivide it, we can separate the authentication keys into each level, and I think it should be written that management, authentication, and verification for the authentication keys are also necessary for level 3.
If it is not written in a state where it can be mapped properly, it cannot be implemented.
You are absolutely right.
I think this discussion is a very large part of the capabilities and requirements of traditional trust frameworks. It needs to be well described. Also, I think that if the government has control over the participating CSPs, it can manage and limit the authenticators, but in the case of accepting private CSPs, the design of the trust framework should be very important. It is easy to promote it in a closed world like academia, but in the case of the government, it will be providing services to the people, so I think how to control the CSPs will be a big challenge in terms of implementation.
In that sense, there is a wide range of Level 2A FIDOs and passkeys, and there are differences depending on the implementation. In the past, they were mainly implemented by OS platform vendors and manufacturers, but recently, vendors that provide so-called password managers have started to provide passkeys, and it has been announced that users have a wider range of choices.
On the vertical axis of this table, there should be an evaluation axis that the metadata service is registered, that is, the Authenticator is managed.
We talked about level 3 HW, but FIPS 140-2 is pretty good, and common criteria evaluation and assurance level 4 + is pretty good. However, FIDO and others have been discussed, but the Restricted Operating Environment is very important. Is it good to use Arm's secure element, or is it bad without a dedicated secure element, or is it good if it is an implementation backed by Apple's Secure Enclave? I think it is a troubling point that we cannot talk about HW strictly in a horizontal manner. However, in reality, there are some places where people think these are generally the highest level and use them, so I think it is necessary to take care of how to handle gray areas that are not reflected in the NIST scale.
The same story comes up in Level 2, where NIST is pessimistic about the issue of not knowing if the Authenticator is truly a local authenticator. Some of the Authenticators work with just a tap, others do fingerprint authentication, and unless you know what it is, the Authenticator will be interpreted as not doing a local password or biometric equivalent. On the other hand, considering real time data type phishing resistance, there are cases where an attack that cannot be prevented by a two factor OTP can be prevented by a one factor type that works only with an Authentication Intent tap with the FIDO Authenticator, so I thought it would be a good idea to consider these cases when discussing local authentications.
There may be some subtleties in the classification of single elements and two elements. There are cases where a good single element is superior to a bad two elements.
Apart from the security key for the tap, FIDO credentials, which are attached to a single gesture such as a PIN, pattern authentication, or biometric authentication on a smartphone, are two elements of a single gesture as far as the FIDO Alliance is concerned. They are not only knowledge, but also a combination of the user's operation or biometric information and the possession of credentials, so I think it is better to clearly state that they are not single elements and distinguish them.
There may not be such an implementation anymore, but there must have been a time when the smartphone Authenticator could authenticate without entering a PIN, so what is happening now? I think it is OK as long as it is bound to the point where the keystore will work with the HW and will not be protected if you don't enter a PIN, but I think it is currently gray. At least in NIST SP 800-63-3, it was clearly written that I should be pessimistic, and I understood what I wanted to say, but I thought that I had no choice but to interpret it that way. I think it is what will happen to 63-4.
I think there was a lot of talk from the solution provider side, and I think the solution provider can identify the guarantee level of the solution they provide if they are subdivided and have criteria, but I was concerned about whether the requester can specify the subdivided level such as 2A or 2B. In the flow of analyzing risks and determining the guarantee level to request, I am worried about whether we can have a resolution that can classify administrative procedures from 2A to 2C. Of course, the guarantee level and the risk correspond, so each level should be derived from the point that this risk should be dealt with or accepted.
It is known that two step authentication using OTP of SMS or e-mail and authentication using FIDO are clearly different in terms of how damage is caused, so I think you should consider it positively.
I think that the practice of saying that level 2 is good will be major. If we break it down from there and color code it, I think we have to convey the effect to readers. I think there is a possibility that an industry-wide 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 it is OK to lean forward and say, "2A is effective."
From the point of view of effectiveness, I think it is important to write in levels that readers can understand. In today's material, I think it doesn't have to be the same level 2 for 2A and the rest. To put it in an extreme way, I think it is enough to set only passwords at level 0, and drop 2B and 2C to level 1, or make it a total of four levels, and so on.
Even 2C is effective in reducing the number of incorrect logins. In a service with a huge number of accounts, it is possible for someone to set a similar ID and password and be mistakenly logged in. Even 2C level can prevent such incorrect logins by including two step authentication.
I think it would be a good idea to add the wrong login as a threat. There was a case where a family member logged in with the same browser and the husband accidentally donated a large amount of money using the wife's account.
There can be several patterns, such as staying logged in or logging in to another account.
It is an important event, though it is a difficult part to understand.
Again, the effect is clearly different between 2A and 2C. In 2B, Microsoft has recently changed the Authenticator to an input type, and is clearly conscious of making it resistant to it. I think the vertical items should be reviewed, but I think it will be quite good. Then, what is the meaning of separating 2A and 3? In fact, I think there is little need to be tamper-resistant, depending on what is included in the credentials of the implementation to ensure phishing resistance. I told my partners at an early stage that secure elements are not necessary for that purpose. It is called Restricted Operating Environments, but it is protected by HW, but the software that operates it is running in the user space, but it is sometimes enough. Then, in many cases, it does not have to be level 3. How should I explain it?
I think the problem is that there are no threats written in this table that would make a difference between 2A and 3. Originally, the tamper-resistance was supposed to cover such threats as stealing physical devices and analyzing chips with an electron microscope.
In a system like My Number Card, where the credentials contain basic 4 information, of course you would have to put them in tamper-resistant devices, and if the credentials are random strings that have no meaning at all, I think there is little reason to be tamper-resistant. I think it is better to clearly write down the threats to distinguish level 3 and 2A.
With ISO/IEC 29115, there are threats such as duplicate credentials, so you can distinguish between them. On the other hand, if you don't say that it is HW-only, it will be covered there. In addition, if I write the lending and borrowing of credentials, if I have to deal with it at level 3, probably real-time biometric authentication will be required and I will be able to distinguish between 3 and 2A.
If we use the traditional expression, it would be either fail-safe or foolproof, I think, and I think it's OK to make mistakes without malicious intent and with malicious intent.
Add credential duplication, borrowing and lending, and incorrect logins to this threat, remove SIM swapping, and make session hijacking mandatory. Level 2 is not possible, so I recommend it. 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 is done.
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 I think you are right, and we are planning to post as reference information that this applies to the currently popular methods for personal identification as well as identity confirmation.
You probably can't use it without operation guidance. I think it would be good to organize the classification of levels as I said before.
- Secretariat: We recognize that the identification of level, I would like to take up the matter again on the basis of the comments received.
From an amateur's point of view, I feel that it would be better to say "tamper-resistant HW token" because it would be easier for readers to understand. I thought that it was a matter of judgment whether it was better to write "Required" or "Recommended" at this level as a supplement, or to write "Please observe for the time being" even if you don't understand the meaning even if you read it.
You are absolutely right, and in that sense, I asked you what 2A to 2C are. NIST SP 800 63-4 should have synced passkeys, which should correspond to 2A in this table. It is accepted that the credentials are phishing resistant, including going outside the devices, but it is clearly different from 3. I think it will be easy to do if the way is written properly.
I think there is a high possibility that there will be something to declare in the near future, so I think it will be easy to understand. It is easy to understand that it is declared with a certain security level that it is okay even if it is dropped, so I understand that there is a gray zone of 2A and 3, so I think it is good to think that it will move to the 3 side with the times.
It will change with the progress of technology, but I think it would be good if it is arranged that there are implementation examples like this at each stage of the level.

Regarding revision point (v) "Comprehensive review of the risk assessment process" and revision point (vi) "Expansion of reference materials and tools for risk assessment and method selection"

Based on Appendix 1, the secretariat explained the results of the current discussions on revision points (v) and (vi), and experts held free discussions.

(Expert Opinions)

Until now, I think we have been discussing on the premise of regulating CSPs operated by the government, etc. In the case of recognizing that an external IdP meets the government's standards, whether to accept the certification result of the external IdP as it is or to make a certain reservation is a bit of a consideration. For example, if the government intends to create and operate a trust framework, I think that the use of an external IdP is not a tailoring but a system that wants to use it should be included in the framework, so I was a little wondering if they were thinking that far, and listened to the explanation.
- Secretariat: We recognize that the identification of We have not been able to consider an accreditation system or a trust framework for external CSPs. In addition, we need to confirm whether it is within the scope of these guidelines in the first place. At this stage, we are thinking at the level of assuming that we can respond as much as possible to cases of collaboration with the private sector that are expected in the future.
What is the definition of external IDPs here? NIST SP 63-63-3 states that protocols between CSPs and RPs that are not in the same tightly-coupled system are governed at the federation level, so it is not limited to external IDPs, but includes IDPs within the government. Based on this point, I think it is better to define what is described as external IDPs in this document. 800
- 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 separate organizations within the government, so in that sense, we used the expression external IDPs. As you pointed out, we recognized that we could not consider IDPs within the same organization and system, which were implemented for loose coupling.
I feel very uncomfortable to include the concept of federations in the tailoring, so could you please explain why you decided to do so?
- Secretariat: We recognize that the identification of government agencies, if the decision to use an external IdP was made first and risk assessments were conducted, it is possible that there would not be an external IdP that would guarantee the required level. In that case, we thought it would be more natural for the reviewing side to determine the guarantee level first and use it if there is a government IdP that meets the conditions.
I don't think many people think about the case where the same entity uses CSP in a systematic way. For example, even if there is only one IdP and one RP in an independent system in the same department of the government and there is a problem in the protocol between them, I think it is the spirit of NIST SP 800-63 that if you require the certification assurance level 3, you should also adopt the certification linkage level 3. Considering that, I think it is too late to include it in the tailoring part.
When I talked about federation before, I think there was a discussion about whether it was a means or a protocol. In defining the identity assurance level and the personal identity assurance level, how to judge the reliance on external results must be included, and I agree that it is too late in the timing of tailoring.
Leaving aside whether the tailoring process will be a hit or not, I don't think it is strange that the discussion of federations and IDPs comes up in the selection of methods, and I think it is necessary to start with risk assessments and identify the necessary level before judging whether federations can be established. I think that the available IDPs have been decided in advance, but I didn't think it was strange that the options of implementing on our own or relying on federations were flatly listed. I thought that it was certainly the case in the upper part of the table on page 36, and I thought it was a story about whether to join the trust framework or not, or a story about taking care of IDPs by evaluating them including themselves.
I also thought that the use of external IDPs should be considered at the timing of risk evaluation rather than tailoring.
I think that when you decide what to think about, you decide where to think about it. I understand that the idea is that the required identification guarantee level and personal authentication guarantee level are decided and someone may take care of it. If the RP itself does nothing and relies 100% on the IdP, including the process, I don't think there is any particular problem. However, in the pattern where the RP originally has an ID and PW and ties them together, or the pattern where the IdP is used as a means to order identification cards instead of as a method of authentication, the protocol of the federation is determined technically, but it may vary depending on the use, so I think that apart from the timing of consideration in the first half or the second half, if a federation is to be conducted, a risk assessment should be properly conducted for the federation.
Commenting on the "risk identification" part, I wonder if there is a connection between the risk assessment and the impact assessment. Spoofing and credential borrowing are listed as possible risks, but the results are all combined, so I did not understand how the results of risk identification affect the risk assessment. I felt that it was 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 tied to the degree of risk impact. We assume that the results of risk identification in 3.2 will be used not only for risk assessment but also for selecting methods in tailoring.
Since the result will be the same, I feel that it is difficult to judge on a risk basis whether it was a loan or a theft.
I don't think it's a problem to describe them separately in order to distinguish them as triggers of events, but I think the resulting risks are the same.
I think it is related to the addition of the evaluation item of the person's certification assurance level that was mentioned earlier.
It is more business-related, and there is a story that you can be hospitalized for impersonation as a result of lending or borrowing an insurance card, but I think that such a risk analysis is quite difficult. It is possible to figure out the types of risks by distinguishing them, but to be honest, I don't know if I should let them create that much. Originally, this is supposed to be done by administrative officials and business operators who support them, so I think it is quite difficult.
My organization is also having some difficulties with federations, and I have learned from past experience that it is important to evaluate the other party correctly when federating with an external party. For example, under the organization's rules, phone numbers cannot be easily changed once they are linked, but partner companies can change them. There are threats that we did not notice in prior discussions, and I think it is really difficult to evaluate them. If anything, I would say that the term tailoring, depending on the time, is a nuance that I can understand, but I think it is very difficult as a risk evaluation. I think it is necessary to conduct a very careful risk analysis for ID linkage. Even if you maintain a certain level, if the other party does not work, there is a possibility that a problem will occur, and I thought it would be better to write down what to do as a countermeasure.
Considering that the Guidelines may be referred to by the private sector, I felt that it would be better to explain that there is an option of a federation that relies on others in order to reduce the burden of consideration. At a much earlier stage, I felt that it would be better to write that the Guidelines should be read with this idea in mind.
I think we have learned from the past that we need to be especially careful when there is a difference between the level of assurance required by the RP and the level of assurance provided by the IdP. I think the pattern of relying 100% on the IdP is fine, but in other cases, it is fine to receive a high level of certification results, but we have to think about what to do after receiving them, how to bind it so that it cannot be changed, otherwise there will be loopholes. I think that bad things can happen when My Number Card is used to certify a light private service, so we need to be extra careful in analyzing the risks of federations. I think it is difficult to talk about it in a separate volume, but I think it is necessary to tell them that it is not such an easy thing.
At the very least, the central ministries and agencies are also divided, so I think there are circumstances that we do not understand, but I feel that a situation in which there is too much confusion and mixing does not create a healthy state.
I think it would be good to add whether or not the result of certification can be correctly communicated to the RP as an evaluation factor for the certification assurance level of the person in question.
The original meaning of the certification linkage assurance level is that. That's why the word "external" stuck in my mind. When it comes to creating a framework and how to operate it, it becomes difficult as soon as it becomes a cross-organization. There are few modern systems where the RP and CSP are not separated, and I think they are separated in some way. It's just a matter of OpenID Connect or Kerberos. I think the first step of the certification linkage level is to talk about how reliable the protocol used is.
I think that the definition of external IdP should be dealt with properly, and when I look at the table on page 36, it seems that it is written to select external IdP suddenly only in ②. IdP is Identity Provider, not Identity Verification Method, so it is strange to appear in the selection of identity verification method.

Closing and Next Announcement

(Secretariat)

That is all the matters that I would like to discuss today. The fifth meeting will be held on Tuesday, February 27, 2024. I will summarize the entire policy of revising the Guidelines, which I received your opinions on last time and this time, and list the remaining issues for consideration. In addition, I will discuss some additional issues that I would like you to discuss.
Thank you very much for your long participation today and for all of your comments. I look forward to working with you again in the future.

END