Advisory Panel on identity verification Practice Issues, Examples, Methods and Guidelines (first meeting in FY 2025)

Last Updated:: Nov 6, 2025

We will hold a meeting of experts to formulate a commentary for 's "DS-511 Guidelines on the Treatment of Digital Identity in identity verification in Administrative Procedures, etc." , which has been developed as one of the Digital Society Promotion Standard Guidelines.

Overview

Date: September 30, 2025 (Tue) from 18:00 to 20:00
Venue: Digital Agency meeting room and online
Agenda
1. Opening
2. Agenda
  1. Explanation of the meeting guidelines
  2. Discussion on the contents of the guideline manual (draft)
3. Adjournment

Material

Attendees

Tatsuya Kano (Foundation and Identity Principal Engineer, Mercari, Inc.)
Satoshi Goto (General Manager of RCS Development Department, DX Business Division, Data Management Headquarters, Toppan Edge Co., Ltd.)
Natsuhiko Sakimura (Representative Partner, NAT Consulting LLC)
Amane Sato, Professor, National Institute of Informatics (Director General, Digital ID Infrastructure Research and Development Center)
Takashi Niizaki (CEO, Cedar Co., Ltd.)
Akihide Higo (Director of TRUSTDOCK Inc.)
Naohiro Fujiei (Representative Director of OpenID Foundation)
Takafumi Masuo (Associate Professor, Faculty of Health Data Science, Juntendo University)
Toru Minai (Deputy General Manager, Market Research Office, Innovation Division, Japan Credit Bureau Co., Ltd.
Koichi Moriyama (Chief Security Architect, NTT DoCoMo Inc.
Member of the FIDO Alliance Executive Council Board and Chair of the FIDO Japan WG
Board Member, W3C, Inc.

Agenda (1) Explanation of Meeting Guidelines

The secretariat provided an explanation based on Document 1.

Agenda (2) Discussion on proposed contents of the Guideline Manual

Regarding "Specific Examples of Identification Methods"

The Secretariat gave an explanation based on Document 2, and experts held free discussions.

(Expert Opinion)

Is the column inserted between specific examples of identification methods?
- (Secretariat) In consideration of readability, we would like to post it in a form that is close to the related method.
You mentioned that federation will be added as a new item in the main part of the Guidelines. Don't you intend to summarize specific methods and points to consider in the Manual?
- (Secretariat) We have today's meeting on the subject of identification and authentication, but the actual commentary will also cover federation.
It is said that revisions will be made in a relatively short period of time, but for example, how long and what kind of procedures will be carried out, and will the operation be described in the guidelines themselves? I think it would be good if it is made clear how to deal with the case where a vulnerability is found in some method and the method is adopted.
- (Secretariat) Although there was no plan to include the operation of the revision in the guidelines themselves, we would like to consider it after receiving comments.
There are various methods listed, but I think it would be better if we could take a form that allows us to choose from the requirements, rather than using a Yes/No chart.
For example, I think it would be a good idea to introduce a document that has the function of verifying the applicant, such as a residence card or passport for foreign nationals.
The actual My Number Card on page 12 Regarding the privacy of the auxiliary AP, there is "nothing in particular", but it is written that selective disclosure is possible for those equipped with smartphones, so I think it is a consideration for privacy that selective disclosure is not possible for physics.
There are cases where it is written "less than Level 1" on page 38, but it seems that it should not be used. It is okay to use it, but shouldn't it be written that applicants must be verified? Is it correct to assume that there are no cases in which Level 0 is used in administrative procedures?
- (Secretariat) In the sense of administrative procedures, it is assumed that there are almost no procedures that do not require identity verification, but it is assumed that there may be cases where Level 0 is used for general administrative services not limited to administrative procedures.
To what extent should such cases be included in this guide? If the anonymous case corresponds to the one described here, it is better to write it as such, and if the goal is to push it from level 1 to level 3, I feel that it is better to change the way of writing what to do if it is less than level 1.
Regarding the smartphone credentials on P48, it would be better to write that "the issuance status is correctly managed" rather than that only one is issued. Whether it is one, two, or three, I think it is more accurate to say that the issuer knows when, where, and who issued it. For example, in the US example, when issuing multiple MDls, the guide says that multiple MDls should be carefully managed. It is not strictly limited to one, but essentially, it should be in a state where it is known that it has been issued to the person in question.
In the case of batch issuance of eID in eIDAS, is it one eID? In the future, when multi-devices become the norm, I think that there will be no problem if a person's key is found in multiple devices and is bound there. Of course, we must recognize that the risk of borrowing and lending will increase.
I think that whether it is one sheet or not also means that it is written distinctively. I think that is what is meant by the fact that natural persons can only have one account in financial institutions services. I think that is what is meant by the fact that natural persons can only have one account in financial institutions services. Even in My Number Card If you try to install it on another smartphone when you install it on your smartphone, it will be deleted from the one that was installed until then. Of course, it is important to manage it, but whether it is one sheet or not will be important in various situations in the future.
In the area of mailing and confirmation of arrival at the address, I think that the case of having the identity verification document mailed and mailing the confirmation code to that address, which is written in the example, is not often seen in practice. Although the order is reversed, I thought that it would be a good method to mail an application form from an administrative agency with a key-like number, address, name, etc. printed on it, and have the applicant add a postscript, sign it, etc., attach the identity verification document, and mail it to confirm arrival at the address. In the private sector, this method is a practical way to check with a list of applicants.
How did you define "identity verification" in the DS-511? In order to uniquely identify the applicant and confirm its existence, for example, when using a Public Personal Authentication, serial numbers should be sufficient and attribution information should not be required. In essence, I think that what is said to be identity verification is to establish the attributes necessary for the business process. I think it would be better to clarify a little more about what I am saying here and why I am writing a guidebook of identity verification.
Regarding the issuing process of the original credentials, for example, mDL in the US, there is a problem of how much it can be trusted. Even if it says that it contains a digitally signed image, for example, if it is a morphed image, it means that two people can use it. Is it okay not to write anywhere about the risks at the time of issuance of the identity verification document? Since Japan is a country that regards official documents as having been established authentically, it may be said that it is correct, but in the US financial institutions, etc., the issuing process differs depending on the state, so I think that we need to make additional confirmation of how reliable it is. Since those that issue mDL do not take responsibility, financial institutions are thinking to that extent.
In August of this year, NIST published NISTIR 8584, which is a guideline for government agencies. At the time of publication and at the time of identity verification, there was a suggestion to consider morphing. In the past, there were places where measures were taken in a way that was not widely publicized. However, since such a suggestion has been made, it may be better to share the fact that there are such attack methods in the training of the implementation personnel, for example, in the column.
When it comes to countermeasures at the time of issuance, the only way is to take photos by live capture or at a reliable photo booth, which is a controlled environment. It may be difficult to do it right now, but I think it is possible to include the fact that it is better to consider such things here.
I think it's good to say that you can't have complete trust.
- (Secretariat) I think there are some ways to deal with how to be aware as a verifier. I think the scope of this document is to model how a verifier should be aware of the fact that it is easier than ever to shape facial images in various places, including deepfakes, and what kind of attacks can be expected. However, it is difficult to estimate that the ID card has been subjected to a morphing attack.
It is related to who reads the guidelines, but if you want to organize the issuers of the documents properly, you can think of a separate document that organizes the identity verification documents issued by various places including local governments.
The accreditation requirements for QEAA Providers in the European Digital Identity Framework are similar. In My Number Card, for example, there are usually people who have not changed their address.
If you just want to uniquely identify something, an identifier should be enough, and if you want to take an address instead, there should be a business behind it that requires you to take the correct address.
- (Secretariat) We recognize that some are done as a legal obligation, while others are done for receivables management and risk management.
For example, on the front page of the Nikkei the other day, it was said that financial institutions match the list of electric power companies.
If that's the case, I think we'll end up talking about what a correct address is.
In other words, it is necessary to properly understand the limitations. When there was no My Number, the address in the basic 4 information was part of the identification, not the residence. Now that there is a My Number, the person who receives the address must think about what it is and how to use it, which I think is perfect for the column.
On P33 and P34, the face-to-face verification part of the photo identity verification document talks about doing training, etc., but even if we spend a lot of money and work hard, the assurance verification level will be 2. It is a method that takes a lot of time and effort, and as I heard that fraud and falsification of ID cards are becoming more sophisticated, I think it is better to just write that it is better to use the other methods in the first part as much as possible without actively adopting this method.
I think there will be a way to combine face-to-face checks with machines for forgery detection. On the other hand, I think the earlier story about the face-to-face check app being better than that is being shown. In private sector, would it be more compatible or would there be a shift to placing tampering detection machines at counters and checking, or having the person in charge of each counter use the face-to-face check app?
I think there will be a transition, and I see a lot of potential in technology, being able to validate on a smartphone.
The main part is normative, and the main part is an informative guideline for administrative procedures. Is the scope of this guideline also the same? I think it would be good to describe the scope at the beginning of the guideline, such as whether it is useful for the private sector or whether it includes not only natural persons but also juridical persons.
In light of laws and regulations / ministerial ordinances and others, I think it would be better to write about what needs are met by what is written here. If the relationship with laws and regulations and ministerial ordinances etc. were written in the guidelines, I think it would be a very user-friendly guideline.
In relation to this, while I feel that there is a possibility in the scene where the electronic certification for user identification is used, I understand that if the combination of checking the application at the electronic certification for user identification and collecting the basic 4 information satisfies Level 3 in DS-511. However, unfortunately, there is no description in laws and regulations, ministerial ordinances, etc. that it can be said to be an equivalent identity verification. Isn't it better to write that there are situations where it can be used depending on the purpose, but it cannot be satisfied depending on the purpose?
Identity verification using electronic certification for signatures is often said to be equivalent to registered seals in real My Number Card, My Number Card for iPhones, and upcoming My Number Card for Androids, but some teachers say that the purpose is basically to sign with non-repudiation included, so it should not be done carelessly. In that case, in these guidelines, I think we should carefully consider whether it is Level 3, which actively recommends this method, or whether it is better to stop using registered seals. Aside from whether it is a column or not, I think it is better to touch on such points.
Regarding the issue of the face-to-face confirmation of photo identity verification documents, I don't think we can make it to Level 3 because it can actually make a difference. Therefore, I think it would be better to clearly state that there is a limit rather than actively saying that the drill should be done.
As a verification method for identity verification on P7, "Reference to reliable information sources" is included. I think this is good to have, but it is written "by QR code, etc." as a means of realization, so I wonder if it will be really reliable information.
On page 8, it says "face-to-face check of appearance, non-face-to-face check of appearance or by PIN number", but it is hard to tell whether it is face-to-face or non-face-to-face check of appearance or PIN number, and it should be both, so I think it would be better to correct it consistently with the person behind.
I have been saying for a long time that it is not something to be signed with level 4 certificates. It is a privacy conservation, so it is better to write it in the privacy section. There are many parts that say nothing in particular in the privacy section, but taking unnecessary information is definitely a privacy conservation. If so, I think My Number Card's superiority of iPhones will become clear.
The Public Personal Authentication Act is mentioned, but I think it is better to mention the Electronic Signatures in Global and National Commerce Act as well. It is said that it may fall under the act of signing, and in that case, the subject of the signature must be revealed, which is certainly a point to keep in mind. Also, I think it is better not to be mistaken as it recommends using electronic signatures for authentication.
I feel that the order and structure of the methods should be devised. The order of publication seems to be in the order of recommendation.
In practice, there should be no need to implement only one method. There are 10 methods listed as candidates, but I think it is better to have a list that is easy to understand when choosing one from another and when the requirements are like this. For example, if you are thinking of doing a job called level 2, I think it is better to show it by filtering those that correspond to level 2.
- (Secretariat) In the actual guidelines, we will reconsider the order and presentation method. We will also consider explaining how to select the method.
Auxiliary input of items on the face of the card on page 11 I think that the use of auxiliary AP is quite limited on the premise of obtaining My Number. For example, I think it would be good to cut out a pattern to be used in combination with the electronic certification for user identification.
All of the methods from 1 to 9 are based on the premise that a person has a identity verification document with a face photo. I thought it would be good if there was a description of a person who did not have a certificate with a face photo in the column.
The part of "Mail to be received only by the addressee" only refers to the specified matter transmission type, but there must be other patterns, and some people may not know the details, and the names are mixed with legal and non-legal ones, so I would like you to explain that point.
My Number Card's method is the main one, but some driver's licenses, residence cards, and special permanent resident certificates also contain IC chips and are allowed to be used when they are lit under laws and regulations. This method using IC chips is one of the two methods used instead of the photographing method in the world of criminal law, so I think it is good to think about how to express this.
The photo in the license is a controlled environment, so I think it is useful when you need to match the photo, in other words, when you want to be resistant to borrowing and lending.
Even if it is limited to administrative procedures, the administration must decide what to accept. If so, the certification process will run, so I think it would be better to secure an administrative agency. Even if it does not go as far as certification, I think the Japanese version of the mDL or digital student ID could be a little higher. I think it may be worth thinking about ID that works on mobile in particular.
From the description on page 48, I think that this guideline does not exclude it as long as the authority is solid among the things that enter the smartphone.
In the past, anyone could update their resident record and there was no checking of the address on the updated resident record, so all certificates were based on self-declared data.
NIST SP 800-63 is also primarily a identity verification for Credential Issuing, so you should be aware of what the identity verification is for.
It says that additional appearance checks will be conducted when necessary to respond to borrowing and lending, but as a reader, I think you may be wondering what methods of appearance checks are actually available and how strong they are. If you understand the entire guideline, you will understand it, but I think it would be good if it is written in one place. For example, in a face-to-face conversation, the strength is different when comparing the appearance with the information acquired in the face-to-face app and when comparing the appearance with what is written there when you are given a My Number Card. In a non-face-to-face conversation, I think the appearance check written here that can be used in a non-face-to-face conversation is only level 1, 9. It says that it is better to check non-face-to-face appearances, but I was wondering how exactly to do it.

Regarding "Specific Examples of Person Authentication Methods"

The Secretariat gave an explanation based on Document 3, and experts held free discussions.

(Expert Opinion)

There is a description about the account recovery method in the Points to Note Regarding Passkeys, but if the account recovery method is a vulnerable method, it is the same even if other authentication methods are introduced, so if it is described in the passkey part, it should be described in other parts as well.
One thing to consider when using a synchronous passkey is that it depends on the passkey provider. If the passkey provider is compromised and your service is affected, you need to consider how much responsibility you have to take, whether you have to guarantee everything, or whether the platform will have it, so I think it should be mentioned as a consideration. In addition, there is a risk in the case where the cloud service account is compromised, so the risks and considerations of synchronous passkeys and device-specific passkeys are very different. If the reader is the user rather than the implementer, it would be easier to distinguish synchronous passkeys and device-specific passkeys in the manual.
In the area of identity verification, there was an opinion that it would be better to have a chart and to consider the order. Here, too, there is level 1 of password authentication after level 3, and level 2 after that. I feel a bit strange in terms of what is recommended or not recommended, so I think it would be better to devise a structure.
As a difference between one time passwords and passwords, there is a point that passwords are easy to cause wrong logins. By adding one time passwords, wrong logins will be reduced overwhelmingly. It is very useful in terms of privacy, so I think it would be better to write it from that point of view.
Regarding the user identification section, I think it would be better to write it in an easy-to-understand manner because there are questions about how My Number users of the actual My Number Card and My Number Card for smartphones use it from the users' point of view.
Regarding passkeys, what I've heard recently is that there are cases where proper identification is not performed in the scene where a passkey is set, and a third party sets a passkey equivalent to the victim's passkey on the attacker's smartphone, so I think it should be written as a precaution.
Both the synchronization passkey and the device fixed passkey are resistant to phishing, and I think it is good to express the details appropriately according to the position of this guideline.
The real My Number Card is supposed to have no privacy considerations, but X. 509 certificates have no Unlinkability, or Linkability, so that's where it should be.
It is good to use a passkey with the understanding that it can be shared, but some people do not know about it, so I think it is good to add it.
In the section on password authentication, it is stated that "encryption keys are not used," but passwords are sometimes called weak cryptographic keys, so you should check whether this is accurate. Also, P26 clearly uses encryption keys (seeds) for TOTP.
I recognize that the use of P14 by holding it over the reader is the second time to hold it over the reader after verifying the user's identity, but isn't it necessary to include the concept of time? Is it really bad when you use it continuously for a short period of time? It may be a problem with session management.
Regarding the password on P24, there are opinions such as "Do not require different mixed characters" or "Do not require regular changes," but I understand that this does not raise the level of security. The other security questions mentioned are not good, but I think it is better to change the nuance of mixing and regular changes.
- (Secretariat) Some things should not be implemented and some things should not be forced. Secret questions are prohibited because they increase the attack surface, but the ones that are mixed should not be forced and should not be used. We will review it.
Regarding the sending of email verification codes, after all, there is demand for using email verification codes for the purpose of automatically forwarding or sharing emails. In the field in administrative agencies, there are still cases where employees do not have one account, and there are cases where such people forward personal smartphones because they cannot use them in the organization. I would like to see educational content that shares that level of understanding and shows rule-based responses.
- (Secretariat) I understand that there may be automatic forwarding of appropriate emails, account sharing. The wording will be improved.
Unauthorized forwarding is not allowed. If you don't have a proxy account, your secretary may look at it for you.
While NIST SP 800. 0-63 does state that passwords should not be forced to change on a regular basis, I think the exception to this is for shared accounts. ISO/IEC 27002 states that requiring frequent changes is a bad idea, but it should be considered as a kind of shared account, and it should be changed when members change, and even if it is forgotten when members change, it should be limited to that point by regular changes.
With the one time password method on P28, e-mails and Short Message Service are written in parallel, but I think Short Message Service is a higher level. The risks described are as they are, but I think it is better to look as if there is a difference there. RCS, which has an official account system, may also be an option.
Regarding usability considerations in P11, I think that it is not very usable to read the My Number Card every time the user is authenticated, even if the user's identity is confirmed.
In the case of sharing multiple terminals described in P20, a passkey installed in a smartphone while using a PC can be used to authenticate a person by reading a QR Code and connecting via Bluetooth. In this case, even if a PC is shared among family members, the moment that person is using the PC, authentication can be performed on that person's smartphone. This is called a cross-device use case, which uses CTAP, but I think it can be used effectively in situations other than passkeys. If this is used, My Number Card credentials can be installed only on one smartphone, but I think an era will come when My Number Card can be performed on a PC using identity verification credentials installed on a smartphone. When thinking about this, the expression "difficult to use in cases where multiple users share terminals" seems to cover various possibilities, so I would like you to consider how to write it.
There was a lot of talk about the moment when authentication is performed, but I think it would be better to include in the guidelines about session management after authentication is completed, such as disconnecting the session if it is compromised.
Regarding phishing resistance, channel binding and verifier name binding are described, but to be honest, few people can read and understand them. If anything, I think it would be easier to understand if I made a list of those that are not phishing resistant. Password random number recovery is a matter of course, but Push modification and email magic link are also methods that depend on the user's attention. As the OTP says, I think it would be good to explain in more detail, including the fact that the type of characters to be sent is not a number but a letter, that the number of possible numbers is large, and that different input methods are not phishing resistant.

Adjournment

(Secretariat) Thanks to you, the revised version of DS-500 successfully passed the Meeting for the Promotion of a Digital Society Executive Meeting today, and although it was a long process, the new guidelines for Digital Agency have been established. What you are considering this time is exactly what will breathe life into this. Public interest in passkeys and phishing resistance, including card-substituting electromagnetic records and the problem of securities fraud in the world, is increasing very much, so I would like to issue these guidelines in a flexible manner. Thank you for your continued cooperation.

END